WordPress Update issue

[MrZen88]

When I update the core or a plugin with ftp the website always stuck un the «Enabling maintenance mode». I saw the solution on the forum: ​https://wordpress.org/support/topic/unable-to-update-plugins-after-upgrade-to-42/page/3

You need to modify the ligne 149 in the file wp-admin/includes/file.php

if ( empty( $filename ) || '.' == $filename || '/' === $filename ) {

replace with

if ( empty( $filename ) || '.' == $filename || DIRECTORY_SEPARATOR === $filename ) {

In windows you need to do that to the upgrade work.

[boonebgorges]

MrZen88 - Thanks for the ticket, and welcome to Trac.

Your fix looks correct to me. I've added a test in 33999.diff​ that passes before and after for *nix filesystems; I don't have a Windows system handy to run the test, but I imagine it will do the trick.

Would like the OK of @dd32 before committing.

[dd32]

I'd be curious how \ would end up as the first character, given on windows it should be prefixed with a drive path.. so at first glance, this doesn't look correct at all.

[boonebgorges]

Replying to dd32:

I'd be curious how \ would end up as the first character, given on windows it should be prefixed with a drive path.. so at first glance, this doesn't look correct at all.

In that case, I cede the floor :-D

[MrZen88]

Replying to boonebgorges:

Replying to dd32:

I'd be curious how \ would end up as the first character, given on windows it should be prefixed with a drive path.. so at first glance, this doesn't look correct at all.

In that case, I cede the floor :-D

The problem occur when you update via FTP on the website. When you read the code, it don't check a real path but a relative path. And it look like that we need to specify the DIRECTORY_SEPARATOR. It always a good practice tu use DIRECTORY_SEPARATOR when you specify a path if you want your code to work on Windows and linux. Because linux understand a slash ('/') and windows understand a backslash ('\') as directory separator. The code just refer to a relative path who want to be to the root of your site.

Try it, install filezilla server on windows and make an automatique update from the website via FTP and you will see in the filezilla log that he can reach the root of the site. It work only with DIRECTORY_SEPARATOR.

[SergeyBiryukov]

Replying to MrZen88:

It always a good practice tu use DIRECTORY_SEPARATOR when you specify a path if you want your code to work on Windows and linux. Because linux understand a slash ('/') and windows understand a backslash ('\') as directory separator.

Windows actually understands both, this was previously discussed in #20849 and other tickets.

But it does look like we should check both '\' and '/' in case of a relative path here.

[boonebgorges]

Windows actually understands both

Yes, but that's when we're asking the system to parse or generate a filepath. Here we're just doing string comparison. These are the cases where we need to use DIRECTORY_SEPARATOR.

[dd32]

Replying to boonebgorges:

Windows actually understands both

Yes, but that's when we're asking the system to parse or generate a filepath. Here we're just doing string comparison. These are the cases where we need to use DIRECTORY_SEPARATOR.

But yet we also standardise all paths we operate on to use /. What I'm getting at here, is that we don't use DIRECTORY_SEPERATOR inside WordPress for a reason, because we don't use Windows formatted paths like that, and I'm curious WHY this fixes it in this case. It feels like we're not normalising the path at a higher level, or the system is seeing the path in a way that is not standard.

[dd32]

Replying to MrZen88:

The problem occur when you update via FTP on the website. When you read the code, it don't check a real path but a relative path. And it look like that we need to specify the DIRECTORY_SEPARATOR. It always a good practice tu use DIRECTORY_SEPARATOR when you specify a path if you want your code to work on Windows and linux. Because linux understand a slash ('/') and windows understand a backslash ('\') as directory separator. The code just refer to a relative path who want to be to the root of your site.

Try it, install filezilla server on windows and make an automatique update from the website via FTP and you will see in the filezilla log that he can reach the root of the site. It work only with DIRECTORY_SEPARATOR.

FWIW, FTP implementations all unix-style path separators, regardless of the operating system. Using DIRECTORY_SEPERATOR would actually break in that scenario.

[DrewAPicture]

@dd32 What's your best recommendation to move this ticket forward?

[dd32]

AFAICT this ticket is invalid.

[DrewAPicture]

See comment:12.

[ocean90]

Related changesets: [31936]/[32322]

[swissspidy]

#35345 was marked as a duplicate.

[ocean90]

#36965 was marked as a duplicate.

[ocean90]

#36965 was marked as a duplicate.

[ocean90]

@neogeneva gave the answer for this issue in ticket:36965:6. I could reproduce this behaviour. Results of a few dirname() examples:

	Windows	*nix
DIRECTORY_SEPARATOR	"\"	"/"
dirname( '' )	""	""
dirname( '/' )	"\"	"/"
dirname( 'file.php' )	"."	"."
dirname( '/.maintenance' )	"\"	"/"

33999.patch​ adds a check for a backslash.

[ocean90]

In 38151:

Filesystem API: Prevent an endless self-calling loop in wp_tempnam().

Under certain conditions upgrades on Windows may fail because wp_tempnam() gets called in a loop.
This can happen when wp_tempnam() is called with \.maintenance for the $filename parameter. The function strips the extension, in this case .maintenance, which results in an empty filename. Because it's empty, wp_tempnam() calls itself with dirname( '\.maintenance' ). On *nix systems this would be "/" which allows wp_tempnam() to fall back on time(). But on Windows it's "\".

This change adds the backslash to the list of characters which allow wp_tempnam() to fall back on time().

See [32322], [31936].
Fixes #33999.

[ocean90]

Replying to ocean90:

This can happen when wp_tempnam() is called with \.maintenance for the $filename parameter.

I meant /.maintenance. (source)