Extension talk:EditSubpages

This is really useful! Thanks so much for the development.

Errors

Great extension, but I got an error after installing it: "Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of array_unique(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in [redacted]/extensions/EditSubpages/EditSubpages.php on line 60 Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of array_unique(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in [redacted]/extensions/EditSubpages/EditSubpages.php on line 69" Er, help? I also get this error when I log out and try to edit my unrestricted pages: Warning: preg_match() [function.preg-match]: Unknown modifier '\' in [redacted]/extensions/EditSubpages/EditSubpages.php on line 55 Warning: preg_match() [function.preg-match]: Unknown modifier '\' in [redacted]/extensions/EditSubpages/EditSubpages.php on line 55 The attempted edit tab does not show up for the unrestricted pages. --

Both issues should be fixed in version 1.2. I've moved it into Subversion, so you need to download it from there instead of copy/pasting. --Skizzerz ^{talk - contribs} MediaWiki Support Team 23:50, 3 March 2008 (UTC)

Many, many thanks!

This is working great, except I may have found either a bug or a problem with my set-up. The pages I list, and their talk pages, are editable by everyone. If I list a specific talk page, it isn't editable, even though it's showing in the list. Also, subpages of the pages I list are not editable. I thought that all subpages were editable, and that anonymous users could create new subpages? 24.16.13.116 22:33, 6 March 2008 (UTC)

Should be fixed now. --Skizzerz ^{talk - contribs} MediaWiki Support Team 00:14, 7 March 2008 (UTC)

Another Error

It seems that I am unable to "unlock" a page that is in a namespace. Pages in the main namespace get unlock fine, but pages in the Help namespace or Project namespace (I just haven't tried any others) don't get unlocked. Smaug 00:38, 28 March 2008 (UTC)

I'll look into that. --Skizzerz ^{talk - contribs} 19:02, 30 March 2008 (UTC)

Fixed in version 2.0. Grab it from Subversion. --Skizzerz ^{talk - contribs} 22:56, 4 April 2008 (UTC)

EditSubpages gives Fatal error if Extension:ConfirmAccount is installed

Looks like EditSubpages.php barfs at line 30 if MediaWiki:Unlockedpages does not exist. Better mention this in installation instructions. --84.253.237.195 20:02, 29 March 2008 (UTC)

Seems I was too hasty in drawing conclusions. I get

Fatal error: Call to a member function getText() on a non-object in
/biz/fcjazzjuniorit.fi/html/mediawiki-1.11.0/extensions/EditSubpages/EditSubpages.php on line 30

Even if MediaWiki:Unlockedpages exists. Google show lots of same erros, trying to find out actual cause, but may be something with webhotel setup. --Taleman 13:09, 30 March 2008 (UTC)

That is odd. The purpose of that particular line is grab the title of the current page. MediaWiki:Unlockedpages plays no part in that step. I'm guessing it has something to do with your setup, then, since it appears $wgTitle (which is the current page's title object) doesn't seem to be defined for you, despite the fact that it was declared in a global the line prior. Not quite sure how to help you on this... --Skizzerz ^{talk - contribs} 19:01, 30 March 2008 (UTC)

From discussion on #mediawiki 2008-03-31

< Werdna> that extension is badly-written
< Werdna> the extension should be using the userCan hook, not the UserGetRights hook
< Werdna> perhaps the order of execution has been changed?

I am running

   * MediaWiki: 1.11.1
   * PHP: 5.2.5 (cgi)
   * MySQL: 5.0.45-community

I updated MediaWiki, same error message if I add

#error_reporting(E_ALL);
#ini_set("display_errors", 1);
#$wgShowExceptionDetails = true;

to LocalSettings.php.

MediaWiki  	1.12.0
PHP 	5.2.5 (cgi)
MySQL 	5.0.45-community

--Taleman 07:21, 31 March 2008 (UTC)

I installed MW 1.12.0 on another web hotel, there EditSubpages works, at least before I install other extensions and change LocalSettings.php. --Taleman 10:54, 31 March 2008 (UTC)

I installed Extension:ConfirmAccount, then the Fatal error appears. So my conclusion is, that EditSubpages does not work if ConfirmAccount is also installed. --Taleman 11:17, 31 March 2008 (UTC)

Hmm... I initially used UserGetRights instead of userCan because it made the coding a hell of a lot easier for the same effect, but I'll play around with a userCan version too. As for the ConfirmAccount issue, that may be fixed by switching to using userCan as well... I really don't know. --Skizzerz ^{talk - contribs} 22:27, 31 March 2008 (UTC)

Ok, I'm attempting to fix this error right now, but the userCan hook is being mean to me and not working :(. I should hopefully have the next version (2.0) up by next week or so. --Skizzerz ^{talk - contribs} 17:01, 4 April 2008 (UTC)

Fixed in version 2.0. Grab it from Subversion. --Skizzerz ^{talk - contribs} 22:56, 4 April 2008 (UTC)

Installed new EditSubpages.php. Edit tab is shown on pages mentioned in Unlockedpages, and page can be modified, but saving the page shows dialog about having to log in to edit pages. And modifications are not saved. I did not see any altered installation instructions, and do not understand why this fails. --Taleman 06:23, 6 April 2008 (UTC)

Hmm... I think I may know the fix for that. --Skizzerz ^{talk - contribs} 15:41, 6 April 2008 (UTC)

I installed version 2.1. Now the Edit tab is not shown and page can not be edited. Upgrades are going in the wrong direction. --84.253.237.195 10:45, 11 April 2008 (UTC)

the only thing changed in v2.1 was the fix in the extension credits. The code itself was not changed (see diff for proof), so something else you may have done is causing this issue you mention. Also, I'm going to completely re-vamp the extension pretty soon to allow more a more powerful syntax. --Skizzerz ^{talk - contribs} 20:08, 11 April 2008 (UTC)

True, I mixed up the unlocked pages. Sorry for confusion. Hope you get saving edit working soon. --Taleman 03:38, 12 April 2008 (UTC)

(reset indent) Yes, I'm completely re-vamping that bit as well to allow for the more powerful syntax I mentioned before. I am almost done writing it, so perhaps in 4-ish days I should have it all tested and committed. --Skizzerz ^{talk - contribs} 23:41, 12 April 2008 (UTC)

Can't wait until you're done :) Got the same problem with being able to edit, but not to save. My configuration:

• MediaWiki: 1.11.0
• PHP: 5.2.1 (apache2handler)
• MySQL: 5.0.38-Ubuntu_0ubuntu1-log

Thanks in advance, --Flominator 10:42, 16 April 2008 (UTC)

Fixed

This has now been fixed in version 2.2. Funny thing is, I only had to add one letter and change four others to make it work :P. Anyway, you can get a sneak peak of my new syntax on the extension page :) --Skizzerz ^{talk - contribs} 01:56, 17 April 2008 (UTC)

Thank you very much for that quick fix. It's now working --Flominator

It takes skill to know what letter to add and which to change. Big thanks, I will update to 2.2. --Taleman 08:51, 17 April 2008 (UTC)

German translation

/* German
 */
$messages['de'] = array(
	'editsubpages-desc' => "Gibt den Administratoren die Möglichkeit, eine Seite und deren Unterseiten für das unangemeldete Bearbeiten über [[MediaWiki:Unlockedpages]] freizuschalten",
	'unlockedpages'     => ' #<!-- Lassen Sie diese Zeile wie sie ist --><pre>
# Listen Sie freigegebene Seiten mittels
# * [[Seitenname]]
# Zu entsperrende Seiten müssen mit einem * gelistet werden.
# Alle anderen Einträge werden als Kommentar gewertet.
# Diskussionsseiten werden ebenfalls entsperrt.
# Mehr Informationen: http://www.mediawiki.org/wiki/Extension:EditSubpages 
 #</pre><!-- Lassen Sie diese Zeile wie sie ist -->',
);

--Flominator 10:11, 17 April 2008 (UTC)

Logic behind EditSubpages - "Only apply these restrictions to anons"

