Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I get this error on almost every administration page:
Warning: filemtime(): stat failed for drupal-7.0.fr.po in l10n_update_source_check_file() (line 288 of /var/www/devia.org/sites/all/modules/l10n_update/l10n_update.check.inc).
Warning: filemtime(): stat failed for drupal-7.0.nb.po in l10n_update_source_check_file() (line 288 of /var/www/devia.org/sites/all/modules/l10n_update/l10n_update.check.inc).
Comment | File | Size | Author |
---|---|---|---|
#24 | file-uri.patch | 582 bytes | Gábor Hojtsy |
#9 | screenshot.1.png | 3.54 KB | javizcaino |
#8 | debug_backtrace-output.txt | 101.41 KB | Tor Arne Thune |
#6 | l10n_update-debug_backtrace.patch | 640 bytes | Tor Arne Thune |
Comments
Comment #1
Gábor HojtsyWhat are the permissions on that file? Can the webserver read it? Sounds like it cannot.
Comment #2
Tor Arne Thune CreditAttribution: Tor Arne Thune commented/var/www/profiles/standard/translations$ ls -l
-rw-r--r-- 1 root root 699223 2011-01-11 16:03 drupal-7.0.fr.po
-rw-r--r-- 1 root root 492052 2011-01-18 16:04 drupal-7.0.nb.po
Comment #3
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedComment #4
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedGetting the same error on a new multi-site installation now, where the translation files are stored and shared between multiple sites in sites/all/translations.
Comment #5
Gábor HojtsyOk, well, it would be great to know a better stack trace of the case when this is happening. It is possible the files are looked for in the wrong directory(?). Can you provide a debug_backtrace() of when this is happening? Thanks!
Comment #6
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedI would be happy to do that, but I'm not sure how to add the debug_backtrace(). I searched a little on drupal.org, but couldn't figure out how. Could you update the attached patch with the correct way to do it?
Comment #7
Gábor HojtsyLet's try these three lines first at the place here you tried to add that line:
Comment #8
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedOk, so I patched the file as described, enabled a module, navigated to another administration page and got the same errors as before, preceded by the debug_backtrace dump. I attached it as a text file, as it is kind of large.
Comment #9
javizcaino CreditAttribution: javizcaino commentedSubscribing because it also happens to me.
As a starting point, I can tell you that it automatically can update the language of several modules, but it always stops when actualizing Drupal Core translation and appears the supplied error message...
Comment #10
lismail CreditAttribution: lismail commentedGuys,
I had the same error before. However (at least for me) it looks like permission issue. Here's the way I solve it:
Previously, my /translations directory and its contents are:
drwxrwx--- 2 root apache 512 Jan 27 02:46 translations
-rw-r--r-- 1 apache apache 1687 Jan 27 02:43 devel-7.x-1.0.id.po
Because the .po files created have write permission given only to apache, I changed the /translations directory ownership:group with:
chown apache:root translations
That's all, and the error gone.
Cheers,
Lismail
Comment #11
Dematron CreditAttribution: Dematron commentedBegin solving problem as lismail describe. That's take effect. And I has noticed that the problem appeared when I copied site from one server to another, and nearly all permissions droped or corrupted.
Comment #12
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedThe translations directory was created by the module and has these permissions:
drwxrwxrwx 2 username username 4096 2011-02-02 18:14 translations
The files in the translations directory have been saved there by the module and have these permissions:
I'm really stumped on this.
Comment #13
Gábor HojtsyI did not have time to look into this, but my assumption for now is that the file is not looked for at the right place (the error message does not have a specific path either). I'd suggest people looking into this maybe look at it with this in mind.
Comment #14
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedOkay, so I have reinstalled my multi-site development environment. This time I created the translations directory before setting 'Store downloaded files' to this directory:
After having set 'Store downloaded files' to this directory (
sites/all/translations
), I went to Regional and language > Languages and added a predefined language (French). Everything went okay, and the files were stored insites/all/translations
:After the messages telling me that everything went successful with the downloading and importing of the new language, I navigated to Administration > Configuration and got the same filemtime() errors again, as in the original post.
Comment #15
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedWhere is the file path (uri variable in the $source array) specified?
I see this code:
$source->uri = $file->filename;
, but this does not include the file path, if I understand correctly?The function in question is:
I'm really not qualified to find a solution for this, or even look at this code, but I will try to understand where the file path gets set.
Comment #16
joostvdl CreditAttribution: joostvdl commentedSame problem here....
Comment #17
fietserwinAssumption in #13 is correct. filename is only the filename without any path part. The change below worked for me to prevent the warning. BUT: The line above ($source->uri = $file->filename;) looks suspicious tome as well: assigning a filename (without path part) to a uri property while the $file object has a uri field itself...
Values during execution (only checking local):
old code:
new code (prevents warning):
new code (should it be like this???):
Comment #18
AlanAtLarge CreditAttribution: AlanAtLarge commentedSubscribing
Comment #19
kenheim CreditAttribution: kenheim commentedSubscribing
Comment #20
fietserwinComment #21
Jose Chaves CreditAttribution: Jose Chaves commentedsame problem here...
Comment #22
TedTheRushBandFan CreditAttribution: TedTheRushBandFan commentedVerification of code correction proposed by post #17:
Change in file, 'l10n_update.check.inc' line 287,
from, "$source->uri = $file->filename;"
to, "$source->uri = $file->uri;"
No error reported at save. Translation of website successful.
Thank you fietserwin, module devs and Drupal community! YAY!
Comment #23
Homotechsual CreditAttribution: Homotechsual commentedComment #24
Gábor HojtsyOk, looks like there is agreement that this change looks good. I'm committing this and will hopefully release yet another alpha with other fixes included soon (in a couple days).
Comment #26
joostvdl CreditAttribution: joostvdl commentedWhen will a new alpha be released?
Comment #27
Gábor HojtsyI'd like to at least get the drush fixes in from #1057150: Rework drush l10n-update commands. Will try to set aside some time for this. Please leave this issue as fixed.
Comment #28
Gábor HojtsyFor people waiting to roll this fix out, the 7.x-1.0-beta1 version I just released includes it: http://drupal.org/node/1158904