Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
simpletest.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
19 Jan 2015 at 06:22 UTC
Updated:
15 Mar 2015 at 12:14 UTC
Jump to comment: Most recent, Most recent file


Comments
Comment #1
rocketeerbkw commentedThere are two messages in
simpletest.installbut I was only able to trigger the first. I'm not sure the second one will ever fire and could be removed but that's probably another issues.I expect this to break tests, but right now it takes more than an hour to run locally so I'll wait for testbot.
Comment #2
idebr commentedComment #3
idebr commentedThe error text has been changed from
./sites/simpletesttosites/simpletest. While this may be a change for the better, let's keep it out of scope of this issue and fix the double escaping first.Comment #4
rocketeerbkw commentedThanks! I added the prefix back. I've also updated the after screenshot.
Comment #5
idebr commentedI have been looking through the User interface standards but I could not find a reference on how to display paths/files. The meta issue suggests using a Twig inline template if you want to maintain markup, as documented here: https://www.drupal.org/node/2311123
I'm fine with dropping the
<code>tag in favor of the<em>tag, but I'm not sure how it affects the scope of this issue. I'll leave this for someone else to review.Comment #6
rocketeerbkw commentedI tried an inline template but it didn't fix the problem. I don't think this use case works like that. The problem that I found is that any time you use
!as a parameter int()the string system expects you to mark it as safe somehow. SoString::checkPlain()will mark strings safe if you're using it witht(), but since it concatenates<code>outside the call, the entire string isn't considered safe and it gets escaped.So option one would be to do
String::checkPlain('<code>./' . $site_directory . '< /code>')and this should fix the problem and it won't change any string translations.But this technically violates the best practices for
t(). I think according to https://www.drupal.org/node/322774 the<code>tags should be in the string itself. So something like<code>@sites-simpletest< /code>and then just'@sites-simpletest' => $site_directory;To keep the scope as small as possible, it sounds like the first option is best? It fixes the escaped HTML and doesn't change strings for translation. Then another issue for fixing the "correctness?"
Comment #7
subhojit777I was not able to replicate the problem. Everytime I am doing
chmod 444 -R sites/simpletest, after I open a new page the permission gets back to 777Comment #8
rocketeerbkw commentedOption one from #6 doesn't work (obviously in hindsight) because
String::checkPlain()escapes the HTML, but that's the problem in the first place. So I went with option two, moving the HTML into the string instead of the argument.For replicating the problem, if apache is set as the owner of the directory, it can change permissions back to the correct values. On my local install, the files are owned by my user account, and the apache user isn't in the group I have set either.
Comment #9
idebr commented@rocketeerbkw It appears there is an issue with the line endings in your patch. Can you check if your git configuration matches the recommended git settings: https://www.drupal.org/documentation/git/configure
Comment #10
rocketeerbkw commentedThanks, not sure why that got messed up.
Comment #11
biigniick commenteddouble post on accident...
Comment #12
biigniick commentedseems to be working for me.
- nick
Comment #13
alexpottConvert to an @ and remove the String::checkPlain() would work best. This is fine because nothing inside the
codetags is translated.Something like:
Comment #14
alexpottActually the file name is not code so it should not be wrapped in
codetags anyway. It should be wrapped in placeholders.This would then match
system_requirements()Plus adding the
./is weird and unnecessary.Comment #15
rocketeerbkw commented@alexpott my patch from #1 addressed your comments in #14 but it was "out of scope" according to #3.
So either #1 or #10 are ready. My vote was always #1.
Comment #16
biigniick commentedBoth #1 or #10 work for me
Comment #17
alexpottCan someone re-upload the patch in 1 so that the correct rtbc patch is the latest in the issue?
Comment #18
alexpottThis is because testbot retests the rtbc queue - only the latest patches.
Comment #19
rocketeerbkw commentedThis is the same patch from #1.
Comment #20
rocketeerbkw commentedRTBC based on #16
Comment #21
alexpottCommitted 397f4a6 and pushed to 8.0.x. Thanks!