I try to convert a MediaWiki database from 1.4.5 to 1.5.8 (yes I know I am a bit late. but up to now the database has perfectly
served me ever since 2005). We now want to migrate to a new Linux server, so we want to upgrade to the latest available version.
I understood I should first migrate to 1.5 first.
So I downloaded <https://releases.wikimedia.org/mediawiki/1.5/mediawiki-1.5.8.tar.gz>
https://releases.wikimedia.org/mediawiki/1.5/mediawiki-1.5.8.tar.gz
I follow the script on https://www.mediawiki.org/wiki/Manual:Upgrading
But I receive the following error message:
php maintenance/upgrade1_5.php
2017-06-25 15:09:10: Checking cur table for unique title index and applying if necessary
wiki: cur table has the current unique index; no duplicate entries.
2017-06-25 15:09:10: ...converting from cur/old to page/revision/text DB structure.
2017-06-25 15:09:10: Creating page and revision tables...
2017-06-25 15:09:10: Last old record is 31158
......Moving text from cur.
2017-06-25 15:09:10: Last cur entry is 31970
PHP Notice: mysql_query(): Function called without first fetching all rows from a previous unbuffered query in
/var/www/html/bike/includes/Database.php on line 349
2017-06-25 15:09:11: 0.31% done on old; ETA 2017-06-25 15:12:48 [100/31970] 147.11/sec
2017-06-25 15:09:11: 100.00% done on old (last chunk 0 rows).
Unable to free MySQL result
Backtrace:
GlobalFunctions.php line 513 calls wfBacktrace()
Database.php line 495 calls wfDebugDieBacktrace()
FiveUpgrade.inc line 426 calls Database::freeResult()
FiveUpgrade.inc line 49 calls FiveUpgrade::upgradePage()
upgrade1_5.php line 22 calls FiveUpgrade::upgrade()
The following (empty) tables are created:
xxx_page;
xxx_revision;
All of the other V1.5 tables are still missing.
* How could I avoid the above error?
* What could I have done wrong/missing
vi /var/www/html/bike/includes/Database.php
:349
function doQuery( $sql ) {
if( $this->bufferResults() ) {
$ret = mysql_query( $sql, $this->mConn );
} else {
$ret = mysql_unbuffered_query( $sql, $this->mConn );
}
return $ret;
Geert Van Pamel
Hi,
I'd like to find a PHP developer to manage some configuration updates on my
MW. I'm busy on other projects and don't have time.
The work to be done is:
* Update ImageMagick
* Update PHP to version 7
* Update MW to current release
* Install Parsoid for visual editor
* Install https using service from Let's Encrypt
Thanks
David
mailto:davidshaw@wikisea.org
You might prefer the using the $.when() idiom for this, which waits for
multiple concurrent promises, and is usable here given that $() is
essentially a shortcut to the internal $.ready promise, which is publicly
available per https://api.jquery.com/jQuery.ready/ – The following has
worked for years (since jQuery 1.8), and became documented (and officially
supported) since jQuery 3.
$.when(
$.ready,
mw.loader.using( [ 'mediawiki.util' ] )
).then(function(){
// mw.util.addPortletLink( ... );
} );
On Sun, May 21, 2017 at 4:31 PM, Brion Vibber wrote:
> If you both need to manipulate part of the page and need a specific
module,
> probably this:
>
> // If we haven't already started loading the module, start loading it:
> mw.loader.using('mediawiki.util', function() {
> // Module is loaded, *but* it's possible the page HTML is not done. Wait
> // for it:
> $( function() {
> // Now it should be safe to do everything:
> mw.util.addPortletLink(....);
> } );
> });
Hey all,
TL;DR: In MediaWiki 1.30, the jQuery library will be upgraded from 1.x to
3.x
(with jQuery Migrate enabled by default).
Read about this release and the API changes:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/https://jquery.com/upgrade-guide/3.0/
== Upgrade guide ==
An overview of the important changes is available at:
https://jquery.com/upgrade-guide/3.0/
This page also contains advice on how to migrate your code. In most cases
it involves fairly
simple changes, such as using a different method name, or adding quotes in
selectors.
The vast majority of the added requirements and removed methods are
restored through
the jQuery Migrate plugin with a deprecation warning in the console. As
such, it's unlikely
your code will require any immediate changes.
If you do find a deprecation warning in the console, you can use the
warning documentation
to find out more: https://github.com/jquery/jquery-migrate/blob/
e967c3b98b/warnings.md
In MediaWiki 1.30, it will be easy to find uses of deprecated methods with
the deprecation
warnings. However, you don't need to wait for MediaWiki 1.30 to start
migrating. The
methods removed in jQuery 3 have been deprecated for a while already, and
their
replacements are already available in jQuery 1.x, today.
== Timeline ==
* April 2017: jQuery 3 lands in MediaWiki core master with jQuery Migrate
plugin.
* April to July 2017: Testing and fixing of issues detected during
development.
* July 2017: jQuery 3 enabled in Wikimedia's Beta Cluster. [1]
* August 2017: jQuery 3 enabled on Wikimedia wikis in production.
jQuery 3 will also be released as part of MediaWiki 1.30.0 (expected in
November 2017). [2]
As part of MediaWiki 1.30, inclusion of jQuery Migrate will made
configurable so that sites
that have already migrated may disable the plugin for better run-time
performance.
Track progress at <https://phabricator.wikimedia.org/T124742>.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Beta_Cluster
[2] https://www.mediawiki.org/wiki/MediaWiki_1.30
I've just swatted a change to production and merged a patch into the
current master of TextExtracts which updates the extension to strip any
script tags and input tags that may result from parser output.
The problem is theoretical and I'm not aware of any existing vectors for
attack but I recommend anyone using the TextExtracts extension in
production either update to the current master or update
$wgExtractsRemoveClasses global config to include script and input tags.
The issue is tracked in https://phabricator.wikimedia.org/T107206 (currently
hidden but I've requested it be made public)
Its been almost a year on this ticket without any progress. Can we please
get some way of merging two pages that functions regardless of edit
timestamps? I am in the process of cleaning up a project where forking has
happened by accident quite often, and this would be a significant time
saver.
Ideally we would be able to give two pages: A & B, either by order or by
new parameter select the final title, and the result being that all edits
from A and B are now at A. Or could we get an option that overrides that
part of MergeHistory's failsafe check?
> On Thu, 15 Jun 2017 12:34:51, Gary Guo <nbdd0121(a)hotmail.com> wrote:
>
> Wikitext allows nested instantiations of templates, so the language
> is not regular. Therefore there exists no regular expessions that can
> match wikitext.
In that case, what resource could be considered as a standard
definition for the syntax of wikitext?