Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
18 Jun 2015 at 06:40 UTC
Updated:
27 Oct 2015 at 03:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dave reidComment #2
dave reidComment #4
polI'm all for that.
Comment #5
dave reidWith a test now.
Comment #7
dave reidOk! No tests it is! testbot runs on PHP 5.3. :(
Comment #8
polYep, see #1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7
Comment #9
hussainwebJust a small nit and good for RTBC. The testbot now runs on multiple PHP versions. These changes won't fail on PHP 5.3 once committed. It is the PHP interpreter version used here that causes it to fail. Once the file is in, then the testbot can run on PHP 5.3 as well.
Comment #11
hussainwebOkay, it seems that the testbot changes are only on 8.0.x. Anyway, we could go ahead with patch in #2. Just a small nit:
Extra space before 'handler'.
Comment #12
hussainwebComment #13
mglaman+1. Have to use TravisCI for running tests, can't use D.o
Comment #14
David_Rothstein commentedWell we might be able to commit it with the tests (and should if we can) - as far as I can see the testbot only fails because it tries to check the syntax of all files changed by the patch:
So once this is in core (and no longer being changed by patches) it wouldn't cause tests to fail after that (in theory)... though we'd have to keep a close eye on it afterwards :)
Comment #15
David_Rothstein commented(And the reason it would be nice to is that Drupal 7 should start having multiple-PHP-version testbots in the near future.)
Comment #16
chx commentedwait a minute if a PHP 5.3 testbot fails on this highly desirable and nice patch then we can't commit it like that cos it'll fail D7 from that point on -- D7 is still 5.2 if I remember correctly. We need to find a way to not autoinclude that file.
Comment #17
David_Rothstein commentedWell the original RTBC was for #2 rather than the latest patch. But see my comment in #14 - I don't think this will fail after commit even though it fails as a patch (but we can't be 100% sure until it's committed)...
I suppose that also means if anyone needs to edit this file later the testbot will fail that followup patch too, so it's a strange situation.
Maybe there is another way to test this instead?
Comment #18
dave reidWe could commit this without tests, that would work. Otherwise I have no idea how we could get this to pass on the current bot situation and resolve this *now* for Drupal 7 and the people that desire to use traits in modules.
Comment #19
mglamanThere won't be issues so long as test bot doesn't try to use a Trait. So patch from #2 means I can use traits on projects, or on my TravisCI builds for contributed projects.
Comment #20
David_Rothstein commentedUgh, we can't do what I suggested because https://qa.drupal.org/7.x-status seems to do a PHP syntax check on every single PHP file in core. I thought it only did syntax checks for patched files.
So we may have to go with #2 for now.
Code looks OK but do we need a trait_exists() check in _registry_check_code() to match what's done for classes and interfaces?
Comment #21
Crell commentedOn behalf of 2008 me, I want to apologize for the existence of this issue. Splitting the autoloader into separate class and interface functions was a stupid idea and I don't know why I even did it. The patch in #2 seems correct, unless we want to fix that mistake and unify the autoloader entirely.
Re #20: If we're keeping the current autoloader design, yes, likely we should add that. Although... since the class/interface already existing should mean the autoloader is never triggered in the first place why do we even have that check...?
Comment #22
David_Rothstein commentedRunning the tests from #9 locally, they actually failed on PHP 5.4. This fixes that, and also renames the file to hopefully get around the testbot syntax check limitation. (It's really not something the testbot should be doing this aggressively, I think, but the testbots are changing so much these days I'm not even sure filing an issue about it would be relevant - easier to just work around it.)
The file rename using ".php54inc" is a little iffy (and I realized after I wrote it that it also means this won't be blocked by .htaccess so somebody could use this file to flood a PHP < 5.4 site with errors if you wanted to) - maybe it would be better to choose a different extension that .htaccess actually blocks. Currently the testbot does syntax checks on
.php/.inc/.install/.module/.testfiles only, so there's a lot of other extensions that could be used.Hm, good question - offhand I am not sure. Added it in the attached anyway :)
Comment #23
David_Rothstein commentedHey, looks like it worked.
This version switches to a .sh extension which I think is the least unreasonable option of the ones in .htaccess.
Comment #26
David_Rothstein commentedComment #27
hussainwebI think that both methods of masking the file extensions from testbot scanner is a bit iffy, but I think it is fine. Maybe we could add a @todo note in the .sh file to rename this back when the testbot is changed to not check every file in the source. I am thinking this could be done on commit.
Comment #28
hussainwebI just tested this on a site with Drupal 7.39. Without the patch, the trait was not found. I applied the patch, reset the registry and it worked fine. It is already RTBC and I am just waiting for it to be committed.
Comment #29
dave reidComment #30
David_Rothstein commentedCommitted to 7.x - thanks!
I added a @todo on commit based on @hussainweb's suggestion above, and also created #2589649: Rename drupal_autoload_test_trait.sh to use a standard extension once the testbot allows it: