Extension talk:Simple Forms/2008

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{{#dpl: namespace=Category|format=,\n*%TITLE%,,}} 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 .= "<option$sel>$opt</option>\n";

to

$input .= "<option$sel value=\"".str_replace('"','\"',$opt)."\">$opt</option>\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

{{#form}} and {{#input}}

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:

{{#form:
 [[My link]]!
 {{#input:type=hidden|name=title|value={{FULLPAGENAMEE}}}}
 {{#input: type = text|name = testme}}
 {{#input: type = submit|value = Go}}
 }}

does not display the link "My link", but the literal text [[My link]]. 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:

{{#form:
{{#input:type=hidden|name=title|value={{FULLPAGENAMEE}}}}
{{#input: type = text|name = foobie}}
{{#input: type = submit|value = Go}}
}}

{{#request:foobie}}

The {{#request:foobie}} 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 <section> 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:

{{#form:
{{#input:type=hidden|name=content|id=new}}
{{#input:type=hidden|name=title|value={{FULLPAGENAME}}}}
{{#input:type=hidden|name=caction|value=append}}
{{#input:type=hidden|name=regexp|value=<section begin=example \/>.*<section end=example \/>}}

Edit Value: {{#input:type=text|id=edit}}

{{#input:type=ajax|value=Update Extension|update=update-me|onClick=
document.getElementById('new').setAttribute('value', '<section begin=example />' +
document.getElementById('edit').value + '<section end=example />');}}}}

<br />
<span id="update-me"><section begin=example />1234<section end=example /></span>

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 <[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

)

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:

{{#form:method=post|
  {{#input:type=hidden|name=title|value=FormTest2}}
  <table>
    <tr><th>STR:<td>{{#input:type=text|name=STR|size=3}}
    <tr><th>SIZ:<td>{{#input:type=text|name=SIZ|size=3}}
  </table>
  {{#input:type=submit|value=Proceed}}
}}

The second article (FormTest2) uses:

{{#form:method=post|
  {{#input:type=hidden|name=title|value=FormTest3}}
  <table>
    <tr><th>STR:<td>{{#input:type=text|name=STR|size=3|value={{#request:STR}}}}
    <tr><th>SIZ:<td>{{#input:type=text|name=SIZ|size=3|value={{#request:SIZ}}}}
    <tr><th>DmgBonus:<td>{{#input:type=text|name=DmgBonus|size=3|value={{#expr:{{#request:STR}} + {{#request:SIZ}} / 2}}
  </table>
  {{#input:type=submit|value=Proceed}}
}}

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:

{{#form:method=get|action=http://someserver/common/utils/ToolsDBSearch.jsp|
...
   {{#input:type=submit|value=Search}}
}}

It usually creates HTML that looks like:

<form method="get" action="http://etiweb/common/utils/ToolsDBSearch.jsp" action="/wiki/index.php" id="sf-4874d38920275" name="sf-4874d38920275">
...
<p><input type="submit" value="Search" /></p>
</form>

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:

<form method="get" action="/wiki/index.php" id="sf-4874d38920275" name="sf-4874d38920275">
...
<p><input type="submit" value="Search" /></p>
</form>

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:

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

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

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

{{#input:type=ajax|format=link|update=example3|content=[[foo]]|THREE}}
<div id=example3>''this is a '''div''' with '''id''' set to '''example3'''''</div>

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:

{{#form:
    {{#input:name=content|type=textarea}}
    {{#input:type=ajax|value=Create|update=result}}
}}
<div id="result">''Newly created article will be shown here...''</div>

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)

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)

Allows blocked IPs to post

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

if ($wgSimpleFormsAllowEdit && ($allow || $wgUser->isAllowed('edit'))) {

should change to:

 if ($wgSimpleFormsAllowEdit && ($allow || ($wgUser->isAllowed('edit') && !$wgUser->isBlocked()))) {