Mediawiki installation/REL1 26

From Biowikifarm Metawiki
< Mediawiki installation
Revision as of 02:01, 8 February 2016 by Andreas Plank (Talk | contribs) (Created page with "== Install and Update Steps == Updating to a wmf development clone calls often for lot of test and brings surprises when used. It is not recommended. Stable releases are pref...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Install and Update Steps

Updating to a wmf development clone calls often for lot of test and brings surprises when used. It is not recommended. Stable releases are preferred.

Steps in general:

  1. update git clone
  2. get information on available git_branch_or_tags of extensions (see Bash script ./write_wmf-shared_git-branches-tags2home_ext-tags-and-branches.sh)
  3. create shared wiki resource (see Bash script ./create_or_upgrade_shared_wiki-core-resource-structure.sh)
  4. update extensions (see Bash script ./create_or_upgrade_shared-wiki-extensions.sh)
  5. check old LocalSettings.php for deprecated stuff, check and substitute deprecated variables and set up a new shared settings file in /var/www/MediaWikiCommonSettingsVREL1_26.php
  6. backup database of v-host-wiki
  7. update v-host wiki (see ./create_or_upgrade_vhost-wiki.sh)

Update notes:

  • a productive v-host Wiki should be updated only if tests on Test Wiki were successful
  • maintenance/update.php did not touch shared tables (user etc.) unless you force update.php to do so. It was possible during test phase to share tables also with older wikis.

For the different needed features the set up concept is as follows:

/usr/share/mw-wmf-clone/core          (mediawiki)
/usr/share/mw-wmf-clone/extensions    (extensions)
/usr/share/mw-wmf-clone/skins         (skins)

└─ /usr/share/mediawiki26                      v-host-wiki
   ├── extensions-rich-features/            -> ├── extensions/        
   ├── vendor-rich-features/                -> ├── vendor/            
   ├── composer-rich-features.json          -> ├── composer.json      
   ├── composer-rich-features.local.json    -> ├── composer.local.json (manage composer extensions here!!)
   └── composer-rich-features.lock          -> └── composer.lock      
   
   /usr/share/mediawiki26                      v-host-wiki
   ├── extensions-simple-features/          -> ├── extensions/        
   ├── vendor-simple-features/              -> ├── vendor/            
   ├── composer-simple-features.json        -> ├── composer.json      
   ├── composer-simple-features.local.json  -> ├── composer.local.json (manage composer extensions here!!)
   └── composer-simple-features.lock        -> └── composer.lock      

Normal folders /extensions or those used by composer (/vendor and composer*.json files) are not used at the moment.

To see what wiki folder links back to a shared wiki you can search for symbolic links (-L) that have the same file as given:

find -L /var/www/ -maxdepth 2 -samefile /usr/share/mediawiki26/index.php -exec dirname '{}' ';' | sort | awk '{print "#   " NR " -> " $0}'

Composer

For composer managed extensions consult Composer (PHP) or Composer (MediaWiki):

  • manage needed extensions in the *.local.json not in composer.json
  • WARNING: on a shared setup wiki family the setup will not work when there is no actual file vendor/autoload.php, because it checks for a hard coded file (php file git view) so although normal folders /extensions, /vendor are not used now, you have to run once:
    cd /usr/share/mediawiki26 && sudo php /usr/local/bin/composer.phar update --no-dev
  • on the level of v-host-wiki you can update and manage composer extensions which will update and write back into to the folders of /extensions-simple-features, /vendor-simple-features etc., so updating affects all symlinked wikis then, and depending on the extension (if one requires update.php because it changes the DB) a maintenance update may be needed on all linked v-host wikis:
    cd /path/to/v-hostwiki && sudo -u www-data php ./maintenance/update.php --dbuser wikiadmin --quick --conf ./LocalSettings.php
  • untested: skin may be managed also by composer

Settings: LocalSettings.php

Needed for symlink setup:

/**
 * If you customize your file layout, set $IP to the directory that contains 
 * the actual MediaWiki files. It will be used as a base to locate files.
 */
putenv ("MW_INSTALL_PATH=/var/www/testwiki2" );
if(getenv( 'MW_INSTALL_PATH' ) ) { 
  $IP = getenv( 'MW_INSTALL_PATH' );
} else {// __FILE__ resolves symlinks but getcwd() does not
  // $GLOBALS['IP'] = dirname( __FILE__ );
  $IP = getcwd( );
}

/**
 * extension directory 
 *
 * needed for maintenance/update.php to work on symlink-setup
 * @since MW 1.25
 */
$wgExtensionDirectory="/var/www/testwiki2/extensions";

Extensions

Unexpected problems with extensions during test setup:

  • CollapsibleVector
  • Cldr → cldr
  • SyntaxHighlight_GeSHi
Extension Composer
managed?
Developer Notes
SyntaxHighlight_GeSHi yes http://biowikifarm.net/test/MediaWiki:Common.js came:
Fatal error: Class 'Symfony\Component\Process\ProcessBuilder' not found in /usr/share/mediawiki27wmf/extensions-simple-features/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php on line 284 

Solution: needs a composer update in its extension folder (read SyntaxHighlight_GeSHi (documentation))

cd /usr/share/mediawiki26/extensions-simple-features/SyntaxHighlight_GeSHi/
sudo php /usr/local/bin/composer.phar update --no-dev
cd /usr/share/mediawiki26/extensions-rich-features/SyntaxHighlight_GeSHi/
sudo php /usr/local/bin/composer.phar update --no-dev

Then in LocalSettings

wfLoadExtension( 'SyntaxHighlight_GeSHi' );
Flow no Preferred over extension:LiquidThreads (unmaintained)
  • Problem: $wgNamespaceContentModels[NS_USER_TALK] = CONTENT_MODEL_FLOW_BOARD; disables welcome message by Extension:ConfirmAccount but adds a flow alert: “Welcome to TestWiki2, Testwiki2 User! We're glad you're here.”
  • Problem: “view history” on fresh created user talk page (by Extension:ConfirmAccount) shows not the expected history but only the page title
  • Problem: dependent on VisualEditor, settings must be restricted then:
    $wgFlowEditorList=array('wikitext');
GraphViz yes
GraphViz::getUploadSubdir: mkdir(/var/www/testwiki/media/graphviz/images/, 16893) failed
- resolved in dev-master
Mp3Handler no External extension was merged into biowikifarm subversion and adjusted to some needs
EmailToWiki no External extension (TODO), see ./get_EmailToWiki_to_extensions_wmf-shared.sh
MultimediaViewer no
  • MultimediaViewer is on top of MediaWiki:Jquery.zoomImage.js (ON) when clicked, only either one of them should be active
  • works well but problem: «Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf Lamium_album_scan.jpg. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt).»
  • negative but acceptable: only 2-step-zoom compared to MediaWiki:Jquery.zoomImage.js (ON)
  • TODO: NGINX configuration add_header could help to display media from rep OpenMedia, see
    cat /etc/nginx/cors-nginx.conf
  • if deactivated then TimedMediaHandler has a basic UI except for images
