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.
This issue and following patch is related to the drush / command line part only, since we don't use the php-cli / script part and can't guarantee it will work as expected, but it should be possible to port the patch easily.
Drupal 8 and its API moves quickly, so current version of rr is no longer compatible with it. We have tried to fix all issues until it worked again with current Drupal 8 head/master, since we include both Drupal 8 and Registry Rebuild by default in every Aegir instance installed with Barracuda/Octopus.
Comment | File | Size | Author |
---|---|---|---|
#3 | D6_Aegir.jpg | 133.1 KB | omega8cc |
#3 | D7_Aegir.jpg | 132.89 KB | omega8cc |
#3 | D8_Aegir.jpg | 132.87 KB | omega8cc |
#1 | patch_commit_9ab82d07a618.patch | 5.77 KB | omega8cc |
Comments
Comment #1
omega8cc CreditAttribution: omega8cc commentedPatch attached for review - available also: https://github.com/omega8cc/registry_rebuild
Comment #2
rfayThanks so much! If somebody will just rtbc this after testing on 7/8 I'll commit. Would appreciate testing that it isn't broken on 6.
Comment #3
omega8cc CreditAttribution: omega8cc commentedJust to confirm that since we use it in the Aegir environment, and we have even modified Aegir to always run `drush rr` as a part of every clone, verify and migrate task, we have tested it also with many D6 and D7 sites to make sure it works as expected. See attached screenshots.
Comment #4
rfayIt sounds like you have already become a maintainer of registry rebuild, with that kind of investment in this.
May I add you to the committers?
Comment #5
omega8cc CreditAttribution: omega8cc commentedI'm happy to help as a co-maintainer/committer, thank you!
Comment #6
rfayThanks! You have full privileges, so feel free to commit this when you think it's ready (I think you know it is already :-)
Thanks so much for your effort on this!
Comment #7
omega8cc CreditAttribution: omega8cc commentedDone. Thank you!
Now I need to port this to the php-cli / script part before marking as rtbc/fixed.
Comment #8
rfayPer #1790592: Drop separate php-file support and switch to drush-only?, it might be reasonable to drop the separate php version.
Thanks so much for your effort on this.
Comment #9
omega8cc CreditAttribution: omega8cc commentedI fully support this idea. Thanks!
Comment #10
rfayIncluded in 7.x-1.9.
@omega8cc, when committing, please post the link (or hash) to the commit. Thanks so much for your work on this!
#9 was http://drupalcode.org/project/registry_rebuild.git/commitdiff/2c9288e
Comment #11
omega8cc CreditAttribution: omega8cc commentedRight, I totally forgot about it here, sorry.
Comment #13
omega8cc CreditAttribution: omega8cc commentedDrupal 8 is not supported at the moment, at least after it dropped the old registry stored in the db tables.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedCould you at least make it so that I can use the latest drush for d7 and d8 without the need to have two drush verison installed just to have compatible "modules" in them?
Comment #15
omega8cc CreditAttribution: omega8cc commentedLatest supported Drush version is 6.4.0, but even if we didn't port Registry Rebuild to D8 yet, we could look into supporting at least 7.0.0 Alpha4, sure.
Comment #16
cferthorneyNow the API's for Drupal 8.X are more stable given we're in beta testing, is it worth looking to rework this so it will work with Drush 7.x and 8.x ? I would offer to start work on it myself but haven't studied the underlaying architecture changes yet for D8 to be confident of succeeding in the time I have available at the moment.
Comment #17
omega8cc CreditAttribution: omega8cc commentedRegistry Rebuild works with Drush 7 (at least up to rc2), even if it couldn't support Drupal 8. Then Drush 7.0 dropped Drupal 8 support entirely.
Drush and Drupal 8 are still going through drastic changes, versions support deprecation, which makes it really hard to follow without locking yourself in some not really acceptable alternatives. See for example what a mess this still generates: https://github.com/omega8cc/boa/issues/729
The problem is that for extension like Registry Rebuild, which is expected to be backward compatible and focus on supporting production sites, this kind of rapid and drastic changes is just not something we would like to follow too quickly.
D8 is formally in beta, but it is far from being safe from further drastic changes which will propagate and affect Drush, and thus also extensions like Registry Rebuild.
At the moment we can't even easily test D8 support, and even Drush 7 newer than rc2, without adding some experimental and temporary options in the BOA stack.
I think we need to wait a bit until we could safely open 8.x branch, without going through incompatibility/deprecation cycle too early.
Comment #18
dawehnerIMHO registry rebuild doesn't really make sense for Drupal 8, as there is no such thing as a class registry anymore.
Comment #19
omega8cc CreditAttribution: omega8cc commentedWe first need to make
rr
Drush 8 compatible (which is easy), and then it may still be useful, because in Drupal 8 there issystem_rebuild_module_data()
instead of D7 specificregistry_rebuild()
or D6 specificmodule_rebuild_cache()
. There is still some registry in Drupal 8, just not for classes. Who knows, why not to make it easy to testrr
with Drupal 8, so people could decide if it is still helpful.Comment #20
omega8cc CreditAttribution: omega8cc commentedComment #21
dawehner@omega8cc
I'm curious whether drush rr though matters for that? Doesn't drush cr solves the same kind of problem?
Comment #22
omega8cc CreditAttribution: omega8cc commentedIt depends. The
drush cr
does exactly whatdrush rr --fire-bazooka
does. So it is a very aggressive, D8 specificdrush cc all
, plussystem_rebuild_module_data()
invoked viadrupal_rebuild()
->drupal_flush_all_caches()
chain, with many other things included.Maybe in Drupal 8 only this type of
--fire-bazooka
mode makes sense, I don't know. Maybe it could be useful to have a less aggressive option to run justsystem_rebuild_module_data()
with only related caches purge, without smashing all caches, css/js aggregates etc. I don't know. Why not to try this? For backward compatibility we could even makedrush rr --fire-bazooka
a wrapper fordrush cr
in D8. Why not?Comment #23
rfayI think that the fact everybody is used to drush rr as a default "get out of hell free" card is worth something. It's probably just worth making it do everything it can do.
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedIf you delete module without uninstalling it drush cr is not enough. So yeah, rr is still needed imho.
Comment #25
colanIf that's the only reason we would need it, why not just add that functionality to drush cr?. Then we can deprecate this "module" in favour of Drush core. I don't believe in the philosophy of keeping a module around just because it existed in a previous major version of Drupal. Let's try to reduce the number of moving parts, not create more.
Comment #26
omega8cc CreditAttribution: omega8cc commented@colan It was discussed in the past and the idea was rejected by Drush maintainers -- see:
#1447272: Incorporate drush rr (Registry Rebuild) into drush as native command
https://github.com/drush-ops/drush/issues/1744
Comment #27
colanNo, I was responding to this:
Don't add rr to drush. Add code to help with deleting a module without uninstalling it to cr.
Comment #28
omega8cc CreditAttribution: omega8cc commented>> Add code to help with deleting a module without uninstalling it to cr.
How is this different from adding registry_rebuild to Drush? You are talking about adding stuff to Drush, no? They don't want it.
Furthermore, adding rr-like improvements to Drush (it is not going to get added to cr, which already does too much to be effective like rr) would mean that PHP script method is no longer available, while there are still people who benefit from this, because not every host comes with SSH/command line access, perhaps.
Also, rr is not just about issues related to "deleting a module without uninstalling" -- there is different Drush extension for this, while rr is about fixing problems when changing paths to *existing* modules etc. breaks the site.
Comment #29
jonhattanFor the record, drush cr is just a wrapper of Drupal 8's
core/rebuild.php
Comment #30
omega8cc CreditAttribution: omega8cc commented@jonhattan -- Yes, I know, but it seems that it could be still useful to have an alternative which does (and requires) less than
core/rebuild.php
to fix problems caused by path changes in the codebase contrib space. We still need to test if this assumption makes sense.Comment #31
omega8cc CreditAttribution: omega8cc commentedRegistry Rebuild always worked with Drush 8, we just need to make it work with Drupal 8, even if it will be just a wrapper for Drush / Drupal 8 specific commands, so people could continue to use the familiar
rr
, and it will do its best, without requiring to learn Drupal 8 specific stuff for this task.Comment #32
chOP CreditAttribution: chOP at Technocrat commentedThere isn't a release branch for a Drupal 8 version of this module. Unless this patch is added to an 8.x-2.x branch it will not work as a Composer managed dependency for Drupal 8.
The following fails right now:
Nor will it likely work as a Drush install against a Drupal 8 install.
I guess with Drush you could force a Drupal 7 version to download using the following, but it will be less than ideal: