Extension talk:Simple Forms

Actually work?
Does this actually work?? I can't get it to do anything other show the full URL. --198.70.22.217 20:16, 27 April 2007 (UTC)
 * It's still in development, I'll add a message to say it's not ready. —The preceding unsigned comment was added by Nad (talk • contribs) 13:50, April 27, 2007. Please sign your posts!
 * See demo for an example --Zven 01:22, 30 April 2007 (UTC)

Anything new?
Anything new with this extension? I see that the code listed on the organic website has some errors in it. The article creation part would be wonderful for those who don't want to use semantic forms. --72.21.245.86 07:57, 27 May 2007 (UTC)
 * Bug fixed - I'll hopefully get some time to work on it again soon, currently it allows forms to be created and query-string items to be processed as in this example. --Nad 09:12, 27 May 2007 (UTC)

An idea to think about
What if there was an easy way to add another type of input verses text for the create article part of this extension? Like if you were able to use another extension as an input, like some form of media, .gif, .mp3, .wav, .flv, ext... --198.70.22.217 14:36, 5 June 2007 (UTC)
 * Sounds interesting, but not quite sure what you mean.... you mean like an input type that can work like an upload form? --Nad 21:35, 6 June 2007 (UTC)


 * Yeah, basically like an upload form. If someone wanted to upload a media file of some sort, I would say that videos would be most widely used, but others as well. That could be in one input type and then maybe some text in another input type describing it.


 * Another thought is to allow wikitext in the input. I have no idea how difficult that would be, but that way if someone wanted to use one of the media input extensions out there as the input, like one of the .flv extensions that uses outside sites like a youtube they could instead of actually uploading a file. Both ways could useful, but I'm not sure how doable it is allow wikitext. Maybe only allow some pre-defined extensions? Or just use similar functionality of the other extensions in this one as an input type.


 * And then to take it even a step further, use templates with the form using these different types of input. Haha, I guess all this doesnt make them to "simple" anymore! I just think there is room for a great form extension for Mediawiki and I'm surprised that after this long that not to many have went that route.--75.73.16.68 00:12, 7 June 2007 (UTC)
 * Yeah I've wondered why forms haven't really taken off in mediawiki too. I think the youtube functionality you describe sounds more like extending the template embedding functionality rather than forms, which I'm also working on in another extension called Extension:Livelets. I have made the #input parser-function easy to add new kinds of input to so after it's up and running I'll have a look at getting it to do some more exotic functionality. --Nad 02:06, 7 June 2007 (UTC)
 * I agree, I think that extending the template functionality would be key. The main thing I guess I'm trying to get at would be: When creating a new article, the user would have the option to add thier video or whatever right from the form along with text fields, etc... I know this is done at www.wikioutdoors.com. They have some sort of a forms entry that allows the user to choose an image for the article in question based on a template. Maybe the livelets works something like that? --72.21.245.86 03:56, 11 June 2007 (UTC)

Ajax configuration
$wgSimpleFormsUseAjax appears to be a configuration setting in Extension:Simple Forms and a variable in LocalSettings.php. Is the first one in the configuration file a logical only, and the second picked up to specify the path of mootools? --Zven 03:05, 26 June 2007 (UTC)
 * Disregard that, the configuration defaults in Extension:Simple Forms are overridden with configuration changes in LocalSettings.php --Zven 00:05, 28 June 2007 (UTC)

Edit functionality??
Version 0.3.2 (2007-07-09): Removed special-page and #edit parser-function, SimpleForms will not be implementing these
 * This seemed like one of the best features of the extension! Thats too bad it is no longer going to be implemented.... --198.70.22.217 19:36, 9 July 2007 (UTC)
 * SimpleForms can still edit articles in the ways shown in the examples, but will not be implmenting the #edit parser-function or special-page for interfacing to structured data (this feature had not been implemented yet). SemanticForms is the best solution for handling structured data, so it is a waste of effort re-implementing functionality which already exists --Nad 22:21, 9 July 2007 (UTC)
 * I still see a huge benefit to having this extension include the edit/create page functionality. It doesnt require semantic mediawiki for one, but it can viewed as a simple form. Whereas semantic forms, a great extention, dont get me wrong, but it has lots of overhead where this great extension could be a more user friendly form experience.  --72.21.245.86 17:29, 15 July 2007 (UTC)

use tables for widget arrangement
As also mentioned on your user page at organic design, I have trouble when using a wiki table within th ebody of a #form. To achieve acceptable layout the use of tables would really be helpful. See.
 * Thanks, Algorithmix 14:24, 26 July 2007 (UTC)


 * I agree. Not being able to use tables essentially makes Simple Forms useless to me. :/ —Eep² 07:22, 4 September 2007 (UTC)


 * I have this problem:

