Extension talk:DeletePagePermanently

From MediaWiki.org
Jump to navigation Jump to search

Doesn't Work with MediaWiki 1.16.5 Vector Skin[edit]

When I try to delete a page it says "This page can not be deleted permanently"

protect page from being deleted[edit]

is there a way to protect some pages to be permanently deleted? thanks

works fine on Mediawiki 1.15.0[edit]

it works fine on Mediawiki 1.15.0 Thanks for this extension! Enzo

Using with Vector Skin[edit]

In order for the action to show properly on the vector skin, you must add a new hook. The hook definition is as follows:

$wgHooks['SkinTemplateNavigation'][] = array (

function AddVectorHook(&$sktemplate, &$links) {
    global $wgRequest, $wgRequest, $wgTitle, $wgUser, $wgDeletePagePermanentlyNamespaces;

    if (!$wgUser->isAllowed('deleteperm'))
        return false;

    $action = $wgRequest->getText('action');

    #Special pages can not be deleted (special pages have no article id anyway).
    if ($wgTitle->getArticleID() != 0 && $wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace()] == true && $wgTitle->getNamespace() != NS_SPECIAL) {

        $links['actions']['ask_delete_permanently'] = array (
            'class' => $action == 'ask_delete_permanently' ? 'selected' : false,
            'text' => wfMsg('delete_permanently'),
            'href' => $wgTitle->getLocalUrl('action=ask_delete_permanently')

    return true;

Yes but how and where do we add a new hook? --Holygamer 15:04, 9 February 2012 (UTC)


I had to replace the $action for "delete_permanently" in my environment to make it work

if ($action == 'ask_delete_permanently' )
  // Before :
  // $action = $wgArticle->getTitle()->escapeLocalUrl()."&action=delete_permanently";		
  // Now : 
  $action = $wgArticle->getTitle()->getLocalUrl('action=delete_permanently');
  // index.php/TestPage&action=delete_permanently 
  // become index.php?title=TestPage&action=delete_permanently
  $wgOut->addHTML("<form id='ask_delete_permanently' method='post' action=\"$action\">

Hallo together,

I got the same problem, but I solved it in an other way. I am using MW (1.15.4), SMW (1.5.0), SMWHalo (1.5.0), PHP (5.2.10), MySQL (5.1.37) with <DeletePagePermanently> (2.1). The User LeLorrain (00:19, 29 December 2009 (UTC)) posted in "manque onglet ?", that he changed line 120 (v 2.1) from


    $action = $wgArticle->getTitle()->escapeLocalUrl()."?action=delete_permanently";

into [2]

    $action = $wgArticle->getTitle()->escapeLocalUrl()."&action=delete_permanently";


I changed it back into the old solution with "?". But there is another posibility to do so:


    $action = "?title=".$wgArticle->getTitle()."&action=delete_permanently";


It is necessary to know how mediawiki uses the line: The address of the page (SITENAME) which should be deleted, looks like this:


If you wanna delete this page permanently, the ask-page comes with this address:


After clicking on OK there comes this address (old version) [1]:


This works!!!

But in version (2.1) there is no "?", there is an "&" and so the address is [2]:


This could not work!!!

My line produses this address [3]:


This works!!!

Posibility [4] from top works also fine. The address which is shown is:


So it works too!!!

Benor 17:10, 22 June 2010 (UTC)

Undefined offset:[edit]

If you try to open a page with namespace not defined in $wgDeletePagePermanentlyNamespaces (like Special:SpecialPages) I've got the following error:

Undefined offset:  -1 in /xxx/xxx/extensions/DeletePagePermanently/DeletePagePermanently.php on line ~ 86

You have:

if ( $wgTitle->getArticleID() != 0 & $wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace()] == true & $wgTitle->getNamespace() != NS_SPECIAL ) {

Obviously the $wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace() won't return boolen if the namespace is not defined in $wgDeletePagePermanentlyNamespaces. It will return -1. Probably you have to check if is in array first and then the value. One way of doing it is to just add @ before the expression like

@$wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace()] == true

But I guess this could be done in a more elegant way. Rocco08


One way to fix it is to add an isset conditional before the check. This works because the entire expression will short circuit and the offending conditional will never evaluate.

if ($wgTitle->getArticleID() != 0
     && isset($wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace()])
     && $wgDeletePagePermanentlyNamespaces[$wgTitle->getNamespace()] == true
     && $wgTitle->getNamespace() != NS_SPECIAL
) {

Also for those of you using the vector skin fix above you'll need to make this change a few lines below as well. --Spt5007 19:02, 2 July 2010 (UTC)

Caveat for copying/pasting code[edit]

This isn't specific to this extension, but I spent a bit figuring it out. After I "installed" this extension, my wiki's browser search ($IP/opensearch_desc.php) was broken. Turns out I'd pasted an extra line or two at the end of the file; it was breaking the XML that's supposed to get sent. So, watch out you don't add any empty lines to the end of the file! Miken32 21:52, 2 April 2009 (UTC)

Translation string errors[edit]

I got an error in the .i18n.php messages file, after installation. It appears the French translation contains extra ' in two strings. After quoting these strings with double quotes i.s.o, single quotes the problem is gone.

You need only to escape the extra quote with a backslash (\). The source code is updated. --LeLorrain 00:13, 29 December 2009 (UTC)

manque onglet ?[edit]

j'ai installer l'extension sur la version 1.15.1

je n'ai pas de message d'erreur mais je n'ai pas l'onglet "DeletePagePermanently" qui permet la suppression de la page.

que faire? merci :)
--Voice 15:40, 27 September 2009 (UTC)

I hope you understand english because i can't speak french and translated you post with google ^^
There are 2 reasons why you can't see the tab: either you don't have the rights or the namespace you are in, is not configured for the extensions.
Check the configuration of $wgGroupPermissions (for the userrights) and look, if the namespace is in $wgDeletePagePermanentlyNamespaces (to enable deleting of articles in the namespace) array. (For non-standard namespaces use the numbers you chosen in the $wgExtraNamespaces array)
--W.stoettinger 12:51, 28 September 2009 (UTC)

I grieve also translated with google;) I just add lines of code in the LocalSettings.php. as indicated:

$wgGroupPermissions['*']         ['deleteperm'] = false;
$wgGroupPermissions['user']      ['deleteperm'] = false;
$wgGroupPermissions['bureaucrat']['deleteperm'] = false;
$wgGroupPermissions['sysop']     ['deleteperm'] = true;

$wgDeletePagePermanentlyNamespaces = array(
	NS_MAIN => true,
	NS_IMAGE => true,
	NS_CATEGORY => true,
	NS_TEMPLATE => true,
	NS_TALK => true,

it is this right?

I have not included for:
(For non-standard namespaces use the numbers you chosen in the $wgExtraNamespaces array) ?

thank you
--Voice 20:02, 28 September 2009 (UTC)

This isn't working in 1.15, just takes me to a page saying that the page 'insertpagenamehere?action=delete permanently' is empty and to create it.

Hi there, we fixed this behaviour by changing line 115 from:
$action = $wgArticle->getTitle()->escapeLocalUrl()."?action=delete_permanently";
$action = $wgArticle->getTitle()->escapeLocalUrl()."&action=delete_permanently";
Though we are no PHP-Programmers, this is only a temporary workarround.
The source code is updated. Thanks! --LeLorrain 00:19, 29 December 2009 (UTC)

j'ai trouver la solution pour le manque d'onglet utile à savoir si vous utilisez d'autres extensions qui jouent sur les droit d'utilisateur. pour ma part j'avais installer l'extension ipbwiki du coups mon compte est passé de sysop à Admin il suffis donc d'ajouter cette ligne dans le fichier LocalSettings.php:

$wgGroupPermissions['Admin']     ['deleteperm'] = true;

voila :)
--Voice 20:23, 11 October 2009 (UTC)

Category count update[edit]

Hi, I noticed that the DeletePagePermanently extension does not update category count. Here is a patch generated by git, I started from version 2.1.1 found on the extension page.

$ cat 0001--fix-category-count-on-deletion.patch 
 DeletePagePermanently.php |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/DeletePagePermanently.php b/DeletePagePermanently.php
index 884e719..d161cf7 100644
--- a/DeletePagePermanently.php
+++ b/DeletePagePermanently.php
@@ -177,6 +177,15 @@ class DeletePagePermanently
         # Delete page Links
         $dbw->delete( 'pagelinks', array ( 'pl_from' => $id ), __METHOD__ );                
+        # update categories count before removing category links
+        $cat = array();
+        $res = $dbw->select( 'categorylinks', 'cl_to', array( 'cl_from' => $id ), __METHOD__ );
+        foreach( $res as $row ) {
+            $cat[]= $row->cl_to;
+        }
+        $article = new Article( $title );
+        $article->updateCategoryCounts(array(), $cat);
         # delete category links
         $dbw->delete( 'categorylinks', array( 'cl_from' => $id ), __METHOD__);

Now the count should be correct after a page deletion. You can mail me at sberder@gmail.com for informations.

The problem is corrected and the source code updated. Thanks! --LeLorrain 00:06, 29 December 2009 (UTC)


In other langages than english, the tab shows « <delete_permanently> ». Marc 15:39, 3 March 2010 (UTC)

Fixes for MW 1.16[edit]

I rewrote parts of the code to make the extension compatible with MW 1.16. The main reason for this is that the code given in the "Mediawiki 1.16.x" section does not work with MW 1.16: the "delete permanently" tab is displayed without any label. The method "$wgMessageCache->addMessage()" is deprecated in MW 1.16, and no longer supported. I removed it and changed some little things to make the extension work properly. Please feel free to put this code on the main page if you wish to. Alvinos 12:00, 9 March 2010 (UTC)

>> I tried using this (below) with MediaWiki 1.16.0 and saw two problems: 1) The Special:Version page is now completely blank, and 2) In Cologne Blue skin the link for "Permanently Delete" does not appear (although the Tab does appear in monobook.) Thalion 17:22, 23 December 2010 (UTC)

