Page MenuHomePhabricator

Errors when using monoversion configuration template
Open, MediumPublic


Dear Sébastien,

I am currently trying your extension to setup a monoversion wikifarm within my MediaWiki 1.23 installation (this is a migration project, too...) on a CentOS 7 machine. (Using Git master version of your code...)

The wiki code lives in /var/www/html/

Following the docs I did:

  1. Install the extension in extensions folder and ran composer to install the yaml dep.
  2. Shuffled around the LocalSettings.php files
  3. Used the monoversion template for farms.yaml, put that in extensions/MediaWikiFarm/config, edited the server string to match my host.
  4. Added following to the LocalSettings.php: $wgMediaWikiFarmConfigDir = '/var/www/html/';

First nothing worked, until I added $wgMediaWikiFarmCacheDir = false;, which seems to be related to your last comment on

After that, at least my main page was showing up, but no CSS, JS, etc was loaded. Looking into the Firefox Debugger I found many Error 500 statuses for these (pointing to load.php).
Looking inside /var/log/messages I found:

mediawikifarm: Logging parameter must be false or a string
mediawikifarm: Only explicitly-defined wikis declared in existence lists are allowed in monoversion mode.
mediawikifarm: Only explicitly-defined wikis declared in existence lists are allowed in monoversion mode.
mediawikifarm: Only explicitly-defined wikis declared in existence lists are allowed in monoversion mode.

After setting $wgMediaWikiFarmSyslog = 'mediawikifarm'; inside LocalSettings.php, that error went away.

Looking up the other error lead my to [[ | Line 1072 of src/MediaWikiFarm.php ]]

Digging into the code, I wondered why $explicitExistance is not true and I think the reason is that with the default monoversion template for farms.yaml there is no hash variables given, which results in $explicitExistance = null ([[ | Line 912 of src/MediaWikiFarm.php ]])

So: shall I fix my farms.yaml and fix the template, too (would create a merge request for this) or should the code be fixed for this case?

Thanks for your work and help,

To be fixed:

Event Timeline

Good Morning Sébastien,

I digged a bit deeper and tried to get my wiki running.

I think the monoversion sample config given as an example is currently broken. As $explicitExistance is always set to null when there is no variables section, this will never work.

When I tried to setup a variables section, I missed that I needed to provide at least one file argument. Shouldn't this be also allow an array instead of a file?

It would be ok for me not to change the code, but provide a better sample config and more documentation about the necessities. Do you agree?

I'm willing to create a patch and write more docs about this...


I don’t regularly test the monoversion case, I should setup it on my test installation to routinely check if everything still work.

I only quickly read this issue, I will test in more details in the coming days.

It’s possible the docs are outdated given I added the warning "Only explicitly-defined wikis declared in existence lists are allowed in monoversion mode." quite recently (to prepare T162737 and avoid the case where some wikis "exist" only with a wildcard instead of being properly defined in MediaWikiFarm).

I was able to reproduce the issue with the same details, thank you for your detailled analysis.

1) About the introductory example

To answer to your comment, yes, I aggree the code could stay as it is, but the example should be improved. The variables section should stay mandatory given we want to create a farm, hence with multiple wikis even if this introductory example only has one wiki. I propose these two first config files:

# In this example the different wikis will be '', '', etc. depending of the content of the file number.yml
      - variable: 'number'
        file: 'number.yml'
    server: 'mywiki-(?P<number>\d)\.example\.org'
    suffix: 'wiki'
    wikiID: 'mywiki'
      - file: 'LocalSettings.php'
        executable: true


# You can add here more wikis
- 1

2) About the $wg variables

In the multiversion mode there is the file config/MediaWikiFarmDirectories.php, with a template file in docs/config/MediaWikiFarmDirectories.php. I will review the monoversion case and probably add the missing (and relevant) variables in the template LocalSettings in docs/config/LocalSettings.php.

3) About the installation guide

I wrote the installation guide with, in mind, a person who want to convert a single existing wiki to a farm, initially with a single wiki, with a minimal number of changes in the whole setup. I’m no more sure it is the right way to focus on this setup, perhaps the installation guide should focus on a test install, in monoversion mode, with two blank wikis: something similar to @Envlh wrote in the Quick start, but in the monoversion case.

On the other side, it could be created another documentation page to explain how to convert an existing wiki to a farm. This proposed organisation of the documentation is not very different from the current state, but it would be more clearly explained and easier to navigate.

Do you think it would be better?

4) About using an array to declare the existing wikis

I refer here to the variables section, I aggree it could be created an array instead of a file, the two options would be mutually excluding. When I reproduced the issue, I thought the same thing :)

Thank again for your detailled report.

Seb35 triaged this task as Medium priority.Dec 1 2017, 7:33 PM

Change 394974 had a related patch set uploaded (by Seb35; owner: Seb35):
[mediawiki/extensions/MediaWikiFarm@master] Alternative declaration of wikis for small setups

This first change is for the point 4) hence it will be directly possible to add the values of each variables in the farms.yml file, making it easier to write introductory tuturials and for small farms. However this is only for small setups given it has two drawbacks:

  1. any change in the list of wikis invalidate all cached configuration files (given farms.yml is the entry config file);
  2. when there are multiple variables, it will be only possible to create a cartesian space, instead of a fibre bundle as made possible when using files: e.g. if v1 ∈ { 'a', 'b' } and v2 ∈ { '1', '2' } the list of declared wikis will be { ('a', '1'), ('a', '2'), ('b', '1'), ('b', '2') }, but when you use files, v2 can depend on the value of v1 and create for instance this list of declared wikis: { ('a', '1'), ('a', '2'), ('b', '3') }.

Change 394974 merged by jenkins-bot:
[mediawiki/extensions/MediaWikiFarm@master] Alternative declaration of wikis for small setups

Change 394993 had a related patch set uploaded (by Seb35; owner: Seb35):
[mediawiki/extensions/MediaWikiFarm@master] Improve discoverability of $wgMediaWikiFarmSyslog

This second change addresses the issue of the discoverability of the logs in syslog, and I remove the message "Logging parameter must be false or a string" in the case there is no config parameter $wgMediaWikiFarmSyslog (or is null) in order to safely remove it when you don’t want logs (safely = without being forcingly spammed by this message).

Change 394993 merged by jenkins-bot:
[mediawiki/extensions/MediaWikiFarm@master] Improve discoverability of $wgMediaWikiFarmSyslog

I realised an additional issue in the monoversion case: when a wiki does not exist, MediaWikiFarm should return an HTTP 404 or HTTP 500 and should not further execute MediaWiki, but with the example configuration MediaWikiFarm still load the LocalSettings.php and MediaWiki is executed. Similarly to the multiversion case, the file MediaWikiFarm.php should contain something like if( MediaWikiFarm::load() == 200 ) { ... } else { die( 0 ); }.

The issue mentionned above (in monoversion case, do not further execute MediaWiki when the wiki is missing), I just solved the issue with rEMWFb9f6eba97b.

Aklapper added a subscriber: Seb35.

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See for tips how to best manage your individual work in Phabricator.)