TimedMediaHandler no
Call to undefined method ForeignDBRepo::fetchImageQuery()

Short solution:

Long solution:

  • $wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', … ); could work (just a guess: but different version of MW API seem a problem in not getting certain file information). Results were that often red links of embedded media where shown.
Semantic_Mediawiki yes
  • no more type:String only type:Text but longer strings get hashed!! SMW-docu:„Since SMW 1.8.0 the first 40 characters (if more than 72 characters were stored as property value) or all 72 characters (if a maximum of 72 characters were stored as property value) are searchable“
  • TODO: reprogramming of http://species-id.net/openmedia/Template:Property_setting
Semantic_Forms yes
  • custom mandatory form field CSS-layout must be CSS-code!important
VisualEditor no Required an extra git clone (according to VisualEditor documentation), using the normal git archive caused missing resources and files from it's submodule. Untested: possibly https://github.com/Kentzo/git-archive-all would be worth a try to get also submodules, but cloning a flat git did work:
cd /usr/share/mediawiki27wmf/extensions-simple-features
sudo git clone --depth 1 --branch origin/wmf/1.27.0-wmf.9 https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git
cd VisualEditor
sudo git submodule update --init --recursive
cd lib/ve
sudo git checkout origin/wmf/1.27.0-wmf.9

Problem: VisualEditor and Parsoid almost develop together. VE was deactivated:

/usr/lib/parsoid/src/api/localsettings.js
Error loading data from server: (curl error: 7): docserver-http-error: (curl error: 7)

Solution: probably better update Parsoid service as well. See https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVisualEditor.git/96e330650d345bfa10534ace1c1bb9e34e9389a0 extensions/VisualEditor/ApiVisualEditor.php about line 113

requestRestbase()
  'url' => '/parsoid/local/v1/'
 since 1.26wmf21 changed to
  'url' => '/restbase/local/v1/'

Different URL handling, hence upgrade of Parsoid is needed, change probably after REL1_26

WikimediaMessages no

Skin:Vector

Not sure if composer.local.json can also manage skins

…
"require":{
  "mediawiki/vector-skin":"dev-wmf/1.27.0-wmf.9"
}
…
 

Collpaseable sidbar is not part of skin:Vector but now in extension:CollapsibleVector

# cd /usr/share/mediawiki27wmf/extensions-simple-features
cd /usr/share/mediawiki26/extensions-simple-features
sudo git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CollapsibleVector.git
cd /usr/share/mediawiki26/extensions-simple-features/CollapsibleVector
sudo git checkout origin/REL1_26
# cd /usr/share/mediawiki27wmf/extensions-rich-features
cd /usr/share/mediawiki26/extensions-rich-features
sudo git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CollapsibleVector.git
cd /usr/share/mediawiki26/extensions-simple-features/CollapsibleVector
sudo git checkout origin/REL1_26


Settings:Login

$wgPasswordDefault ='B'; /* old MD5 hashing on shared Wikifamily with pre MW1.24 and post MW 1.24+ Wikis */