Sounds like I should be able to undo that evil patch then. But it also looks 
like update.php calls AddRFCAndPMIDInterwiki, which means I’m going to have to 
kill it every time I do an update. Ugh.

I wasn’t clear on the database error.

I don’t recall seeing errors from update.php, which is why I was surprised when 
I got the white screen of death that required adding the l10n_cache table 
manually. I just found another that wasn’t added by update.php, the  
bot_passwords table. 


> On Apr 9, 2018, at 11:18 AM, Brian Wolff <> wrote:
> For PMID interwiki, there was probably some sort of caching happening.
> Interwiki links are cached for 3 hours by default (
> $wgInterwikiExpiry). It will take that long before removing PMID from
> the interwiki table will take affect.
> For the DB error, that would be odd. They do slightly different
> things, but are basically the same. Usually when people encounter
> errors its because of different versions between webserver php and
> shell php. What is the precise error you got from update.php?
> --
> Brian
> On Mon, Apr 9, 2018 at 3:53 PM, Jim Hu <> wrote:
>> I’ve been way too slow in updating our wikis to new versions, often because 
>> new versions reveal all the places where my custom extensions are poorly 
>> coded (by me). One thing that has been a total nightmare for me is that our 
>> biology/genetics based wikis are heavily dependent on having pages that have 
>> titles based on PMIDs. For example, in GONUTS (, we 
>> use pages like this one 
>> to gather information related to a specific paper by combining citations 
>> within the wiki with information pulled in from an external web service.
>> This weekend I had to bite the bullet and update GONUTS and I went with 
>> 1.29.2 from 1.25, and I was shocked to find that links to those pages and 
>> creating pages with those titles was causing bad title exceptions. I traced 
>> the problem to the overlap between PMID: and an interwiki namespace, but 
>> deleting the pmid row from the interwiki table in the database didn’t fix 
>> the problem.
>> I finally resorted to something that I know is a terrible, terrible idea: I 
>> tweaked the code on line 337 of MediaWikiTitleCodec.php to specifically 
>> ignore matches to ‘PMID’. It works, but I’m hoping someone can guide me on 
>> how to do this without messing with the MW core code.
>> I also noticed something about the updating process. I made a test copy of 
>> my backend database from a SQL dump and ran the web installer pointed at the 
>> 1.25-based database. Then I copied LocalSettings.php from the old install 
>> and did testing/debugging. When I was satisfied that things were working, I 
>> edited LocalSettings.php to point the wiki to the production database and 
>> ran maintenance/update.php… and got a fatal error that was addressed in an 
>> item I found online: 
>> <>
>> So, it seems that the update from the shell doesn’t behave quite the same as 
>> the update from the web-based system. There might have also been a 
>> difference in PMID strings getting magic links, but I’m not sure if the 
>> difference was due to shell vs web on that one.
>> Jim Hu
>> _______________________________________________
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:

MediaWiki-l mailing list
To unsubscribe, go to:

Reply via email to