-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nickj(a)svn.wikimedia.org wrote:
> Revision: 21819
> Author: nickj
> Date: 2007-05-02 23:08:12 -0700 (Wed, 02 May 2007)
>
> Log Message:
> -----------
> (bug 7958) Special:Cite of older version of an article should use old version id.
> Applying Brion's patch, with one-line tweak:
> - uses the existing Skin/$wgOut-based revision ID record, rather than oldid value from WebRequest.
> - additionally sets it to the current revision for parser cache hits (where
> it was not previously needed, since it was only used to feed to parser objects
> to fill the {{REVISIONID}} variable).
> - Explicit declaration of the existing $mRevisionId data member in Skin.
> - "Permanent link" should now work too when paging through historical versions (previously it
> would be greyed out when paging backwards or forwards through old revisions).
>
> Modified Paths:
> --------------
> trunk/phase3/RELEASE-NOTES
> trunk/phase3/includes/Article.php
> trunk/phase3/includes/Skin.php
> trunk/phase3/includes/SkinTemplate.php
Note that this commit introduced a regression: see Bug 9812 ,
http://bugzilla.wikimedia.org/show_bug.cgi?id=9812 .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGPgQJqahN/0dU8mcRAo6QAJ9B8bG6Jxo0XDsbofGKlVjHQiY4egCglRL4
Vrko0YRyji2QefeWz19Nj/o=
=Bblf
-----END PGP SIGNATURE-----
hello,
/home/wikipedia/bin/sync-common-file can now be used to sync a single file
from common to all apaches. (i got bored of using sync-common-all for
robots.txt ;-)
- river.
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.11alpha (r21924).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Fuzz testing: image with bogus manual thumbnail [Introduced between 08-Apr-2007 07:15:22, 1.10alpha (r21099) and 25-Apr-2007 07:15:46, 1.10alpha (r21547)]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 495 of 513 tests (96.49%)... 18 tests failed!
I imported the enwiki-20070402 dumps with MediaWiki 1.10rc2 along with
all images for this release. Issues identified:
1. Greatly improved performance on article rendering.
2. MIME detection in the default settings still does not detect .png
files correctly
3. alternate file -bi method works, but this utility has problems with
a lot of svg image files.
4. Rendering of xml+svg files is still broken. 1.9.3 actually had some
problems rendering svg images, but most of them worked. 1.10rc2
has severe breakage and they do not render at all on Fedora Core 5.
The site with 1.10rc with a fresh database import is located at:
http://test.wikigadugi.org
You are free to visit the site and inspect these issues. The
LocalSettings.php file is using these settings (with DB passwords removed):
<?php
# This file was automatically generated by the MediaWiki installer.
# If you make manual changes, please keep track in case you need to
# recreate them later.
#
# See includes/DefaultSettings.php for all configurable settings
# and their default values, but don't forget to make changes in _this_
# file, not there.
# If you customize your file layout, set $IP to the directory that contains
# the other MediaWiki files. It will be used as a base to locate files.
if( defined( 'MW_INSTALL_PATH' ) ) {
$IP = MW_INSTALL_PATH;
} else {
$IP = dirname( __FILE__ );
}
$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR .
get_include_path() );
require_once( "includes/DefaultSettings.php" );
# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );
if ( $wgCommandLineMode ) {
if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD',
$_SERVER ) ) {
die( "This script must be run from the command line\n" );
}
}
## Uncomment this to disable output compression
# $wgDisableOutputCompression = true;
#$wgReadOnly = true;
$wgUseTidy = true;
$wgTidyBin = '/usr/bin/tidy';
$wgTidyConf = $IP.'/extensions/tidy/tidy.conf';
$wgArticlePath = "/wiki/$1";
$wgSitename = "WikiGadugi";
## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
$wgScriptPath = "";
## For more information on customizing the URLs please see:
## http://www.mediawiki.org/wiki/Manual:Short_URL
$wgEnableEmail = true;
$wgEnableUserEmail = true;
$wgEmergencyContact = "root@localhost";
$wgPasswordSender = "root@localhost";
## For a detailed description of the following switches see
## http://meta.wikimedia.org/Enotif and http://meta.wikimedia.org/Eauthent
## There are many more options for fine tuning available see
## /includes/DefaultSettings.php
## UPO means: this is also a user preference option
$wgEnotifUserTalk = true; # UPO
$wgEnotifWatchlist = true; # UPO
$wgEmailAuthentication = true;
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "XXXXX";
$wgDBuser = "XXXXX";
$wgDBpassword = "XXXXX";
$wgDBport = "5432";
$wgDBprefix = "";
# MySQL table options to use during installation or update
$wgDBTableOptions = "TYPE=InnoDB";
# Schemas for Postgres
$wgDBmwschema = "mediawiki";
$wgDBts2schema = "public";
# Experimental charset support for MySQL 4.1/5.0.
$wgDBmysql5 = false;
## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();
## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads = false;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
# $wgHashedUploadDirectory = false;
## If you have the appropriate support software installed
## you can enable inline LaTeX equations:
$wgUseTeX = false;
$wgLocalInterwiki = $wgSitename;
$wgLanguageCode = "en";
$wgProxyKey =
"bee7d337552387a49caaf5fe88e685d8aa20b84949d0f90c3e9b80bb138ef8c1";
## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook':
$wgDefaultSkin = 'monobook';
## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
# $wgEnableCreativeCommonsRdf = true;
$wgRightsPage = ""; # Set to the title of a wiki page that describes
your license/copyright
$wgRightsUrl = "";
$wgRightsText = "";
$wgRightsIcon = "";
# $wgRightsCode = ""; # Not yet used
$wgDiff3 = "/usr/bin/diff3";
# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$configdate = gmdate( 'YmdHis', @filemtime( __FILE__ ) );
$wgCacheEpoch = max( $wgCacheEpoch, $configdate );
$wgUseFileCache = true;
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
$wgUseGzip = false;
$wgAntiLockFlags = ALF_NO_LINK_LOCK | ALF_NO_BLOCK_LOCK;
$wgShowExceptionDetails = true;
require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
require_once( "$IP/extensions/Cite.php" );
require_once( "$IP/extensions/ImageMap/ImageMap.php" );
require_once( "$IP/extensions/wikihiero/wikihiero.php" );
require_once( "$IP/extensions/checkuser/CheckUser.php" );
$wgGroupPermissions['checkuser']['checkuser'] = true;
$wgCheckUserLog = false;
Hello,
I made some update to our various sites.
There were some issues with the following bugs and some pages have been
automatically renamed with a suffix '/broken'. The list of pages is
provided as a comment and can be fixed manually by any user:
* Bug 9782: Set sitename for Belarusian Wikipedia
* Bug 9232: Set project namespace for Thai Wikipedia
* Bug 8005: Project namespace prefix in the Greek Wikiquote
* Bug 8964: Set sitename for Occitan Wiktionary
* Bug 8631: Set sitename and project ns name for Catalan Wikiquote
* Bug 9561: Set sitename and project ns name for Catalan Wiktionary
* Bug 9707: Change of Armenian project names
Other fixes:
* Bug 9788: Created Appendix namespace on Icelandic Wiktionary
* Bug 9728: Disabled uploads for Spanish Wikiquote
* Bug 9725: Created Portal namespace on Greek Wikipedia
* Bug 9800: Changed the Searched Default for de.wikiversity
* Bug 9573: Additional namespaces on French Wikiversity
* Bug 9732: Created namespaces for Farsi Wikipedia
* Bug 9586: Subpage activation for template namespace in kkwiki
* Bug 9523: Added a Portal namespace to Hebrew Wikinews
* Bug 8528: Created Portal namespace on Malayalam Wikipedia
* Bug 9283: Created Wikijunior namespace on English Wikibooks
* Bug 9170: Updated logo and timezone on slovene Wikiquote
* Bug 8614: Changed $wgSitename for Chuvash Wikipedia
* Bug 7976: Set project name for Old Church Slavonic Wikipedia
* Bug 8546: Enable Special:Import for Polish Wikibooks
* Bug 6595: Set sitenames for Urdu projects
* Bug 8135: Japanese wikinews requests a new namespace
* Bug 6119: Run site stats update script on Ripuarian Wikipedia
* Bug 8879: Set site name for Latin Wikibooks
* Bug 9569: Add a Portal (Gátt) namespace to Icelandic Wikipedia
--
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hasharhttp://www.livejournal.com/community/wikitech/
IM: hashar(a)jabber.org ICQ: 15325080
Are there machine-readable versions of pages like &action=history,
Special:Contributions, and Special:RecentChanges?
(Or would those be too prone to abuse?)
Sorry, if this is the wrong forum for this question, if not can someone please
refer me to the correct place...
I'm building a web site that contains small portions of Wikipedia articles. I
have been using php curl to obtain the articles, caching them, and checking once
a week for updates. I don't expect to reference more than a few hundred
articles. This process broke a few weeks ago and I'm trying to determine why.
I've started getting the following message:
-------
The Wikimedia Foundation servers are currently experiencing technical
difficulties.
[.... snip ...]
If reporting this error to the Wikimedia System Administrators, please include
the following details:
Request: GET http://en.wikipedia.org/wiki/Cinco_De_Mayo, from 64.202.165.131 via
sq29.wikimedia.org
(squid/2.6.STABLE12) to ()
Error: ERR_ACCESS_DENIED, errno [No Error] at Fri, 04 May 2007 23:16:48 GMT
-------
Because of the ERR_ACCESS_DENIED above, I'm concerned I've been doing this the
wrong way and have gotten blocked. I would very much appreciate it if someone
could tell me if this is the case.
Also, if I'm doing this the wrong way, can someone point me in the direction of
the proper method?
A sample link to my site is: http://daysuntil.com/Rosh-Hashanah/index.html
Thanks very much,
David DeGroote
Hi, all,
Looking at the database layout
(http://www.mediawiki.org/wiki/Manual:Database_layout), I see that there
are several link tables. There's the externallinks table, categorylinks
table, langlinks table, pagelinks table, imagelinks table, and even a
perennially-empty trackbacks table, but there is one kind of links that
is not covered by these tables: Interwiki links. The recent, um,
"controversy" made me wonder how many of these interwikis are actually
used, but that information is not stored anywhere.
Would adding a table to the schema be useful? Thinking about it, it would
have a layout similar to the langlinks table, so it would be like this:
mysql> DESCRIBE mw_interwiki;
+----------+-----------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+-----------------+------+-----+---------+-------+
| in_from | int(8) unsigned | NO | PRI | 0 | |
| in_lang | varchar(10) | NO | PRI | NULL | |
| in_title | varchar(255) | NO | | NULL | |
+----------+-----------------+------+-----+---------+-------+
3 rows in set (0.01 sec)
So, would it be a good idea to do this? It would allow things
like [[Special:Linksearch]] for interwikis. Thoughts? Comments?
Titoxd.