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.
My host is migrating to PHP5. I ran a test of my site under PHP5 and the Ad modules did not seem to work. So, my questions are:
Have any other users tested or are running the module on a Drupal installation under PHPv5? Are they any know incompatibilities or adjustments that need to be made?
Comments
Comment #1
Jeremy CreditAttribution: Jeremy commentedI develop and use the ad module exclusively under PHP 5. What specifically did not work for you?
Comment #2
rkdesantos CreditAttribution: rkdesantos commentedI get the following errors:
Configuration error, failed to lock cache file.
on the banner ad area
and this in the logs:
Comment #3
Jeremy CreditAttribution: Jeremy commentedYou are having a file permissions issue. The ad module needs write permissions in the files/ directory. These errors are telling you that it does not have the necessary permissions to lock and write the cache files.
Comment #4
rkdesantos CreditAttribution: rkdesantos commentedI figured as much Jeremy. The question is what to do to fix it? Do I need to change the ownership of the files? Is there a specific setting for the file permissions required (currently they are 664)?
Comment #5
Jeremy CreditAttribution: Jeremy commentedThe files need to be owned by the same user that the web server is running under. That user needs write permission to these files and the directory they are in.
If you're asking about how file permissions work, you may want to start by reading here.
Comment #6
rkdesantos CreditAttribution: rkdesantos commentedI'll investigate which user owns the files and change it if need be. I understand how file permissions work however PHP5 handles that differently than did PHP4 apparently.
Would it be easier to: 1) turn off file caching for the module. 2) delete the files 3) turn on PHP5 for Drupal 4) turn file caching for the advertisement module back on and let it recreate the files with the ownership it expects?
Comment #7
Jeremy CreditAttribution: Jeremy commentedFrom what information I have, it should be as simple as chown'ing the files.
Do a "ps -ef | grep apache" or "ps -ef | grep http" to determine what user it's running as. The move to your files/ subdirectory and chown the files to be owned by that user. (They should already be, as they should have been created by the web server process, but perhaps the owner of your web server process was changed during the upgrade.)
Comment #8
rkdesantos CreditAttribution: rkdesantos commentedWell, the files are owned by "noboby" and that is the owner of the apache and http processes.
Comment #9
Jeremy CreditAttribution: Jeremy commentedHow about the ownership/permissions of the customfiles/ directory? If you have permissions, the simplest way to debug this is to su to "nobody" and try touching one of those files.
Comment #10
rkdesantos CreditAttribution: rkdesantos commentedWell that might be an issue except that it doesn't bother any other module:
drwxrwxrwx 8 afana afana 4096 Apr 16 11:32 customfiles/
So I'll have to try to see what happen if I change the owner of customfiles to "noboby" or change the owner of the cache files to "afana" and see which one works better.
Comment #11
Jeremy CreditAttribution: Jeremy commentedLooking at your permissions, it seems things should be working, but obviously it's not. I recommend you su to user 'nobody' and try touching the files and see what happens.
You could try and collect more information by reviewing DEBUG.txt, following those instructions with the file cache enabled. Perhaps there will be a clue in that more verbose output.
In any case, one specific error is quite clear due to the error that you've shared:
Thus, fopen is failing to obtain 'r+' permissions.
Comment #12
rkdesantos CreditAttribution: rkdesantos commentedApparently fixed.... once the cache files were changed to be owned by my site ("afana") and not by "nobody" everything worked as expected.
Comment #13
rkdesantos CreditAttribution: rkdesantos commentedOK, the ads display correctly but we are getting these intermittent errors logged while running under PHP5:
I have temporarily disabled caching for the module.
Comment #14
Jeremy CreditAttribution: Jeremy commentedUpdating issue title to reflect actual problems.
Lot's of questions for you, please answer all of them.
How often do you see these errors? Is there any sort of consistency? How often have you configured your file cache to be rebuilt? Does this error show up each time it is rebuilt? (A blind guess, I've no specific ideas what is causing this at this time.)
Can you trigger this error manually, or on a development website? Can you review DEBUG.txt, and trigger this error with &debug=2 enabled?
Offhand, the error doesn't make much sense, as we've already validated that the tids variable is not empty. And as tids is not empty, explode() should always return an array.
Comment #15
rkdesantos CreditAttribution: rkdesantos commentedOne to three times per hour; every 30 minutes; doesn't appear to be the case that it is tied to the periodic rebuild but can't rule that out - I would have to monitor the file updates with the cache enabled to determine that.
Don't have a development site at the moment so I am not sure. How would I go about triggering it manually? By causing the cache to be rebuilt? (Which should happen if I turn caching back on).
I can try to run with cache enabled and report on the debug results if you wish. Here are the results with the cache disabled:
Comment #16
rkdesantos CreditAttribution: rkdesantos commentedHere is the debug output with the cache enabled:
Comment #17
rkdesantos CreditAttribution: rkdesantos commentedUpdated to 1.5-rc2 and problem still occurs.
Comment #18
Jeremy CreditAttribution: Jeremy commentedWhat line is the error occurring on in 1.5-rc2?
Comment #19
rkdesantos CreditAttribution: rkdesantos commentedHere's a recent clip from the error log:
Comment #20
Jeremy CreditAttribution: Jeremy commentedFix committed to development branch. Added error checking to prevent error from being dumped to screen when no ads are available in cache.
Comment #21
rkdesantos CreditAttribution: rkdesantos commentedFirst blush says that fixed the problem. Thanks.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.