Timing on bootstrap [#1839420]

Follow-up on #1838194: Premature calling of list_themes() (caused Fatal error)

XAutoload tries to be clever when deciding what to do at which time.
E.g. it tries to have the boot modules already available, even while the other modules are still loading.

Problems:

1. Extensions remembered.
Once we find out that a module or theme does not exist, we remember that for the rest of the request, even if at a later time that extension becomes available.

2. Classes remembered (APC cache).
If xautoload (via class_exists) finds that a class does not exist, the APC cache remembers that for the rest of the request (or even longer), even if at a later time that class might be available.

I think the second issue only applies to APC cache.
And I think we should worry less about it, because this seems like the common behavior of class loaders.

Comments

Comment #1

donquixote CreditAttribution: donquixote commented 14 November 2012 at 05:10

I have an interesting approach in 7.x-2.x-dev, to switch from "bootstrap phase" to "main phase" ...
http://drupalcode.org/project/xautoload.git/blob/refs/heads/7.x-2.x:/lib...

Still I would like a better indicator than module_exists().

Comment #2

donquixote CreditAttribution: donquixote commented 11 February 2013 at 09:27

And now I changed it all again for the 7.x-3.x branch..

Instead of the plugin + DrupalExtensionSystem solution, I am back to explicitly registering all module namespaces and pefixes. Doing it otherwise was stupid.
Instead of system_list() and friends, I simply query the system table. It works fast enough in my tests, it can be done in early bootstrap for all modules in one go, and I hope it is equally reliable.
Besides, we now have the xautoload.early.inc that can be included in settings.php for very early class loading. And even if at this time we use the non-apc-cached loader, we can switch to the apc-cached one later on.

Comment #3

donquixote CreditAttribution: donquixote commented 11 February 2013 at 18:40

system_list() vs db_query():
That's a tricky one.
- drupal_get_filename(): If you move a module into a different folder, xautoload classes in this module will no longer be found until you clear the cache.
- system_rebuild_module_data(): If you have the same module in two places (possibly with different version), and Drupal decides that it wants to look in the new location, xautoload will still look in the old location.

I have an interesting idea to fix the first...
The second probably can remain as it is, because we might already have included files from the old location.

Comment #4

donquixote CreditAttribution: donquixote commented 12 February 2013 at 19:54

Funky funky solution in 7.x-3.0-alpha5:
Whenever we find that a registered directory does not (or no longer) exist, we call the plugin registered for this case, and ask it where the directory might have moved.