Wikibase/Installation/Advanced configuration

= Wikibase Repository =

Setting up items in the main namespace
If you want to set up your items in the main namespace:

Note that if the "Main Page" is still in the Main namespace there will be thrown an exception, at least when you try to access that page. If you see this exception comment out the content model for the Main namespace, and then move the "Main Page" out of Main space without leaving an redirect. Usually the page will be moved to "Project:Main Page". If so the system message Mediawiki:Mainpage should be updated, or a similar message if Mediawiki:Sidebar is changed. Also check if there are other pages in the Main namespace by using Special:Allpages. After the Main namespace is cleansed for other pages you can reenable the content model for Main namespace.

Items in a dedicated item namespace
If you want to set up your items in a namespace of its own, here called, set up and use a   constant and optionally set :

HTML5
The extension uses HTML5 specific attributes, and because of this the  must be set to   in pre MW 1.22. In MW 1.22 and later versions this configurable feature is removed and the returned code is always HTML5.

Define links for external identifiers
In order to add links for some external identifiers in the main interface, as exemplified on Wikidata by Q85#P214 (and configured on-site on P214#P1630):
 * 1) create a property of type String (this property will be equivalent to P1630),
 * 2) get the ID of this property (e.g.  ),
 * 3) configure in  :
 * 4) run the script (possibly not mandatory, but if it does not work, run the script):
 * 5) on the properties, the users can then define the pattern of the links, with   replaced by the identifier provided by the individual items.

Similarly it can be configured canonical URIs in RDF dumps (prefixes wdtn:, psn:, pqn:, prn:), as exemplified on Wikidata with the property P1921 (e.g. used on the property P214#P1921). The configuration is similar with the parameter.

Configuration

 * Basic Settings with changesDatabase,siteLinkGroups,localClientDatabases (with examples)
 * Insert with SQL in the table sites the site_global_key ? database repo and client ?
 * relations between siteLinkGroups of repo and siteGlobalID of client ?
 * example configs with a repo and a wiki family (fr,en)

Configuration of is done by assigning to   in your  file. The options are listed below and their default is set in the. You should not modify the settings file, but can have a look at it to get an idea of how to use the settings, in case the below descriptions do not suffice.

''The extension use the variable name, note the initial prefix  , while configuration of other extensions might use the initial prefix. The difference is important and the configuration will fail if the latter is used.''

Example of how to change a setting:

Available settings:
 * The available settings are documented in

Maintenance scripts
This extension has some maintenance scripts in the  subdirectory. They assume that the extension is installed in the extensions directory of the MediaWiki software (i.e. files are in the  directory), if this is not the case, you can set the   environment variable to the path of your MediaWiki installation and the scripts will use it.

An usual way to set the environment for scripts run by cron jobs is to do something like env 'MW_INSTALL_PATH=/var/www/repo' php &hellip; This should then run whatever php-script you want to append after the php interpreter.

rebuildAllData.php
This script should rebuild all the Wikidata data in secondary storage from articles in Data namespace. You may use it to rebuild data after testing.

deleteAllData.php
This script should delete all the Wikidata data in secondary storage and articles in Data namespace. You may use it to delete the data after testing.

populateSitesTable.php
Usage:

From mediawiki folder run;

This script will load the wiki matrix from meta.wikimedia.org and use that information to populate the local  table. This provides Wikibase with the information it needs to connect to other wikis, e.g. to suggest or normalize the titles of pages when creating site links.

To insert a new wikibase client without wiki matrix see Manual:Sites table.

extractInterlang.sql
This is an SQL query that extracts interlanguage links from a wiki in a format readable by importInterlang.php. You may use it in a database of a wiki that has interlanguage links, so that you can later import them for testings.

importInterlang.php
This script imports interlanguage links from a file into a wiki, also creating labels in the process. The file is a tab-separated CSV file, in the following format:

page_title    ll_lang   ll_title -архив       cs        Seznam forem vlády -архив       de        Liste der Staatsformen und Regierungssysteme -архив       en        Government#Forms of government -архив       eo        Listo de formoj de registaro -архив       es        Anexo:Formas de gobierno -архив       fr        Liste de formes de gouvernements -архив       jv        Daftar wangun pamaréntahan -архив       ku        Lîsteya pergalên siyasî -архив       mk        Список на општествени уредувања -графика      de        -graphie -графика      en        -graphy -графика      id        -grafi -графика      ka        ...გრაფია -графика      sv        -grafi

The first row of the file is ignored.


 * The first column contains article titles of articles on the base wiki (the wiki the links are linked from).
 * The second column contains language codes of the links.
 * The third column contains article titles of the linked articles.

Script options:


 * : if set, the script will print API requests, responses, and other information.
 * : if set, the script will ignore API errors and continue importing even if it encounters an error.
 * : This should be the language code of the base wiki, the wiki you have extracted interlanguage links from.
 * : The file with interlanguage links, presumably generated by extractInterlang.sql.
 * : Base API url of the wiki you are importing the link into. For example,

Example command line:

To import the test items from extensions/Wikibase/repo/maintenance run

pruneChanges.php
This script is located in Wikibase/repo/maintenance/pruneChanges.php. It allows to prune the Wikibase changes table. If you run it without any parameters, it will delete all changes older than 7 days. To delete all changes older than 1 day run

createBlacklistedItems.php
This script creates blacklisted items in Wikidata Data namespace, typically to create easter eggs and similar. The actual data is hardcoded in the script. You may use it before the item ids reaches the first blacklisted items.

importProperties.php
Maintenance script for importing properties in Wikidata. Usually this will use the example file in en-elements-properties.csv as source while building the example entries. You may also use it to create other entries for testing.

To import the test properties from extensions/Wikibase/repo/maintenance run

rebuildEntityPerPage.php
Maintenance script for rebuilding the items_per_page table.

rebuildTermsSearchKey.php
Maintenance script for rebuilding the search key of the TermSQLCache. The search key is an additional column in the wb_terms table. This column is optional in the table and is used for caseless searches.

searchEntityArtefacts.php
This is a maintenance script that queries the database for entity artifacts. During use the database accumulates failed entries and this script tries to find them and print them.

= Wikibase Client =

Configuration
Configuration of is done by assigning to members of   array in your LocalSettings.php file. The options are listed below and their default is set in the. You should NOT modify the settings file, but can have a look at it to get an idea of how to use the settings, in case the below descriptions do not suffice.

''The extension use the variable name, note the initial prefix  , while configuration of other extensions might use the initial prefix. The difference is important and the configuration will fail if the latter is used.''

An example of how to change the settings:

Required settings
repoUrl optionally, can be protocol relative such as '//wikidata.org'; this setting defaults to "//wikidata.org")"

