Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've just noticed that (as per this issue) comment moderation tables have been removed from the installation schema.
So, what if someone installed Drupal prior to this patch and it is not using the contrib moderation modules? Those tables remain on the DB or should they be removed by a new update step?
Comments
Comment #1
killes@www.drop.org commentedThey should not be removed as we do not want to destroy the user's data. He might still need it.
Comment #2
markus_petrux commentedSorry, but then, those who don't need it end up with useless tables. An update step could check if the tables are empty or no other moderation module that may need them is active, or something...
If not removed by the update script, maybe a note in the upgrade doc could explain what to do?
Comment #3
killes@www.drop.org commenteduseless tables don't hurt anybody. :p
I agree that the update notes should list deprecated features and where to get replacements. This is also true for queue.module.
Comment #4
eaton commentedI agree -- the decision to leave the old data was explicit. 'update' should never mean 'nuke a user's old information.' removing functionality and migrating it into contrib modules is jarring enough: leaving the data there, invisible to end users, doesn't hurt anything.
Comment #5
Wesley Tanaka commentedIt sounds like #3 and #4 are saying "by design"
Comment #6
markus_petrux commentedEveryone upgrading from 4.6 will keep these tables there. If they use comment moderation, they need to know that they have to install an additional contrib module, that probably uses the same tables (I don't know, I haven't looked at this module). right? As far as there is documentation about it, no problem here.
But what if someone who upgraded from 4.6 to 4.7 was not using comment moderation, but after some time (maybe a lot of time) needs said feature. They will somehow see that they need a contrib module. Will that contrib module know how to deal with those tables? Being a contrib module, who will ensure it is consistent with the core in future? what if, what if, ugh! I mean, keeping those tables is potentially dangerous.
Wouldn't it be better to remove anything related to comment moderation from the core? It is just a defensive approach to make sure no unexpected problem happens in the future.
If not solved by the update script, which is what I thought about when creating this issue, then... it seems some kind of documentation is needed.
Is this issue useless/incorrect to remind something has to be done related to these tables? Sorry, I'm re-activating the issue 'cause I'm not sure about this.
Comment #7
eaton commentedI'm working on the contrib module. It'll use its own tables and offer an option to migrate existing data to the new table structure.
Comment #8
Uwe Hermann commentedWhat is the current status of this issue?
Comment #9
killes@www.drop.org commentedI think Eaton has updated nmoderation, not sure there is an upgrade patch yet.
Comment #10
magico commentedWhat worries markus_petrux is that between upgrades obsolete data stays in the database.
Following #3, I agree that the update system should list deprecated features and inform that "some tables" can be removed. But never do that without express consenting from the admin.
Comment #11
LAsan commentedWhat is the current status of this issue?
Moving feature request to cvs.
Comment #12
mdupontI guess we can close this issue now, the policy is to provide migration paths.