Bug #55773

Consistent look for the element browser in RTE and link input fields

Added by Tymoteusz Motylewski about 5 years ago. Updated 6 months ago.

Status:
Closed
Priority:
Should have
Category:
RTE (rtehtmlarea + ckeditor)
Start date:
2014-02-07
Due date:
% Done:

0%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

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.

diagram.png View (90.5 KB) Tymoteusz Motylewski, 2014-02-07 18:42

link_browsers.png View (481 KB) Tymoteusz Motylewski, 2014-02-07 18:42

typo3-linkmodals.jpg View (402 KB) Riccardo De Contardi, 2017-04-02 17:56


Related issues

Related to TYPO3 Core - Bug #55782: RTE Image Wizard with white space above tabs Closed 2014-02-07
Related to TYPO3 Core - Bug #55946: RTE Image Wizard layout is inconsistent Closed 2014-02-13
Related to TYPO3 Core - Bug #55951: RTE Link Wizard layout is inconsistent Closed 2014-02-13
Related to TYPO3 Core - Task #71840: Style linkhandlers with Bootstrap Closed 2015-11-25

History

#1 Updated by Stanislas Rolland about 5 years ago

  • Category set to RTE (rtehtmlarea + ckeditor)

#2 Updated by Stanislas Rolland about 5 years ago

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.

#3 Updated by Tymoteusz Motylewski about 5 years ago

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.

#4 Updated by Mathias Schreiber about 4 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Mathias Schreiber

Hey Tymoteusz,

any progress here?

#5 Updated by Tymoteusz Motylewski about 4 years ago

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.

#6 Updated by Alexander Opitz almost 4 years ago

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

#7 Updated by Tymoteusz Motylewski almost 4 years ago

Definitely this is still an issue :)

#8 Updated by Alexander Opitz almost 4 years ago

  • Status changed from Needs Feedback to New
  • Assignee changed from Mathias Schreiber to Stanislas Rolland

I'm assigning it to Stanislas.

#9 Updated by Riccardo De Contardi almost 3 years ago

  • Target version set to Candidate for Major Version
  • TYPO3 Version changed from 6.2 to 8

No more for 6.2, I guess. That's why I switch version to 8.

#10 Updated by Riccardo De Contardi almost 2 years ago

I attach a screenshot with the situation on v. 8.7-dev (latest master)
On the left: all the link types (I used header > link); on the right: the modal for CKEditor

The last row is a linkhandler example.

#11 Updated by Tymoteusz Motylewski almost 2 years ago

  • Status changed from New to Resolved

#12 Updated by Benni Mack 6 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF