Extension talk:CustomEdit/Archive 1

Hi Barry,

I just wanted to let you know that this is an extremely useful tool. I am using this to create several data entry forms on a family genealogy wiki where certain information needs to be captured in a specific format for some templates I have written to work. Plus, not all of my community members are wiki-savvy, and this helps me to "dummy-proof" the site a little.

I did want to share one minor tweak I made that allows you to have more flexibility, such as when you have custom namespaces. This lets you add an extension onto the end of an article name rather than at the beginning (I've got several forms that work off of the article end name that create supplemental pages to an individual person's base record). I changed line 6 of the code as follows:

f Each form has its own extension; of course, you have to change the function name for each extension you load
 * Your code:       if (strpos($editpage->mTitle->getText,'Person/') === 0)
 * My change:       if (strstr($editpage->mTitle->getText,'/union') <> FALSE)


 * $wgHooks['AlternateEdit'][] = 'fnMyCustomEdit'; (line 3)
 * function fnMyCustomEdit(&$editpage) (line 4)

So far, it's been working like a charm! Thanks for your great contribution. --Hoggwild5 00:15, 22 December 2006 (UTC)

Found a glitch -- it seems that the forms get triggered on the talk pages for any page that triggers the form. Any thoughts on how to keep that from happening? I'm currently working on a wiki that has extranamespaces set up for both the regular pages and the talk pages. --Hoggwild5 02:45, 22 December 2006 (UTC)
 * I was able to answer my own question....thought I would post the answer here in case anyone else was looking for this solution. You need to modify line 6 of the code as follows:


 * My change:       if ( (strstr($editpage->mTitle->getText,'/union') <> FALSE) && ! $editpage->mTitle->isTalkPage )

And now, it works perfectly! --Hoggwild5 06:14, 22 December 2006 (UTC)


 * Ahhh... I've noticed this too. Haven't tried the fix yet but thanks for posting it! Blckdmnd99 14:03, 5 April 2007 (UTC)

MW Versions?

 * What versions of MW have people successfully used this with? Are there are issue moving up to 1.9 that you know of? Blckdmnd99 14:03, 5 April 2007 (UTC)
 * Tried it with 1.6: worked fine. Moved up to 1.11.0 and had the problem described at . --Flominator 14:39, 11 April 2008 (UTC)

wgReadOnly Bug

 * I happened across a bug this morning. I set Manual:$wgReadOnly and all pages were locked successfully except for the ones activated by this extension. (ie, the ones with whatever page prefix you've defined.) Just a heads up to everyone. If I work out the cause, I'll post back. Blckdmnd99 14:03, 5 April 2007 (UTC)

Interfacing with Categories..
hi,

Firstly, thanks for this brilliant extension. I have however one question have you, or anyone using this extension managed to interface this with existing categories. For e.g i would like some of the fields to be drop down menu's instead of text boxes. If you could interface this with existing categories that would be even better....

thanks!!

AJ.

- I've already solved the issue of creating categories however there is another issue. When i use a checkbox instead of a text field it only captures the last value. Any idea how to work around this issue?

Use with Caution
Just a heads up -- the coding for this page bypasses a number of checks and balances contained in EditPage.php, so use with caution. -Hoggwild5 14:51, 29 May 2007 (UTC)


 * Thanks for the warning! Could you be more specific? How serious is the risk? A link to info? Is there any workable way to re-introduce the most important checks? --Anderssl 08:07, 25 April 2008 (UTC)

User-friendliness
Is it possible to make this more user-friendly so the PHP file doesn't have to be edited to add/remove fields? Having to edit the PHP file plus create a template with the fields duplicated, is not very efficient design. Instead, how about only relying on the template, which can be specified on the page to call the CustomEdit extension, or whatever? -Eep² 03:42, 21 July 2007 (UTC)

Question about the templates
I managed to make extension work in principle. However I have no experience on creating templates. Could you give an example of template that would show info that is inserted to form? Wavelet
 * Try Help:Template. --Flominator 14:41, 11 April 2008 (UTC)

Bug with previewOnOpen?
Hey, first of all: Thanks for a great contribution, I have been able to customize this to my own needs and am very grateful! However, I just thought I'd let you know of a possible bug: When I download the code and try to use it, I get the following error message: "Fatal error: Call to private method EditPage::previewOnOpen from context '' in *myWikiPath*/extensions/CustomEdit.php on line 103" Simply removing the method call removes the error and doesn't seem to cause any problems, but I suspect it was there for a reason, no? Does anyone know if this will cause a problem, and if there is a workaround? My version info: * MediaWiki: 1.11.1 * PHP: 5.2.5 (apache) * MySQL: 4.1.22-log

Anderssl


 * I have the Same Problem whats Wrong?
 * I don't know what's wrong, but I've found out, that the Problem doesn't exist with MediaWiki 1.6, but with MW 1.11. @ Anderssl: Your solution seems to work. --Flominator 14:36, 11 April 2008 (UTC)

Hi guys, that change should be fine in most cases and certainly won't cause any problems. There is a Mediawiki option to display a page preview when first showing the edit page - which the previewOnOpen call was trying to detect. The developers have changed something related to that but unless anyone has that option enabled and really wants it to work, it probably is fine as it is. I just tested this extension with 1.12 and it works. I contributed a small change to remove a warning about variable $summary not defined. Barrylb 11:03, 16 April 2008 (UTC)

Switch to normal editform?
I want to add a link that let's users choose if they want to bypass the customized (dumbed down) edit form, and instead edit the "source code" of the article directly, as in the default edit form. I thought of just adding a parameter to the url, e.g. "*Article*&action=edit&customedit=no" or something like that - but I can't figure out if it's possible to access that variable from inside the CustomEdit.php file. Do anyone know?

The other possibility would be to just add an alternative textarea in the page itself, which is the solution I am trying out now - it works fine to show the article source, but somehow I can't manage to grab the contents and save them after they've been edited... And I have no idea why not... Is it because the curlies and the template call in the article source cause problems for the editpage->getText function? --Anderssl 13:19, 28 April 2008 (UTC)


 * Ah, stupid question. I figured it out myself (for other noobs: I used the first option, and then $_GET to get the variable. Works wonderfully. --Anderssl 13:52, 28 April 2008 (UTC)

Error message when I press the Edit tag in the top of pages
Hi, Barrylb and Flominator. After I installed the extension "CustomEdit (version 1)", I cannot edit pages anymore. Because when I do that, I will see the following message: Fatal error: Call to a member function getNamespace on a non-object in D:\AppServ\www\mediawiki-1.11.0\includes\Revision.php on line 49 Could you give me a hand?--Roc michael 00:26, 10 May 2008 (UTC)
 * MediaWiki: 1.11.0
 * Win XP
 * The AppServ Open Project - 2.5.7 for Windows
 * Apache Web Server Version 2.2.3
 * PHP Script Language Version 5.1.6
 * MySQL Database Version 5.0.24a
 * Hi Roc, have you created MediaWiki:CustomEditTemplates? Which page did you want to edit? Have you installed any hacks that required to patch the core code? --Flominator 11:10, 10 May 2008 (UTC)

I'm having the same issue as Roc michael; to work around this, I disabled the extension until I had created MediaWiki:CustomEditTemplates and registered a template in there, then created the template. If you activate the extension before MediaWiki:CustomEditTemplates is present, you get a fatal error as the extension tries to read a template name from a non-existent page (you could build in some error checking to check for the existence of the page, then exit out of the code with a message to the user to make this more user friendly).

If you activate the extension after you create MediaWiki:CustomEditTemplates but before you create the template that's registered there, you will get a warning message until the registered template(s) are created. Again, some error checking for the existence of the templates is probably in order here. If both MediaWiki:CustomEditTemplates and the registered templates are in place when the extension is activated, everything works without error messages.--Hoggwild5 17:34, 1 June 2008 (UTC)
 * Thank you for finding out. As I'm right in the middle of my diploma thesis, I can't promise to fix this one quickly. Any volunteers? --Flominator 16:18, 4 June 2008 (UTC)

Multiple parameter issue in template.
I am using this mod alongside a calender and event mod to allow users to easily post events. The Events are sorted on the calender via a date category. The template i have is as follows: Event Name: Event Time: Event Date: Participants:

The issue i have is while running this template the customedit extension displays a seperate text form for each instance of

Is there any way for the extension to display thetext form only once yet fill in noth parameters? 80.194.167.119 18:07, 17 August 2008 (UTC)
 * You mean one form field for each different parameter in the template? I think I could do that, if that is, what you want. --Flominator 07:06, 7 September 2008 (UTC)
 * What i mean is using the following template i get a form displaying:

name	|--|

time	|--|

users	|--|

date	|--|

date	|--|

Description:

Because of this the date must be entered twice or it is not saved in the page. I was looking for a method of running that template as is but only having the date form field displaying once. I could not find a method so i had to remove the first instance of date and ask my users to supply the date in the event name as well. 80.194.167.119 21:50, 12 September 2008 (UTC)
 * Solved in the current version. --Flominator 14:58, 30 September 2008 (UTC)