2

I'm trying to install Mediawiki 1.22.6 into a subdirectory /wiki/ of apache document root directory, which contains some other directories. When I try to open http://example.com/wiki or http://example.com/wiki/index.php for the very first time to generate LocalSettings.php, the script is not run; instead, a part of it is printed:

bar(), etc etc) which throw parse errors in # PHP 4. Setup.php and ObjectCache.php have structures invalid in PHP 5.0 and # 5.1, respectively. if ( !function_exists( 'version_compare' ) || version_compare( phpversion(), '5.3.2' ) < 0 ) { // We need to use dirname( FILE ) here cause DIR is PHP5.3+ require dirname( FILE ) . '/includes/PHPVersionError.php'; wfPHPVersionError( 'index.php' ); } # Initialise common code. This gives us access to GlobalFunctions, the # AutoLoader, and the globals $wgRequest, $wgOut, $wgUser, $wgLang and # $wgContLang, amongst others; it does not load $wgTitle require DIR . '/includes/WebStart.php'; $mediaWiki = new MediaWiki(); $mediaWiki->run();

Running the script with php -f index.php produces the expected output.

There are no aliases or rewrite rules; mod_php seems to be enabled — Mediawiki works if installed as document root. In current install the document root is a symlink.

Virtual host is configured as follows:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /home/hell/public_html
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /home/hell/public_html>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        IndexOptions +ShowForbidden
    </Directory>
    <Directory /home/hell/public_html/private>
        AuthType Basic
        AuthName "Restricted Access"
        AuthUserFile /home/hell/apasswords
        Require user satan
    </Directory>
#   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
#   <Directory "/usr/lib/cgi-bin">
#       AllowOverride None
#       Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
#       Order allow,deny
#       Allow from all
#   </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

So there is no special configuration for Mediawiki.

G. Cito
  • 103
  • 4
Michael Ivko
  • 151
  • 7
  • Is PHP enabled on the server? Does serving/accessing a simple like `file.php` with `` as its contents work? – G. Cito May 13 '14 at 14:44
  • It's weird. PHP is apparently enabled (`php5.conf` and `php5.load` are in `mods-enabled`). If the document root is a subdirectory of some user's home directory, both `file.php` and Mediawiki's `index.php` work. If it is a symlink form some user's home directory to a directory located in `/storage/`, neither of them works. If the document root points directly to a directory in `/storage/`, `file.php` works but not Mediawiki. – Michael Ivko May 14 '14 at 08:30
  • Actually no, they all work. It could have been a cache quirk. – Michael Ivko May 14 '14 at 10:45

2 Answers2

0

The minimum PHP version required for Mediawiki 1.22.6 is 5.3.2. You don't show the full output in your question, but it looks like the message you are getting is actually the contents of Mediawiki's main index file. The simplest explanation is that you don't have an Apache handler (e.g. AddHandler) configured to properly serve .php files, so the index.php file is being served as text.

Even if PHP is enabled (usually with a configuration directive like LoadModule php5_module libexec/apache2/libphp5.so in your main httpd.conf or included in some way from a separate file or directory) you may still need to enable it inside your VirtualHost container with a directive like:

AddHandler application/x-httpd-php .php

Since it's more secure to serve .php files using PHP (we don't want their contents to be readable if they include information that should not be public), a handler for .php files should be enabled for the whole server. If you are serving PHP files using a CGI or FCGI process additional configuration steps might be required.

A more complicated explanation

You may have multiple versions of PHP installed. Perhaps your version of mod_php was compiled against an older version of the PHP libraries, whereas the command line version (sometimes installed separately via a package like php-cli) is linked against a more up to date set of libraries and thus works properly.

Locate the libraries associated with mod_php (substitute your package management tool commands as appropriate):

% pkg info -a | grep mod_php
mod_php5-5.4.28,1              PHP Scripting Language
% pkg info -l mod_php5-5.4.28,1
mod_php5-5.4.28,1:
    /usr/local/libexec/apache24/libphp5.so
    /usr/local/share/licenses/mod_php5-5.4.28,1/LICENSE
    /usr/local/share/licenses/mod_php5-5.4.28,1/PHP301
    /usr/local/share/licenses/mod_php5-5.4.28,1/catalog.mk

or

% locate libphp5.so
/usr/local/libexec/apache24/libphp5.so
% pkg which /usr/local/libexec/apache24/libphp5.so

If you are sure the version of PHP you have installed is correct and your server is set up to handle .php properly but you are still having problems, then debugging using Apache debug levels and log files is your next step.

G. Cito
  • 103
  • 4
0

Apparently, when userdir is enabled, php is disabled for /home/*/public_html directories. Renaming public_html to something else helped.

Michael Ivko
  • 151
  • 7
  • So it works now? Or the test file works in some locations and not others but MW doesn't work? There's a lot of moving parts in your setup it seems and many Apache Directives for controlling behaviors and handling of content in one Location (FileSystem or Virtual) or another; with or without symlinks; etc. – G. Cito May 14 '14 at 15:36
  • Yes, it works now. I don't actually need to move the files, it was just for test. – Michael Ivko May 14 '14 at 18:03