Permanently delete already deleted pages[edit]

This extension is great. Thanks for your hard work.
I'd also like to use it to delete pages which have already been marked as deleted. But that's not possible right now since the tab isn't showing on deleted pages.
How can I change that ?

Undelete the page in the normal way then use this extension to delete it permanently. -- Malvineous 05:33, 5 February 2011 (UTC)
Or if you want to permanently delete all pages which were deleted, use the deleteArchivedRevisions.php maintenance script -- Harry Wood (talk) 01:06, 7 October 2012 (UTC)

Problems with SMW(SemanticMediaWiki) Annotations/Properties[edit]

Problem: We use the extension together with the SemanticMediaWiki(SMW) and we noticed that pages that are indexed with the (SMW) still appear in their queries.

Current Solution What happen is this we delete pages that include semantic properties and ones their are delete their are still appear the SMW query list (even after a purge, no backlogs of update jobs). As for the moment what we did was that we had to create the page again without the SMW annotations and then delete the page again. This can be only a short-term solution since we are using SMW extensively. Would be nice to have a better solution for this.

System Environment MediaWiki 1.16.0beta2, PHP 5.2.9-1 (cgi-fcgi), MySQL 5.0.77-community-nt LightTPD 1.4.22, SphinxSearch (Version 0.7.0), Semantic MediaWiki (Version 1.5.1)

