Filter tips show up on every text field by default in Drupal. There is no way to switch it off via the UI.
#3063877: Add access control to /filter/tips adds a way to hide it (don't give anyone the permission), but I wonder if we really need it at all.
Drupal has shipped with ckeditor for years, and hand editing HTML is at best discouraged with ckeditor5.
When formatting tips are actually needed, we already provide field descriptions which site admins can edit - this would allow them to give a couple of markdown examples, link to external resources etc.
Apart from being mostly redundant, the page also looks extremely dated.
Entirely remove the functionality in a minor release of Drupal core.
Remove the 'tips' method from the interface for filter plugins, open a follow-up issue to remove it from the base class for Drupal 12.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot from 2025-02-09 09-18-00.png | 215.17 KB | catch | |
| Screenshot from 2025-02-09 09-13-23.png | 300.95 KB | catch |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !11180
Comments
Comment #2
catchComment #3
dqd+1 for raising this. My vote for it and 100% agree with the argumentation and reasons. And it would close a group of other issues. Additionally it minimizes the efforts to keep track with those tips and all possible combinations of allowed tags etc and it never really looked well seated under the textareas of body and comment fields and was kind of circumventing to style. And since we do not have any hard wired dependencies in core with this part of filter.module it would be mainly removing the respective parts in web/core/modules/filter (tips) and making sure that it does not break contrib in case that modules use tips to place their own (if any?)
And which gives far more flexibility. Also in how it looks or how it is implemented (markup). Only drawback is that it do not change it's tips automatically regarding the allowed tags when switching between formats, I worry? Maybe we should provide a token which picks up the allowed tags from the formats to be used in the field description?
Comment #4
lauriii+1 for the removal as discussed during the Burgas onsite. The content on this page isn't relevant in the world of CKEditor 5.
Comment #7
catchMR looks good so far, except I think we probably need to remove the method from FilterInterface rather than deprecate it.
We also need to remove the filter tips link from
Drupal\filter\Elementand should deprecate the route that it points to (which we can do now after https://www.drupal.org/node/3317784).There are some templates in claro/stable etc. not sure if we can remove those yet or if it would need to happen in a 12.x-only issue.
Comment #9
eelkeblokWhat is the reason for hiding the branch?
Comment #11
longwaveAre we intending to remove just /filter/tips and the "long" format of tips here, or the "short" format and guidelines as well?
If we remove the guidelines/short format, then (when multiple formats are allowed) it's not necessarily clear to end users what the difference is if they select different text formats from the dropdown.
If we keep the guidelines, we could hide them in the case that only one format is available?
Comment #12
catchI think when I opened this, I didn't realise that the ::tips() method provides both the long and short versions of the tips. The main purpose of the issue was to remove the 'long' tips.
Having said that:
This is no longer the case for ckeditor-enabled formats because you get a different toolbar depending on the configuration. But it is the case where there's no wysiwyg editor and could be pretty confusing. Although if there's only one available format, it's possible to add a description in the field config to say you can use markdown etc.
Given all that I think this issue should be about removing the $long argument from the interface method, and the route, and the link to the route. But we should open a follow-up to try to streamline the short tips behaviour too as you mentioned.
Comment #13
longwavePipeline is green, also wrote a change record, think this is ready for review.
Comment #14
catchTwo small comments on the MR, otherwise looks great!
Comment #15
longwaveResponded - I think we should leave /filter/tips working for end users in 11.x but it can go away in 12.
Comment #16
catchOK that makes sense, don't think there is anything left to do here.
Comment #17
quietone commentedComment #18
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #19
longwaveComment #22
larowlanCommitted to main and backported to 11.x
Kind of feels odd to add to main when we'll want to turn around and delete it shortly, but 🤷 this is our process
Thanks folks, glad to see this confusing feature removed, as a bonus will also confound a few fingerprinting tools that hit this open path to see if a site is running Drupal.
Here's a kitten 🐈️
Adding tag for release notes, published the change record
Comment #26
smustgrave commentedWanted to verify if preprocessFilterTips() is suppose to be deprecated? That would mean filter-tips.html.twig would be deprecated too right?