Hi,
I'm trying to use Wikibase on my pool wiki and language wikis.
In my pool wiki, I can create properties and items, but I can't add site
links to them. ID: "Q1", site id: "cswiki", site link: "article name"
gives me the error "The specified article could not be found on the
corresponding site." even though that article exists on cswiki.
I also can't access data from the language wikis. If I use
{{#property:P1}} in an article on cswiki, nothing shows up.
I downloaded Wikidata-refs-heads-master.tar.gz and extracted it to the
extension folder of my pool wiki and language wikis.
My LocalSettings.php of the pool wiki looks like this:
# Wikibase
$wgEnableWikibaseRepo = true;
$wgEnableWikibaseClient = false;
$wmgUseWikibaseRepo = true;
$wmgUseWikibaseClient = false;
require_once __DIR__ . "/extensions/Wikidata/Wikidata.php";
require_once __DIR__ .
"/extensions/Wikidata/extensions/Wikibase/repo/ExampleSettings.php";
# SiteMatrix Extension
require_once "$IP/extensions/SiteMatrix/SiteMatrix.php";
$wgLocalDatabases = array( 'cswiki', 'dewiki', 'enwiki', 'eswiki',
'frwiki', 'huwiki', 'hywiki', 'itwiki', 'nlwiki', 'plwiki', 'poolwiki',
'ptwiki', 'ruwiki', 'srwiki', 'svwiki' );
My LocalSettings.php of the language wikis (cs for example) look like this:
# Wikibase Extension
$wgEnableWikibaseRepo = false;
$wgEnableWikibaseClient = true;
$wmgUseWikibaseRepo = false;
$wmgUseWikibaseClient = true;
require_once __DIR__ . "/extensions/Wikidata/Wikidata.php";
# Settings
$wgWBSettings['repoUrl'] = 'http://pool.mypedia.com';
$wgWBSettings['repoScriptPath'] = '/w';
$wgWBSettings['repoArticlePath'] = '/wiki/$1';
$wgWBSettings['siteGlobalID'] = 'cswiki';
$wgWBSettings['repoDatabase'] = 'poolwiki';
$wgWBSettings['changesDatabase'] = 'poolwiki';
# Optional
$wgWBSettings['siteGroup'] = 'mypedia';
$wgWBSettings['sort'] = 'code'; //optional
$wgWBSettings['sortPrepend'] = array(
'cs'
);
In populateSitesTable.php, I changed
"https://meta.wikimedia.org/w/api.php" to
"http://pool.mypedia.com/w/api.php" and "$validGroups = array(
'wikipedia', 'wikivoyage', 'wikiquote', 'wiktionary','wikibooks',
'wikisource', 'wikiversity', 'wikinews' );" to "$validGroups = array(
'mypedia' );"
Do I need to change "$wikiId = $this->getOption( 'wiki' );" too, since
it says "wiki" is expanded to "wikipedia"?
Table "sites" in the poolwiki database looks like this:
site_id | site_global_key | site_type | site_group | site_source |
site_language | site_protocol | site_domain | site_data | site_forward |
site_config
1 | cswiki | mediawiki | mypedia | local | cs | http:// |
com.mypedia.cs. |
a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}}
| 0 | a:0:{}
[...]
15 | poolwiki | mediawiki | pool | local | en | http:// |
com.mypedia.pool. |
a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}}
| 0 | a:0:{}
I changed site_group "wikipedia" to "mypedia" and added data for
site_protocol and site_domain by hand.
I noticed that the script path is "/w/$1" here, while $wgScriptPath in
LocalSettings.php is actually "/w", could that cause any problems?
And should I change site_group of the pool to mypedia like I did with
the language wikis or isn't that necessary?
Wikibase DataModel 0.8, Wikibase Repository 0.5 alpha, WikibaseLib 0.5
alpha and Wikidata show up in Special:Version of the pool wiki.
Wikibase Client 0.5 alpha, Wikibase DataModel 0.8, WikibaseLib 0.5 alpha
and Wikidata show up in Special:Version of the language wikis.
Any help would be really appreciated!
Thanks and cheers,
Till
Hi,
I'm running multiple language wikis and one pool wiki. The problem is
that no file descriptions are fetched in the language wikis although
$wgFetchCommonsDescriptions is set to true.
LocalSettings.php of the language wikis:
$wgUseSharedUploads = true;
$wgSharedUploadPath = 'http://pool.example.com/w/images';
$wgSharedUploadDirectory = '/path/to/pool/w/images/';
$wgHashedSharedUploadDirectory = true;
$wgFetchCommonsDescriptions = true;
$wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki
#$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki
$wgRepositoryBaseUrl = "http://pool.example.com/wiki/Image:";
ForeignAPIRepo used to work fine before, but since I switched from
Apache to Nginx, no images show up anymore in the language wikis. This
is how my LocalSettings.php used to look like:
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'pool',
'apibase' => 'http://pool.example.com/w/api.php',
'fetchDescription' => true, // Optional
'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are
seconds)
'apiThumbCacheExpiry' => 0, // required for local thumb caching
);
I also tried to set 'name' => 'poolwiki', (name of the pool database)
but that doesn't work either.
I also re-started Memcached and I even deleted a file description page
from the CloudFlare cache, but still no file description can be seen :/
My software: MediaWiki: 1.22.0
PHP: 5.3.27 (fpm-fcgi)
MySQL: 5.1.70-log
Any help would be über-cool.
Thanks and cheers,
Till
Hey all,
TL;DR:
* We did not make the breaking change last week for Wikimedia; it is postponed.
* MediaWiki 1.24.0 will ship with jQuery Migrate switched off.
* Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed.
* When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis.
As we said last month, we are upgrading MediaWiki's jQuery to version 1.11.x [1],
which removes some long-deprecated functions. These were done in phase one [2]
and two [3] as of last week.
However, we have held off with phase 3 (removing the jQuery Migrate plugin) for
a while to give migration a little more time.
The amount of migration work necessary has been much less than I anticipated.
Very few scripts have actually needed changing, probably because these features
have been deprecated for quite a while now. Some of newer developers may never
have even known of these APIs.
Having said that, it does take a while for a message like this to spread out to
some members of our large community. While those wiki scripts and gadgets which
have active maintainers have been looked into, and (where needed) updated
accordingly, a large number of gadgets and scripts in the cluster of Wikimedia
wikis have not yet had a chance to get a grip on this, let alone extensions and
wikis outside of Wikimedia.
While I don't want to set another deadline, I think it makes sense to ship the
jQuery Migrate plugin for one release (with MediaWiki 1.24), and then remove it
in MediaWiki 1.25. This will give all wikis' communities and extension authors
a few more months until the MediaWiki 1.24 branch point (in Autumn 2014) before
they will need to make adjustments to work with MediaWiki master.
MediaWiki 1.24.0 stable will disable support for legacy jQuery by default. If
you find you have scripts, gadgets or extensions still using legacy jQuery APIs,
you can enable them with a simple line in LocalSettings.php:
$wgIncludejQueryMigrate = true;
And of course when you find you need to do this, please make an effort to
ensure the maintainers of those items still using these legacy features are
aware of this so they may patch the code accordingly (using the upgrade guide[4]
and my earlier announcement [5]). When MediaWiki 1.24 is released, we will
switch off jQuery Migrate for Wikimedia wikis.
— Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740
[2] https://gerrit.wikimedia.org/r/#/c/131494/
[3] https://gerrit.wikimedia.org/r/#/c/133477/
[4] http://jquery.com/upgrade-guide/1.9/
[5] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg75735.html
On 7 May 2014, at 18:29, Krinkle <krinklemail(a)gmail.com> wrote:
> Hey all,
>
> TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This
> major release removes deprecated functionality. Please migrate away from this
> deprecated functionality as soon as possible.
>
> It's been a long time coming but we're now finally upgrading the jQuery package
> that ships with MediaWiki.
>
> We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple
> of years ago due to lack of time and concern about disruption. Because of this,
> many developers have needed to work around bugs that were already fixed in later
> versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been
> the first release in jQuery history that needed an upgrade guide[1][2]. It's a
> major release that cleans up deprecated and dubious functionality.
>
> Migration of existing code in extensions, gadgets, and user & site scripts
> should be trivial (swapping one method for another, maybe with a slight change
> to the parameters passed). This is all documented in the upgrade guide[1][2].
> The upgrade guide may look scary (as it lists many of your favourite methods),
> but they are mostly just addressing edge cases.
>
> == Call to action ==
>
> This is a call for you, to:
>
> 1) Get familiar with http://jquery.com/upgrade-guide/1.9/.
>
> 2) Start migrating your code.
>
> jQuery v1.9 is about removing deprecated functionality. The new functionality is
> already present in jQuery 1.8 or, in some cases, earlier.
>
> 3) Look out for deprecation warnings.
>
> Once instrumentation has begun, using "?debug=true" will log jQuery deprecation
> warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also
> find deprecation notices from mediawiki.js, for more about those see the mail
> from last October [8].
>
> == Plan ==
>
> 1) Instrumentation and logging
>
> The first phase is to instrument jQuery to work out all the areas which will
> need work. I have started work on loading jQuery Migrate alongside the current
> version of jQuery. I expect that to land in master this week [6], and roll out on
> Wikimedia wikis the week after. This will enable you to detect usage of most
> deprecated functionality through your browser console. Don't forget the upgrade
> guide[1], as Migrate cannot detect everything.
>
> 2) Upgrade and Migrate
>
> After this, the actual upgrade will take place, whilst Migrate stays. This
> should not break anything since Migrate covers almost all functionality that
> will be removed. The instrumentation and logging will remain during this phase;
> the only effective change at this point is whatever jQuery didn't think was
> worth covering in Migrate or were just one of many bug fixes.
>
> 3) Finalise upgrade
>
> Finally, we will remove the migration plugin (both the Migrate compatibility
> layer and its instrumentation). This will bring us to a clean version of latest
> jQuery v1.x without compatibility hacks.
>
>
> A rough timeline:
>
> * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
> will run for 4 weeks (until June 9).
>
> * 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
> weeks (upto June 9). The instrumentation continues during this period.
>
> * 1 June 2014 (1.24wmf7) Finalise upgrade.
>
>
> == FAQ ==
>
> Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
>
> A: Those are regular updates that only fix bugs and/or introduce non-breaking
> enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any
> hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
>
>
> Q: What about the jQuery Migrate plugin?
>
> A: jQuery developed a plugin that adds back some of the removed features (not
> all, consult the upgrade guide[2] for details). It also logs usage of these to
> the console.
>
>
> Q: When will the upgrade happen?
>
> A: In the next few weeks, once we are happy that the impact is reasonably low.
> An update will be sent to wikitech-l just before this is done as a final reminder.
> This will be well before the MediaWiki 1.24 branch point for extension authors
> looking to maintain compatibility.
>
>
> Q: When are we moving to jQuery v2.x?
>
> A: We are not currently planing to do this. Despite the name, jQuery v2.x
> doesn't contain any new features compared to jQuery v1 [3]. The main difference
> is in the reduced support for different browsers and environments; most
> noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which
> MediaWiki is still supporting for now, and is outside the scope of this work.
> Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new
> features. For example, jQuery released v1.11 and v2.1 together[4][5].
>
> -- Krinkle
>
> [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
> final-released/
> [2] http://jquery.com/upgrade-guide/1.9/
> [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/
> [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
> [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/
> [6] https://gerrit.wikimedia.org/r/131494
> [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md
> [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html
> [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
>
I am trying to get the Visual Editor working in my 1.24 wmf11 Mediawiki
install.
I have set everything up per the docs. The parsoid install tests fine
(the "loopback" test works) but when I try to use the visual editor I
get errors.
VisualEditor.php cannot find 'ext.parsoid.styles" and it crashes.
Commenting it out allows it to run, but with errors.
'dependencies' => array(
'ext.visualEditor.core',
'mediawiki.Title',
'mediawiki.action.history.diff',
'mediawiki.user',
'mediawiki.util',
'mediawiki.jqueryMsg',
'jquery.autoEllipsis',
'jquery.byteLimit',
# 'ext.parsoid.styles',
),
So... Where and how do I find this dependency?
I have parsoid installed, running, and tested.
--
Yan Seiner, PE
Asia Project Manager
Roadtrek Motorhomes, Inc
541-513-4838
I was doing some checking on activity using the API at a WMF wiki, and
found that the wiki was reporting that in some cases that the recentedit
count was reporting higher than editcount, and in some cases significantly
higher.
https://tt.wikipedia.org/w/api.php?action=query&list=allusers&auactiveusers…
eg. <u userid="3235" name="[redacted]" editcount="1" recenteditcount="121"
/>
I checked logs for administrative rights, or patrolling, and they showed
nothing. Can someone please explain the quirkiness of the result?
Thanks.
Regards, Billinghurst
Hm, in my Wiki it highlights nothing..
The problem is, that my mediawiki is stored on synology, and i'm not shure if ElasticSearch works on a NAS.
So if you would have an other solution it would be great? :D Otherwise i hope that mediawiki adds this settings soon!
Thx alot!
Rea
-------------------------------------
>one that WMF is slowly moving to. I'm not an expert on the built in search
>but it _should_ highlight the matches. It might not highlight them
>perfectly, like if you search for "cats" and the backend finds "cat" it
>might not highlight it.
>If you want a really nice search I suggest setting up CirrusSearch because
>it should be easier to set up then the other options. And, if it doesn't
>work for you I can help.
>
>Sorry thats kind of a non-answer.
>
>Nik
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.06. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.06.tar…
* sha256sum: 02721b25e8c8fe06889b825a1c03fc4c1b1e4268d1e56169815983b5e87e8932
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR, CleanChanges and LocalisationUpdate ==
* Only localisation updates
== Translate ==
=== Noteworthy changes ===
* New feature, Special:PageMigration page has been added and feedback
is welcome!
** Fetches and displays the translation units created by Translate for
the given page.
** Imports the old translations for given language on paragraph level
and displays them.
** Feature can be now conditionally enabled by setting
$wgTranslatePageMigration to true.
** Allows to edit or delete a translation as well as swapping with the
unit below.
** Allows to save the translations by creating corresponding pages.
** Enabled by default for translation admins.
* Special:AggregateGroups page is now visible to unprivileged users in
read-only mode.
* Email notifications are no longer sent upon translation review.
* Page title can be excluded from translation.
* Regression fix: Message checker live updates is working again with
this release.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Bug 64741: Fix 'Add links' option in Monobook skin when page has no
interlanguage links.
* Added support for Khakas language.
Thanks!
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Just upgraded from 1.22.7 to 1.23.1 and the Google Calendar stopped
working. Might that I was also switching to Semantic Wiki bundle?
http://www.mediawikiwidgets.org/Google_Calendar
Are there any other issues?
Gordo
Hello!
My name is Albert. I am making an extension in mediawiki which is
capable of storing materials, values of their properties like tensile
strength, specific heat etc., add new material, view all stored values
of properties, import/export in CSV, JSON etc. format. But I have been
able to do this to some extent with the help of two extensions.
First extension[1]-> Can add new material, add values for the
properties of that material.
Second extension[2]-> Can show the all the materials and values of
their properties with their timestamp in tabular form.
The code of first extension can be seen at [3]. And the code of second
extension can be seen at [4].
How can I merge the functionalities of both these extensions to make a
single extension? I wish to embed the code of second extension in my
first extension. I tried doing this by writing the code of second
extension in a new class which extends SpecialPage class within main
file of my first extension and then included the name of the new class
in $wgAutoloadClasses[' ']. I am not sure if this method is right. In
short I wish to have a link "view all properties" on my special page
of first extension such that the code of my second extension gets
executed and shows all properties.
Another query is that I wish to make certain forms like add new
property, add new material-type, add new property-type and so on. How
can I navigate those forms with the hyperlinks on the special page of
my first extension. Or how can I add new pages or special pages
perhaps in my extension to achieve the required functionality?
I tried to study linker class from [5] but I could not understand
because of absence of examples. Also I tried to get help from
#mediawiki IRC but could not earn much. Being a beginner I feel it too
tough to get a clear view of how to use the inbuilt functions of
mediawiki. I would be grateful if you share/help me with a simple
extension which clears all my doubts as above.
Please see the two extensions working at [1] and [2] respectively.
[1]-> http://202.164.53.122/~albertcoder/mediawiki-1.22.6/index.php/Special:Mat_e…
[2]-> http://202.164.53.122/~albertcoder/mediawiki-1.22.6/index.php/Special:Joins
[3]-> https://github.com/albertcoder/MaterialsDatabase
(Specialmat_ext.php has all the coding)
[4]-> https://github.com/albertcoder/SqlJoinsMediawiki
(SpecialJoins.php has all the coding)
[5]-> doc.wikimedia.org/
--
Thanks
Albert
www.coderalbert.wordpress.com
" Eat Sleep Conquer Repeat "