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?

Comments

Code in question: advagg_requirements()

<?php
   
list($css_path, $js_path) = advagg_get_root_files_dir();
   
// What should be in the array.
    // $css_path[0] = public://advagg_css
    // $js_path[0] = public://advagg_js
    // Make sure directories are writable.
   
if (!file_prepare_directory($css_path[0], FILE_CREATE_DIRECTORY)) {
     
$requirements['advagg_css_path'] = array(
       
'title' => $t('Adv CSS/JS Agg - CSS Path'),
       
'severity' => REQUIREMENT_ERROR,
       
'value' => $t('CSS directory is not created or writable.'),
       
'description' => $t('%path is not setup correctly.', array('%path' => $css_path)),
      );
    }
    if (!
file_prepare_directory($js_path[0], FILE_CREATE_DIRECTORY)) {
     
$requirements['advagg_js_path'] = array(
       
'title' => $t('Adv CSS/JS Agg - JS Path'),
       
'severity' => REQUIREMENT_ERROR,
       
'value' => $t('JS directory is not created or writable.'),
       
'description' => $t('%path is not setup correctly.', array('%path' => $js_path)),
      );
    }
?>

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?

<?php
print_r
(advagg_get_root_files_dir());
?>

Are you getting these errors in watchdog? "The file permissions could not be set on %uri." from drupal_chmod()

On running drush php-eval "print_r(advagg_get_root_files_dir())", I get:

Array
(
    [0] => Array
        (
            [0] => public://advagg_css
            [1] => sites/example.com/files/advagg_css
        )
    [1] => Array
        (
            [0] => public://advagg_js
            [1] => sites/example.com/files/advagg_js
        )
)

I'm not seeing any "The file permissions could not be set..." messages, but I am seeing tonnes of these:

Write to file system failed. public://advagg_css/css__OmlVpN.......g1I0.css.gz

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!

So 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.

ps I'll be on vacation till the 27th (not at drupalcon) so feel free to create a patch for this.

Okay, 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! :)

Title:CSS/JS directory is not created or writableCSS/JS directory is not created or writable if enabled with Drush
Component:User interface» Code

Updating title.

Status:Active» Needs review
StatusFileSize
new1.29 KB

Status:Needs review» Fixed
StatusFileSize
new3.08 KB

I've committed this patch. Let me know if it doesn't fix the drush issue.

StatusFileSize
new2.93 KB

Also committed this

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Needs work

I 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!

As 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.

@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?

rename

Status:Needs work» Closed (fixed)

I 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.

I 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.