Page MenuHomePhabricator

Remove .php5 files from MediaWiki root
Closed, ResolvedPublic

Description

Some mixed PHP4/5 systems default to running PHP 4 through '.php' files and PHP 5 only on '.php5' files.

It might be nice to have the .php files for entry points be clean enough to load up from PHP 4 and redirect to the .php5 entry point.

Obvious main problem is what to do if there is no .php5 handler set up either. :) Could stick an explanatory notice in the source, I suppose... or only do it if the $wgScriptExtension is set to '.php5' (in which case the installer's already vetted it for us)


Version: unspecified
Severity: enhancement

Details

Reference
bz18010

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:34 PM
bzimport set Reference to bz18010.
bzimport added a subscriber: Unknown Object (MLST).

Trying to include LocalSettings.php to see what the value of $wgScriptExtension is is liable to load up some php5-isms in extension code that break the php4 loading.

We may be better off not trying to redirect like this. At most maybe we can include a link in the error.

"MediaWiki requires PHP 5, you appear to be running PHP 4. Note that some hosts use a .php5 extension instead of .php for their PHP 5 setup. You can try visiting [this url] to see if it works."

At most I think the only place we should ever have a redirect would be in index.php for the installer redirect or something like that.

How long do the .php5 files need to stick around?

Presumably we could just update the docs at some point to say "if you're in a mixed hosting environment, try this..." instead of shipping both files as we do currently?

I'd say it's safe to dump them at this point. PHP5 is 8 years old; if you're in a mixed hosting environment you need a new host.

Changing the bug summary from "Active .php entry points should redirect safely to .php5 variants on PHP 4" to "Remove .php5 files from MediaWiki root", marking this bug as easy (it should just be a matter of a few simple deletions, I think?), and targeting this for 1.21 as I think it's a bit too abrupt to include in 1.20.

Done in https://gerrit.wikimedia.org/r/#/c/35171/

Wondering if we should drop redirect.phtml and wiki.phtml as well--most hosts are unlikely to have these extensions registered for PHP anyway.

(In reply to comment #5)

Wondering if we should drop redirect.phtml and wiki.phtml as well--most hosts
are unlikely to have these extensions registered for PHP anyway.

As long as en.wikipedia.org/w/wiki.phtml-type URLs continue to work, I agree with Brion that these can be killed. That is, for MediaWiki core, they're fine to drop, but for Wikimedia wikis (such as the English Wikipedia), there are still hundreds (maybe thousands) of old URLs that must continue to work (cf. https://en.wikipedia.org/w/index.php?title=Special:LinkSearch&limit=500&offset=0&target=http%3A%2F%2Fen.wikipedia.org%2Fw%2Fwiki.phtml).

taste1at wrote:

Platonides wrote in gerrit:

We can probably remove all but index.php5

I don't have a gerrit account, so I'm answering here:

I think this is not a good idea because it may cause hidden errors, like the wiki is accessible but without stylesheets and javascript (because of missing load.php5 etc.).

So maybe just tell the admins in the release notes that they can just leave the old *.php5, *.phtml files in place if they need it for compatibility.

This would be possible, becuase $wgScriptExtension is not dropped by Chad's patch.

At https://gerrit.wikimedia.org/r/35171, Tim wrote:


It seems like the wrong thing to do as a first step. It seems more sensible to remove $wgScriptExtension, convert the .php5 files to redirects instead of inclusion, and announce deprecation. But actually breaking the URLs seems like something we should do as a last step, if we do it at all.

Chad then abandoned the proposed changeset.

I agree that a slower deprecation process would be nice here. Redirect for a while and announce in the release notes for a version or two. I'm not convinced that the .php5 files need to stay around forever (or even within master), though. The tarball generation script could add the redirects, maybe.

Removing "easy" keyword - some of comments in Gerrit:

‹wgScriptExtension is still used in core to determine path to php files in PHP and JS. Needs to be updated to be php if set to php5.
Otherwise mw will keep generating files to load/api.php5›

‹It seems like the wrong thing to do as a first step. It seems more sensible to remove $wgScriptExtension, convert the .php5 files to redirects instead of inclusion, and announce deprecation. But actually breaking the URLs seems like something we should do as a last step, if we do it at all.›

MaxSem claimed this task.