Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Upfront:
- using remotes
- migration between to platforms which are 99% the same. There is a minor code change ( update of module )
- Issue is 100% reproduceable - happens on all sites
- all sites use taxonomy_access and nodeaccess extension
When you migrate a site from platform A to B on the same remote ( and pretty sure to any other platform on every server ) the sites content is not accessable by anybody after the migration. You must rebuild the nodeaccess table ( admin/content/node-settings ) for getting it work again. Migrating the site again will have the same effect again and again. Even if the platfom stays identicly ( use the same makefile ) the nodeaccess table is still broken.
Marking as critical, as this make migration unuseable.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | accessrebuildui1.patch | 1.45 KB | EugenMayer |
| #4 | ccuid1.patch | 680 bytes | EugenMayer |
Comments
Comment #1
EugenMayer CreditAttribution: EugenMayer commentedJust to be sure, its not a dupe of http://drupal.org/node/1062070 .. because in the other issue rebuilding does not help. All nodeaccess settings are lost there ( grants table deleted or flushed ), while here they are still there but not generated correctly.
Comment #2
EugenMayer CreditAttribution: EugenMayer commentedI just tested it. After the migration i dumped node_access, rebuild permissions and compared them. It seems like the node_access table missses 80% of all entries. That smells very much again because of running stuff like rebuild as anon and not -u 1
Comment #3
EugenMayer CreditAttribution: EugenMayer commentedfixing title ( has nothing to do with a platform ). Verified it happens on site verify, making this one a huge bomb on my side..
Comment #4
EugenMayer CreditAttribution: EugenMayer commentedWell as expected, its due the node_access_rebuild with anon, which simply fails as not all nodes can be loaded due to db_rewrite_sql. E.g. term_access and og nodes are missing then.
Patch attached
Comment #5
EugenMayer CreditAttribution: EugenMayer commentedComment #6
anarcat CreditAttribution: anarcat commentedI think this patch should also be ported to the drupal5 and drupal7 engines. You seem to already have the d7 code, it just needs to be moved to the relevant file. Not sure about the d5 api.
Can you update the patch for this?
I am a bit surprised to see cache_clear_all() doesn't already operate with uid 1, maybe that patch should be sent upstream to drush?
Thanks for the catch...
Comment #7
EugenMayer CreditAttribution: EugenMayer commentediam really running low on time, esp. because of the number of other issues with aegirs ( see issue queue ) on which it seems i have to work on all on my own. I would be happy if you could add those things anarcat. Thanks!
Comment #8
EugenMayer CreditAttribution: EugenMayer commentedrerolled, added docs and D7 code.
Dont expect me to add anything for D5 - i simply dont know the API and not going to waste my time looking at the API. Its 2 releases back in time, its time to drop it.
Comment #9
omega8cc CreditAttribution: omega8cc commentedI'm not sure we should fix in Aegir something looking as a bug in the Drush itself?
Why is it running node access rebuild on drush cc, after all?
I see it was introduced here: http://drupal.org/node/655808 but maybe it should be reverted in the Drush?
Comment #10
anarcat CreditAttribution: anarcat commentedI had this conversation with webchick, and as moshe, she's also of the opinion that node_access modules shouldn't check the running user: that's the bug.
I would check taxonomy_access and node_access modules to see if they do user_access() checks or node_access() checks without an explicit uid. Checking against the running user doesn't make sense, because if you run as UID 1, then you get access to everything anyways.
Otherwise, I believe we can just skip flushing those node_access tables, unless really necessary. I will commit a fix to master and stable to make sure we don't rebuild those caches unless node_access_needs_rebuild has been raised somewhere.
Comment #11
EugenMayer CreditAttribution: EugenMayer commentedanarcat you might think about that keyword:
db_rewrite_sql
Iam pretty sure you wil discover that not a single "user check" is done in those modules. Its simply the D6 access / rewrite sql API which counterfires here.
Comment #12
anarcat CreditAttribution: anarcat commentedEugen, I am aware of db_rewrite_sql.
If the contrib modules do not check the logged in user, then they are implemented properly. If they are implemented properly, then we do not need to do special user session changes.