WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 3 months ago

#25714 new defect (bug)

Notices with translation upgrade

Reported by: GregLone Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.7
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Hello,

There are some php notices when WordPress tries to upgrade translations if the file does not exist. As a result, the upgrade fails.

Warning: copy(/volume1/web/screenfeed/wp-content/languages/themes/twentyeleven-fr_FR.po): failed to open stream: Permission denied in /volume1/web/screenfeed/wp-admin/includes/class-wp-filesystem-direct.php on line 217

In this case, these are the upgrades for TwentyTen and TwentyEleven: while the themes exist in the folder wp-content/themes, the .po and .mo files in the folder wp-content/languages/themes don't.

Regards.
Greg

Attachments (1)

i18n-upgrade-notices-fail-37.png (195.2 KB) - added by GregLone 6 months ago.
Notices on language upgrade

Download all attachments as: .zip

Change History (13)

GregLone6 months ago

Notices on language upgrade

comment:1 nacin6 months ago

Good thing is, the core update works just fine. These kinds of copy errors shouldn't actually be considered a fatal error by the updater, but we didn't get there for 3.7.

Could you explain a bit more *exactly* when and where this occurs? Unfortunately the PHP warning is not very useful for debugging.

comment:2 GregLone6 months ago

Edit (arg):
it does not occur because the file does not exist, but because the rights for the folder wp-content/languages/themes were not sufficient (755). Pass the folder to 777 and all is fine. Sorry for the mistake -_-'
So, in the end, the problem is trivial: some notices if the upgrader can't write into the folder (maybe it should display a message?).

@nacin
Sorry, I though the screenshot was enough to explain the situation.
It occurs when a language needs an update: the update button shows up in /wp-admin/update-core.php. Just click it and follow the process.

comment:3 GregLone6 months ago

  • Severity changed from normal to trivial

comment:4 SergeyBiryukov6 months ago

  • Component changed from Filesystem to Warnings/Notices
  • Milestone changed from Awaiting Review to 3.7.1
  • Severity changed from trivial to normal

comment:5 follow-up: dd326 months ago

755 should be high enough to allow writing to the directory when using the direct transport, since it specifically checks the ownership.

775 would be needed when using Group Writable, and 777 would be needed when relying on the "everyone can write to this" check, These last two should only be hit in the event that someone has forced WordPress to use the direct transport even though it rightly detected it couldn't write to the files.

Our Language is_writable() checks only check wp-content/languages (well, actually wp-content since the language directory might not exist) is writable, it doesn't check wp-content/languages/themes is also writable.
How those directories were created with 755 if your other directories were 777 I'm not sure though, as FS_CHMOD_DIR should've been set to whatever ABSPATH's permissions were.

comment:6 in reply to: ↑ 5 ; follow-up: GregLone6 months ago

Replying to dd32:

755 should be high enough to allow writing to the directory when using the direct transport, since it specifically checks the ownership.

Agree.

775 would be needed when using Group Writable, and 777 would be needed when relying on the "everyone can write to this" check, These last two should only be hit in the event that someone has forced WordPress to use the direct transport even though it rightly detected it couldn't write to the files.

I wasn't aware of the 775/777 + direct transport, that explains a lot. There's this "myth" where "if you can't upload your photos, chmod your content folder with 777 and put define('FS_METHOD', 'direct'); in your wp-config.php, and it'll work". Lots of people do that, and I think some of them even chmod 777 all files/folders.

Our Language is_writable() checks only check wp-content/languages (well, actually wp-content since the language directory might not exist) is writable, it doesn't check wp-content/languages/themes is also writable.
How those directories were created with 755 if your other directories were 777 I'm not sure though, as FS_CHMOD_DIR should've been set to whatever ABSPATH's permissions were.

OK, noted, thanks.

comment:7 in reply to: ↑ 6 dd326 months ago

Replying to GregLone:

Replying to dd32:

775 would be needed when using Group Writable, and 777 would be needed when relying on the "everyone can write to this" check, These last two should only be hit in the event that someone has forced WordPress to use the direct transport even though it rightly detected it couldn't write to the files.

I wasn't aware of the 775/777 + direct transport, that explains a lot. There's this "myth" where "if you can't upload your photos, chmod your content folder with 777 and put define('FS_METHOD', 'direct'); in your wp-config.php, and it'll work". Lots of people do that, and I think some of them even chmod 777 all files/folders.

That's exactly what happens, people who are attempting to fix upload problems should NOT be defining FS_METHOD though, as it affects only upgrades, and has the potential to decrease their sites security as well (on shared hosts) and lead to errors such as this one.

comment:8 alex-ye6 months ago

  • Cc nashwan.doaqan@… added

comment:9 follow-up: azaozz6 months ago

There's this "myth" where "if you can't upload your photos, chmod your content folder with 777 and put define('FS_METHOD', 'direct'); in your wp-config.php, and it'll work".

That's exactly what happens, people who are attempting to fix upload problems should NOT be defining FS_METHOD

Can we check if defined('FS_METHOD') && FS_METHOD === 'direct' and throw another warning when a file fails to copy? Including a link to http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants would be good.

comment:10 nacin6 months ago

  • Milestone changed from 3.7.1 to Awaiting Review

Seems like this is not for 3.7.1.

comment:11 in reply to: ↑ 9 GregLone6 months ago

Replying to azaozz:

Can we check if defined('FS_METHOD') && FS_METHOD === 'direct' and throw another warning when a file fails to copy? Including a link to http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants would be good.

The filter 'filesystem_method' can also interfere.
I don't know if it's the best way, but personally, I check the filesystem method like this:

$credentials = request_filesystem_credentials( wp_nonce_url('update-core.php?action=do-core-upgrade', 'upgrade-core'), '', false, ABSPATH );
$fs_method   = get_filesystem_method( $credentials, ABSPATH );

comment:12 nacin3 months ago

  • Component changed from Warnings/Notices to Upgrade/Install
Note: See TracTickets for help on using tickets.