Extension talk:Simple Forms/2007
2007
editActually work?
editDoes 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?
editAnything 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
editWhat 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)
- 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)
- 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)
Ajax configuration
edit$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??
editVersion 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)
- 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)
use tables for widget arrangement
editAs 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 [1].
- 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:
<table style="width:auto"> <tr> <td>'''Test'''</td> <td>{{#form:{{#input:type=text|name=test}}}}</td> </tr>
The form is rendered as "action="/wiki/index.php" id="sf-46efb375c8fcf">
after the text-entry field. —Eek 11:18, 18 September 2007 (UTC)
- There was a bug preventing a form from having only a single input item in it, which is fixed now (version 0.3.10). --Nad 21:02, 18 September 2007 (UTC)
- Thanks; that fixed it. —Eek 21:41, 18 September 2007 (UTC)
Error Message
editI get an error message after i have installed per the instructions: Undefined index: action in ... SimpleForms.php on line 106. Any idea as to what might cause that?
- It's because you've got your PHP set to super-pedantic, so that trying to read array entries that don't exist raises an error instead of returning a default null result. I've made a minor update which should fix it. --Nad 22:08, 2 August 2007 (UTC)
- What about the fatal error above? -Eep² 04:49, 3 August 2007 (UTC)
AJAX-enabled Simple Forms with WikEd - having a problem
editI've set up my MediaWiki to utilize WikEd, but when I enable Ajax with motools, a line of text appears between MediaWiki's edit buttons and WikEd's edit buttons that just repeats the word "undefined" over and over again (trailing off the right side of the window). The cursor changes to the "link hand" icon when rolling over it, but the link simply points to http://mySite/undefined. When I disable WikEd or AJAX for simple forms, the text goes away. It appears to be some conflict between the javascript libraries - maybe an overloaded variable or function? Everything works fine though - but I can't leave that string of text there for everyone to see. Any ideas? — Preceding unsigned comment added by Funnyman22 (talk • contribs) 14:46, August 20, 2007
- I have this same problem but just with Simple Forms installed and Mootools enabled with it. See http://www.organicdesign.co.nz/Talk:Extension:SimpleForms.php#Bugs for more info. —Eep² 01:30, 21 August 2007 (UTC)
- I just upgraded to MediaWiki version 1.11 and the problem seems to be resolved. Give it a try. Funnyman22 20:56, 12 September 2007 (UTC)
- That undefinedundefined problem is a bug in wikibits.js prior to MW1.10, see Mootools --Nad 22:11, 12 September 2007 (UTC)
- I just upgraded to MediaWiki version 1.11 and the problem seems to be resolved. Give it a try. Funnyman22 20:56, 12 September 2007 (UTC)
Page creation bug
edithello, i have tested the extension and i am very happy with it. But I have a problem that it is not possible for me to create new articles.
Also the test Blog example doesn't work on my wiki. I can only post comments with this form when there is already a discussion page, otherwise nothing happens. ----stp-- 13:36, 20 July 2007 (UTC)
- I'll get these bugs fixed as soon as I get some time. --Nad 21:19, 20 July 2007 (UTC)
- Thanks, I will be very grateful If you can fix this bug. Please post here a comment if you have solved the problem ----stp-- 07:28, 23 July 2007 (UTC)
Hi, I have some problems to create a new page. The extensions works (BlogExample) but I can't create a new page. Can you submit a short example how to do? The form should be in Template and the page should go to the namespace KB: Thanks
- There's a bug with the page-creation currently which I'll look into as soon as I get some time to work on it again. --Nad 02:29, 24 August 2007 (UTC)
- The page-creation bug has been found and fixed. --Nad 11:48, 27 August 2007 (UTC)
Creating new page (part2)
editHello,
Could you give me an short example how to create a new page? Unfortunately with the examples I'm stuck (ok I'm a newbie). I only need 2 fields and the text from one of them should be the title of the page but it should also appear as text in the body
Thanks --DJO 83.135.249.174 12:47, 28 August 2007 (UTC)
- If you just want to make a link that creates a new page with the content being the same as the title, the URL of the link can be:
/wiki/index.php?title=foo&content=foo
- A slightly better way of generating the url which is independent of wiki configuration is
{{fullurl:foo|content=foo}}
- If the URL needs to be done using Ajax, then have a look at OrganicDesign:Blog example which creates a new page if it doesn't exist or edits it if it does. --Nad 19:55, 28 August 2007 (UTC)
- Thank you for the explanation but I didn't get the trick. Let us take the blog example. I have put this in a template called Template:New3. In this template you have the possibility to enter a heading and other information. When the user has filled out the fileds and click the submit button a new page should created in another namespace where the title of the page is the value from the Heading field. The data from the Heading field should be also (and the rest) as text in this new page. The namespace I can change, not the problem. But what is the following parameter? You have in the example Talk:{{PAGENAMEE}}. What is the trick to change this?
- See OrganicDesign:Create article example for the simplest way of creating a new article with SimpleForms, also you should probably download the latest version as some minor bugs have been fixed which may affect it. --Nad 13:03, 29 August 2007 (UTC)
- Now it woks as I want. Thank you very much for your help
- See OrganicDesign:Create article example for the simplest way of creating a new article with SimpleForms, also you should probably download the latest version as some minor bugs have been fixed which may affect it. --Nad 13:03, 29 August 2007 (UTC)
- Thank you for the explanation but I didn't get the trick. Let us take the blog example. I have put this in a template called Template:New3. In this template you have the possibility to enter a heading and other information. When the user has filled out the fileds and click the submit button a new page should created in another namespace where the title of the page is the value from the Heading field. The data from the Heading field should be also (and the rest) as text in this new page. The namespace I can change, not the problem. But what is the following parameter? You have in the example Talk:{{PAGENAMEE}}. What is the trick to change this?
Selected select
and other input types
edit
How can I get a select
list option to be selected by default? Also, a checkbox checked by default, radio button selected by default, default text in a textarea, etc. —Eep² 04:38, 4 September 2007 (UTC)
- Set the value property in a select list to the default value. Same with radio and checkbox.
Multiple values with Select input
editHow can I receive multiple values with an input field of type Select? With option "multiple=1" several values can be selected but only the first item in the list is always passed over e.g. to an evaluating java expression (such as "document.getElementById('SeveralValues').value").
- Multiple selects aren't done yet. --Nad 07:42, 14 September 2007 (UTC)
- That response implies that multiple selects will be available at a future point, which given the following response about multiple same-name parameters makes me curious:
- It's unlikely that multiple parameters of the same name will ever be supported as it means the query string can't be mapped to a hash table
- First, how are multiple selects going to be supported if multiple same-name parameters aren't? Second, why can't the query string be mapped to a hash table? It's how php handles query parameters. When multiple same-name parameters exist it's just mapped to an array that contains all the values assigned to than parameter name. —Sledged (talk) 05:46, 9 December 2007 (UTC)
- I see what you're saying now, the query-string example you supplied should have used []'s to show that you were talking about a single array value, not multiple single values of the same name. Multi-selects will be supported when I eventually get some time. --Nad 21:20, 9 December 2007 (UTC)
- GET requests represented as URLs don't use []s, and I was using the URL as a direct link to prove the point I was making. —Sledged (talk) 04:59, 10 December 2007 (UTC)
- I see what you're talking about, now. I didn't realize php handled multiple same name parameters differently than most others. I got a mod so that the extension has support for multiple selects. Mind if I apply it to the displayed code on OrganicDesign? —Sledged (talk) 07:38, 2 March 2008 (UTC)
- GET requests represented as URLs don't use []s, and I was using the URL as a direct link to prove the point I was making. —Sledged (talk) 04:59, 10 December 2007 (UTC)
- I see what you're saying now, the query-string example you supplied should have used []'s to show that you were talking about a single array value, not multiple single values of the same name. Multi-selects will be supported when I eventually get some time. --Nad 21:20, 9 December 2007 (UTC)
- That response implies that multiple selects will be available at a future point, which given the following response about multiple same-name parameters makes me curious:
Form failure with IE
editHi Nad! The form stored here can work with firefox but has malfunction with IE. I don't know what is the cause. Could you give me a hand?--Roc michael 12:51, 17 September 2007 (UTC)
- The only windows machine I have is running IE7 and the form looked the same as on firefox. There seems to be a problem though because it's showing an unmatched double-brace below the form, and yet all the brackets in the wikitext match. I'd suggest asking Gero if he would upgrade to the latest version as he's running a version that's a couple of months old and some of the bug-fixes since then may solve the problem. --Nad 21:43, 18 September 2007 (UTC)
- Thanks! Nad. It's works with both IE and FF.--Roc michael 14:13, 19 September 2007 (UTC)
- Good error spotting - I used a test-editor with matching-bracket-highlighting and still missed that mistake! It would still be a good idea to upgrade though as quite a few bugs have been fixed since 0.3.3 --Nad 21:47, 19 September 2007 (UTC)
- Thanks! Nad. It's works with both IE and FF.--Roc michael 14:13, 19 September 2007 (UTC)
Produces Entities If Used in an #if condition
editGot the login example working nicely, but placing it inside an #if condition to detect if the user was logged in or not caused the form html to be produced with entities instead of tags, so i saw in the browser what i wanted in the source.
-129.12.38.148 15:29, 17 September 2007 (UTC)
- I need to redo the way it renders to allow forms to work inside other parser-functions, this is a priority though so hopefully will be fixed soon. --Nad 21:05, 18 September 2007 (UTC)
Other submission input types and "select" lists
editIs there a way to have an input type other than a button act as a submission method? Specifically, I want to create a select list that updates another select list based on the first select list's selection. Is this possible with Simple Forms currently?
- I'll make a dynamic select-list example at some stage, mean time you should be able to add some javascript to the select's onChange event --Nad 21:51, 19 September 2007 (UTC)
I also want to allow for multiple select lists (like Semantic Forms can do--but preferably without requiring a template for each field) that will be automatically named ("select1", "select2", etc) as they are created (and removed if not in sequence, renaming/reordering apporpriately) without having to resort to long lists of checkboxes, radio buttons, or multi-select lists (because I want a text-entry field for each single selection).
Thanks —Eek 21:44, 18 September 2007 (UTC)
- Multi-selects aren't done yet --Nad 21:51, 19 September 2007 (UTC)
textarea cols not applied
editAdding parameter cols=30 to {{#input:type=textarea}} does not result in correct sizing, and instead fills textarea to full measure. Problem exists on two separate installations, mediawiki v1.7 at work (Apache2 on Solaris 10) and mediawiki 1.10 at home (Apache2 on Kubuntu 7.04). Can set textarea using cols using straight html coding outside of wiki framework, and sizing is set correctly. Viewing source code of wiki created page shows cols=30 is set is being set as part of <textarea>. Note there is no problem with the rows parameter. Testing browsers included FF2 on Linux & Windows, and IE7 on Windows. Any suggestions what is causing cols to not work inside the wiki framework? Thanks in advance. --Jace
- Problem solved! /wiki/skins/monobook/main.css has a definition for textarea with width=100%. Now to see what that effects if commented out. -- Jace --70.41.141.252 03:40, 21 September 2007 (UTC)
- Better Solution: Do not comment out width=100% in main.css. Instead, add "style=width:auto" as a parameter to {{#input --Jace--70.41.141.252 05:09, 21 September 2007 (UTC)
{{#input:type=textarea|cols=30|rows=2|style=width:auto}}
What's new in Version 0.3.11
editHi Nad. Tall us in the Change log, Please :-). Thank you!--Roc michael 01:43, 22 September 2007 (UTC)
More page creation issues
editHow do I get a form to create a page and then, upon editing that page, call all those form values back into the form for editing (like Semantic Forms does)? —Eek 11:28, 22 September 2007 (UTC)
- You can use SimpleForms to create a form as an interface to templates within an article as in the OrganicDesign:Updating template articles with an Ajax form example, and that kind of form-to-template integration will be made easier to implement in the next version, but there are no plans for SimpleForms to hook in to the edit action in the way SemanticForms does. --Nad 11:53, 22 September 2007 (UTC)
- Is there an easier way without having to duplicate every template value when saving? That seems really tedious--especially since my form will have at least 77 parameters and it's bad enough having to create separate form (input) and template (output) pages... —Eek 21:04, 22 September 2007 (UTC)
- What do you mean by "duplicate every template value when saving"? if you're referring to the difficult syntax involved in that form-updating example, then yes there will be a much easier way in simple forms 0.4 which is already done but has a bug which I haven't been able to find yet, so should be ready soon. --Nad 21:27, 22 September 2007 (UTC)
- I'm referring to this line:
{{#input:type=ajax|value=Save|update=contact-form |onClick=document.getElementById('xc-content').setAttribute('value','{'+'{ExampleContact\n|name='+document.getElementById('xc-name').value+'\n|phone='+document.getElementById('xc-phone').value+'\n|address='+document.getElementById('xc-address').value+'\n}'+'}');}}
- As you can see, this is only for a mere 3 parameters; imagine how long it would be for 77! :/ Hopefully the "much easier way" can automatically pull in the form's parameters without having to manually specify each one when saving/updating... —Eek 07:40, 23 September 2007 (UTC)
- Yip, that's what I thought you must have meant, 0.4 will not require any script to be added for each property, it will just be a single form attribute allowing it to post the values into directly into the template. --Nad 07:54, 23 September 2007 (UTC)
- OK, sounds good, but will it require each form element/control to have an "id" instead of just a "name"? Seems like the ID is redundant since each element/control has a unique name anyway (or can, at least). —Eek 14:40, 23 September 2007 (UTC)
- It works such that every input in the form is mapped into the specified a template in the specified article apecified by the title input, but I'll also allow an attribute to be added to an input to say not to map it into the template (and some names automatically won't such as action, caction etc). Also, I'm checking out if I can use MW's Ajax functionality so it doesn't need to rely on Mootools, but I don't know about that yet. --Nad 21:28, 23 September 2007 (UTC)
By "'title' input" do you mean "'name' parameter"? Cuz I don't know of any "title" parameter. I just want it to be as simple as possible--hence the extension's name. If the form could also act as the output page, that would save having to recreate the design in a template, and allow all the formatting in the form itself, then allow/disallow editing appropriately (which Semantic Forms does by disabling form fields while still showing them). —Eek 23:08, 23 September 2007 (UTC)
- Every SimpleForms form must have an input named title (usually a hidden input, but in the case of the name/address example above it's a dropdown list) which is the article that the form will be posted to. The form is a separate article to the template used in the article it updates. --Nad 00:15, 24 September 2007 (UTC)
DynamicPageList2 and MW1.11
editHi guys! Im trying to get the code example at link Ajax Form to work. I have tried both options eg.
{{#form:style=width:400px| {{#input:type = hidden | name = content | value = {{#dpl:category={{#request:cat}}}} }} {{#input:type = select | name = cat | *Select category {{#dpl: namespace = Category | mode = userformat | listseparators = ,\n*%TITLE%,, }} }} {{#input: type = ajax | value = List members | update = listcat-result}} <div id="listcat-result">''No results to display...''</div> }}
and
{{#form: {{#input: type = hidden | name = content | value = {{#dpl:category={{#request:cat}}}} }} {{#input: type = select | name = cat | *Select category {{#dpl: namespace = Category | mode = userformat | listseparators = ,\n*%TITLE%,, }} }} {{#input: type = ajax | value = List members | update = listcat-result }} }} <div id="listcat-result">''No results to display...''</div>
What I have tried/done:
1. Installed SimpleForms.php 2. Installed Mootools with Ajax selected. 3. Installed DynamicPageList 4. Apache has full rights to the js file 5. Done all LocalSettings mods
The page I added this code on was just any page. I wanted to check if all and newly created categories were being read into the combo box, and they are. The problem is with the "List all members" box, when you click on it.
When I click on it, I get the following Error details....
Line: 164 Char: 1 Error: Object expected Code: 0 URL: http://localhost/mediawiki/index.php/Example001
Example001 above is the page I have placed this form onto.
Here is part of my LocalSettings.php entries..
$wgUseAjax = true; $wgAllowUserJs = true; include("$IP/extensions/SimpleForms/SimpleForms.php"); $wgSimpleFormsUseAjax="$IP/extensions/mootools.v1.11.js";
Interestingly, the page loads fine with no errors even if I type in a dummy path to mootools.v1.11.js, so I dont even think this is being referenced. There has to be some issue here. Whether I comment out the mootools reference above or not in LocalSettings.php, when I click on the List Members button, I get the error as mentioned above. Any help would be great, as I think this form is really good! Thank you. —58.175.32.115 15:20, 24 September 2007 (UTC) I tried to load it directly into my skin file as follows:
<script type="text/javascript" src="/mediawiki/extensions/Javascript/mootools.v1.11.js"></script>
This time, if I put a faulty path in the for mootools js file, I get:
JavaScript Error: Description: Object doesnt support this property or method. Line 251.
If I put in the correct path, and I click on List Members, I get no error, but I get no results listed on the page...that is...nothing after I select a category.
- There may be a number of problems here, but the first one I see is that you should have $IP in the value of $wgSimpleFormsUseAjax. It should be set to the relative URL of the mootools script - i.e. the path that you can get to it from your browser from by appending it to you domain name in the address bar. Get the path right in the browser first and then put that in to $wgSimpleFormsUseAjax. --Nad 21:13, 24 September 2007 (UTC)
Hi Nad thx for your help :>) I tried:
Firstly I tried: $wgSimpleFormsUseAjax="http://localhost/mediawiki/extensions/mootools.v1.11.js"; Then tried: $wgSimpleFormsUseAjax="/mediawiki/extensions/mootools.v1.11.js";
No luck. Ive tried this on 2 different systems now and both have the same result. I dont get an error message with:
$wgSimpleFormsUseAjax="/mediawiki/extensions/mootools.v1.11.js";
but get no div results when click on List Members.
- Can you retrieve the mootools script directly from the browser? if not either you're not specifying the correct path, or it's permissions are not set correctly. Once you can retrieve it into the browser use the part of the address after the domain including the leading slash as your $wgSimpleFormsUseAjax value. But you must ensure that yo can read it from browser first. --Nad 23:36, 24 September 2007 (UTC)
Hi Nad!
Mate yes I can. If I type in:
http://localhost/mediawiki/extensions/Mootools/mootools.v1.11.js
I get the popup asking me to save the file mootools.v1.11.js. I also get the error when clicking on List Members. I checked the permissions on the file. [root@localhost Mootools]# chown apache.apache mootools.v1.11.js [root@localhost Mootools]# chmod 0777 mootools.v1.11.js [root@localhost Mootools]# ls -ltra mootools.v1.11.js -rwxrwxrwx 1 apache apache 43715 Sep 25 00:16 mootools.v1.11.js [root@localhost Mootools]# pwd /var/www/html/mediawiki/extensions/Mootools
Updated path for $wgSimpleFormsUseAjax is: $wgSimpleFormsUseAjax="/mediawiki/extensions/Mootools/mootools.v1.11.js";
Nad Im using script:
{{#form:style=width:400px| {{#input:type = hidden | name = content | value = {{#dpl:category={{#request:cat}}}} }} {{#input:type = select | name = cat | *Select category {{#dpl: namespace = Category | mode = userformat | listseparators = ,\n*%TITLE%,, }} }} {{#input: type = ajax | value = List members | update = listcat-result}} }} <div id="listcat-result">''No results to display...''</div>
Nad not getting an Error now when I click on List members, but not retrieving any div results.
Nad I havent got a reference as far as I know, in any css file for id=listcat-result. Would this have something to do with it?
When I click on List members, the "No results to display" disappears but I dont get any results back when selecting a category with articles.
- I'm running out of ideas here, but one thing is that having the div content replaced with an empty result is a good sign, it means that mootools is working, but the content it's getting back from the server is blank.
Do you have all the categories in the drop-down list properly? and what happens if you make an article containing this,
{{#dpl:category={{#request:cat}}}}
and then go to that page with cat=some-category-with-stuff-in-it in the query-string? --Nad 01:51, 25 September 2007 (UTC)
- Which MooTools script are you using? There are various compression versions. I had trouble with the fully compressed one and had to use the regular (full code with comments) in order to get Simple Forms to work correctly. —Eek 03:21, 25 September 2007 (UTC)
Hi Nad, I hope ive done your tip correctly :>)
I created a blank page called http://localhost/mediawiki/index.php/Place
I put in this page:
{{#dpl:category={{#request:cat}}}}
I then went to this page as follows:
http://localhost/mediawiki/index.php?title=Place&cat=hi%20there
Result returned was:
%DPL-1.4.1-WARNING: No results!
My apologies take 2. Just worked out what you meant Nad (dumb me!).
I had a category called Category:NewOne, with one page in it called Testt.
So I did the following Nad....
I created a blank page called http://localhost/mediawiki/index.php/Place
I put in this page:
{{#dpl:category={{#request:cat}}}}
I then went to this page as follows:
http://fire/mediawiki/index.php?title=Place&cat=NewOne
Result returned was:
Testt
So it returned the right stuff here! Dont know why this is working but my original question isnt.
In the above, I put a faulty path to mootools and it still worked.
Hi Eep! Version of mootools im using is mootools.v1.11.js.
I have tried mootools by just selecting Ajax, and selecting everything, and with no compression.
I dont think mootools is working at all here, even though i have the right paths below.
include("$IP/extensions/SimpleForms/SimpleForms.php"); $wgSimpleFormsUseAjax="/mediawiki/extensions/Mootools/mootools.v1.11.js";
This is driving me nuts (moreso than normal). Is there any way, out of the below code...
{{#form:style=width:300px| {{#input:type = hidden | name = content | value = {{#dpl:category={{#request:cat}}}} }} {{#input:type = select | name = cat | *Select category {{#dpl: namespace = Category | mode = userformat | listseparators = ,\n*%TITLE%,, }} }} {{#input: type = ajax | value = List members | update = listcat-result}} }} <div id="listcat-result">''No results to display...''</div>
To test just the line:
{{#input: type = ajax | value = List members | update = listcat-result}}
- You could replicate the OrganicDesign:Ajax links example on your wiki which deals specifically with the Ajax aspects of SimpleForms and doesn't use any forms functionality. --Nad 04:51, 25 September 2007 (UTC)
Thanks Nad. Ill give that a go, but I think I might just pass now on DynamicPages and SimpleForms after this. Thanks for your help! :>)
Getting SimpleForms to work
editHaving played around for some time with the instructions I finally got this great extension working. The key change I had to make was putting
$wgUseAjax = true;
before
include("$IP/extensions/SimpleForms.php");
In a nutshell this is how I installed it:
- Don't bother with mootools as it isn't needed
- Download SimpleForms.php and place in the extensions folder
- Add the following code towards the end of localsettings.php in the order shown and save the file
$wgUseAjax = true; include("$IP/extensions/SimpleForms.php");
- Create an article called SimpleTest and paste the following code into the article:
{{#form: {{#input:name=title|value=Enter article title}} {{#input:name=content|type=textarea|Enter some content}} {{#input:type=ajax|value=Create|update=result}} }} <div id="result">''Newly created article will be shown here...''</div>
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
editIt 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 OrganicDesign: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 OrganicDesign:Ajax.js then there occurs following error
- I created an article at OrganicDesign: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)
- 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)
- Yes, it only occurs, when I use a SimpleForm with ajax-functionality and the error occurs in mediawiki's ajax.js
- 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)
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?
editI 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
editHi 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
editWarning 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 array_key_exists('action', $_REQUEST)
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?
editAfter reading this, I wasn't sure if there is a workaround for using tables to align form input fields nicely, as in:
Your name: | [ input box goes here ] |
Your number: | [ input box goes here ] |
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 <tr>, <td>, </tr>, and </td> 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
editLooks 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)
- worked for me. —Sledged (talk) 20:48, 1 March 2008 (UTC)