before

In a nutshell this is how I installed it:


 * 1) Don't bother with mootools as it isn't needed
 * 2) Download SimpleForms.php and place in the extensions folder
 * 3) Add the following code towards the end of localsettings.php in the order shown and save the file


 * 1) Create an article called SimpleTest and paste the following code into the article:

Note: This example creates an article with the title you enter and adds the comments you enter to the article body. It works once only on each article created. In other words, if you enter the same title and change the comments it doesn't update the comments.
 * Thanks, I've updated the docs to state the $wgUseAjax should be set before the SimpleForms inclusion statement. SimpleForms required MooTools until today when it was upgraded to 0.4.1 and now uses MediaWiki's native ajax functions. --Nad 10:40, 4 October 2007 (UTC)

Javascrip error
It doesn't work with Mediawiki Version 1.7.1 at me. Javascript gots an error:
 * args[args-length - 1] is not a function on line 76 --141.40.1.13 12:52, 4 October 2007 (UTC)
 * The code that error is occurring in doesn't look like simple-forms, does the error definitly only occur with simple forms installed? --Nad 19:47, 4 October 2007 (UTC)
 * Yes, it only occurs, when I use a SimpleForm with ajax-functionality and the error occurs in mediawiki's ajax.js
 * 1.7's ajax.js seems to be doing something a bit different which I'm not sure how to account for currently, I'd recomment upgrading to the current version of mediawiki as 1.7 is very old now and many extension will have trouble supporting it, especially concerning ajax. --Nad 05:16, 5 October 2007 (UTC)
 * I created an article at Ajax.js which shows in its history page how that script has changed throughout the mediawiki versions (the missing versions mean no changes, i.e. 1.7.x is using the same ajax.js code as 1.6.10). You can see that there were major changes in the approach to handling ajax requests between version 1.6.10 and 1.8.4, and since 1.8.4 and the current version there have only been some minor error handling improvements. If upgrading the wiki is too much of a task, then a simple fix would be to replace the ajax.js script with the current version from mediawiki 1.11 --Nad 06:19, 5 October 2007 (UTC)
 * If I use Ajax.js then there occurs following error

