I noticed a javascript error on my browser and I realized that on a multilingual install of Drupal 6.2 locale.module was giving the language .js file the absolute path instead of a website-relative path. This happens with downloads set to either private or public. Hence, the browser can't find the language .js file.

I have the feeling that line 554 of locale.module is the one that's producing the wrong code.

Thanks,
Tony

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

antiorario’s picture

Same here. Issue still present in 6.3.

antiorario’s picture

Version: 6.2 » 6.3

Same here. Issue still present in 6.3.
(Sorry for the double post.)

Stampie’s picture

Version: 6.3 » 6.4

The problem exists even in version 6.4.

The problem must be somewhere, where Tony marked it, because when I was able to make it work by a hack:

I changed
$dir = file_create_path(variable_get('locale_js_directory', 'languages'));
to
$dir = file_create_path(variable_get('locale_js_directory', 'files/languages'));

in line 501 in locale.module, and it works. I do not produce a patch, because the files is a hardcoded directory, where I put all my files, so it will not work everywhere.

Xen’s picture

Patch attached.

Requires that file_create_url returns relative URLs as described in http://drupal.org/node/278770

Fixing this problem without the above mentioned change would require that locale module has to concern itself with what download method is in use, which doesn't feel right.

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

If Drupal can't identify correctly your base url (for example your Drupal installation is behind a proxy server), you have to provide it explicitly in your settings.php file (parameter $base_url).

I don't see why having an absolute path is a bug by itself.

antiorario’s picture

Damien, I'm not sure I understand your point of view.

I always set $base_url for my sites, and that doesn't change the fact that locale.module, of all modules, outputs an absolute path (again, a server-absolute path) in the .js file.

If the result is that the outcome doesn't work the way it's meant to, I call it a bug, and there should be a way to fix it.

If what Xen.dk suggests is at the root of the problem, good enough for me. I'll test it.

Damien Tournoud’s picture

