Last modified: 2014-10-28 20:42:59 UTC
I created this page: http://www.withoutvowels.org/wiki/Hebrew:%D7%91%D7%A8%D7%90%D7%A9%D7%99%D7%AA Nevertheless a link to that page at http://www.withoutvowels.org/wiki/Tanakh:Genesis_1:1 is shown as a link to an not existing page. This is a bug. Maybe it is related with namespaces and page protection? See a fragment of my LocalSettings.php: define("NS_HEBREW", 100); define("NS_HEBREW_TALK", 101); define("NS_TANAKH", 102); define("NS_TANAKH_TALK", 103); define("NS_EXEGESIS", 104); define("NS_EXEGESIS_TALK", 105); $wgExtraNamespaces[NS_HEBREW] = "Hebrew"; $wgExtraNamespaces[NS_HEBREW_TALK] = "Hebrew_talk"; # underscore required $wgExtraNamespaces[NS_TANAKH] = "Tanakh"; $wgExtraNamespaces[NS_TANAKH_TALK] = "Tanakh_talk"; # underscore required $wgExtraNamespaces[NS_EXEGESIS] = "Exegesis"; $wgExtraNamespaces[NS_EXEGESIS_TALK] = "Exegesis_talk"; # underscore required #$wgNamespaceProtection[NS_HEBREW] = array( 'nobody' ); #permission "editfoo" required to edit the foo namespace #$wgNamespacesWithSubpages[NS_HEBREW_TALK] = true; #subpages enabled for the foo namespace #$wgGroupPermissions['sysop']['editfoo'] = true; #permission "editfoo" granted to users in the "sysop" group $wgNamespaceProtection[NS_TANAKH] = array( 'nobodyallowed' ); #$wgNamespacesWithSubpages[NS_TANAKH] = true; #subpages enabled for the foo namespace $wgNamespacesWithSubpages[NS_TANAKH_TALK] = true; #subpages enabled for the foo namespace #$wgGroupPermissions['sysop']['editfoo'] = true; #permission "editfoo" granted to users in the "sysop" group $wgNamespacesWithSubpages[NS_EXEGESIS] = true; #subpages enabled for the foo namespace $wgNamespacesWithSubpages[NS_EXEGESIS_TALK] = true; #subpages enabled for the foo namespace #$wgGroupPermissions['sysop']['editfoo'] = true; #permission "editfoo" granted to users in the "sysop" group
They are 2 different namespaces
"They are 2 different namespaces." I haven't understood what you speak about. Certainly there are a few different namespaces on my site. How is it related with the bug I reported?
Weirdly, it was marked as existing pages after some time passed and I pressed F5. Should I disable page cache?
(In reply to comment #2) > "They are 2 different namespaces." > > I haven't understood what you speak about. Certainly there are a few different > namespaces on my site. How is it related with the bug I reported? Sorry, meant to delete that. I wouldn't disable page cache, it sounds like a job queue type issue
Which job queue type issue? My site is not yet heavily loaded. Hm, maybe Google indexing it overloaded the job queue?
(In reply to comment #5) > Which job queue type issue? My site is not yet heavily loaded. Hm, maybe Google > indexing it overloaded the job queue? What? Google indexing will not cause the job queue to become backed up (It could however have the opposite effect, but really in all probability, google doesn't index you enough for it to matter at all). In any case, according to http://www.withoutvowels.org/w/api.php?action=query&meta=siteinfo&siprop=statistics&format=yamlfm the job queue has (approximately) nothing in it, which means that jobs are being executed normally as they should. However, what's more concerning is that the page in question has no backlinks, ( http://www.withoutvowels.org/wiki/Special:WhatLinksHere/Hebrew:%D7%91%D7%A8%D7%90%D7%A9%D7%99%D7%AA ) which is probably where your issue is coming up (MediaWiki doesn't realize the page is linking to it, so it doesn't know to fix the link). This is probably something broken with the import process. Which maintenance script did you use to import pages? In the mean time, running the refreshLinks.php maintenance script will probably fix the issue.
Running the refreshLinks.php maintenance script does not help with http://www.withoutvowels.org/wiki/Special:WhatLinksHere/Hebrew:%D7%91%D7%A8%D7%90%D7%A9%D7%99%D7%AA which remained empty after running refreshLinks.php. I did page import of Tanakh:* namespace with edit.php. So why my the list of links to Hebrew:%D7%91%D7%A8%D7%90%D7%A9%D7%99%D7%AA is empty? It's wrong.
Could you make some sort of edit (using normal web interface) to Tanakh:Genesis_1:1, and see if that affects the whatlinkshere pages of those other pages (an edit will force refresh of all links tables, which will help narrow down the problem)
Tanakh:Genesis_1:1 is in the namespace Tanakh: which I forbidden to be edited by any user (It can be edited only by maintenance scripts.)
(In reply to comment #9) > Tanakh:Genesis_1:1 is in the namespace Tanakh: which I forbidden to be edited > by any user (It can be edited only by maintenance scripts.) Yes i know. If you temp remove the restriction, make an edit to that page, and see if the whatlinkshere are fixed, it would help narrow down where the problem is. On my local install, edit.php script correctly populates link tables as expected (even if using similar namespace protection configuration).
I added the permission to edit Tanakh: namespace for the user Admin. I edited http://www.withoutvowels.org/wiki/Tanakh:Genesis_1:1 and after this backlinks at http://www.withoutvowels.org/wiki/Special:WhatLinksHere/Hebrew:%D7%91%D7%A8%D7%90%D7%A9%D7%99%D7%AA work OK. Can I now revert it and remove the permission to edit?
>Can I now revert it and remove the permission to edit? Sure. Null edits fix the links table, which means it just didn't work originally for some reason. I'm really unsure why refreshLinks.php (or edit.php for that matter) didn't populate the links table.
I created for test this page: http://www.withoutvowels.org/wiki/Hebrew:%D7%90%D7%9C%D7%94%D7%99%D7%9D On http://www.withoutvowels.org/wiki/Tanakh:Genesis_1:1 it is properly shown that now this link is existing. Also http://www.withoutvowels.org/wiki/Special:WhatLinksHere/Hebrew:%D7%90%D7%9C%D7%94%D7%99%D7%9D works as it should. It seems for me that the bug may appear after editing tens of thousands pages with maintenance/edit.php
You've written "maintenance script edit.php doesn't update link tables properly (sometimes)", but originally I posted the bug report that a link on a page created by edit.php was not marked as existing after I manually created a new page whose target the link is. (I recall that it was marked as existing after some period of time.)
(In reply to comment #14) > You've written "maintenance script edit.php doesn't update link tables properly > (sometimes)", but originally I posted the bug report that a link on a page > created by edit.php was not marked as existing after I manually created a new > page whose target the link is. (I recall that it was marked as existing after > some period of time.) At the moment I believe that's a symptom of the link tables not being updated (If MediaWiki didn't know that page linked there, it didn't know to change the link colour when you created the new page). It probably fixed itself later due to the cache getting purged for some other reason
*** Bug 29518 has been marked as a duplicate of this bug. ***
It looks like there's no commit in Article::doEdit() after the wfDoUpdates() call, and edit.php doesn't commit either, it just calls exit(0);
There's no $dbw->begin() either though. I always thought changes took affect immediately if there isn't a $dbw->begin()
I noticed one more "feature": It looks as it should from an admin account, but wrong from a normal user account. :-(
After editing http://www.withoutvowels.org/wiki/Hebrew:%D7%95%D7%94%D7%90%D7%A8%D7%A5 the link to this page from http://www.withoutvowels.org/wiki/Tanakh:Genesis_1:2 looks like a link to an nonexistent page (despite of it exists). But it has wrong looks only from a normal user. It works as it should from an admin user. It is a bug. What to do?
(In reply to comment #20) > After editing > http://www.withoutvowels.org/wiki/Hebrew:%D7%95%D7%94%D7%90%D7%A8%D7%A5 the > link to this page from http://www.withoutvowels.org/wiki/Tanakh:Genesis_1:2 > looks like a link to an nonexistent page (despite of it exists). > > But it has wrong looks only from a normal user. It works as it should from an > admin user. > > It is a bug. What to do? I've seen it from an other (non-admin) user also. It works. It just doesn't work from the user I use to normally browse the site. :-(
>It works as it should from an admin user. Most likely the admin user has different preferences enabled (being an admin in and of itself shouldn't change anything). Since this is a caching issue, and mediawiki keeps different copies of the cache based on which preferences you have enabled (for some of them), the admin just sees a different cached version then a normal user.
(In reply to comment #22) > >It works as it should from an admin user. > > Most likely the admin user has different preferences enabled (being an admin in > and of itself shouldn't change anything). Since this is a caching issue, and > mediawiki keeps different copies of the cache based on which preferences you > have enabled (for some of them), the admin just sees a different cached version > then a normal user. And how to update all caches?
Its already been discussed above - refreshLinks.php
(In reply to comment #24) > Its already been discussed above - refreshLinks.php And I've already said that refreshLinks.php does not help.
I unchecked "Format broken links like this (alternative: like this?)" in user's preferences and have clicked "Save" button. After this (and pressing F5) formatting of links haven't changed for this user. I will create a new user and try to configure it anew, as a bug workaround.
(In reply to comment #26) > I unchecked "Format broken links like this (alternative: like this?)" in user's > preferences and have clicked "Save" button. After this (and pressing F5) > formatting of links haven't changed for this user. > > I will create a new user and try to configure it anew, as a bug workaround. Maybe it is caused by me used "Rename user" module?
Finally I found that this bug spots when "Auto-number headings" option in user preferences is on. What could be the reason of it?
I'm closing this worksforme. Sorry, there's just nothing I can do if I can't make the bug happen to me.
*** Bug 72594 has been marked as a duplicate of this bug. ***
