Hi,

I include my modules with symlinks into my many drupal installations. Sadly I get an openbaseddir restriction if I try to run gz compression as the modules tries to use the path /js/js_24bb...7a.jsmin.js.gz which would be a root path.

If you add the absolute path the module runs fine again. This means to use $jsmin_file_path instead of $jsmin_file_name in line 120 and 121.

Please add this small patch to the module :)

Best regards,

Kars-T

CommentFileSizeAuthor
javascript_aggregator.module.patch1002 bytesKars-T
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

derjochenmeyer’s picture

While rearranging the code for the last release i tried this among other changes, but i ran into problems with some of my installations.

I will try out the patch.

But I would like to have some more positive feedback from the community before including it for the next release.

derjochenmeyer’s picture

Status: Needs review » Postponed (maintainer needs more info)

@all: Please report if anyone has similar problems.

As i wrote in #1 I tried this modification months ago and ran into problems. If nobody else has this problem I will mark this as "won't fix".

Kars-T’s picture

Hi

I tested this again and let it run through a debugger.

$jsmin_file_name is "/js/js_94ebc1fc21b0054d6f7845aafe10634d.jsmin.js"

Line 98

      // Construct the final JSMin file path.
      $jsmin_file_path = file_directory_path() . $jsmin_file_name;

This sets $jsmin_file_path to "sites/default/files/js/js_94ebc1fc21b0054d6f7845aafe10634d.jsmin.js"

Don't know how you ran into problems. What went wrong?

Maybe we need the full path "/var/www/drupal/sites/default/files/js/js_94ebc1fc21b0054d6f7845aafe10634d.jsmin.js" ?
Or maybe "./sites/default/files/js/js_94ebc1fc21b0054d6f7845aafe10634d.jsmin.js"

I still can only say that with openbasedir I need the full path or it won't work. Hopefully someone else will assist in this. :)

EugenMayer’s picture

While http://api.drupal.org/api/function/file_destination/6 should be used to determine the existance (eventhough it reuses file_exists but that could change..depends on bugs in php version) the path relative to htdoc should be used with file_exists and not the filename.

Using the filename with file_exists in that case makes no sense and is def. doomed to fail. Because that depends on the location of the file which included that file which actuall calls that method..which you dont want to know where :).

User realpath or relative paths to htdoc

derjochenmeyer’s picture

How is it "doomed to fail"? At least it seems to work :)

Happy for any suggestions. Could you provide a patch?

Kars-T’s picture

Sadly I don't have enough time to do a new patch in the near future. You are not by any chance german and in the german IRC? irc.freenode.net #drupal.de? Maybe we can chat about this.

derjochenmeyer’s picture

@#6 I'am german but I never ever used IRC. I'll try to set up ChatZilla.

If not a patch, maybe a snippet how to approach this with http://api.drupal.org/api/function/file_destination/6 >> I'll turn it into a patch, but at the moment I dont have time to look deeper into this issue.

derjochenmeyer’s picture

Version: 6.x-1.3 » 6.x-1.x-dev
Status: Postponed (maintainer needs more info) » Fixed

This has been fixed in another issue:
#936588: open_basedir restriction in effect

Pleas test and report.

Status: Fixed » Closed (fixed)

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