Status: Closed (won't fix) » Postponed (maintainer needs more info)

@antiorario: I understand your issue better now.

Have you seen the message in the File system administration page:

A file system path where the files will be stored. This directory must exist and be writable by Drupal. If the download method is set to public, this directory must be relative to the Drupal installation directory and be accessible over the web. If the download method is set to private, this directory should not be accessible over the web. Changing this location will modify all download paths and may cause unexpected problems on an existing site.

As far as I know, that part of Drupal 6 don't work at all for Private download (this last point should be documented better). See for example #181003: private download method and dynamically generated CSS and JS.

antiorario’s picture

Yes, Damien, I'm aware of all that.

I am also aware of the fact that setting the download method to private is bound to break something. (I don't use the color.module, so at least I'm not worried about that.)

I use the private method because I manage multiple sites on the same Drupal installation, and I need things to be cleanly separated. I guess cleanliness comes at a cost.

wuf31’s picture

subscribe

Xen’s picture

Damien:
See my comment on #278770.

We could fix locale.module without changing file_create_url, but it means that locale.module should worry about what type of downloads are in effect, which is ugly. One of the main reasons for having the file_create_url function is so that every module doesn't have to take the way downloads are handled into account.

Xen’s picture

FileSize
1.56 KB

I stand corrected...

After working on the problem, I've found that it's not necessary, or wise, to chance file_create_url to return relative paths.

I've (most likely re-) discovered a pattern regarding local paths in Drupal:

$path = file_create_url(file_create_path(".."));
$path = substr($dir, strlen($GLOBALS['base_url']) + 1);

The "+ 1" part is if you want a path without a leading slash (as drupal_add_js requires), drop it for 'proper' relative URLS.

Attached is a patch to locale.module that uses this method and adds a hook_file_download() which ensures that the generated files are downloadable with the private method.

Also see comments on #278770

Xen’s picture

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

Removed noise from patch.

antiorario’s picture

Thanks Xen.

Now the problem seems to be that whatever .js file Drupal generates can't be found. I'm probably going to give up and try to disable it once and for all. (That is, until the next Drupal update.)

Xen’s picture

FileSize
2.15 KB

Well, it worked on one site, but not on another.

Reimplemented locale_file_download, see if this latest patch doesn't solve your problem.

andypost’s picture

Latest patch helps but checked only on public download method

andypost’s picture

On another site which have a mirror with different domainname it doesn't works...
files/languages is never created
if I create this folder by hands nothing happens - no files copied to folder...

Any ideas?

Xen’s picture

andypost:
If they share the database, that's your problem. When locale.module generates the file, it stores a key in the database it uses to check if the translations has changed. If not, it simply generates the filename from the key, and doesn't do anything to check whether the file exist. But that's an issue for another bug report.

Murz’s picture

subscribe

neochief’s picture

subscribing

Freso’s picture

Version: 6.4 » 7.x-dev

Has this been tested on Drupal 7? (If not, it should be.) If D7 exhibits the same behaviour, it should first be fixed there, then backported.

Dries’s picture

Can someone provide a good summary of the problem? I read all the comments, and somehow we failed to properly articulate the problem.

Status: Needs review » Needs work

The last submitted patch failed testing.

antiorario’s picture

Version: 7.x-dev » 6.8

I'm moving this back to Drupal 6, because it should not be forgotten as a Drupal 6 issue.

@Dries: I thought my original post was quite clear on the matter, but I'll try to rephrase it. If I view the source code for any of my Drupal 6 websites, the line contaning the link to the Javascript localization points to a system path instead of a site-relative path (one starting with /system, I imagine). Example:

<script type="text/javascript" src="//home/web/sitename/files/languages/it_569af6e9cbf1ad376e4c264735a08b69.js?8"></script>

I always set my download method to private, but this happens even with downloads set to public.

dagmar’s picture

Maybe this issue is a duplicate from this one #338630: Locale is unable to rebuild lost Javascript translation files I'm not sure.

neochief’s picture

Status: Needs work » Closed (duplicate)

It's certainly a right problem describe there. I suggest to move our progress there. Thanks.

antiorario’s picture

Status: Closed (duplicate) » Fixed

It doesn't sound like the same problem to me. And it's in Drupal 6, not 7. Maybe the two problems are related, I don't know.

It's time for me to post an update, though. I have been able to (apparently) fix the problem in my websites, and the fix came unexpectedly. The first time it happened, it involved uninstalling the locale module and performing other actions that seemed to just mess up the whole website. Once I re-enabled Locale, the problem in my original post was gone. Specifically, the system was no longer looking for a .js file in the wrong (server-relative) path. In fact, it wasn't looking for that language .js file at all.

When I thought the problem had been fixed for good, it presented itself in another website on the same installation of Drupal 6. This time I was able to understand the situation a little better. Instead of removing Locale, I exported my translations in a .po file and emptied the locale-related database tables (source and target). While this move solved the .js file issue, it obviously didn't help, since the whole interface was in English. Reimporting the previously exported translations made the .js issue reappear.

Next, I manually edited the .po file to remove all strings related to .js files. No big deal, there weren't many. After doing so, I emptied the locale tables again, then imported the modified .po file. Issue gone. Happy websites, and happy me.

The issue has not presented itself in any new websites based on the same Drupal installation.

Now, if anyone involved in the locale.module development still thinks this sounds like a duplicate of #338630: Locale is unable to rebuild lost Javascript translation files, as suggested by dagmar, fine – feel free to mark the issue as such again. I'm marking it as "fixed" because what I'm suggesting here is a "practical" fix, not because it's been solved at the root.

Michel77’s picture

The locale.250451-3.patch also fixes the private download method.

The server local path is translated to the correct private download path.

Before: //var/www/vhosts/{DOMAIN}.{TLD}/www-data/drupal-upload/files/languages/nl_394d5f70b5ecd6021ae92cadd18fba1a.js?Y

After: /system/files/languages/nl_394d5f70b5ecd6021ae92cadd18fba1a.js?Y

antiorario’s picture

I thought that patch had failed. Am I missing something?

Michel77’s picture

@antiorario: Sorry, i manualy aplied the patch (manualy edited the locale.module file), and then the patch worked.
I did not aply the patch using patch < patch.

I tested the patch (using patch < patch) against the drupal 6.10 and it failed horribly with the following errors: Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354

I will create a new unified diff patch from the patched file.

Michel77’s picture

FileSize
2.31 KB

A working patch derived of patch 3 mentioned above, nothing changed, manually applied changes to the Drupal 6.10 locale.module and re-diff-ed.
Tested applying the patch (using patch < locale.250451-4.patch) against Drupal 6.10 locale.module.

Greetings,
Michel Sijmons

Xen’s picture

Version: 6.8 » 6.10
Status: Fixed » Needs review

Freso:
"If D7 exhibits the same behaviour, it should first be fixed there, then backported."

As most seems to run into the problem on D6, why not fix it and test it there, and then forward port it? Makes even more sense if HEAD has changed significantly (i hear theres a FileAPI in the works, it might have changed things).

Dries:
"summary"

Locale module generates invalid paths in the call to drupal_add_js when the download method is private. It assumes that whatever file_create_path returns is usable as an url path, which is not the case when the method is private. Example: Assume that the file path is set to "sites/default/files" and the files folder in the default folder has a .htaccess with something like 'Deny from all'. Download methos is public, so regular file handling creates urls like 'system/files/pic.png'. So locale module should add a js file ala: "system/files/languages/da_18d692a4c917db0fde23fdf025663dcc.js". However, what it does is adding "sites/default/files/languages/da_18d692a4c917db0fde23fdf025663dcc.js" which results in an access denied.

The patch also adds the hook_file_download which is required in order to be allowed to download the file when using private downloads.

neochief:
Not a duplicate.

Freso’s picture

As most seems to run into the problem on D6, why not fix it and test it there, and then forward port it? [...]

Because that's the policy of Drupal core development. Fixes should happen in HEAD first (if the problem exists there), and then back ported to whatever code frozen versions are supported. That's been the policy for as long as I have been involved, and I haven't heard or seen any discussion anywhere about changing this.

Xen’s picture

Freso:
Then someone should probably start that discussion. A lot of bugs get discovered by people that's not using HEAD and a lot of patches gets produced by people trying to fix that bug in a non-HEAD version.

neochief’s picture

Xen.dk, current procedure ensures that bug will not appear in latest versions. Nobody takes you from preparing and using patches for older versions, but it's very important to start commiting from HEAD to older, if we want to get safe future versions.

Xen’s picture

neochief:
I appreciate the logic behind the procedure, I just think it's optimistic to think that everybody that produces a patch does it against HEAD. I would hate to think that patches got lost because there's only a patch against a stable version, and there's no procedure for forward porting of patches.

neochief’s picture

Yes, I completelly understand you, because I was in same situation 2 weeks ago. But than I realised that porting my patches to 7x branch is very easy and all procedure is speeding up.

Ingumsky’s picture

Hmmm... It's still an issue for me (drupal-6.10). I get "The selected file /var/www/virtual/example.net/phptmp/fileKIkyif could not be uploaded, because the destination sites/default/files/languages/ru_e055380dca6b6ffdf70315567d3ccfc5.js is not properly configured" error message on every page of my site -(

I've started at "failed to open stream: No such file or directory in file" (http://drupal.org/node/297990) but patches I found there (#9 and #10) didn't work for me even after cache was cleared and other shamanistic tricks were applied. After all I rolled back those patches and apply the latest patch for 6.x I found here at this topic but at the end of the day I'm sitting in front of me monitor and blaming gods who couldn't help me make any difference with the issue. -\

lark’s picture

Subscribing ....

dobeerman’s picture

subsribe ...

Marko B’s picture

subs

gideros’s picture

Hi, I made patch solutions on v6.10 Turkish localized site, but they don't enough to solve the problem.

I check owner of languages/ directory. It was like,
drwxrwxr-x 2 siteuser siteuser 4096 Mar 24 11:01 languages/

Then I found a difference my previous working drupal setup (v6.9). The owner of directory was "nobody". Then I changed the owner of languages/ directory as follow,

for linux box:
connect as root (you may not applied if use vps site account)
# cd ~/public_html/drupal/sites/default/files
# chown nobody:nobody languages

current properties
# ls -l
# drwxrwxr-x 2 nobody nobody 4096 Mar 24 11:01 languages/

Now I get rid of the "The selected file /tmp/fileXxxxX could not be uploaded, because the destination sites/default/files/languages/tr_xxxxxxxx.js is not properly configured." messages on every page.

This is also may help to you and your drupal site.

Xen’s picture

FileSize
1.35 KB

Forward ported to D7.

Gábor Hojtsy’s picture

Version: 6.10 » 7.x-dev
Priority: Normal » Critical

Marking this critical for the reason that people with private download methods will have this broken. The issue at #361557: Wrong path on locale Javascript which I just marked duplicate has a more detailed explanation of why this is critical. We desperately need to fix this in Drupal 7 and backport to Drupal 6.

Gábor Hojtsy’s picture

Also marked another critical issue as a dupe of this one: #284137: System file path is visible with multilanguage and private download method

Gábor Hojtsy’s picture

Marked #441202: Fatal issue with javascript duplicate of this issue.

sun’s picture

Status: Needs review » Needs work
+  $dir = file_create_url(file_create_path(variable_get('locale_js_directory',
+                                                      'languages')));

Weird spacing/wrapping here.

+  $dir = substr($dir, strlen($GLOBALS['base_url']) + 1);

I'm pretty sure that this won't work on multilingual sites, because on such sites, absolute URLs may be prefixed with more than just the $base_url (language path prefix).

Mangust’s picture

Hi, i was struggling with 6.13. This bug is still there. I applied patch from this discussion manually, and then created patch against 6.13. Maybe someone need it.

michaelcrm’s picture

Version: 7.x-dev » 6.13

the patch of #47 doesn't work on 6.13, the same errors kept showing.

dagmar’s picture

Version: 6.13 » 7.x-dev

@michaelcrm: please don't change the version of the issue, this problem must be solved for Drupal 7 and then backported to Drupal 6.

andypost’s picture

Issue tags: +Needs tests

#42 looks fine except newline

Also needs 2 tests to check that localization js is available in private and public download methods, suppose better to extend file-related tests

SimonVlc’s picture

Any update on this? I´ve got the problem in a 6.13 installation... is there any temp workaround until fixed?

Thanks in advance!

lopolencastredealmeida’s picture

Sometime ago I posted the issue with an explanation on what was the problem at #446368: FATAL issue with inline translation files localization

The code is still (again) broken on last upgrade.

This is the code that must be changed at locale.inc:

  // Construct the filepath where JS translation files are stored.
  // There is (on purpose) no front end to edit that variable.
  $dir = file_create_path(variable_get('locale_js_directory', 'languages'));

$dir must hold "/sites/yoursite/files/languages" and not any other user defined path, specially when using private download.

I think this is simply solved just changing the way you are making this specific path.

lopolencastredealmeida’s picture

Where is variable_set('locale_js_directory', 'languages') located?
The only place I found it was in modules/locale/locale.test

The only solution is to change it when systems sets it up.

arhak’s picture

for D6 you can also try #572516: make private download method support css/js aggregation, color module and js translations
(which will remain marked as a "won't fix" since it introduces new features around private download method compatibility with features otherwise disabled)

sebzur’s picture

Just a comment.

After changing:
$dir = file_create_path(variable_get('locale_js_directory', 'languages'));
to
$dir = file_create_path('sites/my.site.org/files/languages');
in D6.14 all works fine.

benpeti’s picture

Version: 7.x-dev » 6.14

#55 nearly worked, but I had to remove file_create_path function and had to directly assign the value to the variable, so this worked for me:
$dir = 'sites/default/files/languages';
(D6.14)

antiorario’s picture

Of course it worked. However, static value assignment is not an option, since it can work only for a single-site installation. (Not to mention the fact that it's just wrong.)

andypost’s picture

Version: 6.14 » 7.x-dev

dont change version

castawaybcn’s picture

subscribing, same issue in recently updated 6.15

arhak’s picture

what the current status of this?

last patch @#42

@#46

I'm pretty sure that this won't work on multilingual sites [...]

and no positive neither negative tests on this

PS: patch might need a re-roll since #338630: Locale is unable to rebuild lost Javascript translation files was committed for D7

arhak’s picture

recall that this is marked as critical and the major issue would be revealing absolute filesystem path which is a security hole

arhak’s picture

Issue tags: -Needs tests +Security

tag

arhak’s picture

Issue tags: +Needs tests

sorry, didn't meant to untag it

c960657’s picture

Are you sure this is still an issue in HEAD? AFAICT locale_js_alter() now uses the public:// scheme.

sun.core’s picture

Version: 7.x-dev » 6.15
Priority: Critical » Normal

Moving back to D6 for now.

andypost’s picture

Version: 6.15 » 6.x-dev
Issue tags: -Needs tests

Remove tag because tests for D7 already in from #338630: Locale is unable to rebuild lost Javascript translation files
Suppose locale_file_download() is needed

batigolix’s picture

subscribe

andypost’s picture

Could someone to re-roll patch against current DRUPAL-6

yang_yi_cn’s picture

subscribe

andypost’s picture

Status: Needs work » Needs review
FileSize
869 bytes

As fixed in 6.16 #338630: Locale is unable to rebuild lost Javascript translation files

So only locale_file_download() is needed to support a private downloads

Peter Arius’s picture

subscribe

Peter Arius’s picture

When updating to D6.17 I tried the patch from #70.

However, this patch does not solve the problem for my drupal installation. Only when using the more extensive patch from #47, the issue goes away.

More data:
D6.17
Download method: private
Languages: German, English
in sites/default/settings.php, there is: $base_url = 'http://my.site/drupal'

Issue is:
Lots of "page not found" log entries for file http://my.site/drupal//....../files/drupal/languages/de_a1ca75159f0a2019ae77b937a35cdbf8.js?e

clashar’s picture

subscribe

TomiMikola’s picture

This patch is to help in case someone is using https scheme and having trouble with language js file path pointing to "http://...." url. You'll notice IE giving warnings for non-secure items on page. This is repatch of http://drupal.org/node/250451#comment-1813626 for DRUPAL-6-20.

andypost’s picture

@TomiMikola don't you tried patch #70, locale_file_download() is needed to download files in secure manner

Status: Needs review » Needs work

The last submitted patch, locale_languages_js_url_correction.patch, failed testing.

TomiMikola’s picture

@andypost: I'm using public download method. hook_file_download() documentation says "...when the private file download method is selected".

My site is using public download method while running under https. Thus all references to js and css files should also be requested using https scheme. My patch was to correct this problem.

andypost’s picture

@TomiMikola so please read a whole issue - we talk about public|private + https methods, so final patch should introduce both fixes

Nchase’s picture

could someone tell why #74 didn't pass. I've tested in on a development site and it does what it should on 6.20. Is there anything new about it?

c960657’s picture

All D6 patches are currently failing due to #961172: All D6 Core patches are failing.

c960657’s picture

Status: Needs work » Needs review
Issue tags: -Security

Status: Needs review » Needs work
Issue tags: +Security

The last submitted patch, locale_languages_js_url_correction.patch, failed testing.

Nchase’s picture

still the same on 6.22.

Nchase’s picture

anything new?

Apfel007’s picture

Any news?

Apfel007’s picture

must I life with this bug?

svarco’s picture

I'm afraid, yes... :(
It's affecting me too and I can currently not upgrade to D7 because my website has module dependencies not available in D7. :(

rolfo85’s picture

In D7 this problem still exists !!!!!!!!
Hellllpppppp !

it is impossible that there is not a patch

rolfo85’s picture

How do I use private files and not have the problem of javascript in the folder languages​​?

mgifford’s picture

Version: 6.x-dev » 7.x-dev
Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)

I'd like steps to produce this in D7. I don't think this is going to get fixed in D6. The code has changed a lot so the old patch is no longer relevant.

sun’s picture

Version: 7.x-dev » 6.x-dev
Status: Postponed (maintainer needs more info) » Needs work

In D7, locale_js_alter() hard-codes the public:// stream wrapper scheme, as @c960657 mentioned in #64 already.

Whether this issue can be fixed for D6 just depends on whether someone is able to provide a clean + working patch.

voerg’s picture

In D6.37 with private file system this line solved this issue for me:

$dir = str_replace(variable_get(file_directory_path, ''), 'system/files', $dir);

I have put that line in the file ~drupal_root/modules/locale/locale.module line 500 in "function locale_update_js_files()" right after this line

$dir = file_create_path(variable_get('locale_js_directory', 'languages'));

I know its not nice to modify core-modules this way! I appreciate any help to patch this in the core module itself or provide a more general solution.

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.