wgScript is not defined
 * in line 84 of ajax.js
 * I don't want upgrade to higher mediawiki-Version because of debian-etch stable package 1.7. Could you perhaps change the MediaWiki Versions at Extension:Simple Forms.
 * I'm not sure what you're asking? I doubt I will be changing it to support the older ajax.js, I think the new ajax.js could be modified to work though. I think Debian they can be a bit over cautious with their stable repository sometimes and php5 is an example. Any lack of stability exhibited by php5 on Debian (which I've never heard of in practice) is far out-weighed by the benefits it has over php4 - it's a major improvement and it's been in the field for a couple of years now. I'd recommend installing php5 from unstable (remember to turn unstable off again after you've done the install) or from the dotdeb repository, and upgrading to the current mediawiki. --Nad 10:07, 8 October 2007 (UTC)

How do you create a new page based on a template?
I am having trouble creating a new page from simpleforms which is based on a template. For example I would like to pass inputted parameters to a new page and format them based on a predefined template. This is similiar to using the preload function in the url. Can you provide an example of how I might accomplish that? --Jkuter 15:36, 11 October 2007 (UTC)
 * That requires very difficult syntax including javascript currently, but the next version has much better support for mapping forms to templates, it would best to wait for that. --Nad 20:19, 11 October 2007 (UTC)
 * No problem, lay it on me. Is this because all the input vars need to be extracted and layed on the URL for the preload?  This is a hassle but doable.  When do you think the next version will be released?  --jason 22:46, 11 October 2007 (UTC)

Can´t get #request contents
Hi Nad, I installed the latest version of Simple Forms, but a small test at http://semeb.com/dpldemo/Test_Simple_Forms shows that the contents of #request is not recognized. I set wgUseAjax to true before including your extension as you mentioned. Some other examples do work, however (those without ajax like the one above which creates a new document). The problem seems to lie in the Ajax hemisphere .. Can you help? Gero aka --Algorithmix 20:55, 21 October 2007 (UTC)
 * I installed your latest version, but it still doesn´t work. I observed another strange effect: The form is not interpreted but output as HTML strings when inside an if clause. See http://semeb.com/dpldemo/Test_Simple_Forms_2 --Algorithmix 19:28, 22 October 2007 (UTC)
 * The last patch wasn't working, 0.4.5 hopefully will fix the action=render caching problem --Nad 00:55, 27 October 2007 (UTC)

Bug - Undefined index action on line 53
Warning message in version '0.4.3, 2007-10-22':

PHP Notice: Undefined index:  action in ..../SimpleForms.php on line 53

The line is:

if ($wgUseAjax && $_REQUEST['action'] == 'ajax' && $_REQUEST['rs'] == 'wfSimpleFormsAjax')

Try testing  first.

--Djb 03:14, 24 October 2007 (NZDT)
 * Ok that should be fixed --Nad 20:38, 23 October 2007 (UTC)

table formatting still a work in progress?
After reading this, I wasn't sure if there is a workaround for using tables to align form input fields nicely, as in: I tried both wiki markup and regular HTML, and neither one worked. I tried adding magic words #row, #cell, #rowx, and #cellx to SimpleForms.php (to return as, , , and  respectively), but I must have been missing something because the tags always show up with the <> characters converted to HTML entities (same as before I made any changes).

If a fix is in the works, then I'll just hang on until it's ready -- but if there is already a workaround, I haven't been able to find it.

Thanks! --Woozle 01:18, 25 November 2007 (UTC)
 * It should be fine with html forms, what's your wikitext source look like? --Nad 21:00, 25 November 2007 (UTC)

Extension doesn't work in 1.12 after parser changes
Looks like the extension doesn't work in the latest svn version of mediawiki. Is this because of the parser changes? Is there an ETA for a fix?


 * The next version of simple forms (0.4.0) is a major change which will work with 1.12 and fix a number of other conflicts it currently has with the parser (such as not working with wiki tables and not being able to have forms inside other parser-functions like #if). Unfortunately I've just been really snowed under with work in the last couple of months and I don't know when I'll get the time to get 0.4 released. --Nad 21:49, 8 December 2007 (UTC)


 * Changing where it reads

'noparse' => true


 * to

'noparse' => true, 'isHTML' => true


 * worked for me. —Sledged (talk) 20:48, 1 March 2008 (UTC)
 * Just checked it out on todays release with the above change and its working well. Thanks!--jason 00:57, 21 March 2008 (UTC)

Can't get it to work in Mediawiki 1.6.6
Including it at the end of LocalSettings.php kills my wiki (the server delivers no content until its removed). This suggests to me a parsing error in the file. Using PHP 4.3.10. Ideas please ?

andy - 3.1.07.

problem with simpleforms "categorise the current article" template
I've installed simpleforms and it seems to be working fine (other templates work without problem) but the single feature I need the most isn't working. In particualr, the form to categorise the current article code runs into a snag by producing a dropdown list that contains the Select category instead of pulling up my list of categories. Any help is greatly appreicated as I've spent more than three hours searching for a solution to the problem but to no avail. - Thank you.
 * Have you installed DynamicPageList? Joejk2 21:51, 28 March 2008 (UTC)

Namespace protection bypassed ?
I've got the impression that the request handling doesn't take account of namespace protections (done with $wgNamespaceProtection). For instance, with the following settings : $wgGroupPermissions['*']['createtalk']   = true; $wgGroupPermissions['*']['edit']   = true; $wgGroupPermissions['sysop']['edit']   = true; $wgGroupPermissions['*']['purge']   = true;

$wgGroupPermissions['validation']['editmain'] = true;

$wgGroupPermissions['sysop']['editmain'] = true; $wgNamespaceProtection[NS_MAIN] = array( 'editmain' ); $wgNamespaceProtection[NS_HELP] = array( 'editmain' ); $wgNamespaceProtection[NS_TEMPLATE] = array( 'editmain' ); $wgNamespaceProtection[NS_MEDIAWIKI] = array( 'editmain' ); $wgNamespaceProtection[NS_CATEGORY] = array( 'editmain' ); $wgNamespaceProtection[NS_SPECIAL] = array( 'editmain' );

a request to main namespace sent while not logged is accepted and a revision is created while it should not be allowed (in main namespace, only sysops should be able to write).

I guess that it is due to the fact that SimpleForms only checks (line 312 and 321) : (...)$wgUser->isAllowed('edit')(...)

Does anyone knows how to fix this, that is how to express the additional check for namespace protection ? Thanks in advance :) Gizmhail


 * To answer my own question this vulnerability can be fixed by changing (line 312 and 321) (...)$wgUser->isAllowed('edit')(...) by (...)($wgUser->isAllowed('edit')&&!$title->isNamespaceProtected)(...) Gizmhail 01:03, 2 March 2008 (UTC)

Option value and little protection
To simplify handling of select field in Javascript for some browsers, it might be conveniant to have value set for the option in a select. This can be done by changing line 177 from: $input .= "$opt \n"; to $input .= "$opt \n";

By the way, to prevent some crashes (if parameters are not properly set, like with an empty title), you can change line 302 from : if ($title->getNamespace == NS_SPECIAL) return; to if (!$title||$title->getNamespace == NS_SPECIAL) return;

UNIQ problems
My MW version is 1.10.0rc2. I see stuff like UNIQ18dfddda347ad1fc-item602aea0c27d49d76 instead of the form fields. Please help.
 * Same issue in MW 1.12 with the Ajax example to return category members Joejk2 21:48, 28 March 2008 (UTC)
 * I'm seeing UNIQ values in the ajax response with MW 1.11, I'm backing out to the previous version 0.4.6 which works fine.--Danbrice 05:23, 29 March 2008 (UTC)
 * I'm unsure what this bug is... now I've seen it with 0.4.6, 0.4.7 & 0.4.8 versions. Sometimes (not always) I can resolve it by clearing the cache in the database --Danbrice 06:50, 29 March 2008 (UTC)

TRUNCATE TABLE objectcache; TRUNCATE TABLE querycache;
 * I really can't say I understand what's going on here, but I noticed that my content value's were being converted to UNIQ values, so they were just being passed along to the ajax post as UNIQ values, of course never being converted to their correct values. Adding the following line fixes that problem, but I still had to do the truncate cache tables as I'm getting some more UNIQ values further down the chain, and I'm afraid it will come back again.

After this line: foreach (func_get_args as $arg) if (!is_object($arg)) { add: $arg = $parser->unstripForHTML($arg); --Danbrice 20:39, 29 March 2008 (UTC)

I have added the line and it does not change anything. SF version 0.4.8, MediaWiki: 1.10.0 (r22894), PHP: 5.2.0-8+etch10 (apache), MySQL: 5.0.32-Debian_7etch5-log

More 1.12.0 problems
Some forms that used to work in mediawiki 1.11.x do not display properly in 1.12.0. It seems that any wikitext within the form is not being evaluated. For example:

does not display the link "My link", but the literal text. I assume the parser changes in 1.12.0 triggered this behavior, but does Simple Forms need to do something to compensate for it? --Maiden taiwan 18:29, 31 March 2008 (UTC)


 * I have noticed the same thing, wiki syntax used to work with the forms and now it does not. Since the parser order has change I expect that this may be a major extension change and I have not looked into a fix.  Does anyone know if wiki text within the simple forms code will ever be possible again?  Is this a bug or a feature?  Thanks.--jason 18:23, 8 April 2008 (UTC)

Forms fail for wikisysop in 1.12.0
If you're logged in as wikisysop, this simple form does not work:

The  never displays anything, even on form submissions that clearly show "foobie=something" in the query string. When logged in as a regular user, the form works fine. This is with MediaWiki 1.12.0, Apache 2.2.8 and PHP 5.2.5, on Windows 2003 Server.

--96.233.112.177 02:16, 8 April 2008 (UTC)

Help with Regular expressions
Hi, I need a hand with using regex... I'm pretty good with regex in general but I just can't seem to get this working. Basically I want to have a form that replaces the body of tags (from the Labeled Section Transclusion extension) on the same page as the form itself. This is the body of a test page I tried making:

1234

Now say I type 4321 in the text box, the span refreshes to display a garbled mess of nonsensical characters, and when I hit refresh/edit, the entire page's markup has been replaced with this:

43214321 43214321 43214321 43214321 43214321 4321 43214321 4321 43214321 43214321 43214321 4321 43214321 43214321

As best as I can tell, empty lines are being replaced with '4321', while non-empty lines are being replaced with '43214321'. Help!!! -- DDe 08:44, 23 April 2008 (UTC)
 * I think the problem may be that the form needs to be a different article than the text you're replacing - maybe try transcluding the form or the sections being replaced. Also you can simplify the regexp and replacement by using assertions, eg. instead of replacing

.*
 * with

$1
 * you can instead replace

(?<=).*(?=)
 * with

$1 Also since the match is working on the entire form (which I think is a problem here) the regexp is actually replacing part of itself because it contains the text its been told to match. You could get round this by putting one of the characters in square brackets in the match, eg &lt;[s]ection... so it behaves the same but doesn't match itself - however I think having the form in the matched article is causing some other issue, I'm not sure exactly. --Nad 21:55, 23 April 2008 (UTC)