Extension talk:Simple Forms

=2007=

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)

Javascript 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)
 * Try using the InputBox extension.

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)

=2008=

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.08.

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

I have the same problem (MW 1.10.1.) and both recommendation are not work! It would be a super extension if it worked. Is there a possibility maybe to solve this error?

--Javaph 12:06, 18 December 2008 I am using the MW 1.9

After Adding the Line i had the problem still, but since we have and

i added the same line twice $arg = $parser->unstripForHTML($arg);

in: function formMagic(&$parser) { ... foreach ($argv as $arg) if (!is_object($arg)) { $arg = $parser->unstripForHTML($arg); ... } and function inputMagic(&$parser) { ... foreach (func_get_args as $arg) if (!is_object($arg)) { $arg = $parser->unstripForHTML($arg); ... } i am not sure if it works but now i can see the Form,a dn actually that is what i wanted

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)

title error
Using MediaWiki 1.12, SMW 1.1.1 and SimpleForms 0.4.9

Created following page: http://www.mediawiki.org/wiki/Extension:Simple_Forms#Ajax_example

Getting on submit: Fatal error: Call to a member function getNamespace on a non-object in /home/progres9/public_html/jewage/w/extensions/SimpleForms/SimpleForms.php on line 454

Somehow empty title instead of UNTITLED is passed to script leading to this error. I didn't get why empty title isn't replaced by UNTITLED in the beginning. --Eugenem 10:53, 8 May 2008 (UTC)

I'm experiencing the same problem with Mwiki 1.12 and SimpleForms 0.4.10. Any help ? -- Nehru

How can i send the information to my emailadres?
Hello,

I saw this form, and i want that people can fill it in and send it to my emailadres when they push te button. But i cant find anywhere how that works. Can someone explain me how to do it? Click, if you have time and you want to do it as an test to let me see how it works; you welcome then!

--Cobra 14:36, 8 May 2008 (UTC)
 * SimpleForms doesn't handle emailing, but I made a companion extension a while ago which can post the form contents to an email address, see Extension:FormMailer --Nad 21:25, 8 May 2008 (UTC)


 * Have you got an example of an form for my wiki? I can build it out i think, but i cant script very well. Can you please help me? If you want; click here you see an few questions, how can i send these things to an emailadress? Can you fix that? When i have that example, i get it and can work it out. Thnx

--Cobra 19:29, 11 June 2008 (UTC)
 * I've fixed the form, but you'll need to set your email address in your LocalSettings.php file for example,

$wgFormMailerRecipients = array('foo@bar.com', 'foo@bar.org');
 * --Nad 00:41, 12 June 2008 (UTC)


 * I have filled in my emailadress in the localsettings, but it dont works..

include("$IP/extensions/FormMailer.php"); $wgFormMailerRecipients = array('emailadress', 'same emailadress'); $wgFormMailerVarName = true; $wgFormMailerFrom= true; $wgFormMailerDontSend = true; $wgFormMailerMessage = true; $wgFormMailerSubject = true;

What am i doing wrong? --Cobra 14:12, 12 June 2008 (UTC)

Bump; you know how i can fix it?

--Cobra 22:15, 14 June 2008 (UTC)
 * Just remove all the other items apart from $wgFormMailerRecipients as you've given them values which don't make any sense, and if you only want it posting to one email address then don't add it twice in the array. Also ensure that your server and wiki are sending mail correctly - i.e. can the wiki mail you when items on your watchlist change etc --Nad 23:10, 14 June 2008 (UTC)

It's working (not all) the 'menu' box where you can klik on which car you like (last car poll) i get this in my mail; cars: Array and the form they can fill in dont show up in the email. Hope you know how i can fix it. Thanks --Cobra 00:04, 15 June 2008 (UTC)
 * The inputs must have unique names other data from subsequent inputs with the same name will replace previous ones. --Nad 01:53, 15 June 2008 (UTC)

Simple Forms Example
To Whom It May Concern: I am a wiki newbie so please bear with me :)

I have setup my wiki and installed the SimpleForms.php extension. I would like a simple form to do the following:

1. Allow a user to input a name of a place 2. Allow the user to select a submit button 3. On the next page, display the newly generated page (title should be what was entered by the user in step 1).

I have searched for hours and have yet to find a clear example which actually shows the code for this. I have decent html and js experience.

Your help is much appreciated!

Thanks, Will

wfSimpleFormsAjax
I've got this extension installed, but I get an error any time I hit the submit button using any of the examples. The error always centers around wfSimpleFormsAjax. Here's an example error from one of the samples:

Error: 400 Bad Request ( Bad Request

unknown function wfSimpleFormsAjax )

