At this point most of our wikis have been upgraded to MediaWiki 1.4,
which has a few spiffy new features, some bug fixes, and some
performance improvements in page rendering.
I'm slating the upgrades for *.wikipedia.org to start around 1 or 2 am
UTC Thursday morning (Wednesday evening in the US). There will be some
read-only time during the conversions, which may last up to a few hours
depending on how cooperative the databases are.
Note that there's an issue with the special character insertion
template on the edit page; on older versions it happened to be possible
to insert raw HTML and JavaScript in that portion of the template but
ongoing cleanup (for security and robustness reasons, outlined in my
recent post to Wiktionary-l) mean that it doesn't work anymore.
It is a useful thing though, and it should be possible to make it work
through alternate means, namely a simple MediaWiki extension module.
I'll try to have one ready around the time of the conversion if
somebody doesn't beat me to it.
Please don't forget to file bug reports at
http://bugzilla.wikipedia.org for unresolved problems on the other new
wikis. We might not get to everything immediately, but we'll never be
able to fix problems we don't know about.
-- brion vibber (brion @ pobox.com)
Thank you for your advices and the backround info.
I just tried to install MediaWiki 1.4beta3. Unfortunatly is doesn't work
too. Here's the response message:
[...]
MediaWiki 1.4beta3 installation
Please include all of the lines below when reporting installation problems.
Checking environment...
* PHP 4.3.9: ok
* Warning: PHP's register_globals option is enabled. MediaWiki will
work correctly, but this setting increases your exposure to potential
security vulnerabilities in PHP-based software running on your server. You
should disable it if you are able.
* PHP server API is apache2handler; ok, using pretty URLs
(index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP is configured with no memory_limit.
* Have zlib support; enabling output compression.
* Turck MMCache not installed, can't use object caching functions
* Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
* Installation directory: C:\Programme\xampp\htdocs\mediawiki
* Script URI path: /mediawiki
* Warning: $wgProxyKey is insecure
* Connected as root (automatic)
* Connected to database... 4.1.7-log; enabling MySQL 4 enhancements
* Warning: $wgProxyKey is insecure
* Created database wikidb
* Creating tables...A database error has occurred Query: CREATE TABLE
categorylinks ( cl_from int(8) unsigned NOT NULL default '0', cl_to
varchar(255) binary NOT NULL default '', cl_sortkey varchar(255) binary NOT
NULL default '', cl_timestamp timestamp NOT NULL, UNIQUE KEY
cl_from(cl_from,cl_to), KEY cl_sortkey(cl_to,cl_sortkey(128)), KEY
cl_timestamp(cl_to,cl_timestamp) ) Function: Error: 1071 Specified key was
too long; max key length is 1000 bytes Backtrace: Database.php line 345
calls wfdebugdiebacktrace() Database.php line 297 calls
database::reportqueryerror() install-utils.inc line 118 calls
database::query() index.php line 516 calls dbsource()
[...]
Any hints?
By the way: Is the import/export format of MediaWiki 1.4 compatible with
version 1.3? (I would like to exchange pages with a 1.3 MediaWiki
installation...)
Regards
Stefan
hi
here is an extract from a short talk i had on irc lately:
>kakau does anyone present remember this posting concerning a
wikipedia visual navigator? my very humble suggestion (about 2 mths
ago) was then bluntly rejected for no clearcut reasons or let's put it
the other way: did anyone of you once come across
http://www.visualthesaurus.com/online/ or touchgraphs wikibrowser
http://www.touchgraph.com/TGWB_101_SS.html ???
>hashar I did I dont think we can use that on wikipedia servers, it
will generate too many queries for the DB servers
kakau and exactly *this* is *not* true. all you'd need to make that
work would be a wiki "action" that only listed either the hyperlinks or
the categories or both of one article at a time... look at
tgwikibrowser. it's fairly straigthforward. while you are in "visual"
mode, the load would be even less than for a full text query result
>hashar that s still one more query made additional queries to build
the tree
>kakau you won't have one person do both at the same time: either
people navigate through "bubbles" or through text. this argument is
nil... 8) some people, just to insist a bit more, do in fact like
http://www.kartoo.com/ which is not so far from my suggestion, either i
just cannot imagine that the outside world is really busy and keen on
visual navigation just for laughs i'd rather think that the idea holds
some "extra value"... for the "customer"
as an aside: i think i posted an idea about a "semantic wikipedia" over
one year ago. the idea, sadly enough, was turned down too. now we see
categorization in full bloom. whom exactly should i address to make my
visual navigation proposal be heard?
8)
I've created a <charinsert> extension which produces the little
javascript inserter bits for the characters you feed it. This can be
used in wikitext, such as the 'copyrightwarning' messages which was
previously HTML.
I set up the English Wikipedia chars again using this:
http://en.wikipedia.org/wiki/MediaWiki:Copyrightwarning
Please feel free to set up the appropriate equivalents at the other
'pedias, 'tionaries, and all.
-- brion vibber (brion @ pobox.com)
Hi,
I'm quite new to mediawiki and the supporting stuff like PHP and MySQL. And
I'm not sure if this list is the right one for my problem. So please excuse
any misuse...
I tried to install Mediawiki 1.3.9 on my local german WinXP SP 2 notebook,
using a fresh XAMPP 1.4.10a installation.
The install page says:
[...]
Checking environment...
* PHP 4.3.9: ok
* Warning: PHP's register_globals option is enabled. MediaWiki will
work correctly, but this setting increases your exposure to potential
security vulnerabilities in PHP-based software running on your server. You
should disable it if you are able.
* PHP server API is apache2handler; ok, using pretty URLs
(index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP is configured with no memory_limit.
* Have zlib support; enabling output compression.
* Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
* Installation directory: C:\Programme\xampp\htdocs\mediawiki
* Script URI path: /mediawiki
[...]
But after entering all the data and submitting the page, I get a blank page
in response.
No LocalSettings.php file is generated.
The wikidb database was created, but seems to be incomplete. (Some tables
seems to be missing.)
After refreshing http://localhost/mediawiki/config/index.php, I get this
response:
[...]
MediaWiki 1.3.9 installation
Please include all of the lines below when reporting installation problems.
Checking environment...
* PHP 4.3.9: ok
* Warning: PHP's register_globals option is enabled. MediaWiki will
work correctly, but this setting increases your exposure to potential
security vulnerabilities in PHP-based software running on your server. You
should disable it if you are able.
* PHP server API is apache2handler; ok, using pretty URLs
(index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP is configured with no memory_limit.
* Have zlib support; enabling output compression.
* Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
* Installation directory: C:\Programme\xampp\htdocs\mediawiki
* Script URI path: /mediawiki
* Warning: $wgProxyKey is insecure Connected as root (automatic)
* Connected to database... 4.1.7-log; enabling MySQL 4
enhancementsWarning: $wgProxyKey is insecure
* Database wikidb exists
* There are already MediaWiki tables in this database. Checking if
updates are needed...
Updating ipblocks table... Query "ALTER TABLE ipblocks ADD ipb_auto
tinyint(1) NOT NULL default '0', ADD ipb_id int(8) NOT NULL auto_increment,
ADD PRIMARY KEY (ipb_id)" failed with error code "Table 'wikidb.ipblocks'
doesn't exist".
[...]
I found this problem descrption in various wikipedia discussion pages, e.g.
http://meta.wikimedia.org/wiki/Talk:Running_MediaWiki_on_Windows#Nothing_ha…http://meta.wikimedia.org/wiki/Talk:Running_MediaWiki_on_Windows#Nothing_ha…http://de.wikipedia.org/wiki/Wikipedia_Diskussion:MediaWiki-Installationsan…
(german)
Can anyone help on this? E.g. where can I find any log files giving more
info? (I looked at mysql\data\mysql.err but found nothing there.)
Regards
Stefan
Hi,
I'm currently fiddling with the importUseMod-script for migrating a wiki and
have implemented a functionality for replacing CamelCase notation with "correct
fluent text". Along this I also took the opportunity to insert appropriate
[[Category:...]] and {{...}} lines into the respective SQL statements in varying
numbers. After running the import SQL those insertions are available in the
plain article text and displayed/executed correctly, but they are not subject to
search and "Specialpages:Category" links.
Example: The lines [[Category:Glossary]] and {{revise}} are part of a large
number of articles. The category list at the bottom of the page is displayed
correctly and if the Article "Template:revise" exists, its content is included
correctly. But when clicking the category name or performing a text search on
"revise", there is nothing returned. This changes when a respective article is
once opened for edit and saved immediately after (or doing actual changes). Then
this article is availabe in the category listing and comes up as a search result.
Of course I can see that this is due to the missing information in the
categorylinks and searchindex tables which is obviously created/updated when
saving an article.
Now for the question after all: Opening and just saving ~1000 articles for the
sake of indexing categories and search may be an honourable task, but an eternal
one as well -
Is there a function/script/trick to run once and after that the
categories and searchindexes would be up to date? No problem if this
takes a while.
Greetings
Philipp
I have committed an unfinished and experimental, but basically working external
search daemon and extension to use it, based on the Lucene search engine [1].
This enables searching to be moved out of MySQL and handled separately, thus not
bogging down the database server with search queries and updates, as well as
giving us the full power of a complete search engine, rather than
MySQL's rather
limited one. I suspect it will also be a bit faster; indexing en.wikibooks on a
1.1GHz Athlon with IDE disk takes 180 seconds (index size on disk: 53MB).
Other interesting possibilities include much shorter delays for search updates,
incremental updates, various new ways to search other than title/body content,
and so on.
To use it, check out the `lucene-search' module from CVS, and see the README.txt
file for more information. Note that it ONLY works with 1.5. I may backport it
to 1.4 at some future point.
Kate.
[1] http://jakarta.apache.org/lucene/docs/index.html
commons.wikipedia.org is now running on REL1_4. Overall it's looking
pretty good, but there may yet be surprises. Large categories full of
images present a bit of a difficulty, as least with the thumbnails not
all rendered yet...
We'll expand the beta onto the other Wikimedia wikis over the next week
or so.
-- brion vibber (brion @ pobox.com)