Last modified: 2007-06-28 14:53:37 UTC
While more and more hosting environments are adding PHP 5 support, many of them are still doing weird things like having PHP 4 for '.php' files and PHP 5 only for '.php5' files. There are some third-party directions for poking about and renaming files in MW to work this way, but it's kind of lame to have to do that. The installer should be able to detect it's running on PHP 4 and suggest trying an alternate '.php5' file, which would basically just consist of an include(). These would only have to be provided for a few key entry points: config/index.php index.php redirect.php thumb.php img_auth.php api.php Other files are included indirectly, so their extensions don't really matter. Additional config var or vars would be required to make sure the URLs are correct for things other than the main $wgScript, but that shouldn't be very difficult.
If you have access to the server, you can change the settings to make .php be PHP 5 and .php4 be PHP 4. If not, you can also use symlinks.
Both of those might not be true. For instance, many restricted hosting environments make it either difficult or impossible to change the assignments this way. Many hosting environments may not have symlinks available. Nor would symlinks exist by default. Hence, a sane system built-in to run out-of-the box is desirable.
(In reply to comment #2) > Both of those might not be true. > > For instance, many restricted hosting environments make it either difficult or > impossible to change the assignments this way. Many hosting environments may > not have symlinks available. Nor would symlinks exist by default. > > Hence, a sane system built-in to run out-of-the box is desirable. True. I assume the installer throws an error when it detects PHP 4? In that case, it could prompt the user for a PHP 5 extension (if applicable), and create the files index.{{PHP5EXT}}, api.{{PHP5EXT}}, etc., which simply include() their 'parent' .php file. index.php5 would include('index.php'), and so on.
There's no need to try to create files. Not only would it be unreliable (non-writable directories), it's unnecessary -- just have index.php5 etc sitting around ready to be used.
I'm poking at this bug, and I'm wondering: is the user is the one who would be adding the index.php5 file? If it is the case, that would neatly solve the problem of getting user input, because install_version_checks() doesn't exactly lend itself well to asking prompts, etc. But it would also mean that they would have to create pages for all of the entry points.
Hmm... I think Brion is suggesting that the default distribution of MediaWiki come with the php5 files. That seems a bit cluttered, but we could probably have the installer clean up after the files for a regular install. Reconnaissance: index.php -> $wgScript redirect.php -> $wgRedirectScript thumb.php -> $wgThumbnailScriptPath img_auth.php -> ??? api.php -> Probably not necessary, just make sure you tell API users that the URL is a little different Patch upcoming.
(In reply to comment #6) > Hmm... I think Brion is suggesting that the default distribution of MediaWiki > come with the php5 files. Yes, that was exactly my suggestion. > That seems a bit cluttered, Not really. > but we could probably > have the installer clean up after the files for a regular install. No, please do not try to do anything of the sort! *NEVER* attempt to remove files in this way -- it's unstable, failure-prone, unsafe, and likely to fail and generally screw things up (for instance when moving across hosts or upgrading or submitting patches or....)
Created attachment 3833 [details] Fixes bug, awaiting review Understood. I have attempted no such thing. This change partially reverts r18781, where you removed these variables in order to reduce clutter. I didn't feel that it was appropriate to introduce conditional blocks into the configuration file, so I added them back in unconditionally. I introduce one new constant: MW_INSTALL_PHP5_EXT which is used to detect whether or not .php5 files are being used. Also, I set the action attribute in form to blank: this ensures that the same page is submitted via the form. There are a few index.php links Keeping in line with Brion's recommendation to include the .php5 preloaded, I have not structured the patch so it is easy to pick an alternative file-extension for users to use.
Quick note: actually, the form does have an explicit action attribute set. Disregard that note on the comment above.
It might be simplest to set a var something like this: $wgScriptExtension = '.php'; or $wgScriptExtension = '.php5'; Then various defaults would just use "index$wgScriptExtension", "redirect$wgScriptExtension" etc; then it wouldn't be necessary to set it explicitly in a lot of places. (It might be nice to include the . in the variable for, for instance, people who like to customize things so the extension isn't visible on the web end of things. The detail of making that work would be left to custom setup, though.) Another thing to check is to make sure that the config/index.php cleanly detects the PHP 4 condition and is able to print out a warning, along with a link to both: * the alternate index.php5 * documentation pages explaining common ways of configuring hosting sites so regular ".php" will work.
$wgScriptExtension is a great idea; if I have time, I'll incorporate it into the patch. I have, however, done your second point (there was an instanceof call that had to be killed) except for the documentation page, of which I do not know the URL of.
(In reply to comment #4) > There's no need to try to create files. Not only would it be unreliable > (non-writable directories), it's unnecessary -- just have index.php5 etc > sitting around ready to be used. Who says it's php5? Why not phtml, phtml5, p5html or whatever a sufficiently sick mind could come up with? I don't think non-writable dirs are an issue: if you uploaded the MediaWiki files to a certain dir, it's either already writable or you can set its permissions so it's writable.
Experience supporting users who would benefit from this suggests that those "sick minds" opt for a .php5 extension. Making the wiki root directory writable is a sloppy and potentially hazardous idea.
Created attachment 3834 [details] v2 Patch version 2. After all that squabbling, I decided that the installer itself will only handle .php5 extensions. However, you can easily change $wgScriptExtension in LocalSettings.php and rename the .php5 files to whatever you need them to be to make things working. The previous patch had a bug: thumbnail location should not be specified unless you specifically need to override the default. Also, I had to edit DefaultSettings.php and Setup.php; hopefully the documentation updates were reasonable.
Looks good! Seems to work when I set up my local environment; applied in r23505. Exposes a few minor issues where index.php is hardcoded: * bug 10396 - AJAX calls * bug 10398 - pre-install splash screen
