Add drush commands for developer [#2589905]

Hi there,

I'am using the xautoload as soft dependency forTwig for Drupal 7 project and yesterday I ran into some issues with cloning a site (incl. DB) on the same server with APCU support.

The xautoload_cache_prefix is duplicated to, and is not re-generated if the DB is copied obviously so the two sites used the same APCU cache ID and that resulted in some strange vehavior and random WSOD;s

To overcome this problem I was thinking to create a few drush commands and submit them as path to your project, but before I start creating them in the namespace of this module I wanted to check with you if that is something you see as a useful add-on to it.

I was thinking about the following commands:

Regenerate cache prefix
Clear all caches
Ensure production setting (aka check all boxes ;))
var dump the autoloader cache (to check if your class/file is actually included

If that something you would like, I will submit a patch, if not I will create a separate project or GIST with this drush commands and share that with the world :)

BTW, thank you for this project!.. really appreciate it, saved me time from creating and maintaining my own autoloader for TFD7 :)

Comments

Comment #1

13 October 2015 at 10:19

Rene Bakx created an issue.

Comment #2

donquixote CreditAttribution: donquixote commented 13 October 2015 at 10:55

I would say yes, it is a good idea, but maybe we should do some more thinking.

I always thought people might need some kind of rescue line, in case the cache is making problems. But I wanted to wait until someone actually reports such problems.

Maybe one problem is that the cache id is stored in the database. We could store it in APCu itself instead. But this only works for the APCu cache, not for other caches (e.g. the database cache). Maybe store it in Drupal's cache system (cache_get()) instead of using variable_get().

Also it would be nice if we could make this a side effect of existing drush commands like drush cc all, so people don't have to learn something new.

And what about people without a commandline? Maybe they can put something in settings.php?
Or maybe we should again wait until it happens.

Comment #3

donquixote CreditAttribution: donquixote commented 13 October 2015 at 10:56

Or maybe make the cache prefix depend on something unique to the site?

Comment #4

Rene Bakx

He/Him/Smurf

Dutch

Netherlands

CreditAttribution: Rene Bakx commented 13 October 2015 at 14:09

#3 was my initial guess.

I thought it was a md5 or something like that of the $drupal_hash_salt variable. Because well that should be unique to every site, and if it's not your problems could potentially be a bit bigger then a confused loader system :)

Storing the ID in APCU could be a solution, but to be honest I was looking into expanding the autoloader cache into a redis/memcached instance because on one external server I can't install APCU but I do have a memcached instance. And then it would be nice that the cache key could remain the same so the clearing of the autoloader cache would be bit more predictable.