Thanks, --MWJames 10:21, 15 June 2010 (UTC)

Don't working with Postgre[edit]


relation searchindex does not exist ... FROM searchindex.



Comment out the line 195 in DeletePagePermanently.php:

#$dbw->delete( 'searchindex', array( 'si_page' => $id ), __METHOD__);

Is it correct solution?

Thanks, --Tshr 13:17, 9 July 2010 (UTC)

How to use extension from MW api?[edit]

I'd like to call this extension from bot scripts, is it easily doable? When I call mywiki.net/wiki/Page&action=delete_permanently that seems ok but I only get HTML output, no XML output or equivalent so far :(

image will remain in the image folder, undeleted[edit]

I added this sentence:

Although this extension deletes the image page, the image will remain in the image folder, undeleted

Errectstapler 06:05, 19 June 2011 (UTC)

Changes for MW 1.17.0[edit]

Do we still use the DeletePagePermanently code for MW 1.16.x after upgrading to MW 1.17.0?

02:29, 25 July 2011 (UTC)

Frankly, I suspect changes do need to be made because:

Interwiki links in articles are now recorded in a separate table.

See Changes in MediaWiki 1.17 and MediaWiki Manual: Interwiki Table.

But not being too experienced with either PHP or databases, I am not sure.

15:43, 26 July 2011 (UTC)


I have an error[edit]

This is after an upgrade to 1.18. Worked fine before.

Fatal error: Call to a member function addMessage() on a non-object in /home/every821/public_html/GargoyleWiki/w/extensions/DeletePagePermanently/DeletePagePermanently.php on line 74"

DeletePagePermanently.php line 74

$wgMessageCache->addMessage( 'delete_permanently', wfMsg('tab_label'));

Mlpearc powwow 03:29, 23 December 2011 (UTC)

Same problem here. Current version of this extension does not work with MediaWiki 1.18
$wgMessageCache was removed completely in version 1.18.0.
I'm not yet sure how exactly this extension is supposed to work but I'll probably fix this soon if no one else beats me to it :) For now, uncommenting line 74 might just be enough. Guaka 14:07, 8 February 2012 (UTC)
Not yet working as it's supposed to but this is probably what line 74 should look like:
                MessageCache::singleton()->addMessage( 'delete_permanently', wfMsg('tab_label'));
Guaka 15:05, 8 February 2012 (UTC)
UP/Same problem in line74. Current version of this extension does not work with MediaWiki 1.18
User:IsiaNT 09 February 2012
same err with mw 1.20 alpha (last svn before git) Greudin (talk) 18:10, 20 April 2012 (UTC)

Call to undefined function wfLoadExtensionMessages()[edit]

I'm getting this on 1.21 alpha. I know the one I'm using is unstable and not yet ready for prime time, but would anyone be kind enough to update this? Some of the other extensions had this function dropped just to work on newer builds. Blakegripling ph (talk) 07:53, 19 February 2013 (UTC)

Please see this thread: wfLoadExtensionMessages() removed from 1.21.1

--Jlemley (talk) 18:03, 10 June 2013 (UTC)