TYPO3 Core

Tymoteusz Motylewski wrote:

Link browser called from the RTE (BrowserLinks.php) looks differently than link browser triggered from any link input field (implemented in the ElementBrowser.php).
See attached screenshot - left side is RTE, right, link input field.

This situation is caused by huge amount of duplicated code between these 2 classes.
Also attached screenshot with the class diagram.

We should eliminate duplicated code and make both element browser look the same.

Not so simple. The RTE has many additional configuration options and fields for this form. But if you manage to remove some redundant code, that would be nice.

I agree that the look of the forms in the RTE is bad. This was fixed in related issue.

Whether the form should be presented above or below the trees has been discussed recurrently in the past. I would not change this without some consensus.

Thanks Rolland for taking care! Can you point me to any discussion about it.
I think backend should look consistent, so users can learn it quicker, so we should decide on one position of the form.
What I've experienced is that having form above tree is better, as most beginners don't know that they need to scroll down to set link title or sth else.

I'm working on cleaning up duplicated code in these classes (starting from init()) I'll push sth soon.

the current status is that big parts of the refactoring already made it's way into 6.2 (e.g. streamlining the init()) part.

We still need to streamline the views. e.g. Fields should go above the tree, to make them easier to find.
Also there is still a lot of copy paste code, and html and js code inside php.
The current blocker is the lack of concept, how the link/image/element browser should look and behave like.
In RTE the wizard opends in the modal (ext-js based), but for link fields it opens a new window.

some quotes from core-dev slack:
Benni Mack:
----------
no need to take on these things now. I think we need a good UI concept to get rid of them. I think the UX guys should talk about that at the UX week.

I had an idea for the element browser things... have a suggest field, which searches the different things all for one, and then a layer next to the field.

Benjamin Kott:
-------------
we had agreed that modals should only be used for small information and confirmations

the master plan for those popups is still missing - but would be nice if they would leave

they will be problematic as soon as we reach a state where we can truly use the backend on a smartphone/tablet

but i think we need to develop some kind of "magic" simplified wizards that can append to the fields and do the job without the need of big communication in modals or overlays

So what we can do for now, is to e.g. try to make the wizards look more alike (like moving fields to top). But the big changes are blocked by lack of final solution for modals.

5 Month later, I'd like to know the state of this issue, is there help needed?

Definitely this is still an issue :)