Wikimedia Bugzilla is closed!

When the 'Semantic Forms permissions test' is not deleted, you get the warning 'This page already exists, but it does not use this form.' when creating a page using the one-step-process.

Hi - is the call to {{PAGENAME}} in the form or the template? And it might help to reproduce this problem on scratchpad.referata.com - I don't fully understand it.

Hi Yaron, indeed there is a call to {{PAGENAME}} in the form, which is the reason that the 'Semantic Forms permissions test' page has been created. 

In my wiki's I never let users choose the page name, but always use information that is entered on the form to assemble the page name. Default approach is that a field 'Name' is used for the name of the page with <unique number> in case a page with that name already exists. The name is always (also) stored in a property. 

In cases with a red link linking to a form, the name of the page is already determined and to make it easy to the user I want to pre-fill the 'name' field on the form with that value. That is why I had {{PAGENAME}} in the form. Then I found out that when there is no page name yet the name field was filled with 'Semantic Forms permissions test'. Accidentally the page was saved and deleted again. Then the problem described above occurred.

The problem can be solved to remove the 'Semantic Forms permissions test' page manually from the database and prevent creation, but I think it is a bug that the existence of that page disturbs proper functioning of the 'one-step-process'. 

I have reproduced the problem on the scratchpad. If you click on the button on [http://scratchpad.referata.com/wiki/User:AdSvS] you'll see what I mean. You'll see the message when 'Semantic Forms permissions test' exists. When you delete that page, you'll get the message that the page had been deleted.

Hi Ad - thanks for putting together the demo. I fixed the problem with the warning messages in Git, and that code is now on Referata as well. That just leaves the issue with why a page named "Semantic Forms permissions test" existed on your wiki in the first place. Did SF do that, or did you just create the page yourself? (You're allowed to do that, of course - I just want to know if this is another SF bug.)

Hi Yaron, I created the page myself, so no bug. I had a form with {{PAGENAME}} as default value in the 'Name' field with also the page name parameter set to that same field. When this form was opened while there was no page yet, the 'Name' field was filled with 'Semantic Forms permissions test' (that might be a bug?) and when I hit 'enter' the page was created.

Thanks for solving this issue so quickly!

Okay, cool. Yes, {{PAGENAME}} in the form, using the one-step process, will show "Semantic Forms permissions test"... I don't know if there's any way around that. Anyway, I'm setting this to "fixed".

When the form is first displayed, the "fullpagename" field contains "Semantic Forms permissions test"... i traced this down in SFFormPrinter.php , line 791, as being the string returned by

} elseif ( $sub_components[0] == 'default' ) {
    $default_value = $wgParser->recursiveTagParse( $sub_components[1] );

A RELATED issue is that the pagename field is "mandatory" however when no value is placed into the field, rather than "required entry" (sic) being entered, no error message at all is displayed... nothing happens when "save" (or "preview") is clicked.

Thanks!

Hi - I essentially have the same reaction here as I did to Ad's reporting of the issue: I don't know if there's any way around it. In the form, you have "default={{FULLPAGENAME}}" for that field, but no name has been set yet for that page, because the form uses the one-step process. Maybe the solution is just to remove that "default" value?

As for the "mandatory" thing - there's other strange stuff in that field tag, that may be causing the problem. (I hope that's the issue, anyway. :) ) You have "property=icom:name" and "type=string". There doesn't seem to be a property on your wiki named "icom:name", and there's no "type" parameter allowed for field tags.

wow thx for the quick reply. 

If the form is accessed from a forminput then the pagename is placed in the field correctly, so removing that default means the user has to retype, perhaps incorrectly, the name that was already entered, so I resist removing that.

Insofar as the mandatory issue, I fixed those items you noted (I was a little sloppy setting up the test) but the problems remain: save and preview buttons don't do anything, and there is no error message.

Thanks!

Well, it's strange to have a form that's meant to be accessed by both #formlink and #forminput - in one case, the "page name" field sets the page name, while in the other, it... doesn't do anything, as far as I know. For that matter, it's strange to have a "page name" field in the template. Why not just always use #forminput?

As for the other problem - I don't know if this is the issue, but now you have "input type=string"; "string" is not a valid input type.

Given the lack of response, I'm setting this back to "fixed"; feel free to re-open, although maybe a separate bug report would be preferable for whatever remaining issues there are.