I have the problem that I would need "Only apply these restrictions to users". At all I can not understand the logic behind the setting "Only apply these restrictions to anons": Why should I allow anons things which I don't allow registered users? --StStefan 10:31, 5 December 2010 (UTC)

You have users being able to edit every page, and unlock only specific pages for anons (who can't edit by default). I don't think it's possible to even do the opposite (restrict users while unrestricting anons) using only this extension. --Skizzerz 04:15, 28 December 2010 (UTC)

MWNamespace::getTalk does not make any sense for given namespace -1

message error with mediawiki 1.18.

Workaround, if you have no talk pages in unblocked list: change line 39 to $nstalk = '';

maybe one can check somewhere for namespace -1 before accessing the talk namespace

Forentw 19:36, 8 January 2012 (UTC)

Fixed in version 3.1 --Skizzerz 21:54, 21 March 2012 (UTC)

Unlocking of other namespaces

I am using Mediawiki 1.18 with

$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['trusted']['edit'] = true;

When I activate the extension the Category pages and several others become editable for common users. Forentw 23:49, 17 January 2012 (UTC)

I need more information than that in order to figure out your issue. What does your Unlockedpages look like and do you actually understand the purpose of this extension? It is meant so that you can allow anonymous users (and by extension all logged in users) to edit certain pages you otherwise have locked down. Trying to use it to have a differentiation between logged in users and a "trusted" usergroup might not work properly, if at all, in the current version of EditSubpages. --Skizzerz 21:50, 21 March 2012 (UTC)

Needs Howto setup permissions in LocalSettings.php

When I use this extension in Mediawiki 1.16.2 it allows editing. I tested, with and without the extension.

The anonymous user can edit the page. But when they try to save the page it says you need to login in order to save pages.

These are my user options, what are the correct ones for this extension?

# User options
// Prevent anonymous users from reading
$wgGroupPermissions['*']['read'] = false;
// Only SysOp (Admin) can create accounts -
$wgGroupPermissions['*']['createaccount'] = false;
// Prevent anonymous users from editing
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['createtalk'] = false;

The "correct options" are to not have any. When you load the extension, it will set the correct options so that it can function properly. Attempting to modify anonymous user permissions related to editing/creating pages after loading the extension will more than likely cause the extension to not function properly. For that specific example, ONLY the "createaccount" permission is necessary, as EditSubpages doesn't touch account creation. All the other ones should be removed. Also, preventing anons from being able to read pages defeats the purpose of this extension, as they can't access pages anyway. --Skizzerz 21:47, 21 March 2012 (UTC)

Wildcard usage

So I'm a little confused on how to do this.

I have a 4 page deep subpage structure like: www.domain.com/beverages/sodas/coke/coke-zero or www.domain.com/foods/fast-food/burgers/cheese-burger

What I want, is to only allow people to add or edit anything under the last two sub-pages. So coke & coke zero, or burgers & cheese-burger. In that case, a list of all combinations of the first two pages (beverages & sodas) would be huge, so how can I do this with wild-cards? Thanks!

I think you're looking for the following: * .+/.+/.*|+r, which would allow editing and creation of any 3rd or higher (4th, 5th, etc.) level subpage, regardless of what the first two levels are. --Skizzerz 20:16, 27 July 2012 (UTC)

Looks to be working perfectly. Thanks for the awesome extension!

Not working on Special:SpecialPages in 1.19.1

I've just upgraded to MediaWiki 1.19.1 and I get the following error when navigating to Special:SpecialPages:

MWNamespace::getTalk does not make any sense for given namespace -1

Backtrace:

#0 /home/astoreho/public_html/wiki/includes/Namespace.php(94): MWNamespace::isMethodValidFor(-1, 'MWNamespace::ge...')

#1 /home/astoreho/public_html/wiki/includes/Title.php(745): MWNamespace::getTalk(-1)

#2 /home/astoreho/public_html/wiki/extensions/EditSubpages/EditSubpages.php(39): Title->getTalkNsText()

[rest of backtrace snipped]

Philip J. Rayment (talk) 15:43, 27 August 2012 (UTC)

What version of EditSubpages? You should ALWAYS be using the latest version (3.1). --Skizzerz 23:44, 30 August 2012 (UTC)

Okay. After upgrading MediaWiki to 1.19.1, I did download the "latest" version. I clicked the "download snapshot" link in the infobox, chose the (default) option for 1.19.x, and downloaded the file, which was http://upload.wikimedia.org/ext-dist/EditSubpages-MW1.19-107261.tar.gz. I now see that it is version 3.0.

Since seeing your comment, I've downloaded the Development Version, which I see is 3.1.

I still get the same error.

Philip J. Rayment (talk) 09:04, 31 August 2012 (UTC)

If you are getting the exact same error, then please completely delete your existing EditSubpages extension and then re-upload version 3.1. Getting the same error means that you did not actually upgrade the files. If the error message is different, however, I need to know the new error message (that includes if the "backtrace" part is different). --Skizzerz 02:54, 2 September 2012 (UTC)

Fixed. The latter problem was my mistake, sorry. In upgrading MediaWiki, I had a copy of the original installation as a backup, and I "upgraded" EditSubpages in the original, not the new working copy, i.e. I put version 3.1 in the wrong Extensions folder. Thanks for your help. Philip J. Rayment (talk) 10:03, 23 September 2012 (UTC)

Actually, not fixed, although the problem is now different. When going to an unrestricted page when not logged in, I get the following error message:

Fatal error: Call to a member function exists() on a non-object in /home/astoreho/public_html/wiki/extensions/EditSubpages/EditSubpages.php on line 127

Philip J. Rayment (talk) 10:39, 23 September 2012 (UTC)

As version 3.2 still doesn't work, and I've had the time to have another look, it seems that the problem is that $newtitle is not being set in some circumstances. Here is the fix I did:

           $found = self::checkPage( $pieces[0], $evEditSubpagesCache['text'], $flags );
           if( !$found && $flags['n'] ) {
               $found = self::checkPage( $pieces[0], $evEditSubpagesCache['pagename'], $flags );
           }
           if($found) {$newtitle = Title::newFromText( $pieces[0] ); }	//<--- I added this line.
           if( !$found && $flags['t'] ) {
               $newtitle = Title::newFromText( $pieces[0] );
               //make sure that it's a valid title
               if( $newtitle instanceOf Title && !$newtitle->isTalkPage() ) {
                   $talk = $newtitle->getTalkPage();
                   $talkpage = $talk->getPrefixedText();
                   $found = self::checkPage( $talkpage, $evEditSubpagesCache['talktext'], $flags );
                   if( !$found ) {
                       $found = self::checkPage( $talkpage, $evEditSubpagesCache['text'], $flags );
                   }
               }
           }

If $found was true before it got to the line after the one I added, $newtitle was not getting set, which led to an error on !$newtitle->exists further down.

I'm not a php expert and I don't know if this completely solves the problem, but it does seem to work for me at the moment.

I might add that I made the change to version 3.2, not 3.3, as 3.3 has another problem. The new JSON-based language module includes EditSubpages.i18n.php which supposedly makes extensions compatible back to MediaWiki 1.17, but it apparently requires php 5.3, whereas MediaWiki versions up to 1.19 work with php 5.2.3. So if you wiki has php.5.2.3, as mine does, EditSubpages 3.3 doesn't work with it.

Philip J. Rayment (talk) 12:27, 21 April 2014 (UTC)

(reset indent) Thanks for the heads-up, I'll see if I can get a version 3.4 shipped that officially fixes that issue you found. As for compatibility, don't count on PHP 5.2 support. You should really update PHP on your web server, I recommend 5.5 (or 5.4 otherwise). Both 5.2 and 5.3 are ancient and no longer supported by the PHP group. --Skizzerz 20:33, 22 April 2014 (UTC)

Updating PHP on a server I'm not in control of is easier said than done.

As for the i18n.php file, MediaWiki acknowledge the problem and are planning to fix it.[1] Actually, the fix might already be available.[2]

Philip J. Rayment (talk) 00:22, 25 April 2014 (UTC)

Sure, and if they fix it that's fine, but note that I'm not going to be officially supporting PHP 5.2 moving forward. For example, the recent 3.4 update will break wildcard matching on Windows and PHP 5.2 (although Windows + PHP 5.3 will continue to work just fine). I know that upgrading is "easier said than done" but nothing will ever be done if you don't ask whomever is hosting the server to perform the upgrade. If that host refuses, and you are able, you should then talk with your feet and move to a different host that actually cares about its customers by not running outdated server software that (at this point) has known unpatched security exploits. --Skizzerz 14:33, 25 April 2014 (UTC)

I guess in the end it's up to you what versions you maintain compatibility with, but MW 1.19, which runs on php 5.2.3, is being maintained until May 2015[3], and, to quote that link, "Extension maintainers are therefore strongly encouraged to maintain a git tag or branch for their version corresponding to the release tag the stable and oldstable version. An initial version, that simply points to the state of the code at the time of the release may be created centrally. However, it is the responsibility of the extension maintainer to fix bugs not only in HEAD but also in the oldstable and stable versions.". I can understand you adding new features that don't work on older versions, but fixing bugs for extensions that work with older versions of MW that are still maintained (i.e. currently back to 1.19.x) seems to be a prudent path to take. Philip J. Rayment (talk) 14:59, 29 April 2014 (UTC)

My philosophy is to keep the most current version (e.g. the "master" branch) compatible with recent versions of MediaWiki, to include the latest stable version and latest LTS release if possible. However, my philosophy is also so that end users are running supported software all the way through, and while MediaWiki 1.19 may be supported for another year, PHP 5.2 has stopped being supported around 3 years ago. This means that anyone running on PHP 5.2 is currently exposed to numerous security issues with the PHP language, some of which can be exploited simply by visiting PHP-enabled sites. Due to this, I refuse to support PHP 5.2, although I will still gladly support MW 1.19 on the master branch as long as it is running on PHP 5.3+. --Skizzerz 14:38, 2 May 2014 (UTC)

Not unlocking pages

Been working on this for a while, and can't figure it out. I have had a hosted linux mediawiki 1.18.1 install running with EditSubpages just fine, but now that I've moved to my own dedicated server running windows mediawiki 1.19 I can't seem to get it to work. Everything seems similar to the old install, and I've tried stripping just about everything out of my localsettings file with no help. With Editsubpages disabled - anonymous has rights to edit; with it enabled - anonymous doesn't have rights to edit anything, only logged in users have rights. I'm using "* .+/.+/.*|+r" for unlock. Any ideas of what it could be, or how I could debug what's breaking? Thanks Just a though, but I'm wondering if maybe this has to do with IIS's occasional use of %3A instead of a colon? Tried changing ":" in the two lines of EditSubpages.php, but it didn't help. Also, one difference I see in Special:Version is a new column next to the name of "(31ffd50)" with a link to https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/EditSubpages.git;h=31ffd5012705cac2d5ff40d88cabd913d8befd59 . That column doesn't show up in my older Mediawiki linux install. Not sure if either of those things matter, just trying to figure this out.

Do you have a link to the wiki in question such that I can check it out? --Skizzerz 00:03, 1 December 2012 (UTC)

You can check it out at www.wikiocity.com . To follow down the subpages, you can click Texas, then San Antonio, then Post Offices, then a location. I just did a fresh install of MediaWiki, and wasn't able to get EditSubpages working from a clean site. Seems like it's gotta be something with my setup? I'm going to put some more work into trying to figure it out, but I could really use the help. Thanks!

Sorry for the delayed response, but I have just shipped version 3.2 which addresses this issue. MediaWiki's move from Subversion to Git severely reduced the speed at which I could develop until I got everything figured out. --Skizzerz 23:10, 6 January 2013 (UTC)

All users can still edit all pages

I'm using Mediawiki 1.26 and the Auth_remoteuser extension (to get usernames from an external SSO solution). After installing EditSubpages, all users can still edit pages and create pages, nothing is locked. Any idea what the incompatibility might be? --73.247.226.42 06:13, 10 January 2016 (UTC)