Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
After installing this module, I see the following two messages on the status page:
- Adv CSS/JS Agg - CSS Path is not setup correctly. CSS directory is not created or writable.
- Adv CSS/JS Agg - JS Path is not setup correctly. JS directory is not created or writable.
However, the permissions on the Drupal files directory looks fine, and the main Drupal file system reports "Writable (public download method)".
So is there really a problem here, or are things being reported incorrectly?
Comment | File | Size | Author |
---|---|---|---|
#10 | advagg-1997588-10-fast404-check.patch | 2.93 KB | mikeytown2 |
#9 | advagg-1997588-9-fix-drush-install-dir-permissions.patch | 3.08 KB | mikeytown2 |
#8 | advagg-1997588-8-fix-drush-install-dir-permissions.patch | 1.29 KB | mikeytown2 |
Comments
Comment #1
mikeytown2 CreditAttribution: mikeytown2 commentedCode in question: advagg_requirements()
This is a simple check to make sure that file_prepare_directory() returns TRUE. It's very similar code to what we have in core drupal_build_css_cache() ($csspath variable), drupal_build_js_cache() ($jspath variable).
Could I get the output of this on your system?
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedAre you getting these errors in watchdog? "
The file permissions could not be set on %uri.
" from drupal_chmod()Comment #3
colanOn running
drush php-eval "print_r(advagg_get_root_files_dir())"
, I get:I'm not seeing any "The file permissions could not be set..." messages, but I am seeing tonnes of these:
It's actually filled up entirely with those. So it's possible that permissions message rolled out of the rotation already and I missed it.
In fact, I just looked at those directories, and they're owned by the *nix user instead of the web user. I have a feeling that this happened because I enabled the module with Drush instead of of doing it from the web UI. Would that make sense? In the code, maybe we could set the owner of these directories explicitly to the owner of the parent files directory. That should solve this problem for other Drush users in the future.
So anyway, after fixing the permissions on those directories, the errors disappeared from the status page. Is there anything I need to do now to reset anything, or should it all be working now?
Thanks for the quick reply!
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedSo I would have to run chown() & chgrp() on hook_install/enable.
Some combination of stat() & posix_getpwuid() (if function exists) on public:// and then set the dir ownership from there.
Comment #5
mikeytown2 CreditAttribution: mikeytown2 commentedps I'll be on vacation till the 27th (not at drupalcon) so feel free to create a patch for this.
Comment #6
colanOkay, great. I will be at DrupalCon, so I won't have a lot of time either, but at least we now know what's going on here. It shouldn't be too hard for one of us to write a patch at some point! :)
Comment #7
colanUpdating title.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedComment #9
mikeytown2 CreditAttribution: mikeytown2 commentedI've committed this patch. Let me know if it doesn't fix the drush issue.
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commentedAlso committed this
Comment #12
tetmo CreditAttribution: tetmo commentedI hate to be a bother, but which of these patches do I apply? I tried the first one and got after drush cc all:
Drush command terminated abnormally due to an unrecoverable error.
Error: syntax error, unexpected '$stat_public' (T_VARIABLE) in /home/***/public_html/sites/all/modules/advagg/advagg.install, line 57
Parse error: syntax error, unexpected '$stat_public' (T_VARIABLE) in /home/***/public_html/sites/all/modules/advagg/advagg.install on line 57
Doing the second patch gives:
File to patch: advagg.install
patching file advagg.install
Hunk #1 succeeded at 52 (offset 40 lines).
Hunk #2 FAILED at 460.
1 out of 2 hunks FAILED -- saving rejects to file advagg.install.rej
I rarely implement patches so I am not sure what is fixed and what is not.
The post-installation fix mentioned above required moving the file permissions to the webserver. I am on a VPS and am not wanting to do this. My file permissions are:
drwxrwxr-x 2 user user 4.0K Aug 19 06:13 advagg_css/
drwxrwxr-x 2 user user 4.0K Aug 19 06:13 advagg_js/
Sorry for the confusion, but what is the actual file permissions needed for this module so this can be fixed?
Thanks!
Comment #13
tetmo CreditAttribution: tetmo commentedAs a follow up to this I wanted to let folks know how I solved this. My unix permissions were fine. The problem was that my php.ini had a list of disabled_functions that was causing things not to be written to the directory.
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commented@tetmo
The patches have been committed, thus you do not need to apply them unless you have an older version of AdvAgg; upgrade if that is the case :)
I can add in a check to see if a php function has been disabled before trying to use it. Do you remember what functions were disabled in your php.ini?
Comment #15
tetmo CreditAttribution: tetmo commentedrename
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedI must say that rename an odd function to disable. I'll add it to the installation requirements check.
Created this issue #2070197: Check that needed php functions are not disabled. Closing this issue.
Comment #17
tetmo CreditAttribution: tetmo commentedI disable everything that is not needed and this is the first time this function has been needed. But to your point, most site administrators will probably not encounter this issue.
Comment #18
shapor1974 CreditAttribution: shapor1974 commented