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.When the Devel module is enabled, the _background_process_cwdfix() function throws this error: "Warning: include_once(./includes/unicode.entities.inc): failed to open stream: No such file or directory in /path/to/drupal/includes/unicode.inc on line 339".
This led to some amusing heisen-bugs in some AJAX I was trying to debug today.
The problem seems to be related to the use of $_SERVER['PHP_SELF'] to determine the current working directory, though I haven't determined why it breaks with Devel enabled but not without. Devel doesn't apparently manipulate server variables, but it does do strange things like registering shutdown functions in hook_exit.
This can be fixed by using $_SERVER['SCRIPT_FILENAME'] to calculate the current directory instead. Patch attached.
p.s. Thanks for the great work on Background Process and Ultimate Cron. They really saved my bacon on my current project.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | cwdfix.patch | 697 bytes | gielfeldt |
| background_process_6.x-1.10_cwdfix.patch | 444 bytes | davideads |
Comments
Comment #1
gielfeldt CreditAttribution: gielfeldt commentedHi David
Glad to hear my modules are useful,
It's funny regarding PHP_SELF, because I actually started out using SCRIPT_FILENAME. However, I read that SCRIPT_FILENAME might not always be available as it is webserver dependent, whereas PHP_SELF is supposed to always be available as it is set by the PHP interpreter.
I'll look into the matter to see what the problem is and/or if I can switch to SCRIPT_FILENAME or perhaps store PHP_SELF somewhere in an earlier phase.
Comment #2
gielfeldt CreditAttribution: gielfeldt commentedHmmm... having looked at it more closely, I don't see how this cwdfix function can work at all :-)
I may have to switch to SCRIPT_FILENAME as you suggest.
Investigation in progress ...
Comment #3
gielfeldt CreditAttribution: gielfeldt commentedHi again
Could you try this patch? I've tried to adopt the Drupal 7 way of dealing with this issue.
EDIT: The reason I want to avoid using SCRIPT_FILENAME is because of potential platform issues.
Comment #4
patrickd CreditAttribution: patrickd commentedwhat about
isset($_SERVER['SCRIPT_FILENAME']) ? $_SERVER['SCRIPT_FILENAME'] : $_SERVER['PHP_SELF']?Comment #5
gielfeldt CreditAttribution: gielfeldt commentedYes, I thought about that. The problem is that PHP_SELF doesn't really work I think. It doesn't contain the full path (at least not on my system), so that's why I don't understand it has worked at all :-)
I'm more inclined to lean towards the Drupal 7 way, as this probably has been thought through (or at least I hope so :-))
Comment #6
davideads CreditAttribution: davideads commentedI will try the patch when I'm at work, which looks like the right way to go.
I don't think using PHP_SELF will work at all, as it is relative to the document root. I also remain baffled that I saw the error with devel enabled but not without. I'd say it was something to do with the error handler, but in my dev environment I've got the PHP error settings set to print darn near everything.
Comment #7
davideads CreditAttribution: davideads commentedThe new patch appears to be working fine.
Comment #8
gielfeldt CreditAttribution: gielfeldt commentedGreat. I will commit it soon. Be aware, that if you update to 6.x-1.x-dev, there are some changes that requires that no there are no cron jobs running while updating.
Comment #9
gielfeldt CreditAttribution: gielfeldt commentedCommitted to 6.x-1.x-dev
Comment #10
orjantorang CreditAttribution: orjantorang commented6.x-1.x-dev works perfect.
I had trouble on WampServer (Windows 7, PHP 5.3.4) and on one Debian server running LiteSpeed with PHP 5.2.17, but 6.x-1.10 was working perfectly on a Debian with LiteSpeed and PHP 5.3.3-7+squeeze3.
Now it's running on all my servers, thanks for a great module!