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
Comment | File | Size | Author |
---|---|---|---|
#74 | locale_languages_js_url_correction.patch | 848 bytes | TomiMikola |
#70 | 250451-locale-private-files-d6.patch | 869 bytes | andypost |
#47 | locate.module-priv.filesys.fix_.6.13-D6.patch | 1.3 KB | Mangust |
#42 | 250451-7.x-1.patch | 1.35 KB | Xen |
#30 | locale.250451-4.patch | 2.31 KB | Michel77 |
Comments
Comment #1
antiorario CreditAttribution: antiorario commentedSame here. Issue still present in 6.3.
Comment #2
antiorario CreditAttribution: antiorario commentedSame here. Issue still present in 6.3.
(Sorry for the double post.)
Comment #3
Stampie CreditAttribution: Stampie commentedThe 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.
Comment #4
Xen CreditAttribution: Xen commentedPatch 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.
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedIf 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.
Comment #6
antiorario CreditAttribution: antiorario commentedDamien, 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.
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commented@antiorario: I understand your issue better now.
Have you seen the message in the File system administration page:
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.
Comment #8
antiorario CreditAttribution: antiorario commentedYes, 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.
Comment #9
wuf31 CreditAttribution: wuf31 commentedsubscribe
Comment #10
Xen CreditAttribution: Xen commentedDamien:
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.
Comment #11
Xen CreditAttribution: Xen commentedI 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
Comment #12
Xen CreditAttribution: Xen commentedRemoved noise from patch.
Comment #13
antiorario CreditAttribution: antiorario commentedThanks 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.)
Comment #14
Xen CreditAttribution: Xen commentedWell, it worked on one site, but not on another.
Reimplemented locale_file_download, see if this latest patch doesn't solve your problem.
Comment #15
andypostLatest patch helps but checked only on public download method
Comment #16
andypostOn 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?
Comment #17
Xen CreditAttribution: Xen commentedandypost:
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.
Comment #18
Murzsubscribe
Comment #19
neochief CreditAttribution: neochief commentedsubscribing
Comment #20
Freso CreditAttribution: Freso commentedHas 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.
Comment #21
Dries CreditAttribution: Dries commentedCan someone provide a good summary of the problem? I read all the comments, and somehow we failed to properly articulate the problem.
Comment #23
antiorario CreditAttribution: antiorario commentedI'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.
Comment #24
dagmarMaybe this issue is a duplicate from this one #338630: Locale is unable to rebuild lost Javascript translation files I'm not sure.
Comment #25
neochief CreditAttribution: neochief commentedIt's certainly a right problem describe there. I suggest to move our progress there. Thanks.
Comment #26
antiorario CreditAttribution: antiorario commentedIt 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.
Comment #27
Michel77 CreditAttribution: Michel77 commentedThe 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
Comment #28
antiorario CreditAttribution: antiorario commentedI thought that patch had failed. Am I missing something?
Comment #29
Michel77 CreditAttribution: Michel77 commented@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.
Comment #30
Michel77 CreditAttribution: Michel77 commentedA 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
Comment #31
Xen CreditAttribution: Xen commentedFreso:
"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.
Comment #32
Freso CreditAttribution: Freso commentedBecause 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.
Comment #33
Xen CreditAttribution: Xen commentedFreso:
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.
Comment #34
neochief CreditAttribution: neochief commentedXen.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.
Comment #35
Xen CreditAttribution: Xen commentedneochief:
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.
Comment #36
neochief CreditAttribution: neochief commentedYes, 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.
Comment #37
Ingumsky CreditAttribution: Ingumsky commentedHmmm... 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. -\
Comment #38
lark CreditAttribution: lark commentedSubscribing ....
Comment #39
dobeerman CreditAttribution: dobeerman commentedsubsribe ...
Comment #40
Marko B CreditAttribution: Marko B commentedsubs
Comment #41
gideros CreditAttribution: gideros commentedHi, 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.
Comment #42
Xen CreditAttribution: Xen commentedForward ported to D7.
Comment #43
Gábor HojtsyMarking 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.
Comment #44
Gábor HojtsyAlso marked another critical issue as a dupe of this one: #284137: System file path is visible with multilanguage and private download method
Comment #45
Gábor HojtsyMarked #441202: Fatal issue with javascript duplicate of this issue.
Comment #46
sunWeird 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).
Comment #47
Mangust CreditAttribution: Mangust commentedHi, 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.
Comment #48
michaelcrm CreditAttribution: michaelcrm commentedthe patch of #47 doesn't work on 6.13, the same errors kept showing.
Comment #49
dagmar@michaelcrm: please don't change the version of the issue, this problem must be solved for Drupal 7 and then backported to Drupal 6.
Comment #50
andypost#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
Comment #51
SimonVlc CreditAttribution: SimonVlc commentedAny update on this? I´ve got the problem in a 6.13 installation... is there any temp workaround until fixed?
Thanks in advance!
Comment #52
lopolencastredealmeida CreditAttribution: lopolencastredealmeida commentedSometime 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.
Comment #53
lopolencastredealmeida CreditAttribution: lopolencastredealmeida commentedWhere 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.
Comment #54
arhak CreditAttribution: arhak commentedfor 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)
Comment #55
sebzur CreditAttribution: sebzur commentedJust 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.
Comment #56
benpeti CreditAttribution: benpeti commented#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)
Comment #57
antiorario CreditAttribution: antiorario commentedOf 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.)
Comment #58
andypostdont change version
Comment #59
castawaybcn CreditAttribution: castawaybcn commentedsubscribing, same issue in recently updated 6.15
Comment #60
arhak CreditAttribution: arhak commentedwhat the current status of this?
last patch @#42
@#46
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
Comment #61
arhak CreditAttribution: arhak commentedrecall that this is marked as critical and the major issue would be revealing absolute filesystem path which is a security hole
Comment #62
arhak CreditAttribution: arhak commentedtag
Comment #63
arhak CreditAttribution: arhak commentedsorry, didn't meant to untag it
Comment #64
c960657 CreditAttribution: c960657 commentedAre you sure this is still an issue in HEAD? AFAICT locale_js_alter() now uses the public:// scheme.
Comment #65
sun.core CreditAttribution: sun.core commentedMoving back to D6 for now.
Comment #66
andypostRemove tag because tests for D7 already in from #338630: Locale is unable to rebuild lost Javascript translation files
Suppose locale_file_download() is needed
Comment #67
batigolixsubscribe
Comment #68
andypostCould someone to re-roll patch against current DRUPAL-6
Comment #69
yang_yi_cn CreditAttribution: yang_yi_cn commentedsubscribe
Comment #70
andypostAs 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
Comment #71
Peter Arius CreditAttribution: Peter Arius commentedsubscribe
Comment #72
Peter Arius CreditAttribution: Peter Arius commentedWhen 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
Comment #73
clashar CreditAttribution: clashar commentedsubscribe
Comment #74
TomiMikola CreditAttribution: TomiMikola commentedThis 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.
Comment #75
andypost@TomiMikola don't you tried patch #70, locale_file_download() is needed to download files in secure manner
Comment #77
TomiMikola CreditAttribution: TomiMikola commented@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.
Comment #78
andypost@TomiMikola so please read a whole issue - we talk about public|private + https methods, so final patch should introduce both fixes
Comment #79
Nchase CreditAttribution: Nchase commentedcould 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?
Comment #80
c960657 CreditAttribution: c960657 commentedAll D6 patches are currently failing due to #961172: All D6 Core patches are failing.
Comment #81
c960657 CreditAttribution: c960657 commented#74: locale_languages_js_url_correction.patch queued for re-testing.
Comment #83
Nchase CreditAttribution: Nchase commentedstill the same on 6.22.
Comment #84
Nchase CreditAttribution: Nchase commentedanything new?
Comment #85
Apfel007 CreditAttribution: Apfel007 commentedAny news?
Comment #86
Apfel007 CreditAttribution: Apfel007 commentedmust I life with this bug?
Comment #87
svarco CreditAttribution: svarco commentedI'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. :(
Comment #88
rolfo85 CreditAttribution: rolfo85 commentedIn D7 this problem still exists !!!!!!!!
Hellllpppppp !
it is impossible that there is not a patch
Comment #89
rolfo85 CreditAttribution: rolfo85 commentedHow do I use private files and not have the problem of javascript in the folder languages?
Comment #90
mgiffordI'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.
Comment #91
sunIn 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.
Comment #92
voerg CreditAttribution: voerg commentedIn D6.37 with private file system this line solved this issue for me:
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
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.