Page MenuHomePhabricator

Cannot delete page: MediaWiki\Page\PageAssertionException: The given PageIdentity Special:Badtitle/[,,,] does not represent a proper page
Closed, InvalidPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

Since upgrading to MW 1.39 it is impossible for me to delete pages in a custom namespace.

What happens?:

When a user hits the delete link (or appends action=delete to the URL):

MediaWiki\Page\PageAssertionException: The given PageIdentity Special:Badtitle/NS[...]:[...] does not represent a proper page

Stacktrace

from[...]/includes/page/WikiPageFactory.php(57)
#0[...]/includes/page/WikiPageFactory.php(96): MediaWiki\Page\WikiPageFactory->newFromTitle()
#1[...]/includes/page/DeletePage.php(267): MediaWiki\Page\WikiPageFactory->newFromLinkTarget()
#2[...]/includes/actions/DeleteAction.php(443): MediaWiki\Page\DeletePage->canProbablyDeleteAssociatedTalk()
#3[...]/includes/actions/DeleteAction.php(348): DeleteAction->showForm()
#4[...]/includes/actions/DeleteAction.php(142): DeleteAction->tempConfirmDelete()
#5[...]/includes/actions/DeleteAction.php(112): DeleteAction->tempDelete()
#6[...]/includes/MediaWiki.php(542): DeleteAction->show()
#7[...]/includes/MediaWiki.php(322): MediaWiki->performAction()
#8[...]/includes/MediaWiki.php(904): MediaWiki->performRequest()
#9[...]/includes/MediaWiki.php(562): MediaWiki->main()
#10[...]/index.php(50): MediaWiki->run()
#11[...]/index.php(46): wfIndexMain()
#12 {main}

What's potentially strange here is the function canProbablyDeleteAssociatedTalk() being called when there is no associated talk page. In fact, there's no talk namespace associated with the custom namespace (which has never been a requirement).

There are similar error reports, but all of them point to different causes, e.g. a trailing space or a faulty redirect.

Event Timeline

Thanks for reporting this. I assume the code should call NamespaceInfo::hasTalkNamespace() at some point, and avoid checking the "associated talk page" which can't even exist. However, it looks like the implementation of hasTalkNamespace is that it always assumes that non-negative namespaces always have talk pages. I might be missing something, but isn't this inconsistent with the "having an associated talk is not a requirement" thing that I also remember being the "official" policy?

Thanks for your reply. I never got that from the documentation myself nor did I experience issues before. Why create a namespace if you;re not going to use it? With over 20 custom namespaces, it would also create a lot of unnecessary.clutter.

Maybe that changed after 1.35 though and associated talk namespaces have become a hard requirement.

I'll.test if adding the talk NS will solve the issue. [Edit] It. does.

Apparently, it is a hard requirement, so I went ahead and clarified this in the documentation. There's an outstanding RFC which proposes to drop it: T165149.

I suppose we could close this issue.

In T339879#8948002, @DG wrote:

Apparently, it is a hard requirement, so I went ahead and clarified this in the documentation. There's an outstanding RFC which proposes to drop it: T165149.

I suppose we could close this issue.

Oh, thanks for finding that, looks like I got confused. I'm closing this task then.