Make WordPress Core

Opened 8 years ago

Closed 6 years ago

#35066 closed defect (bug) (wontfix)

Rename `.maintenance` for compatibility

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: low
Severity: normal Version:
Component: Upgrade/Install Keywords: 2nd-opinion close needs-patch
Focuses: Cc:


FTP Servers really don't like hidden files, often due to the server being configured to hide them. This has caused compatibility issues such as #28013 & #34976

We should consider changing it to a non-hidden file, initial suggestion would be something such as wordpress.maintenance or wp.maintenance.

This would benefit us in that we'd no longer be creating/altering hidden files which are often treated as special by the system, which would make our upgrades more reliable.

Attachments (3)

35066.diff (867 bytes) - added by chacha102 8 years ago.
35066.2.diff (1.4 KB) - added by chacha102 8 years ago.
35066.3.diff (3.9 KB) - added by chacha102 8 years ago.

Download all attachments as: .zip

Change History (12)

#1 @jdgrimes
8 years ago

Note that we'll probably need to maintain back-compat for plugins that use the .maintenance file to send WordPress into maintenance mode. So we could add recognition of the new file and start using it for core's upgrade routines, but we'll probably want to keep the check for the old maintenance file as well.

#2 @dd32
8 years ago

Keeping backwards compat here is kind of annoying honestly, but would have to be done for a short period at least. I'd probably recommend supporting both at first and removing it in x.y+2

8 years ago

8 years ago

#3 @chacha102
8 years ago

Because of how often the check is ran, and because the file system doesn't cache false responses to file_exists, I definitely agree we should move to get rid of the backwards compatibility as soon as possible. Fortunately, for the majority of requests I only had to add one file_exists check.

I played around with a structure to store which of the file_exists checks came out true so that including the file didn't require an additional (albeit duplicate) check, but I felt that would ad to much overhead to the first set of checks that are much more commonly ran.

#4 @chacha102
8 years ago

  • Keywords has-patch added; needs-patch removed

8 years ago

#6 @dd32
8 years ago

  • Milestone changed from 4.5 to Future Release

Pushing to Future Release as beta hit.

#7 @dd32
8 years ago

Tempted to mark this as wonftix. I no longer really see it worthwhile to switch with reports of this being so few and far between.

Alternate options would be to use file_exists() directly and perform a FTP DELETE operation regardless of if we can see it via FTP.

#8 @dd32
8 years ago

  • Keywords close needs-patch added; has-patch removed
  • Priority changed from normal to low

#9 @dd32
6 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing due to the lack of reports in recent history.

Note: See TracTickets for help on using tickets.