Help:Keeping wiki up to date: Difference between revisions

From Computer Science Wiki
(Created page with "We're using a particular branch (REL1_35) of MediaWiki. It is a LTS branch. We'll keep to the LTS release upgrade policy, which will require a major version upgrade to the nex...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
We're using a particular branch (REL1_35) of MediaWiki. It is a LTS branch. We'll keep to the LTS release upgrade policy, which will require a major version upgrade to the next LTS approximately [https://www.mediawiki.org/wiki/Version_lifecycle once in two years].
We're using a particular branch (REL1_35) of MediaWiki. It is a LTS branch. We'll keep to the LTS release upgrade policy, which will require a major version upgrade to the next LTS approximately [https://www.mediawiki.org/wiki/Version_lifecycle once in two years].


== Getting minor changes ==
=== Getting minor changes ===
While we are on the branch, picking up the latest minor changes and security fixes is relatively easy. Change into your MediaWiki clone directory and issue this command:
While we are on the branch, picking up the latest minor changes and security fixes is relatively easy. Change into your MediaWiki clone directory and issue this command:


Line 100: Line 100:
The changes will be applied automatically and you will be all set to go.
The changes will be applied automatically and you will be all set to go.


=== Upgrading extensions / skins using composer ==
=== Upgrading extensions / skins using composer ===
Certain extensions require or prefer to be installed with <code>composer</code> to easily ensure all dependencies are installed. Currently we only use it for the Chameleon skin. Instructions for <code>composer</code> are kept in <code>composer.local.json</code> file in the clone root.  
Certain extensions require or prefer to be installed with <code>composer</code> to easily ensure all dependencies are installed. Currently we only use it for the Chameleon skin. Instructions for <code>composer</code> are kept in <code>composer.local.json</code> file in the clone root.  


Line 111: Line 111:
Upgrading with <code>git</code> and <code>composer</code> is easy. Just mind the open source gaps: lazy maintainers, messing dependencies, crazy versioning, etc &mdash; any factor can bring up errors. I would recommend:
Upgrading with <code>git</code> and <code>composer</code> is easy. Just mind the open source gaps: lazy maintainers, messing dependencies, crazy versioning, etc &mdash; any factor can bring up errors. I would recommend:
* do not edit anything in the file system except <code>LocalSettings.php</code> and <code>composer.local.json</code>
* do not edit anything in the file system except <code>LocalSettings.php</code> and <code>composer.local.json</code>
* if you have to, tru to keep your changes ''isolated'' (eg. create a directory, store your stuff there, and refer your files via <code>LocalSettings.php</code> <ref>I am used to create a directory <code>extensions/wikivisor</code>, add my changes to the empty <code>MySettings.php</code> inside this directory, and then include them into the config putting at the bottom of the main <code>LocalSettings.php</code>:
* if you have to, try to keep your changes ''isolated'' (eg. create a directory, store your stuff there, and refer your files via <code>LocalSettings.php</code> <ref>I am used to create a directory <code>extensions/wikivisor</code>, add my changes to the empty <code>MySettings.php</code> inside this directory, and then include them into the config putting at the bottom of the main <code>LocalSettings.php</code>:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
require_once( 'extensions/wikivisor/MySettings.php' );
require_once( 'extensions/wikivisor/MySettings.php' );
Line 117: Line 117:
So I can move the entire dir to a safe place before upgrade and bring it back after upgrade.
So I can move the entire dir to a safe place before upgrade and bring it back after upgrade.
</ref>
</ref>
* read online, sometimes docs are updated ))
* use minor release upgrades during the LTS life cycle (<code>git pull</code>)
* when it comes to the major LTS upgrade call a pro (you know where you can find me) to ensure smooth and lossless upgrade.


=== Notes ===
=== Notes ===
<references/>
<references/>

Latest revision as of 11:34, 10 June 2022

We're using a particular branch (REL1_35) of MediaWiki. It is a LTS branch. We'll keep to the LTS release upgrade policy, which will require a major version upgrade to the next LTS approximately once in two years.

Getting minor changes[edit]

While we are on the branch, picking up the latest minor changes and security fixes is relatively easy. Change into your MediaWiki clone directory and issue this command:

git pull

All of the latest changes for the branch you are using will be applied.

Switching to a different version[edit]

Each of Mediawiki versions are tracked as branches or tags. In order to switch to a different version (for example from the REL1_35 branch to the REL1_38 branch), checkout the particular branch or tag you want from within your MediaWiki clone directory:

git checkout REL1_38
Local changes to the repo

Before doing so, check the differences between your clone and the origin repo. The differences can be caused by local changes to files and directories in the git tree. To see differences use:

git diff

You can stash local changes before checking out the new version:

git stash

and (optionally) export them as a patch file:

git diff > patch.diff

The local changes can be re-applied after upgrade correspondingly:

git stash pop

or

git apply --ignore-space-change --ignore-whitespace patch.diff

The new version of core may require newer versions of extensions and skins. There is a number of extensions and skins bundled with the Mediawiki core and some extensions installed manually.

Upgrading bundled extensions

Run from your MediaWiki clone directory:

git submodule update --init --recursive

If the script will end up with the error saying about the failure of upgrading the vendor directory, it is safe to delete this directory and rebuild it issuing:

composer update --no-dev -o
Upgrading manually installed extensions [1]

You must go into each extension directory and update it with a command like git pull --recurse-submodules. Once updated the clone, you can switch to the needed branch running from the particular extension directory:

git checkout REL1_38

Most of the extensions need to be upgraded to the branch matching the branch of MediaWiki core (in our example REL1_38). Some extensions keep their master branch backword compatible (in our set it is Lingo: note the Compatibility policy section of the infobox). So, use:

cd extensions/Lingo
git checkout master

To see the list of the available branches run:

git branch -a

Sometimes, extensions use tags, not branches. To see the list of the available tags, run:

git tag --list

Switching tags is the same:

git checkout 5.3.4
Upgrading database

After updating/upgrading the code and required libraries you should run the MediaWiki command-line script to update database tables as needed, from the clone root:

php maintenance/update.php

The changes will be applied automatically and you will be all set to go.

Upgrading extensions / skins using composer[edit]

Certain extensions require or prefer to be installed with composer to easily ensure all dependencies are installed. Currently we only use it for the Chameleon skin. Instructions for composer are kept in composer.local.json file in the clone root.

The upgrade will be done automatically when you run:

composer update --no-dev -o

Last minute note[edit]

Upgrading with git and composer is easy. Just mind the open source gaps: lazy maintainers, messing dependencies, crazy versioning, etc — any factor can bring up errors. I would recommend:

  • do not edit anything in the file system except LocalSettings.php and composer.local.json
  • if you have to, try to keep your changes isolated (eg. create a directory, store your stuff there, and refer your files via LocalSettings.php [2]
  • read online, sometimes docs are updated ))
  • use minor release upgrades during the LTS life cycle (git pull)
  • when it comes to the major LTS upgrade call a pro (you know where you can find me) to ensure smooth and lossless upgrade.

Notes[edit]

  1. As of the date of these notes the manually installed extensions include:
    • HeadScript
    • Lingo
    • Math
    • PageInCat
    • TimedMediaHandler
    • UserMerge
  2. I am used to create a directory extensions/wikivisor, add my changes to the empty MySettings.php inside this directory, and then include them into the config putting at the bottom of the main LocalSettings.php:
    require_once( 'extensions/wikivisor/MySettings.php' );
    

    So I can move the entire dir to a safe place before upgrade and bring it back after upgrade.