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.

CommentFileSizeAuthor
#3 D6_Aegir.jpg133.1 KBomega8cc
#3 D7_Aegir.jpg132.89 KBomega8cc
#3 D8_Aegir.jpg132.87 KBomega8cc
#1 patch_commit_9ab82d07a618.patch5.77 KBomega8cc
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Active » Needs review
FileSize
patch_commit_9ab82d07a618.patch5.77 KB

Patch attached for review - available also: https://github.com/omega8cc/registry_rebuild

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

Thanks 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.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
FileSize
D8_Aegir.jpg132.87 KB
D7_Aegir.jpg132.89 KB
D6_Aegir.jpg133.1 KB

Just 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.

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

It 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?

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I'm happy to help as a co-maintainer/committer, thank you!

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

Thanks! 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!

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Needs review » Needs work

Done. Thank you!

Now I need to port this to the php-cli / script part before marking as rtbc/fixed.

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

Per #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.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Needs work » Fixed

I fully support this idea. Thanks!

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

Included 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

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Right, I totally forgot about it here, sorry.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Title: Drupal 8 support is broken after some API changes » Drupal 8 support
Version: 7.x-1.x-dev » 7.x-2.2
Category: Bug report » Feature request
Issue summary: View changes
Status: Closed (fixed) » Postponed

Drupal 8 is not supported at the moment, at least after it dropped the old registry stored in the db tables.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Could 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?

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Latest 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.

cferthorney’s picture

cferthorney
he/them
Primary language English
Location Huntingdon, UK
CreditAttribution: cferthorney as a volunteer commented

Now 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.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Registry 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.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner as a volunteer and at Tag1 Consulting commented

IMHO registry rebuild doesn't really make sense for Drupal 8, as there is no such thing as a class registry anymore.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

We first need to make rr Drush 8 compatible (which is easy), and then it may still be useful, because in Drupal 8 there is system_rebuild_module_data() instead of D7 specific registry_rebuild() or D6 specific module_rebuild_cache(). There is still some registry in Drupal 8, just not for classes. Who knows, why not to make it easy to test rr with Drupal 8, so people could decide if it is still helpful.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Title: Drupal 8 support » Drupal 8 (and Drush 8) support
Version: 7.x-2.2 » 7.x-2.x-dev
Assigned: Unassigned » omega8cc
Status: Postponed » Needs work
dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner as a volunteer and at Tag1 Consulting commented

@omega8cc
I'm curious whether drush rr though matters for that? Doesn't drush cr solves the same kind of problem?

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

It depends. The drush cr does exactly what drush rr --fire-bazooka does. So it is a very aggressive, D8 specific drush cc all, plus system_rebuild_module_data() invoked via drupal_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 just system_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 make drush rr --fire-bazooka a wrapper for drush cr in D8. Why not?

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

I 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.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

If you delete module without uninstalling it drush cr is not enough. So yeah, rr is still needed imho.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

If 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.

omega8cc’s picture

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

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

No, I was responding to this:

If you delete module without uninstalling it drush cr is not enough. So yeah, rr is still needed imho.

Don't add rr to drush. Add code to help with deleting a module without uninstalling it to cr.

omega8cc’s picture

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.

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
CreditAttribution: jonhattan commented

For the record, drush cr is just a wrapper of Drupal 8's core/rebuild.php

omega8cc’s picture

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.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Title: Drupal 8 (and Drush 8) support » Drupal 8 support
Assigned: omega8cc » memtkmcc

Registry 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.

chOP’s picture

chOP CreditAttribution: chOP at Technocrat commented

There 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:

composer init --type=metapackage -n
composer config repositories.drupal composer https://packages.drupal.org/8
composer require --dev drupal/registry_rebuild:*

Nor will it likely work as a Drush install against a Drupal 8 install.

drush --yes pm-enable registry_rebuild

I guess with Drush you could force a Drupal 7 version to download using the following, but it will be less than ideal:

drush --yes pm-enable registry_rebuild-7.x