Replacement option:
Put the page path into the altnative text when hovering page tree element.

Also the DIV container is the first to wrap and in my opinion the page path does not add any value because when editing rather the module menu is minimized.

Couldn't we have an overflow style where text get hidden from the left whenever space limitation? We could have a "..." to show something has been hidden.

I like the re-styling idea of the breadcrumb menu better. Jens's proposition looks good.

I would also keep the path, but I agree that it looks ugly, when it jumps to a second line, because it is too long. Basically I think cutting some characters off, is the only solution like:

Home/My long page.../My very very lo.../Subpage for.../Page

However, this also does not always help: When you need the path, you can be sure that the important part, the one which you would need right now, is left out.

So what about putting in these three dots, when something has been cut off, but to add a hover effect, if something was cut off?
In my above example I would hover "My very very lo..." and would get the hover text showing the complete part like "My very very long title for working group A"

So: When you hover a part of the path, which has been cut off, the complete part could become visible.
Do you get what I mean?

Normal state

Hover within breadcrump area

Hover a link within breadcrump

The path is very useful if you get lost by opening a few context menus (for example, Template module, edit whole template, Includes tab, context menu for included extension template, Edit, etc.). The page tree doesn't get updated, but it's easy to get lost in the installation. The path still shows the rootline for your current record.

It's not needed very often, but it's easy when you need it. Of course it can be in a slide-in or drop down panel waiting to be used.

I would keep the page path, but I agree that the current form is not optimal at all. I like the idea of making is slide out by hovering over some icon.

I think the page path is very useful because if often happens that the page tree is not positioned on the right page (although it's getting better all the time).

I Would Prefer The combine the Solutions.
add an PageTS Option to set the PagePath display to one of
the following options: hide,foldout,show(Option names are up for discussion)

• hide - the pagepath is complety hidden for a cleaner BE-Layout
• foldout - there is an button addet to the doc-header as shown in in the screenshots from jens (Path-Overlay1.png,Path-Overlay2.png) with a click the path get shown as an overlay.
• show - the pagepath is always shown

in anycase the pagepath shoud be limited via css overflow if its too long.
and the pages should be linked.

I like the path.
Sometimes you are working on specific content, or opened content through search and don't know the pid or page name.

It's an easy way to get the two information and you can easily copy them.
I like this behavior.

If I've to choose one of the shown examples I'll prefer http://forge.typo3.org/attachments/21339/typo3_v4_4-_mai2010-01_listview-v3-02.png with pid.

First of all, I consider the page path as a useful information for reasons already mentioned from others above.

I really like the overlay idea of Jens Hoffmann.
Like displayed there and also often wished, the feature of clickable parent pages is desirable.

To Felix Kopps suggest:
Make parent page/folder clickable to open page in list view (or edit scope?)
I think the page opended in list view is the better way since this is in my opinion needed more often than editing the specific site. If you want to edit the page you can click edit page properties afterwards.

Greets,
Sebastian

To sum up.

• The page path shall not be removed.
• The single pages must be clickable to open the page (not the edit mask).
• The page path should be eight a new fly-out element or a uncropped overflow elipsis.

That already is a pretty huge improvement, cheers.

Make it behave properly in workspaces. Right now it always shows the Live path of a record and not the path in the draft workspace. The titles in draft may be different as well as the location. See http://forge.typo3.org/issues/36285 .
This is a very easy fix, I have already fixed the underlying BEgetRootLine function such that the correct paths are generated, incorporated in fix for http://forge.typo3.org/issues/39197 (under review).

Please reject the issue.

What is the status?
What is now implemented?