This would do exactly what I need if I could get it working. Any ideas? 129.44.71.244 18:46, 10 June 2008 (UTC)


 * I'm having the same issue. Are you running the 1.13alpha version of MediaWiki by any chance? If that's the case, then it may just be a 1.13 issue. -- Joe Beaudoin Jr. 22:11, 12 June 2008 (UTC)
 * I do have some 1.13's running, but have not had time to test this yet. There are a lot of problems with this extension and a new version is underway which will work properly with the new MW versions. --Nad 00:16, 13 June 2008 (UTC)


 * I have the same problem on a freshly installed 1.12 stable mediawiki. And no idea how to solve that ... Thanks for any input or ideas on that topic. --82.83.56.50 17:35, 30 June 2008 (UTC)


 * I am having the same problem and am running 1.12 stable.
 * Error: 400 Bad Request (
 * Bad Request
 * unknown function wfSimpleFormsAjax

User:Caile13:Kay


 * Same here with mwiki 1.12 stable and simple forms 0.4.10

Hi all! In MW 1.13.0 skins/common/ajax.js says at 65. line about the first parameter of sajax_do_call function: func_name - the name of the function to call. Must be registered in $wgAjaxExportList Write this code $wgAjaxExportList[] = 'wfSimpleFormsAjax'; into LocalSettings.php. It solves the Bad request problem, but there is a new one: Internal Error: wfSimpleFormsAjax returned no data Anon - 16:26, 30 Aug 2008


 * I have a patch to get around this issue and get SimpleForms working again in 1.12 with Ajax. However the patch is not backwards compatible with 1.11, and probably needs some work before it's put into the release of this extension.


 * Here's the diff: (change "<" lines to ">" lines)

<    $_REQUEST['action'] = 'render'; ---           >     $_POST['action'] = 'render'; <                $_REQUEST[$m[1]] = $m[2]; ---           >                 $_POST[$m[1]] = $m[2]; < if (isset($_REQUEST[SIMPLEFORMS_CONTENT]) && !isset($_REQUEST['title'])) { ---           > if ((isset($_POST[SIMPLEFORMS_CONTENT]) || isset($_REQUEST[SIMPLEFORMS_CONTENT]))  && !isset($_REQUEST['title'])) { <    $_REQUEST['title'] = SIMPLEFORMS_UNTITLED; ---           >     $_POST['title'] = SIMPLEFORMS_UNTITLED;


 * In 1.12 includes/WebRequest.php was changed to use $_GET & $_POST instead of $_REQUEST so the attempt to avoid using the AjaxDispatcher failed as $wgRequest was ignoring any changes made to $_REQUEST by this extension. My fix sets the values in $_POST instead, the 1.12 version of WebRequest uses those and it essentially works the same way it did in 1.11.0. --Danbrice 21:33, 4 September 2008 (UTC)


 * Setting $_REQUEST or $_POST is a hack in the first place, and may break again in future releases. Could/Should this extension be modified to use the AjaxDispatcher?--Danbrice 21:33, 4 September 2008 (UTC)


 * Just to say thankyou for this hack, it got Simple Forms 0.4.10 with Ajax working again on a MW 1.13.1 installation. Optimale 12:04, 25 September 2008 (UTC)

Can't get values passed to other articles
Hi, testing something simple. I want to have a wiki article accept a number of different values in text boxes, and then pass them to another article that may perform some maths, add new boxes, pass to another article, etc. It's to build up a character sheet for an RPG, across 20 or so articles.

My first article (FormTest) uses:

The second article (FormTest2) uses:

But when I test, the values on FormTest aren't passed across to FormTest2. What am I missing? I have $wgUseAjax=true; 60.240.122.215 01:48, 11 June 2008 (UTC)


 * Ah ha! worked it out. I need to disable form caching.  Silly me didn't think it through.  The values in FormTest2 and the other articles are hardcoded based on the parameters passed to them when they were last modified.  By adding $wgSimpleFormsEnableCaching = false; to LocalSettings.php, it refreshes each wiki page containing the form.  I also changed $wgUseAjax to false. 60.240.122.215 05:19, 11 June 2008 (UTC)

$wgUseTidy breaks form
Our form looks similar to:

It usually creates HTML that looks like:  ... 

Notice the two action attributes. It tends to work fine, with the first attribute being the valid one. However as soon as we enabled tidy, it broke:

$wgUseTidy = true; $wgTidyInternal = true;

HTML:  ... 

HTML Tidy removes the first repeated attribute, by default. The only way we got around this was to change the default HTMl Tidy configuration to keep the first repeated attribute:

$wgUseTidy = true; $wgTidyInternal = true; //Next line required to support Simple Forms via the repeated-attributes: keep-first directive $wgTidyConf = $IP.'/extensions/tidy/tidy.config';

tidy.config:
 * 1) html tidy (http://tidy.sf.net) configuration
 * 2) tidy - validate, correct, and pretty-print HTML files
 * 3) see: man 1 tidy, http://tidy.sourceforge.net/docs/quickref.html

show-body-only: yes force-output: yes ... fix-backslash: no fix-uri: no repeated-attributes: keep-first
 * 1) without the following, the action attribute is removed in Simple Forms

It seems broken that there are repeated attributes in the first place. Can anyone confirm this happens outside our environment? We're using Simple Forms 0.4.9, MW 1.12, PHP5. Cedarrapidsboy 15:23, 9 July 2008 (UTC)

