Summary: Talk page for PmForm.
Maintainer: Petko
Users: +5 (View / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.


Good recipe, but there is a problem when placing

 ( :pmform  comments where=above: )

in GroupFooter: new comments are being put at the top of the page whatever 'where' is selected. But I want to put them in the bottom of the page. Is it possible? --Finar June 01, 2020, at 11:09 AM

Try where=bottom. Above or below are in relation to the position of the (:pmform...:) directive and there is clearly no such directive in the page (it is in the footer, ie another page). --Petko June 01, 2020, at 11:27 AM

Solution found (possible bug): when (:pmform comments where=above:) is placed in GroupFooter, the 'where' param stops working... In this case you can still define the place to post comments in your #talkpost template like this: (:template defaults where=bottom:) Finar June 02, 2020, at 12:27 PM

It is not a bug, it is implemented this way -- documentation updated. --Petko June 02, 2020, at 03:18 PM

PmForm removes a line in some circumstances

When I use the following markup on a page, then edit and save it using a PmForm that updates the Description and Summary page text variables, the line following "Summary: test:)" is removed. If "Summary: test" is not the last line of Description, then it works correctly.

(:pmform savemyexample:)

(:Description: This illustrates the problem

Summary: test:)
=](:comment --- THIS LINE GETS REMOVED ---:)
(:Summary: Illustration of how PmForm removes a line:)

-- RandyB November 12, 2014, at 01:32 PM

You have 2 PTV definitions both named Summary. I'm not sure how such cases could be handled/decided automatically. To prevent the error, you can use at the place not to be updated either lowercase "summary:", or "Page Summary:", or "Summary:". --Petko November 12, 2014, at 02:40 PM

I understood that PmForm was supposed to update the ptv directive if one is present, ignoring non-directive PTVs. If only non-directive PTVs are present, then it will update the last one it encounters and ignore the others. (E.G. See comments below from February.)

I can't really tell beginning users "Don't ever put a capitalized word followed by a colon on the last line of a multiline field when using a form" - even I may forget.

The worst part is that if a user forgets, then the escape markup that allows the multiline PTV to exist will be removed, and the page will then be corrupted. The user won't see the corruption, because it doesn't happen immediately. When the user puts "Summary: …" in the form field, the page saves everything correctly (because "Summary:…" will not exist on the page until the page is saved), and the page thus appears normal. The page is only corrupted the NEXT time the page is edited via PmForm. That next unsuspecting user will be totally confounded.

-- RandyB November 12, 2014, at 04:46 PM

Are pmwiki's and pmform's PTV parsing consistent?

Suppose a user enters this line on a page:

MyPTV: This is my original value for MyPTV

Another user enters the following line and forgets to remove the above:

MyPTV: This is now the correct value for MyPTV

Shouldn't pmform's input control (:input textarea $:MyPTV cols-60 rows=3:) refer to the same MyPTV as other PmWiki markup? I've had the experience of pmwiki and pmform referring to different ones on the same page.

- RandyB February 05, 2014, at 12:19 PM

This should be fixed in PmWiki 2.2.67, but PmForm may still change the incorrect PTV when updating. Please test the latest version 20140212 with $EnablePmFormUpdateReverse = 1; in config.php. --Petko

I downloaded version 2.2.67 of PmWiki and 20140212 of PmForm, both for the first time. With $EnablePmFormUpdateReverse not enabled, PmForm now updates and PmWiki displays the last instance of the PTV. When set to 1, however, PmForm updates the first instance of the PTV, while PmWiki still displays the last instance. Setting the flag thus doesn't seem useful, since the behavior becomes inconsistent between PmForm and PmWiki. -- RandyB August 03, 2014, at 11:49 AM


Is PmForm compatible with blocklist?

I've tried using PmForm to add comments and to update page text variables, but even if I set $BlocklistActions['browse'] = 1; it still lets me enter phrases that are successfully blocked when entered via the edit form. If PmForm doesn't support blocklists, what would be a good workaround? For example, would it work to create an action such as action=postdata that would be required before displaying the form, and then adding that to BlocklistActions? - RandyB December 24, 2013, at 11:47 AM

If Blocklist is enabled, it should work out of the box with PmForm -- if it doesn't, I'll have to review it. The latest PmWiki version allows to check for blocked words with any posted field, just use $BlocklistActions['pmform'] = 1; to enable it. --Petko December 25, 2013, at 11:16 AM

