The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
#3159848: [Policy] Always install Drupal with Standard on the UI, pared down of use case specific elements (content types, node listing, commenting, theme) left the tags vocabulary in standard profile / recipe, although it is free flowing and is not attached to anything that uses it. We kept it there to manage scope. We should remove it.
Steps to reproduce
Proposed resolution
Remove the tags vocabulary.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
The standard install profile and recipe does not include the tags vocabulary anymore.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3588274
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:
compare
Comments
Comment #2
gábor hojtsyComment #3
gábor hojtsyPostponed on #3159848: [Policy] Always install Drupal with Standard on the UI, pared down of use case specific elements (content types, node listing, commenting, theme) landing first.
Comment #4
gábor hojtsyThe content types are removed on main in #3587118: Remove content types from the standard install profile and recipe, we can move on with this actially.
Comment #5
gábor hojtsyComment #7
gábor hojtsyGreen and looks complete :)
Comment #8
smustgrave commentedWish I had this applied with the comments one, but no worries. Same deal standard install no tags field.
Comment #9
gábor hojtsyAdjust parent to implementation issue from policy issue.
Comment #11
catchCommitted/pushed to main, thanks! Will need a backport for 11.x
Comment #14
smustgrave commentedI asked Gabor if it was okay I did the backport and he said sure.
This was an easy backport only issue was a single migrate test in contact.
Comment #15
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. 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 #16
gábor hojtsyWas a clean rebase with no changes required, so back to RTBC.
Comment #17
gábor hojtsyNeeds a rebase again, @smustgrave can you maybe help with this?
Comment #18
smustgrave commentedRebased!
Comment #19
damienmckennaComment #20
damienmckennaDoes this need a change notice too?
Comment #21
damienmckennaComment #22
gábor hojtsy@damienmckenna: good point, half of the related issues already had change notices. I just added a change notice to #3588276: Remove comment module dependency from standard profile and recipe and added one for this issue too at https://www.drupal.org/node/3606438 -- so far only targeted at main/12.0.0 but when it lands as backport it will also need to be added. I assume 11.5 at this point.
Comment #25
larowlanCommitted to 11.x
Updated the change record to reference 11.x/11.5.x
Thanks all.
Comment #27
gábor hojtsyI came to check if this was a standalone recipe too like the content types that caused problems with Drupal 11.4 but apparently not :) So its fine as-is for a backport I think even with the content types recipes rolled back. Thanks for landing it!