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
In #2551549: Deprecate per-table prefixing we deprecated the use of per-table prefixes under multisite.
Since this behavior will be unsupported in Drupal 9, users should get early warning if their site is based on this technique during the Drupal 8 lifecycle.
Proposed resolution
Add a hook_requirements() warning that this type of table sharing will go away soon.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3022403
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:
- 3022403-warn-users-about
changes, plain diff MR !1143
Comments
Comment #2
mile23See comments about dropping support for per-table prefixes, which prompted the creation of this issue: #3004496: Document best practices for multisite and composer
Comment #3
mile23As a minimum first step, linking to the CR.
Comment #4
mile23Comment #5
berdirAdding a trigger_error() should be easy, just check for it being an array.
That said, that would result in dozens/hundreds of those deprecation messages for anyone who actually has that, because if it happens, it is a global sitewide thing that won't be easy to get rid of, you can't just update some code but likely have to rearchitecture your site. Assuming someone actually managed to make this work reliable, which I very much doubt, which is why we deprecated it in the first place.
Given that, not quite sure if a @trigger_error() is the right approach here. Maybe a requirements hook similar to the php version would make more sense?
Comment #6
mile23Diggit. Updated IS.
Comment #10
mondrakePer-table prefix is theoretically deprecated since 8.2.0, but not enforced practically. That would be done by #3106531: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0, which is now postponed on this issue.
Comment #12
andypostI think about warning message at status page
It could be done in this issue for 9.2
To unblock #3106531: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0 for 9.3.x
Comment #14
daffie commentedIn #3106531-103: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0 and #3106531-109: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0 the release manager @catch made the decision that there will be no trigger_error() for the deprecation of per-table prefixing. Therefore having a seperate issue for adding a hook_requirements() prior to 9.3 and adding a trigger_error() in another is no longer necessary. Therefore closing this issue.
Comment #15
mondrakeComment #16
mondrakeChanged to MR workflow and pushed a first commit taking hunks from current patch at #3106531: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0
Comment #18
daffie commentedTestbot is not happy.
Comment #19
mondrakeLooks like we cannot do the hook_requirements check in isolation.
UpdatePathTestBasedoes for instance write a $database entry in settings.php as part of its setup; that has a 'prefix' as an array, and test update fails on the new check. So one way or another we need to adjust also other code. But that's what #3106531: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0 already does in a more complete way and I am not going to reinvent that here.Comment #20
mondrake