I upgraded to pmwiki-2.2.58, and also added $BlocklistActions['pmform'] = 1; to my config. The edit action still blocks, while pmform doesn't. Note that my URL does not specify an action, if that matters. - RandyB December 25, 2013, at 02:17 PM

It works for me, without adding $BlocklistActions - a word that is in SiteAdmin.Blocklist cannot be posted in a comment via PmForm, try to insert a comment or update a form containing one of the blocked words here. What can I do to replicate your behavior and review it? --Petko December 25, 2013, at 03:45 PM

Thanks for showing me. I have pushed a change in Subversion which should fix this (only blocklist.php changed) - if you can, please test it and report. --Petko December 25, 2013, at 06:55 PM

Older comments

How do I update a page's change summary when posting using PmForm? PmForm does not update the change summary when it writes to a page - which I suppose is a reasonable design. However, that means the page's change summary may be out of date. Could someone clearly document how to update csum when posting via a form other than EditForm, with sample code that isolates what needs to be done?

The latest version should update the edit summary if the posted form contains a field named 'csum' (and will not if there is no such field). It may be an (:input text csum:) or (:input hidden csum "Value":) or empty (:input hidden csum "":) field. Please report if it works. --Petko April 13, 2013, at 12:26 PM

The testing I've done so far works beautifully. Thanks for the update. I'll let you know if I run into problems. -- RandyB April 14, 2013, at 01:06 AM

How to keep page PVs when posting? I'm trying to integrate this recipe to add comments functional to my pages. The only thing I need is to let my anonymous site's visitors add comments to pages. The problem is that posting this form deletes my Page Variables, existed on the page before. For example I have PV ctime and author and title, all of them are overwritten after posting: ctime and title become deleted, author overwrites with name provided by poster. I want all these fields to keep intact, and just add something like

-> Posted by {$$guest} on {$$CurrentTime}

to my page content. What is the best way to do it? --Finar

Should this recipe be modified so it uses the SiteAdmin group by default? --Hagan

Is there a way that I could create a form that would allow people to self register for a login/password combo via PMWiki? If so, how would I that? Thanks, Chris 8-26-08

Here's a partial answer: I am allowing "members" to use PmWiki's built-in AuthUser + .htpasswd authentication and the cookbook recipe to change their own passwords -- and it works, although I have not enabled public registration for a password for the site I'm using it on right now. I'm not using PmForm for this feature. The site is still in testing/development or I'd provide a public link -- but you wouldn't see anything except a normal login form since I haven't enabled public registration for an account. XES August 20, 2014, at 08:33 AM

There's a major bug with radio buttons and checkboxes where the displayed value is inverted, e.g. if the value is (:somevar::) then it will show as ON (ticked); if (:somevar:on:) then it will show as OFF (unticked). Try this

In your config:

$PmForm['Worksheet'] = 'saveto={$FullName} form=#dataform_Worksheet fmt=#datapost_Worksheet';

In your Site.LocalTemplates:

(:input pmform target=Worksheet :)
(:input default source={*$FullName} :)
(:input default request=1 :)
* (:input checkbox $:var_ws_idea :) Compelling Idea
* (:input checkbox $:var_ws_premise :) Premise
* (:input text $:var_ws_thetext :) The Text
* (:input radio $:var_ws_radio1 :) radio 1
* (:input radio $:var_ws_radio2 :) radio 2

(:input submit value="Save Changes" :)
(:input end:)

(:template defaults savevars=$:var_ws_idea,$:var_ws_premise,$:var_ws_thetext,$:var_ws_radio1,$:var_ws_radio2 :)

And in your page where you want the form:

(:pmform Worksheet:)

On the page, set the checkboxes in various combos and you'll see they get inverted after clicking the 'save changes' button.

Andrew Ferguson, September 2014 (fergicide at gmail dot com). Note, this bug has existed for more than 4 years.

This is by design, so not a bug but a feature. PmForm does not update a PTV in the page if the browser doesn't post such a field. In your examples, unchecked checkboxes or single unchecked radio buttons are not posted by browsers when the form is submitted, so the PTVs are not updated. Try using couples of same-name radio buttons like (:input radio $:r1 on:) yes (:input radio $:r1 off:) no or select drop-down boxes instead of checkboxes. --Petko September 28, 2014, at 10:39 AM

Thank you, Petko! Following your advice, I've got the radio buttons working :-) - Andrew Ferguson

Talk page for the PmForm recipe (users).