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.Once /includes is fully converted to PSR-0, there'll be no need to scan it with the registry, since all classes will be loaded by the Symfony autoloader.
So... we should make sure we actually stop doing that before release. Critical task seems about right.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | registry_no_includes.patch | 437 bytes | catch |
| #8 | registry_no_includes.patch | 422 bytes | catch |
| #1 | registry_no_includes.patch | 412 bytes | catch |
Comments
Comment #1
catchThis patch might be enough.
Comment #3
Crell CreditAttribution: Crell commentedAgreed, although obviously we cannot do that until the current classes in /includes that rely on the registry have been migrated. Therefore marking as postponed. (Can something be critical and postponed? :-) )
Comment #4
pounardYes if it depends on another critical issues :) Fix the core so that it won't embed any scanned classes first.
Are you planning on porting DBTng to 5.3, this will the hardest task IMHO (call this madness, but I already tried @home, it's easy but very long).Saw that you actually opened a bug for this, nice.EDIT: IMHO clean separation between procedural code and new OO code, physically I mean, seems more natural, sounds odd that all lives in
includes/. I like theliborlibraryname for the folder containing the OO code, pretty much as a lot of other framework do.Is there an issue for that?
Comment #5
catchThere's no issue for /library but if we wanted to do something like this, we should open that issue soon (i.e. before we create includes/Drupal).
Comment #6
pounardI'm actually asking if you want to do something like this. It definitely feels more natural to me, but it might not to other people.
Comment #7
catchI'm not sure if we should or not, it's the sort of thing that could be discussed in the issue ;)
Comment #8
catchTwo classes left at last count, re-rolled and running this past the testbot again.
Comment #10
catchOh dear.
Comment #12
franz#10: registry_no_includes.patch queued for re-testing.
Comment #14
catch#10: registry_no_includes.patch queued for re-testing.
Comment #16
Berdir#10: registry_no_includes.patch queued for re-testing.
Comment #17
BerdirYay, passed!
I guess there isn't much to discuss anymore then. Should be RTBC.
Comment #18
chx CreditAttribution: chx commented/me weeps quietly. Let's do this, yes. Let's rewrite Drupal completely.
Comment #19
catchI won't weep when me move #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap back to 7.x because it's no longer relevant in Drupal 8. It's much easier to convert every core class to PSR-0 than it is to fix that bug properly.
Comment #20
chx CreditAttribution: chx commentedDid I say otherwise? Surely it's easier to rewrite everything from ground up than fixing bugs. Just why will we call this Drupal?
Comment #21
catchI don't think the choice of class autoloader is what makes Drupal Drupal or not, especially since we didn't have a class autoloader until Drupal 7.
Comment #22
Crell CreditAttribution: Crell commentedThe comment of mine that chx links to is not definitive. Fortunately my fear was not entirely founded, and was based on the grotesquely poor documentation for PSR-0 that was only understandable by someone who was already used to using similar class loaders. (It's improved a bit since then.) My worry was that you couldn't have multiple roots within a single project, which would have broken modules rather catastrophically. Fortunately, I was wrong about that.
Comment #23
catchCommitted/pushed to 8.x.