repoScriptPath same as $wgScriptPath in your repo

repoArticlePath same as $wgArticlePath setting, in your repo, and if not set, then it will either be "$wgScriptPath/index.php/$1" (whatever you have for $wgScriptPath in your repo) or '$wgScriptPath?title=$1'

Overview of available settings

 * The available settings are documented in

Maintenance scripts
This extension has some maintenance scripts in the  subdirectory. They assume that the extension is installed in the extensions directory of the MediaWiki software (i.e. files are in the  directory), if this is not the case, you can set the   environment variable to the path of your MediaWiki installation and the scripts will use it.

An usual way to set the environment for scripts run by cron jobs is to do something like env 'MW_INSTALL_PATH=/var/www/client' php … This should then run whatever php-script you want to append after the php interpreter.

rebuildAllData.php
This script should rebuild all the Wikidata data in secondary storage from articles in Data namespace. You may use it to rebuild data after testing.

(Clearify what this script is doing when called from the client)

deleteAllData.php
This script should delete all the Wikidata data in secondary storage and articles in Data namespace. You may use it to delete the data after testing.

(Clarify what this script is doing when called from the client)

Poll for changes
You need to run the Wikibase Lib maintenance script, pollForChanges.php from the client wiki installation, in order to update the cache of local items on the client wiki: php extensions/Wikibase/lib/maintenance/dispatchChanges.php Note that this script does the synchronization. The repo and the client will only be in sync as long as this script is running.

repoUrl
Link to the Wikibase repository. Example is 'http://wikidata-test-repo.wikimedia.de '.

repoScriptPath
Should be same as your $wgScriptPath setting in your repo, for example '/w'

repoArticlePath
Should be same as your $wgArticlePath setting in your repo, for example '/wiki/$1'. If you don't have $wgArticlePath set in your repo, then it should be either "$wgScriptPath/index.php/$1" (whatever you have for $wgScriptPath in your repo) or '$wgScriptPath?title=$1' which are MediaWiki defaults.

siteGlobalID
Global ID for the site tells the polling script to cache and display interwiki links from the repository that are pointing to the client. Default is 'enwiki' for "en" (language code) and "wiki" for the site group, but this could be set to something else;

siteGroup
Default siteGroup setting is 'wikipedia' (for Wikipedia).

namespaces
Array. An array of namespaces in which the extension will work.

Default: the extension will work only in the main namespace.

sort
String. Selects the sort method you want to use for the interlanguage links. Currently, it recognizes four sort methods:
 * : By language code
 * : By language name
 * : By language name (alternative)
 * : Don't sort. Basically, the order of the links is not guaranteed.

Default:  sort mode.

sortPrepend
Array. Modifies the sort method so that it sorts certain languages at the top of the list of languages, regardless of their general sort order. It should be set to an array that has values set to desired language codes, in desired order. For example, to put English and then Simple English at the top of the list of languages, set it to. It is even possible to make an entire custom sort array with all the languages, that will completely override any of the sorting methods.

Default: the sort will be used unmodified.

Features & Usage
After the extension is installed, interlanguage links will automatically be obtained from the repo and be added to client wiki pages, as long as the polling script is running. The extension will then sort the links (sorting defined per-wiki), and display them, and save them to the database, just as if they are defined on the page. The extension is robust and will keep the existing links in case the central wiki is down.

By default the extension only works in the main namespace, but it is possible to change this with the namespaces configuration option.

Mixing Wikidata and local interlanguage links
The extension doesn't interfere with usual working of interlanguage links. They may continue to be used in parallel to the extension. There are several use cases:


 * Links on pages in namespaces which are not configured to use the extension continue to work exactly as without the extension.
 * If you want to add links in addition to the links stored in Wikidata, simply add new links in the wikitext, they will be added to the links from Wikidata, and all the links will be displayed together.
 * If you want to not show some of the links from Wikidata you can use the noexternallanglinks parser function with the desired language(s). Other links will continue to work normally.
 * If you want to overwrite some links from Wikidata, you can likewise use the noexternallanglinks parser function and add the new links in the wikitext.
 * If you want to turn off Wikidata links completely, you can use the noexternallanglinks magic word. In this case the links won't even be sorted, but will continue to work exactly as without the extension.

noexternallanglinks
is a magic word and a parser function which can turn this extension off for a specific page, or suppress some of the interlanguage links produced by the extension.

If used on its own, as, it will turn this extension off on the page. Only the interlanguage links that are present in the wikitext will be used. Sorting of the links will also be turned off, unless the alwaysSort option is turned on. The same effect is achieved if it is used as a function, with an asterisk: (the asterisk "matches" all the languages).

If used as a function, with parameters, only the links to the languages given as parameters will be removed. For example, will remove the links to French and Indonesian languages. The same effect can be achieved by invoking the function repeatedly:. Note that the remaining links will now be sorted, which means that wikitext links will be sorted even if French and Indonesian links were the only ones existing. It is safe to remove the link of a non-existing language.

Data transclusion
WikibaseClient allows for data inclusion from the Wikibase repo, via the parser function and Lua.


 * Lua
 * Lua documentation


 * Parser functions
 * Supports lookup by property ID (e.g. P2), to include data from a connected (via sitelink) Wikibase item. For example,.
 * Lookup by property label. For example,.
 * With arbitrary access enabled it can be used on any item. For example,.
 * In addition to, which outputs linked wikitext, there is also  , which outputs unlinked labels.
 * See d:Wikidata:How to use data on Wikimedia projects for further documentation.

Other projects sidebar

 * ''See also Requests for comment/Interproject links interface for the current situation on Wikimedia projects.

The option  allows to display an "Other projects" sidebar section with links to some other projects gotten from the item linked to the current page. It currently supports only one link per project and does not allow yet to override links from Wikitext with a nice parser function (but current JavaScript hacks may be easily adapted).

Configuration sample (the links will be displayed in the same order):

The id of the sidebar is "wikibase-otherprojects". it may be used in order to customize the section position in the sidebar using MediaWiki:Sidebar.

Each link uses as label the i18n messages "wikibase-otherprojects-ID" with ID the id of the linked site group (like "wikipedia", "wikisource" or "commons").

Sample page: Appel du 18 juin.