WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 17 months ago

Last modified 17 months ago

#33999 closed defect (bug) (fixed)

WordPress Update issue

Reported by: MrZen88 Owned by: SergeyBiryukov
Milestone: 4.6 Priority: normal
Severity: normal Version: 4.2.2
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:

Description (last modified by ocean90)

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.

Attachments (2)

33999.diff (1.1 KB) - added by boonebgorges 2 years ago.
33999.patch (450 bytes) - added by ocean90 17 months ago.

Download all attachments as: .zip

Change History (22)

#1 @boonebgorges
2 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.4

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.

@boonebgorges
2 years ago

#2 @DrewAPicture
2 years ago

  • Summary changed from Wordpress Update issu to WordPress Update issue

#3 follow-up: @dd32
2 years ago

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.

#4 @wonderboymusic
2 years ago

  • Owner set to boonebgorges
  • Status changed from new to assigned

#5 in reply to: ↑ 3 ; follow-up: @boonebgorges
2 years ago

  • Milestone changed from 4.4 to Awaiting Review
  • Owner boonebgorges deleted

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

#6 in reply to: ↑ 5 ; follow-ups: @MrZen88
2 years ago

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.

#7 in reply to: ↑ 6 @SergeyBiryukov
2 years ago

  • Milestone changed from Awaiting Review to 4.4
  • Owner set to SergeyBiryukov
  • Status changed from assigned to accepted

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.

#8 follow-up: @boonebgorges
2 years ago

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.

#9 in reply to: ↑ 8 @dd32
2 years ago

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.

#10 in reply to: ↑ 6 @dd32
2 years ago

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.

#11 @DrewAPicture
2 years ago

  • Keywords dev-feedback added

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

#12 @dd32
2 years ago

AFAICT this ticket is invalid.

#13 @DrewAPicture
2 years ago

  • Milestone 4.4 deleted
  • Resolution set to invalid
  • Status changed from accepted to closed

See comment:12.

#14 @ocean90
2 years ago

  • Version changed from 4.3.1 to 4.2.2

Related changesets: [31936]/[32322]

#15 @swissspidy
2 years ago

#35345 was marked as a duplicate.

#16 @ocean90
19 months ago

#36965 was marked as a duplicate.

@ocean90
17 months ago

#17 @ocean90
17 months ago

#36965 was marked as a duplicate.

#18 @ocean90
17 months ago

  • Description modified (diff)
  • Keywords dev-feedback removed
  • Milestone set to 4.6
  • Resolution invalid deleted
  • Status changed from closed to reopened

@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' ) "\" "/"
dirname( 'foo/.maintenance' ) "foo" "foo"
dirname( '/foo/.maintenance' ) "/foo" "/foo"

33999.patch adds a check for a backslash.

Last edited 17 months ago by ocean90 (previous) (diff)

#19 follow-up: @ocean90
17 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#20 in reply to: ↑ 19 @ocean90
17 months ago

Replying to ocean90:

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

I meant /.maintenance. (source)

Note: See TracTickets for help on using tickets.