locale.module adds wrong js path

Same here. Issue still present in 6.3.

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

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.

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.

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.

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.

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

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.

subscribe

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.

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

Removed noise from patch.

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

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

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

Latest patch helps but checked only on public download method

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?

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.

subscribe

subscribing

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.

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

The last submitted patch failed testing.

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:

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

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

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

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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

Subscribing ....

subsribe ...

subs

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.

Forward ported to D7.

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.

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

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

Weird spacing/wrapping here.

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

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.

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

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

#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

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

Thanks in advance!

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:

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

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.

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)

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.

#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)

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

dont change version