Fatal errors
I can't seem to get this extension working. I get several, possibly, related errors:

At the bottom of every page I get: PHP Notice: Undefined index: SERVER_ADDR in C:\Inetpub\wwwroot\mediawiki\extensions\SimpleForms\SimpleForms.php on line 33

When I try to use some of the simple examples provided, I get a similar error. For example placing this is a div with id set to example3 on a page and then clicking the link, results in the div's content being replaced with:

Error: 500 OK (PHP Notice: Undefined index: SERVER_ADDR in C:\Inetpub\wwwroot\mediawiki\extensions\SimpleForms\SimpleForms.php on line 33 PHP Fatal error: Call to a member function getNamespace on a non-object in C:\Inetpub\wwwroot\mediawiki\extensions\SimpleForms\SimpleForms.php on line 454 )

I'd appreciate any insights into what might be going wrong.

I'm, running MediaWiki 1.12.0, PHP 5.2.5 (cgi-fcgi), MySQL 5.0.24-community-nt, on Windows 2003 R2, IIS 6.0. -- Aldaron 14:34, 11 July 2008 (UTC)
 * I patched this the other day, it shouldn't have that error any more --Nad 20:56, 12 July 2008 (UTC)


 * For the "getNamespace on a non-object..." error, see my hack/patch in section wfSimpleFormsAjax above --Danbrice 21:38, 4 September 2008 (UTC)

Replacing content problem
It's ok to create an article with

/index.php?title=test&content=test

but I can't change the content with /index.php?title=test&content=moretest

nothing happens. $wgSimpleFormsAllowEdit is set to true. --92.36.38.44 11:48, 5 August 2008 (UTC)

Always needful truncate objectcache and querycache tables
Hi Simpleformers!

I'm testing Simple Forms 0.4.10 on MediaWiki 1.11.2. I'm trying a simplified version of this example. The code is the next:

Newly created article will be shown here...

Because I got always UNIQ results, I went to mysql client and adopted Danbrice's suggestion: TRUNCATE TABLE objectcache; TRUNCATE TABLE querycache; It works fine, but after this, when I wrote something new in the textarea the result did'nt change. I typed again in mysql client the TRUNCATE statements, and the result changed. I included in function wfSetupSimpleForms in SimpleForms.php the next (and I added $wgDBprefix to global variables in the first line of function): $db =& wfGetDB( DB_MASTER ); $db->query('TRUNCATE TABLE ' . $wgDBprefix . 'objectcache'); $db->query('TRUNCATE TABLE ' . $wgDBprefix . 'querycache');

and it works finally fine. I'm not a programmer, and the question is: could this hack cause any problems? 91.82.176.117 23:26, 21 September 2008 (UTC)

A (hopefully) simple one
Hi,

i got SimpleForms to work but I wanted to create an "Create an Article"-form with multiple Input fields. These multiple fields concatented then should be my new article. How do I get this done as the request goes only for the element "content"?

Obvisiously i'm not really into programming.

Hope somebody can help me --84.153.180.176 15:31, 23 October 2008 (UTC)

Multiple ajax links in one line
I tried to create multiple ajax links in one line, but there are always paragraphs between every link. How can I fix it? my code: | | --193.29.115.50 14:45, 28 October 2008 (UTC)

Call to a member function getNamespace in User.php
Hello, I installed some extensions for DPL Calendar. When I add Simple Forms, I get the following error :

Fatal error: Call to a member function getNamespace on a non-object in .../includes/User.php on line 1771

I'm using MW 1.12. What can I do ?

something very basic is wrong, but what?
I installed this extension under mediawiki 1.10, enabled it in LocalSettings.php (yes, $wgUseAjax is set to true), and tried to run some test forms. Seems not to work at all. For example, if I try the replacement of the login form as listed as an example on the extension page, it get this as output:

�UNIQ6839055066cca6fc-iteme5c56e285acdf4 �UNIQ6839055066cca6fc-item10e09a931f171091 �UNIQ6839055066cca6fc-itemf46e8154ec56b45 �UNIQ6839055066cca6fc-item535d9fca633ef7 �UNIQ6839055066cca6fc-item32a21ca776fc4b4a �UNIQ6839055066cca6fc-item6900f8df4c9312a1 �UNIQ6839055066cca6fc-item2619e96e4d3886 �UNIQ6839055066cca6fc-item361288b64d6ea724

What the heck is going on? Thanks for any help Lexw 13:58, 26 November 2008 (UTC)

Can't get it to run. Please help!
After install, when I run the script I get:

Warning: Cannot modify header information - headers already sent by (output started at wiki/extensions/SimpleForms.php:1) in wiki/includes/WebResponse.php on line 10

I am using the current version of MediaWiki. 68.56.108.134 17:56, 6 February 2009 (UTC)


 * I changed the permissions on the file to 777. Now I get:

Parse error: syntax error, unexpected T_VARIABLE in wiki/LocalSettings.php on line 160

Allows blocked IPs to post
Please patch this so that it checks to see if a user is blocked before posting.

should change to: