2008/6/18 <wikitech-l-request(a)lists.wikimedia.org>:
>
> ---------- Thư được chuyển tiếp ----------
> From: Brion Vibber <brion(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Date: Mon, 16 Jun 2008 12:55:56 -0700
> Subject: Re: [Wikitech-l] Pages are not shown after import
> Minh Ngoc Le wrote:
>
>> I imported Vietnamese Wiktionary into my local MySQL 5.0 using mwdumper
>> and
>> no error occured. Then I opened MediaWiki, typed some words but none of
>> them
>> were found. Using PhpMyAdmin, I made sure that pages had been successfully
>> imported but there were only 134.000 pages instead of 227.290. Could
>> anybody
>> tell me what happended?
>>
>
> Was there an error during import? (import == database, not the SQL
> conversion).
>
> -- brion
>
>
I used this command:
java -Xmx512m -Xms128m -XX:NewSize=32m -XX:MaxNewSize=64m
> -XX:SurvivorRatio=6 -XX:+UseParallelGC -XX:GCTimeRatio=9
> -XX:AdaptiveSizeDecrementScaleFactor=1 *-jar mwdumper.jar --format=sql:1.5
> viwiktionary-20080609-pages-articles.xml.bz2* | mysql --user=root
> --password=xxx wikidb
>
There was no errors at all. And then I ran maintenance\rebuildtextindex.php:
php rebuildtextindex.php
>
It ran successfully without any errors, too. However, I still can't view my
pages using my MediaWiki installed in localhost.
System details:
- MediaWiki 1.11.2
- PHP 5.2.6 (with xml, dom, domxml, mbstring, mcrypt, mysql, mysqli,
etc.)
- Apache 2.2
- MySQL 5.0.51a community
- Windows XP SP2 Pro
BTW, I had tried to install MediaWiki 1.12 but I couldn't see any page after
installation, it always produced error at includes\Preprocessor_DOM.php
although I had enabled xml and install every xml extensions to PHP.
It drives me crazy!
On Tue, Jun 17, 2008 at 10:58 PM, <demon(a)svn.wikimedia.org> wrote:
> Revision: 36403
> Author: demon
> Date: 2008-06-17 20:58:32 +0000 (Tue, 17 Jun 2008)
>
> Log Message:
> -----------
> More ~/includes cleanup. Moving all the Search*.php files to ~/includes/search.
>
Did you do this via "copy-paste" instead of "svn mv"? Because now all
histories are lost...
Bryan
The Unified Login System, it doesn't actually cut down on my need to
type login and password at all, does it?
>From the point of view of me, all I see different using the new
Unified Login System is that I don't have to worry about some user
taking my Jidanni username on some MediaWiki wiki that I haven't taken
it already on.
Maybe it should just be called the Universal Username reservation
system.
I don't see how it might make my day to day need to type Login and
password to MediaWiki sites who's cookies aren't already in my browser
easier.
http://meta.wikimedia.org/wiki/Help_talk:Unified_login#How_is_it_going_to_l…
I am trying to...
add sm text to the wikitext when the document is saved. Something like at
the end of each header,p,a tags some text should be added.
To identify within the wikitext where these different html elements start
and stop is difficult.
So i thought a better idea is to give the wikitext to /includes/Parser.php
which will parse the wikitext and generate html.
In places where the file Parser.php is adding html I will comment it and add
my custom text to it.
This definately means Parser has to be called before the text is saved. I
can copy and create a new customParser file and then make changes to it.
So lets say now there will be /includes/myparser.php
Does anyone have a better idea than this. I am also not sure how difficult
will it be for me to identify where the
appropriate html is added. I found some functions like dbBlockLevel will add
p,list tags to wikitext.
help will be highly appreciated.
Thanks
--Viral
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
dale(a)svn.wikimedia.org wrote:
> - window.domain = 'www.parent.domain.com';
> + window.domain = '<?=$parent_domain?>';
Just a note -- I strongly recommend against using the "short tags" (<?
and <?= instead of <?php), as your code won't work at all on a server
with short tags disabled in php.ini.
Portable code should use the long-form tags consistently.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgoz70ACgkQwRnhpk1wk46bOwCgxhT8T8Mv5jLz0PPpBKQTU5Nq
Je4AnjsjG/IsKESaskfug+eTtXqmmpvh
=bAri
-----END PGP SIGNATURE-----
I imported Vietnamese Wiktionary into my local MySQL 5.0 using mwdumper and
no error occured. Then I opened MediaWiki, typed some words but none of them
were found. Using PhpMyAdmin, I made sure that pages had been successfully
imported but there were only 134.000 pages instead of 227.290. Could anybody
tell me what happended?
Thanks.
Hi Everybody,
I am using WikiMedia on one system.
Before this it was running on different machine. That machine crashed and
We have taken backup of wiki DB.
I have PGDMP backup files of previous wiki.
Please let me know what is the procedure to restore backup files to WIKI
running on new machine.
Kindly let me know if any more information required from my side.
Regards
Naresh Nayyar
The following extensions had cross-site scripting (XSS) vulnerabilities:
* geo
* MetavidWiki
* wikihiero
These vulnerabilities are exploitable even if the extensions are
disabled. If you have any of these extensions installed, please update
them immediately.
Many shared hosting services have the php.ini setting "register_globals"
enabled, despite the fact that it is known to be detrimental to security.
A new automated vulnerability scanner has found a large number of
security vulnerabilities in MediaWiki extensions, when register_globals
is enabled. Unless you are sure you have register_globals disabled, the
following extensions should be immediately updated:
Cross-site scripting vulnerabilities:
* Call
* ChangeAuthor
* EditOwn
* SignDocument
* TemplateLink
* WatchSubpages
* WhoIsWatching
* php/ext/MediaWiki
Arbitrary script inclusion vulnerabilities:
* CategoryIntersection
* Makebot
* PasswordReset
* regexBlock
* SemanticCalendar
* SemanticForms
* SemanticMediaWiki
* SocialProfile
* SpamRegex
* StalePages
* TodoTasks
* WhiteList
* Wikidata
All these extensions are vulnerable regardless of whether they are
enabled in LocalSettings.php. They only need to be installed, with their
installation directory accessible from the public internet.
Downloads in .tar.gz form for all these MediaWiki extensions are
available from:
http://www.mediawiki.org/wiki/Special:ExtensionDistributor
Or using a subversion client from:
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions
-- Tim Starling
Hello !
In several Wikimedia projects, the concept of Featured Articles (and
sometimes Good Articles and Featured Portals) has been created. It is
also quite common that an interlanguage link identifying an other
language' Featured Article uses a special list bullet [1]. To display
such a bullet, the most common technical hack uses Javascript : a
template adding an html element identified by an
id="interwiki-{{{1}}}-fa" [2], and a Common.js JS function adding a
special CSS (golden bullet) class to the corresponding interwiki
<li>element. Such a JS function usually iterates on every Interwiki
link, testing :
if ( document.getElementById( InterwikiLinks[i].className + "-fa" ) )
to search for an hypothetical interwiki-lang-fa tag [3]. One
getElementById call, searching through the whole DOM tree, is issued
per interlanguage link : eventually, this is costly.
According to fr:User:Maloq, on a page containing 100+ interlanguage
links, this delays the page loading by more than 1 second on the
client side [4]. This user concludes that the Javascript system has to
be changed, and calls for yet another Javascript hack; however we both
agreed that having an extension handling those Featured articles links
would be quite better. Now :
* Stop me if I'm wrong, but I don't think that we can reasonably
imagine an extension directly querying other wikis for an article
status to display the right bullet
* I first though of extending the interlanguage link syntax, to use a
new syntax approaching the Image one, for example [[fr:Test|FA]] or
[[es:blabla|GA]] to display the corresponding bullet next to the
interlanguage link. From what I know, extending the standard wiki
syntax is not permitted by the current hooks/tag extensions, am I
right on this ? Also, do you see a reasonable way to extend the
interlanguage link syntax without heavy consequences for the wikis not
using the Featured Article concept ?
* The standard idea to address that issue would be to create a new tag
extension, for example interpreting <promoted en="fa" fr="ga" de="fa"
/>. I do not really consider that latter solution as very
user-friendly, do you have another idea / other syntax suggestions to
do this ?
[1]. See for example the interlanguage links of
http://en.wikipedia.org/wiki/Ten-g%C5%8D_sakusen
[2]. http://en.wikipedia.org/w/index.php?title=Template:Link_FA&action=edit
[3]. http://en.wikipedia.org/wiki/MediaWiki:Common.js : search for LinkFA()
[4]. {{fr}} : http://fr.wikipedia.org/wiki/Discussion_Mod%C3%A8le:Lien_AdQ#Tests
--
Nicolas Dumazet — NicDumZ [ nIk.d̪ymz ]
Deuxième année ENSIMAG.
Subject lines are things you put on the top of your email so that the
recipient knows what the email is about, when they see it in a list. They
are useful.
It's unfortunate then, that the last 10 threads on wikimedia-tech (as
sorted by my mail client) had no meaningful subject line.
May I suggest changing the subject when you reply to a mediawiki-cvs post,
to something somehow related to the feature or bug in question?
We manage to pick a meaningful commit message when we commit these
revisions, so surely there's no reason why we can't pick a meaningful
subject when we're talking about them.
-- Tim starling