I see a lot of "Page not found" errors in dblog related to JavaScript translation files. It's about those files that need to be generated by the locale.module [see locale_update_js_files()].
Looking in source of the page, in <HEAD> I see the JS file requested in line: <script type="text/javascript" src="/files/languages/ro_e8ed5acc13877f103dc82336f22ac598.js?3"></script>
but in the specified folder the file is not present. This is happen only for the Romanian language. The site is multilingual (EN, IT, RO). In italian version I got no error.
Comment | File | Size | Author |
---|---|---|---|
#114 | locale-338630-114.patch | 6.83 KB | plach |
#111 | locale.png | 14.27 KB | Yas375 |
#109 | locale-338630-109.D6.patch | 3.66 KB | plach |
#109 | locale-338630-109.patch | 6.51 KB | plach |
#106 | locale-338630-106.patch | 6.52 KB | plach |
Comments
Comment #1
David Koudela CreditAttribution: David Koudela commentedI had installed version 6.6 including Czech localization and everything was OK.
After update to 6.8 I often get this error message in web logs:
Type: "page not found"
Place: https://www.my_own_web.cz/sites/default/files/languages/cs_212be125b34b8...
I have already the localization file, but it has different name:
sites/default/files/languages/cs_212be125b34b88632a34700d1c2cae3a.js
How can I repair it? Where can I find the file name stored?
Comment #2
plachYour problems are due to the fact that the Locale module is unable to rebuild the Javascript translation files: if one of these gets accidentally corrupted or lost there is no way to tell Drupal to rebuild it.
The patch should fix the problem: apply it, clear the cache (Site configuration > Performance > Clear cached data), visit a page which includes the missing file(s) and you should find it again in the
languages
directory.If you are unfamiliar with patching or do not wish to patch the core, you can find a module which will let you rebuild the files manually here:
edit: (updated link) http://download.psegno.it/files/drupal/locale_rebuild_js.zip
Comment #3
plachThis is the 7.x patch.
Comment #5
plachfixed patch
Comment #6
plachComment #7
light9 CreditAttribution: light9 commentedplach thank you so much! Your answer was very helpful for me.
Comment #8
plach@a.horoshavin: did you test the patch or the module?
Comment #9
Agence Web CoherActio CreditAttribution: Agence Web CoherActio commentedHi plach
Your mini-module above enables to rebuild the file properly (BTW the patch was not working for me on D6.8).
However, locale module is not working properly on my configuration :
- file system is private method
- file folder is outside the www folder
- Drupal is in sub-directory of www (called 'my_directory' in my case).
In that case, if I set up the file system path in absolute path, locale module breaks because the page tries to call "/my_directory/absolute_path/languages/fr_xxx.js" which it doesn't exsit.
The only way to fix this is to set the file system path as relative path to Drupal base directory: "../../files". Strangely, the page calls "/my_directory/../../files/languages/fr_xxx.js" which seems to be fine (at least not logging a page not found).
Is that a correct set up ?
Thanks
Laurent
Comment #10
Leeteq CreditAttribution: Leeteq commentedSubscribing.
Comment #11
plachI think this is another issue, I will try to investigate.
Comment #12
realOFF CreditAttribution: realOFF commentedI've tried the Locale Rebuild JS Module on Drupal 6.9.
I run it a couple of times but it seems it didn't work because every time I entered the Module page, I saw the same values in the table.
Now, I don't see the Module tab in the Language Settings and I can't even enter to the Edit page of the any language.
Any ideas?
Thanks in advance.
PS: Now I see I'm also getting error 404 on /path/to/your/sites/stylesheet.css?0. Maybe this is of any help.
Comment #13
plach@LaurantB: as I supposed the problem you are reporting is caused by another issue, see #181003: private download method and dynamically generated CSS and JS for details. Unfortunately JavaScript translations won't work with the private file-system setting enabled until that one is fixed, that's why the patch is not working for you. Moreover I am afraid your soultion won't work because all the paths you suggest will be passed through
file_create_path
and rejected, as they actually point to locations outside the file directory.@realOFF: the values in the table are supposed to remain unchanged, for the other problems I'm afraid I can't help you: that module is an as-is solution while this issue gets fixed in core; if it does not work for you, please try the patch.
Comment #14
kkretsch CreditAttribution: kkretsch commentedJust one fix for the module from #2, you missed the curly braces in locale_rebuild_js.admin.inc around the table name, so with a fixed table prefix the first sql query throws an error. Line 107 should be:
$query = 'SELECT language, javascript FROM {languages} WHERE language IN ('. $placeholders .')';
at least now it worked for me.
Comment #15
plach@kkretsch: thanks, I fixed that, but keep in mind that the module is just an interim solution while the patch find its way to the core...
Comment #17
David Koudela CreditAttribution: David Koudela commentedI have used the module, but the problem still remains and nothing happened.
I still get the "page not found" errors.
Is there any procedure how to remove all correct/incorrect translation files from Drupal and install them again?
This would be sufficient for me now.
I accept that I will lose some of my manual translations.
Comment #18
plach@David Koudela: apply the patch in #2, follow the instructions, delete (backup them!) the language files.
The correct files should get rebuilt and you should not lose you translations.
Comment #19
David Koudela CreditAttribution: David Koudela commentedOk, I did it:
- I applied the patch to the file and I copied it to the directory
- I removed the language files
- I cleaned the cache
But I still get "page not found" errors:
Type page not found
Date Tuesday, 24 February, 2009 - 10:42
User
Location https://www.koudelovi.cz/sites/default/files/languages/cs_f8cc24f295b687...
Referrer https://www.koudelovi.cz/cs/admin/reports
Message 500.phtml
Severity warning
Hostname
Operations
Any ideas what to do or how to better analyze the problem?
Comment #20
plachPlease, check one thing: in the languages directory do you have any cs_*.js files, apart from the missing one?
Comment #21
David Koudela CreditAttribution: David Koudela commentedI have following file:
sites/default/files/languages/cs_f8cc24f295b6870eee00c27dc541587e.js
So it seems to me correct, isn't it?
I have checked also permissions - all directories have at least 755 (rwxr-xr-x), the file has 664 (rw-rw-r--)
Comment #22
plachIn this case I'm afraid neither the patch nor the module will help, they just rebuild the file, if it is actually there you are probably experiencing some kind of server misconfiguration. Are you using private download method?
Comment #23
dagmar@David Koudela: Maybe files directory should have 775 permissions. Apache will create the js file. So, it must have write permissions to create the file.
This bug is also present in Drupal 6.10. Do we have to change the version of this issue?. Maybe it can be fixed in 6.11 version.
Comment #24
David Koudela CreditAttribution: David Koudela commentedI assume you mean following settings: administer >> site configuration >> file system and check box "Download method"
My Download method is public.
Comment #25
plach@dagmar: the issue the patch solves is present both in D6.x and in D7.x, to have the patch automatically passed to the testbed we have to keep the version to 7.x.
@David Koudela: I am sorry, this sounds to me as a server configuration issue.
Comment #26
David Koudela CreditAttribution: David Koudela commented@dagmar: Ok, I have set the permissions of directories to 777 for a moment to be sure, that there is no problem with the permissions.
Then I have deleted the cs_*.js language file and I have tried to access some language local pages, but I still get the same errors :-(.
The language file is re-created again.
I would say that it is right time to uninstall the local language with its translatations, make a clean-up and install it again.
But I do not know how to do it without damaging the system :-).
Comment #27
David Koudela CreditAttribution: David Koudela commentedWell, I did a little progress.
I realized that I did not understand the message of the Drupal log.
The "missing" part was a page 500.phtml somehow requested by: cs_f8cc24f295b6870eee00c27dc541587e.js
I have created empty file 500.phtml at the root directory of my system and the problem disappeared.
I still do not understand why and where it is needed - search of Drupal files and database found nothing :-(
It seems to me a bug, but I can live with it.
Thanks for your help.
Comment #28
plachRerolled the patch and added a simpletest for the JavaScript translations.
Comment #29
dagmarExcellent. Then, the patch for D6 is still #2? Or you are going to do a re roll for 6.x too?
Comment #30
plachHere is the 6.x version.
Comment #31
Frank Steiner CreditAttribution: Frank Steiner commentedWorks fine for our site!
Comment #32
dagmarThe patch should be tested in Drupal 7.
Sorry but, I don't think that your site is in drupal 7 :)
I have tested the 6.x version and can confirm that works fine too.
@Frank Steiner: If you have tested this patch for Drupal 7 please, forgive me, and change the status again.
Greetings
Mariano
Comment #34
plachrerolled
Comment #36
plachrerolled again
Comment #37
plachfixed and encoding problem in the previous patch
Comment #38
cburschkaThe test-case code has blank lines that contain trailing indentation.
I'm not sure
'SELECT min(lid) AS lid FROM {locales_source} WHERE location LIKE \'%.js%\' AND textgroup = \'default\''
is proper - aren't strings containing single quotes supposed to be double-quoted rather than backslashed? I could be wrong there.Comment #39
plach@Arancaytar: thanks for the review, I removed all the trailing spaces. The query should be fine: the backslash quote is a PHP-level quoting not a SQL-level one, however I copied it from line 909 of the original
locale.test
.Edit: sorry, I misunderstood your comment about quotes, however an identical line is already committed.
Edit (2): I checked the coding standards and it seems there are no strong directives to follow about single quotes vs double quotes.
Comment #40
jandd CreditAttribution: jandd commentedI can confirm that the patch in http://drupal.org/node/338630#comment-1307862 fixes the issue for Drupal-6 and would really like to have it integrated with the next 6.x release
Comment #42
plachrerolled
Comment #44
plachfixed the simpletest
Comment #46
lilou CreditAttribution: lilou commentedSetting to 'needs review' - testbot was broken.
Comment #48
plachretry
Comment #50
plachrerolled
Comment #51
catchfew code style things.
$dir .'/'. $language->language .'_'. $data_hash .'.js'
needs extra space for concatenation
+ $status = ($status == 'deleted') ? 'updated' : ($changed_hash ? 'created' : 'rebuilt');
Maybe spit the ternary into two?
No clear what's slipping through what.
This needs phpdoc.
Should be db_query()->fetchObject();
Comment #52
plachImplemented suggestions from #51
Comment #54
altavis CreditAttribution: altavis commentedThank you!
Patch from #52 has solved my problem. I haven't got any *.js file (or even language/ dir to be more precise) - probably lost them when moving from local to server. Anyway it seems to work nicely with D6.13.
Comment #55
momper CreditAttribution: momper commentedsubscribe
Comment #56
ball.in.th CreditAttribution: ball.in.th commentedMy language javascript file is missing too! The D6 patch in #52 fixed the problem for me. Thanks a lot. ^ ^
Comment #57
dagmarShould be
Comment #59
dagmarrerolled
Comment #60
GiorgosKI used to get the warning every time I would "clear cache"
but now it does not appear after applying
patch from #52 for Drupal 6
Comment #61
talino CreditAttribution: talino commentedPrivate Download Method used here too. I have a .JS file in my files/languages folder (outside HTTP root). I tried applying the #52 patch (locally) with 'patch -p0 < locale-338630-52.D6.patch' (from the site root), and got this in Terminal:
Things haven't changed much since then. I still have the JS file being asked for in the source HTML. Cleared the cache etc, a bit stumped. This is the first time I apply a patch. Anything I'm missing?
Comment #62
plach@talino: see #9-#13
Comment #63
talino CreditAttribution: talino commentedThanks, I understand it's incompatible with Private Downloads, however currently the link is still in the source and explicitly displaying the full path to the private files folder (and the host's entire folder structure). This is a major security concern, enough for me to take the site offline. What am I supposed to do now? The site uses French po files for interface string translation but is not multilingual. And I can't use Public Downloads. Do I need to take down a month of work because of a link to a missing JS file?
Thanks.
Comment #64
talino CreditAttribution: talino commentedApologies. Please delete my#63. Haven't clicked far enough. Got the patch and responding there (http://drupal.org/node/296831#comment-969355).
Comment #65
arhak CreditAttribution: arhak commenteda little module for D6 which
Provides locale admin pages with buttons to rebuild/invalidate js translations.
is just an unobtrusive way to solve this unusual issue
- enable the module
- navigate to
admin/settings/language#js-translations
- expand "JavaScript translations" fieldset
- use either "Invalidate js translations" or "Rebuild js translations" buttons
Comment #66
marcushenningsen CreditAttribution: marcushenningsen commentedThis small module works for me. I don't really like your custom module package name (arhak - tweaks), though, but that's a minor issue and I just changed it to my likings (Multilanguage =))
Comment #67
arhak CreditAttribution: arhak commented@#66 sorry about that
that is the way I mark the modules which doesn't have a project page in drupal.org
it should go under Multilanguage indeed
I haven't created a project for this neither for other modules because I won't be able to use CVS (explained at Looking for a CVS committer) and that workaround shouldn't be provided as a patch, since this issue has its own patch going on
Comment #68
koorneef CreditAttribution: koorneef commentedThanks for your mini-module !
It solved my JS language problems. Hope you get CVS access soon.
Comment #69
sinasalek CreditAttribution: sinasalek commentedsubscribed
Comment #70
CKIDOWgreat! thx!
Greeting
CKIDOW
Comment #74
fuerst CreditAttribution: fuerst commentedSorry, did not intend to test the failed patch again..
BTW: Modul from #65 works well, thanks!
Comment #75
arhak CreditAttribution: arhak commented@#68 now I have a partner who makes commits on my behalf
do you think such a tiny module should have its own project?
for feature request/bug fixes?
Comment #76
sinasalek CreditAttribution: sinasalek commented#65 works for me too.
Comment #77
arhak CreditAttribution: arhak commented@ #66 marcushenningsen, #68 koorneef, #74 fuerst, #76 sinasalek
does this worth to be in its own project?
or would be better leaving it here "as is" at #65?
Comment #78
arhak CreditAttribution: arhak commentedBTW: if #65 would be a module I would add it a feature to re-import translations, since Drupal doesn't have a way to "upgrade" translations
Comment #79
sinasalek CreditAttribution: sinasalek commentedI think it can be part of the i18n module since it's about translation. But if its maintainers didn't like the idea then a separate module might be the only option because this patch/module i believe is most have for almost all non English/Multilingual sites.
Comment #80
dagmarWait, we cannot test a third party module to solve a core issue. If this bug is still present in Drupal 7 (maybe it was fixed weeks ago) we should provide a patch to fix the core, and once it was committed, make a port to D6.
I'm using #52 in my drupal 6 sites and every times that cron runs, I get a lot of message in my dblog report
I'm not sure if this is the expected behavior, cron runs every three hours, why my js files are parsed if they probably doesn't change.
I'm changing the status of this issue to critical since it seems not be enough important to core maintainers and people that build sites with several languages needs solution for this issue.
We need that somebody confirms that this issue is still present in Drupal 7, if not we should back to D6 version.
Comment #81
arhak CreditAttribution: arhak commented@#79 I wouldn't like to speak lightly, but it seems to me that the maintainer of
i18n
doesn't want to make his module more complicatedno new features allowed?
http://drupal.org/node/578360#comment-2220526
http://drupal.org/node/582438#comment-2220622
maybe an
i18n_bonus
module? ("i18n_bonus", "i18n_extra", or what?)sinasalek, make me a proposition about where to bundle all i18n support we can bring, lets talk about it through mail
Comment #82
arhak CreditAttribution: arhak commented@#80 sorry for dirtying this thread talking about an "alternative" module, it just seems like this patch stopped being attended
I'm in favor of this patch getting done
(don't know what about it in D7)
in the meantime, just referencing an "alternative" solution
now debating if we should open a module to get some fixes like this collected and discuss on its issue queue (letting this patch thread be)
sorry for the inconvenience
Comment #83
Heine CreditAttribution: Heine commented@81, @82, this really should be solved in core.
Comment #84
arhak CreditAttribution: arhak commented@#83 we all agree
"alternative" & "in the meantime" were already mentioned above
EDIT:
PS: to get off this thread I opened a forum topic Gathering more i18n support
Comment #85
sinasalek CreditAttribution: sinasalek commentedIt seems that everyone is agree that this patch should be in core. So if there is any hope of getting it into the core i think maybe a separate module is better , this way we can show the popularity of it to core maintainers. Otherwise IMHO http://drupal.org/project/i18nui by @Jose Reyero is an appropriate place for this module, since i18n maintainer does not accept it.
I invited Gábor to this thread , he was a core maintainer once and he is now responsible for localization server. Maybe he show us the right direction for getting this into the core.
Comment #86
Gábor HojtsyI was asked to look at this issue, but I found it quite hard to parse the problem and the proposed solution here. Can someone who's already active here summarize the issue and the proposed solution, so I can help out?
Comment #87
plach@Gábor Hojtsy: I am providing a summary and a rerolled patch ASAP, meanwhile you can have a look to #2.
Comment #88
plachRerolled #59. This should be ready to go. If someone can test it, confirm it works, and set it to RTBC, we should be able to get this in core soon. The D6 version is almost identical with the exception of simpletests, so backport shouldn't be a problem.
The priority guidelines say this isn't a critcal issue.
The problem we are facing here is that the Locale module is unable to rebuild the Javascript translation files: if one of these gets accidentally corrupted or lost there is no way to tell Drupal to rebuild it.
Currently
_local_rebuild_js
creates the javascript file only if the hash code of the newly gathered string translations is different from the existing one. The patch simply adds a check on the file existence, this way if the file has been somehow lost it gets rebuilt even if the hash codes are identical.A simpletest is added in the 7.x version.
To test the patch: apply it, add a language, create a translation for the "Unspecified error" string and visit the "admin/reports/dblog page", delete the javascript translation file, clear the cache, visit "admin/reports/dblog page" again and you should find the rebuilt file the "languages" directory.
@dagmar:
There is something that's clearing your caches (at least the ones triggering the parsing of javascript files) at each cron run, this should have nothing to do with this patch: I tested it on a plain 6.x installation and a cron run doesn't trigger a new parsing.
Comment #89
plachThere were some inline comments and PHP docs not wrapping correctly.
Code is identical to #88.
Comment #90
Gábor HojtsyI've looked at the patch, and it seems to be good to solve the issue, and doing what it says :) I did not try to run it, but it looks quite good.
Comment #91
sinasalek CreditAttribution: sinasalek commentedThanks Gábor for the comment , i hope that this time core maintainers accept.
@plach Thanks for re-rolling the patch, i'll test D6 version and report back.
Comment #92
dagmarSorry for change this to critical. Now that, Heine and Gábor Hojtsy has seen this issue, I'm changing the priority to normal again.
@plach: Maybe the cache for block is triggering the rebuild of the cache. Can this be the reason of my rebuild messages?
Comment #93
fuerst CreditAttribution: fuerst commented@#77: I see this module as a welcome work around. Fixing the bug in core is the prefered way though. So there is no need to make it a Drupal project I think.
@#78: Open Atrium (openatrium.com) has some mechanism to upgrade translations. May be worth to look there before doing own work.
Comment #94
arhak CreditAttribution: arhak commented@#93 thanks fuerst for pointing that out
@#93#77 it seems that this patch will move on again, then that little module has no reason to become a project
@#93#78 wasn't aware about Open Atrium, will have to take a look at it
Comment #95
plachTests pass, Gabor gave his ok, and the D6 patch (which is identical to the D7 one except for tests) has been tested and confirmed to work.
However I feel uneasy to set my own patch to RTBC: can't someone find 10 minutes to test it and confirm this works even on D7?
Please keep in mind that the sooner the D7 version goes in, the sooner we can have a backport for D6.
Comment #96
plachComment #97
sinasalek CreditAttribution: sinasalek commentedI think i'll have time to test it tommorow. both d6 and d7
Comment #98
sinasalek CreditAttribution: sinasalek commentedI'm unable to reproduce the issue on my local Drupal installation!! it might have something to do with windows or the other modules. I'll try again on Linux and fresh install. it might takes a little bit more time
Comment #99
sinasalek CreditAttribution: sinasalek commentedI'm unable to reproduce the issue on my local Drupal installation!! it might have something to do with windows or the other modules. I'll try again on Linux and fresh install. it might takes a little bit more time
Comment #100
arhak CreditAttribution: arhak commentedI'll test the D6 patch today (don't know when the D7 patch)
How to reproduce the issue:
- fresh Drupal install
- enable
locale
module- (lets pick Spanish language for instance)
- add some
.po
files in that language (e.g.es.po
enablingdhtml_menu
module would be enough, since it has Spanish translation)- add the new language
admin/settings/language/add
- visit some page in Spanish (
dhtml_menu
menu is present on every page)- check directory
default/files/languages
was created and a translation file as well (e.g.es_[MD5].js
)- manually delete the
.js
file- refresh the page in Spanish and check the file was/wasn't re-created
Comment #101
arhak CreditAttribution: arhak commentedD6 not working:
- patch cleanly applied
- bug reproduced following steps @#100
@plach
Perhaps I'm making a dummy question, but all changes in the patch are made to function
_locale_rebuild_js
.Is the bug actually in there?
Wasn't that function working properly?
Did you reviewed the mini-module @#65?
The mini-module @#65 uses
_locale_rebuild_js
as it is.It does NOT introduce any new code. Just a callback and a link to manually invoke that function on demand. (and has received positive feedback)
The problem seems to be (IMO) to detect when the file is missing (note that the hash will be the same known in DB)
am I wrong?
Comment #102
arhak CreditAttribution: arhak commentedI just re-read #88 and the issue is well described
I'm not seen this happening, since
_locale_rebuild_js
is not getting called (as I recall, haven't debug it recently)BTW: without the patch, clearing the cache also fixes the problem, the only reason for another solution (like mini-module @#65) is that "clear cache" can't be afforded by sites with heavy traffic
If testing the patch requires clearing the cache (as I did when testing it on D6) the file will be successfully rebuilt, but then being manually deleted once again brings the same issue back. (and clearing the cache again doesn't makes sense, since it works too without the patch)
PS: forgive/correct me if I'm wrong in something
Comment #103
plachI tested everything again and I can confirm the patch works both on D6 and on D7.
These are the steps to reproduce the bug:
Locale
modulefr_[MD5].js
in thefiles/languages
directoryTo test the patch start from the situation above and:
@arhak:
I reviewd #65: it works without touching
_locale_rebuild_js
because it resets the hash values stored in the DB. This way the check the patch fixes passes and the file gets actually rebuilt._locale_rebuild_js
is called everytime the cache is cleared, however it does not rebuild the file unless some string (hence the overall MD5) has changed.I think clearing the cache is ok, also to rebuild lost CSS or JS aggregates you have to do that.
Comment #104
arhak CreditAttribution: arhak commentedboth patches work
(as described @#103)
tested (before and after patching) on D-6.14, D-6.15, D-7.x-dev(2009.12.15 tarball)
D6 patch cleanly applies
D7 patch applies with three offset warnings (trivial)
Comment #105
arhak CreditAttribution: arhak commentedon the side notes:
1- I'm not aware about the code style guidance for fallingthrough cases, but for
case 'rebuilt':
falling throughcase 'created':
I would prefer and ending comment different from// (re)creation.
I suggest to use something like
// fall through
or// NO break;
as the last statement2- consider the unclear logic around
$status
2a-- variable being first set to
'deleted'
to be corrected later on for'updated'
.Maybe this is the better way, (since at the deletion point there is no way to ensure that
file_unmanaged_save_data
will succeed), but$status = 'deleted';
might be commented about it2b-- uniformity when testing casuistic
consider an
elseif
to avoid mixingif-else
with ternary operator3- (D6 code is frozen, but for D7) the whole logic of function
_locale_rebuild_js
should be cleaned up (would that be possible?)an overall view:
testing several times the
$status
variable is not a big dealmy concern is around these combinations:
-
(!$data || $changed_hash)
-
$data && ($changed_hash || ...)
-
$status && $changed_hash
PS: last, but not least, this patch fixes the bug by means of clearing the cache, if a production site wouldn't afford this cost the module @#65 keeps being a best (though workaround) approach, since manually intervention would be required anyway, I would prefer not to lose all the cached data
Comment #106
plach@arhak: Thanks for reviewing and testing:
1. That was not a two-lines comment, I didn't mean to have an inline comment saying just "(re)creation"; perhaps the one in the attached patch is more clear.
2. I added some inline comments and introduced an
elsif
branch as suggested.3. If you wish to clean up
_locale_rebuild_js
please open another issue. Let's not hold up this bug fix.About cache clearing, as I said before, I think it's ok as a core solution: if you can't afford to clear caches you'll have to resort to manually clear the
variables
entry in thecache
table and reset thejavascript_parsed
variable; but this is a nice task for a contrib module as yours. In core we have no such fine grained cache handling: if you wish to rebuild CSS/JS aggregates you have to clear all caches.Comment #107
arhak CreditAttribution: arhak commentedmarking it RTBC as per #95 (and my own tests)
on the side notes:
- D7 patch now cleanly applies (against 7.x-dev 2009.12.15 tarball)
- patches keeps being the same since #89 (just got more comments and an
elseif
instead of ternary operator)@plach: thanks a lot for taking the time to fix this
forgive my misleading comments #101, #102, #105, and those related to the mini-module @#65
Comment #108
plach@arhak: thanks for helping, hopefully the bot will agree on the RTBC status :)
Comment #109
plachdouble
has
here :(This review is powered by Dreditor.
Attaching the fixed patches.
Comment #110
andypost+1 to commit, tested on d7-cvs and 6.15
Comment #111
Yas375 CreditAttribution: Yas375 commentedAfter applying a patch to D6 and clear cache (with devel module) I recieve error: Fatal error: Unsupported operand types in /var/www/publish/stereo/htdocs/modules/locale/locale.module on line 522
And I have to revert chacges to make my site working again
Comment #112
Yas375 CreditAttribution: Yas375 commentedI have changed permissions for my includes/locale.inc and it's ok now.
yas@serv ~/stereo $ chmod 777 includes/locale.inc
yas@serv ~/stereo $ patch -p0 < locale-338630-109.D6.patch
Comment #113
webchickThis is a warning level. What is the reason such a JS file might be lost? Can we give users some direction on what to check so that it doesn't happen again?
The rest of this test is commented really well and is easy to follow, except for this chunk here which is the most complex. Could you just toss another couple inline comments before each of these that explain what's going on?
Also, could someone just confirm quickly that Yas375's results are an outlier, and not something we need actively be concerned about?
This review is powered by Dreditor.
Comment #114
plachComments added as suggested. D6 version is untouched.
I ain't sure it's correct, but the reason I used a warning is this shouldn't happen in production environments. The only situations in which I had this problems were while deploying sites and not having the rights to write in the 'files' directory. Thus I've been forced to rebuild the file through Drupal.
I can't imagine any (non-malicious) reason why those files would disappear in a production site.
I tested the patches again and had no errors. It seems Yas375 had troubles with applying the patch.
Comment #115
arhak CreditAttribution: arhak commentedHard to know:
- huge chance if a DB backup is imported to other site which doesn't have those files generated
- site moved (without some files)
- manually deleted
- changing file system setting (?)
- applying patches to support private & public download methods
- Can't reproduce it
- Can't see how it might be possible with/without patch or even with a partial patch applied (assuming the missing file permission allowed only part of the patch), since that line does
$parsed += locale_inc_callback('_locale_invalidate_js');
-- the
$parsed
variable is properly initialized$parsed = variable_get('javascript_parsed', array());
-- function
_locale_invalidate_js
also takes care of its local variable$parsed
which should always return an array as well-- the guess I can figure out would be having a corrupted variable
javascript_parsed
which would cause a wrong initializationComment #116
arhak CreditAttribution: arhak commentedcross-posted with #144
Comment #118
arhak CreditAttribution: arhak commentedComment #120
plachGreen. Setting back to RTBC.
Comment #121
webchickOk, thanks. Committed to HEAD!
Marking down to 6.x.
Comment #122
sinasalek CreditAttribution: sinasalek commentedCongratulation everyone :) @arhak @platch
Comment #123
arhak CreditAttribution: arhak commentedD6 is also RTBC since #95 & #104
EDIT: last D6 patch @#109 http://drupal.org/files/issues/locale-338630-109.D6.patch (which keeps being the same since #89 with insignificant minor changes)
Comment #124
arhak CreditAttribution: arhak commented@plach: thanks for the effort of being re-rolling these patches during a whole year
@others: thanks for testing and feedback
Comment #125
plachWow, it's been tough. It seems we need Gabor again :)
Comment #126
realOFF CreditAttribution: realOFF commentedCongratz! and Thank You!
Comment #127
arhak CreditAttribution: arhak commentedhello?!
a RTBC patch, already committed to HEAD waiting for D6 commit @#123, @#109
Comment #128
webchickarhak:
1. That attitude does absolutely nothing but sap will and energy from people who you need to help you. Stop.
2. We need to keep 7.x and 6.x in sync, so the 7.x patch that was committed needs a back-port, including the minor differences. Rolling that would be a constructive use of your time.
Comment #129
arhak CreditAttribution: arhak commented@#128
1. by no way I meant a bad attitude :(
2. when did the patches went out of sync? ... oh, you mean D7#114 vs D6#109 ... I apologizes
Comment #130
arhak CreditAttribution: arhak commented@#128 yet... I just
diff
them and they are sync#114 just changed
LocaleTranslationFunctionalTest
remaining "minor changes" are synchronized up to #109 as they were committed to HEAD
PS: was the attitude problem around the "hello?!" part?, deeply sorry for that
Comment #131
plachAs arhak said, patches #109 (D6) and #114 (D7) are in-sync. The only differences are due to the string-concatenation standard change and the presence of simpletests in the D7 version.
Moreover the D6 version has been successfully tested multiple times (#110, #112, #114), thus setting back to RTBC.
Comment #132
webchickCool, my mistake. Thought there was a comment change, too.
Comment #133
plach@webchick: the comment change was in the simpletests :)
Comment #134
W.M. CreditAttribution: W.M. commentedHello!
So this patch (#114) solves the problem in the same manner as the tiny module posted at #65 ?!
I get all those locale related errors logged in that I want to get rid off...
Thanks for help!
Comment #135
arhak CreditAttribution: arhak commented@#134
their goals are the same, the approaches are different
patch's pro-cons:
- (pro) the patch works automatically when clearing the cache (the mini-module has specialized buttons for it)
- (pro) the patch detects which are the missing files (the mini-module blindly attempts them all)
- (con) the patch requires to clear the entire cache (the mini-module only works on the JS files)
while the amount of generated logs differs, it depends on the situation which alternative generates more logs, but both generate "parsed" and "created" log entries (since it is in core)
probably you might get advantage of the module
log_clear
(included in Utility package) which allows you to selectively drop a sub-set of logs (according to those being filtered)then you could filter by type "locale" and the clear those selected logs
PS: Note that patch @#114 was already committed to D7, its D6 backport is still waiting @#109
Comment #136
nonsie+1
Looking forward to having #109 in D6 soon
Comment #137
Gábor HojtsyThanks, committed to Drupal 6.
Comment #138
sinasalek CreditAttribution: sinasalek commentedGreat! Thanks everyone , Gábor
Comment #140
mafi-a CreditAttribution: mafi-a commentedI just updated from 6.14 to 6.16 and the described issue is still there...
My workaround from privious versions doesn't work anymore:
I added this hook to locale.module:
Has anyone else problems with the latest core version?
Comment #141
plach@mafi-a: Did you clear the cache?
Comment #142
mafi-a CreditAttribution: mafi-a commentedI dug deeper into the code and realized that my problem isn't really with locale but more about the file system
file_create_path(variable_get('locale_js_directory', 'languages'));
returns the wrong path.
I set the issue back to fixed. This should be discussed elsewhere
Comment #143
arhak CreditAttribution: arhak commentedactually, it was closed (since it was committed already)
Comment #144
W.M. CreditAttribution: W.M. commentedSo what's the solution ?!
Comment #145
Gábor Hojtsy@Geir19: Upgrade to Drupal 6.16.
Comment #146
Jaapx CreditAttribution: Jaapx commentedHave the same problem of a lot of file not found entries in wachdog
- D6.15, #145 was not the solution for me, so D6.16 produced the same problem
- Dutch language
- Private files enabled (and working fine)
- Report in wachdog: http://(mydomain)/(directory for private files)/languages/nl_ed3ec6b53945993503faf34345039f3e.js?o
- Must be: http://(mydomain)/system/files/languages/nl_ed3ec6b53945993503faf34345039f3e.js?o
Comment #147
arhak CreditAttribution: arhak commentedit is not intended to work with private download
it will be supported in D7
D6 is code freeze, i.e. no new features in
here you can find a core hack which address your case #572516: make private download method support css/js aggregation, color module and js translations
Comment #148
Jaapx CreditAttribution: Jaapx commentedArhak, thank you for your answer. I missed this discussion in my search.
Comment #149
ducdebreme CreditAttribution: ducdebreme commentedSubscribing
Comment #150
Michsk CreditAttribution: Michsk commentedI got this error, also for the dutch language, in D6.16. I thought these patches were committed?
Comment #151
arhak CreditAttribution: arhak commentedit was committed, check if you are using private download method (read #147)
or else, almost sure you should open a new issue, since I doubt that the reason might be on this fix
if so, drop here a link for others having similar issues to follow it
Comment #152
Bilmar CreditAttribution: Bilmar commentedI am also still experiencing this issue. I'm using Drupal 6.16 and English + Japanese languages.
Is this a known issue?
Comment #153
arhak CreditAttribution: arhak commentedplease, check whether you're using private download method (read above #147, #151)
Comment #154
Bilmar CreditAttribution: Bilmar commentedThanks for the quick reply arhak
I haven't played with any settings but found at www.example.com/admin/settings/file-system
Download method: Public - files are available using HTTP directly.
Is this the setting you are asking? So does this mean it should be working?
I enabled the module at http://drupal.org/node/338630#comment-2035162 but it doesn't seem to help =(
Comment #155
arhak CreditAttribution: arhak commented@#154 yes, that the setting I was talking about, and it is public therefore it should work
could you please check your directories' structure and permissions
you should find
sites/default/files/languages
with javascript files in it- did you cleared the cache?
(this fix is intended to work when clearing the cache, read #135)
- what are the permissions of that directory and its respective files?
- what happens if you rename the
languages
directory to something else?lets say "languages2", to simulate a deletion and check if it gets re-created
Comment #156
Bilmar CreditAttribution: Bilmar commentedEvery time I flush the cache I am seeing the warning message on the first page I go to next. When I clear the cache as admin then in a different browser go to any page as a non-admin user (authenticated role) the warning message shows as well.
- the Languages directory at sites/default/files is set to 0777
- some files within are set to 0666, 0664 and 0777
Should I change the languages folder permissions or any files within?
I made a backup of the Languages directory and deleted it. I flushed the cache on my website and got the warning message as before. I checked sites/default/files and there was a new Languages directory. The Files folder is set to 0777, the Languages folder is set to 0777, and the one js file within is set to 0664.
Please let me know if any further information is required to better troubleshoot.
I really appreciate your help!
Comment #157
arhak CreditAttribution: arhak commentedI pretty sure we should be moving this to a new issue and leave its reference here
according to what you describe at #156 this patch is working as expected
- what languages do you have enabled?
- what the language prefix of the newly created JS file? (first letters before the underscore)
- what happens when you visit the site in other languages? (it is expected to appear a warning and also a new JS file to be created for such languages)
once the site have been visited for every language, no more JS file should be created and no more warnings either
if your site isn't being moved, those JS files should live there until you enable new modules causing more JavaScript translation to be imported (in which case, they might be re-created and log message should appear again for each language)
when are the undesirable/unexpected warning arising then?
Comment #158
arhak CreditAttribution: arhak commentedaccording to #152 your JS file should start with "jp" for Japanese (for English there won't be any translation, since it is the source language)
how many often do you see the warnings?
are those warnings for the same warned files? e.g. misc/drupal.js, misc/jquery.js, misc/collapse.js, etc
if so, then the new issue should be related to "why are those JS files getting lost over and over?"
note that this issue is about to get them back and it is working
also note webchick at #113
Comment #159
arhak CreditAttribution: arhak commentedif the answer isn't mentioned at #115, then it should be investigated to satisfy webchick's question at #113
also note plach at #114
EDIT: links
Comment #160
Bilmar CreditAttribution: Bilmar commentedHello,
I have Japanese enabled and it's set as the default with no path prefix and English with path prefix /en
Japanese: www.example.com
English: www.example.com/en
The file being created in the sites/default/files/languages folder is ja_........js which looks to be the language code shown at www.example.com/admin/settings/language
I am always seeing the same warning shown below, and it shows on the first page I view right after flushing the cache.
line 1708 looks to be the $file line below, which is which a larger function
undesirable/unexpected:
It is ok if the admin sees this warning, but authenticated users are also seeing this warning if they happen to view a page before the admin views a page right after the cache is flushed, which makes users of the site think something is wrong with the site =(
I'm sorry for any troubles and really appreciate your help on this.
If there is any other info I can provide please let me know.
Thank you
Comment #161
arhak CreditAttribution: arhak commentedthis would be another issue
I recall users complaining about it being a security issue unveiling filesystem directory tree
but not addressed here
sites/all/themes/example/js/jquery132min.js
this seems to be the problem, and also unrelated to this issue
it seems you have no "read" access to that file, check whether Apache's user (www-data) has read access to it (if in doubt, give it a 664 to test if the warning goes away)
finally, the conclusion keeps being the same, this issue is working properly (as expected) and therefore, closed
it would be more useful to open new issues for troubleshoting those issues, and if you think it might help others, drop their respective links over here for other to follow up
Comment #162
Bilmar CreditAttribution: Bilmar commentedThank you very much arhak for your kind explanation
I will do the tests as you recommended and if it does not work i will open a new issue
Regards
Comment #163
clashar CreditAttribution: clashar commentedsubscribe
Comment #164
janhajk CreditAttribution: janhajk commented@Laurent_ #9
Found a solution for your Problem:
http://tech.janschaer.ch/content/drupal-problem-mit-language-files-dejs
Translate with google it's in German
Comment #165
ninebark CreditAttribution: ninebark commentedI have Drupal 6.20 which incorporates the fix discussed here. I see this error message on every page on the French side of my site:
The selected file /tmp/fileroEf4K could not be uploaded, because the destination languages/fr_fe5252174f66c5935e23acb7707e47cd.js is not properly configured.
If I delete the .js file or the /languages directory and then clear the cache, neither the file nor the directory is recreated. I tried installing the locale_rebuild_js module, but the check boxes next to both the English and French languages on admin/settings/language/rebuild_js are greyed out, so I cannot manually rebuild them either. Both /files and /files/langauges have permissions 777.
Any ideas?
Comment #166
arhak CreditAttribution: arhak commenteddid you tried #65
Comment #167
ninebark CreditAttribution: ninebark commented@arhak - Thank you, but this solution didn't work for me either.
I've had to resort to hiding the error message.
Comment #168
Loquere CreditAttribution: Loquere commentedI also had this problem. There were thousands of log messages about js language files which can't be created. Also my temp folder was growing really fast.
None of the suggested solutions worked for me. I've tried to solve this issue for days... and finally managed to fix it.
Here is what I did:
In includes/locale.inc file there is _locale_rebuild_js() function. In that function I've changed the line
if (file_unmanaged_save_data($data, $dest)) {
to
if (file_put_contents($dest, $data)) {
And now the new language js file is saved successfully to the languages folder.
The problem was that the file_unmanaged_save_data() function first saves the file to temp folder and then tries to move it to destination folder. And that's what caused this problem: the files were saved with apache ownership and the script couldn't move the file because it was with user ownership.
That might not be a professional solution. I am not Drupal expert. But that solved my problem.
Comment #169
oriol_e9gComment #170
fuerst CreditAttribution: fuerst commentedWhen looking at
file_unmanaged_save_data()
and related functions (file_unmanaged_save_data()
,file_unmanaged_copy()
anddrupal_chmod()
) I can not see anything that will change ownership. I rather suggest you may check the ownership/permissions of your destination directory. Looks like the Apache user can not write there.BTW: Set issue Version and Status back to 6.16/closed (fixed) because #168 seems not to be related to the issue.