Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
#784672: Allow text field to enforce a specific text format finally landed in core.
As commented there in #299, this module should provide an upgrade path now. I see that D10 compatibility was releases as a new major version, that wasn't actually required, it's fine in regards to BC and semver to increase min version of requirements as long as your own API doesn't change.
It's a little bit awkward now, because for this, it really does make sense to have a new major version. So we have a major version for exactly one minor core version :) The idea is to remove all code related to the allowed formats setting and add an update function that moves existing configuration to the core setting.
For extra awkwardness, not all functionality of this module is in core yet, see #3323007: Add an option to 'hide filter guidelines' on text fields, so we can't remove that yet unless we also get that issue into core for 10.1.
Steps to reproduce
Proposed resolution
- Create an upgrade path for a site builder to migrate their allowed formats settings into Drupal core's settings
- Remove the allowed formats feature from this contributed module.
- Rename the module to Hide format info (former Allowed Formats)
- Update the project description to Hides info about the selected text format. The 'allowed formats' functionality has been moved in core since Drupal 10.1.0.
- Update the README.md explaining these changes.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork allowed_formats-3324446
Show commands
Start 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
Comments
Comment #2
berdirI'll look into providing a patch here if nobody beats me to it, but I'll wait a bit to see where that other issue goes.
Comment #3
moshe weitzman commentedSo lets offer a 3.x branch that has the upgrade path?
Comment #4
berdirYes, "lets" do that ;)
That was my proposal, the problem is just that we still need 50% of what this module does, I guess it's unlikely at this point that the referenced issue will get into 10.1. So we have a 3.x that makes allowed_formats really a hide_format_explanation.module, and then maybe a 4.x for a future core version that also removes the need for that bit with another upgrade at which point the module is no longer needed.
Comment #5
klemendev commentedI agree 3.x with the missing 50% in the core would be good idea
Comment #6
pcate commentedThis sounds like a good path forward for this module. I just updated a client site to D10 and having two sets of "allowed formats" settings on fields is confusing for site builders. But we still really need the hide tips/guidelines functionality.
Comment #7
scotwith1tSeems like this functionality should not have rolled out in core without coordinating with this module to provide that new version/upgrade path. Current users of this module are now confused/penalized by having 2 sets of these checkboxes in the UI and existing field config data stored by the contrib module until an upgrade path is figured out. Will keep an eye on this, for sure.
Comment #9
claudiu.cristeaI’m working on this
Comment #11
claudiu.cristeaReady for review. Also, as per #4, we need a followup in Drupal core to move also the "hide explanations" feature to core.
Comment #12
claudiu.cristeaOuch, I see now there's #3323007: Add an option to 'hide filter guidelines' on text fields
Comment #13
berdirVery nice, with tests and everything! ;) This was on my list, but didn't get to it yet. Added some comments.
Comment #14
claudiu.cristeaHm, just saw now that testing is not enabled for 2.x :( It would be good to see tests here
Comment #15
berdirTested a bit on our project, seems to work fine. As mentioned, the idea is to commit this to a new 3.x branch.
Comment #16
claudiu.cristeaI’ve tried to contact the maintainers but got no answer so far. To summarize:
Comment #17
luke.leberThis all looks awesome overall.
One question -- is the
allowed_formats_field_config_presavereally needed? I don't believe that I've seen this pattern before -- even in core data updates. It seems to be pretty widely understood that running database updates is an important step in the CI/CD/manual upgrade process.Definitely not a blocking review, and can easily be removed in 4.x whenever core adopts the pending widget config settings. I'm more curious from a learner's perspective than anything.
Comment #18
berdirYes, that is in fact the pattern that core is mostly using, See my review comments which also mention an example.
Comment #19
acbramley commentedRan this update on our project with over 50 formatted text fields and all updated as expected, great work!
Comment #20
claudiu.cristeaComment #22
claudiu.cristeaComment #23
claudiu.cristeaWill cut a 3.0.0-alpha1 release to be evaluated by the community
Comment #24
tgoeg commentedI can confirm the set allowed format (a reduced HTML set) for a text field was properly migrated over after updating to 3.0.0-alpha1 and performing an
updbstep.And I can only use the allowed format afterwards.
So it works as it should from my side, thanks!
Comment #25
cedeweyUpdated the agreed upon resolution so it's easier for people to understand how this issue was resolved.
Comment #26
claudiu.cristeaI think the project page needs also an update, same as for the README but I have no permission to do that
Comment #27
chrissnyder3.0.0-alpha1 worked for me and was able to update to Drupal 10.1's built in allowed_formats setting.
Comment #28
claudiu.cristeaI've released 3.0.0 and added there release notes about this important change. I've also added those explanations to the module's front page https://www.drupal.org/project/allowed_formats