Last modified: 2007-06-28 14:53:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12387, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10387 - Detect and handle '.php5' extension environments
Detect and handle '.php5' extension environments
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-27 15:53 UTC by Brion Vibber
Modified: 2007-06-28 14:53 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Fixes bug, awaiting review (6.94 KB, patch)
2007-06-27 20:40 UTC, Edward Z. Yang
Details
v2 (8.42 KB, patch)
2007-06-27 22:38 UTC, Edward Z. Yang
Details

Description Brion Vibber 2007-06-27 15:53:40 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.
Comment 1 Roan Kattouw 2007-06-27 16:44:42 UTC
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.
Comment 2 Brion Vibber 2007-06-27 18:45:35 UTC
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.
Comment 3 Roan Kattouw 2007-06-27 19:28:44 UTC
(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.
Comment 4 Brion Vibber 2007-06-27 19:30:40 UTC
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.
Comment 5 Edward Z. Yang 2007-06-27 19:35:10 UTC
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.
Comment 6 Edward Z. Yang 2007-06-27 19:47:27 UTC
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.
Comment 7 Brion Vibber 2007-06-27 19:52:51 UTC
(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....)
Comment 8 Edward Z. Yang 2007-06-27 20:40:47 UTC
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.
Comment 9 Edward Z. Yang 2007-06-27 20:42:04 UTC
Quick note: actually, the form does have an explicit action attribute set. Disregard that note on the comment above.
Comment 10 Brion Vibber 2007-06-27 20:48:27 UTC
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.
Comment 11 Edward Z. Yang 2007-06-27 20:51:59 UTC
$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.
Comment 12 Roan Kattouw 2007-06-27 21:04:23 UTC
(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.
Comment 13 Rob Church 2007-06-27 21:08:00 UTC
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.
Comment 14 Edward Z. Yang 2007-06-27 22:38:24 UTC
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.
Comment 15 Brion Vibber 2007-06-28 14:53:37 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links