Extension talk:Page Forms

Name Space
To make a former version of SF work with SMW prior to 1.8. I had the following namespaces defined in my localsettings: $sfgNamespaceIndex = 150; if (! defined('SF_NS_FORM')) define('SF_NS_FORM',      $sfgNamespaceIndex); if (! defined('SF_NS_FORM_TALK')) define('SF_NS_FORM_TALK', $sfgNamespaceIndex+1);

This seems to clash with the most recent versions of SF and SMW (which I'm running on MW 1.20.5), where in includes/SMW_setup.php the namespace is defined $smwgNamespaceIndex = 100; // 106 and 107 are occupied by the Semantic Forms, we define them here... define( 'SF_NS_FORM',           $smwgNamespaceIndex + 6 ); define( 'SF_NS_FORM_TALK',      $smwgNamespaceIndex + 7 ); define( 'SMW_NS_CONCEPT',       $smwgNamespaceIndex + 8 ); define( 'SMW_NS_CONCEPT_TALK',  $smwgNamespaceIndex + 9 );

At the moment this results in the 'edit with form' tab not showing up.

What do I have to change to make it work? Wiki is http://de.wiki-products.org/ Thanks in Advance --Francishunger (talk) 11:55, 8 May 2013 (UTC)


 * Hi - I think this change happened in SMW well before version 1.8, but anyway - there might be an easier way to do it, but the most straightforward way I can think of is to call two database queries, if you have direct access to the database:


 * Hopefully that will fix the problem. Yaron Koren (talk) 12:19, 8 May 2013 (UTC)


 * Thanks, Yaron. It worked very well. Still some links to forms do not work but for the moment I'll try to figure it out myself. It was indeed from a legacy version. I think the problem just appeared with the change towards the new database storage concept. Thanks again. --Francishunger (talk) 08:57, 9 May 2013 (UTC)

Edit Conflict
Hello,

I have a client that is getting a red error message on a new wiki page when she goes to save her data and there is an edit conflict. All her data is lost so I was wondering if there is a solution for an edit conflict other than navigating away from the forms that were just filled out.

The tab that is the problem on the wiki page is a form driven by a form template.

Thanks,

Margaret Lee --144.15.255.227 16:47, 8 May 2013 (UTC)


 * By "new wiki page", do you mean that she went to create a page, and someone else created a page with that same name between the time she started editing and the time she hit "save"? Yaron Koren (talk) 19:44, 8 May 2013 (UTC)


 * On our production wiki (MW 1.17.0, SMW 1.7.1, SF 2.4.2, PHP 5.2.14), if I click "edit with form" on a page, then someone else clicks "edit with form" on the same page and saves, and then I save after them, I get a page with red letters saying "edit conflict". If I hit the back button (even in modern browsers that tend to remember form state) it will reload the form with the new data (i.e. the data the person saved while I was still working). So I lose my changes.


 * On our dev wiki (MW 1.20.4, SMW 1.8.0.4, SF 2.5.2, PHP 5.4.7) if I do the same test, when I click save (after the other person has saved) I am brought back to the form with my data still intact, but without any indication that there was an edit conflict. If I click save again it overwrites the previous persons data without any indication that I performed the overwrite.


 * --Jamesmontalvo3 (talk) 20:36, 8 May 2013 (UTC)


 * Okay. So... which one are you complaining about? :) Or is it both? Yaron Koren (talk) 21:01, 8 May 2013 (UTC)


 * Let's call it feedback :) I was confirming what Margaret saw with the red "edit conflict" page. That was a major issue since you would lose data, but clearly it's already been fixed. Perhaps somewhere in the documentation it should be noted, but that's the best you can do for an old version, right? With the new version you don't lose data, and the intermediate editor will see that their data has been overwritten after the second save is performed. To improve the way it's handled, when you click save and you're brought back to the same form, perhaps put a line that says "Someone has edited this page since you started working in the form. Right-click View History and open in a new tab to see changes made." or something like that. For a more thorough solution perhaps you could bring up a diff of all changes made since you started editing. Making SF work with Extension:AjaxShowEditors could help reduce conflicts, too. --Jamesmontalvo3 (talk) 21:38, 8 May 2013 (UTC)


 * Thank you James for going into specifics. You have explained it like you have had the same experience.
 * If two people are editing the same form page, the person who saves first wins. The second person who saves is directed to a page with the words in red "Edit Conflict". So, is the answer update to MediaWiki 1.20? I am not sure if the extensions I use can move up to MW 1.20.
 * Thanks again,
 * Margaret--Amblerllc (talk) 01:44, 9 May 2013 (UTC)


 * James - okay, thanks for the suggestions. Perhaps with forms, unlike with the regular edit page, there's no ideal solution for this problem; but I'm glad to hear that it's at least working better.
 * Margaret - I think it's the updated Semantic Forms version, rather than the updated MediaWiki, that's responsible for the difference in behavior. Yaron Koren (talk) 13:29, 9 May 2013 (UTC)

Asking about header tabs
Hi Yarin, how are you?

Im using seantic forms with header tabs extension. I have a very long form, which I divided in 2 tabs, and wanted to give my users a help text, which basically explains how to fill the form, some sort of a help. For this, I created another tab, with name "How to fill this form?".

I would like if possible remove the "save" and "summary" and "minor" button from the "How to fill this form?" tab, but keep it in the other 2. Is there some practical way to do that?

Thanks a lot in advance, and thanks for a marvelous extension.

Chei.


 * Hi - I don't think there's any way to do that, unfortunately; you can have inputs in one tab, or under all of them, but not anything else. And thanks! Yaron Koren (talk) 21:41, 13 May 2013 (UTC)

Multiple-instance templates om MW 1.19.6 and SMW 1.17 and SF 2.3.2
Hi,

I use Multiple-instance templates in combination with subojects in a form. The form is straighforward

As is the template

{{#subobject:Issue_{{PAGENAME}}_{{{Issuenaam}}}
 * Paginanaam={{PAGENAME}}
 * Issuenaam={{{Issuenaam|}}}
 * Issuetekst={{{Issuetekst|}}}

This worked fine before we migrated to MW 1.19.6 (former version was 1.17.1). When I want to add an issue in this form, nothing happens. In the different browsers (Chrome, FF, IE10) I get the same error message.

mw.loader::execute> Exception thrown by ext.semanticforms.main:Object [object Object] has no method 'combobox' load.php:148

Does someone know the cause of this behaviour?


 * My guess is version incompatibility - you should upgrade SF to the latest version. Yaron Koren (talk) 12:33, 16 May 2013 (UTC)


 * It works fine now. But I get another problem instead. I use one and sometimes two different templates on one page. Both templates have their own form. If a form is used for one template, only the data of the template is saved which is part of the current form. The other data gets lost. --Tschijv (talk) 14:25, 28 May 2013 (UTC)


 * I think it relates to https://www.mediawiki.org/wiki/Extension_talk:Semantic_Forms#Partial_form_bug_in_SF_2.5.2 Because I also use a partial form. --Tschijv (talk) 14:40, 28 May 2013 (UTC)


 * Problem solved. I removed the partial form code.

{{{info|partial form|edit title=Cocreatie gegevens bewerken}}

Collaboration with "Proofread Page" extension
Is there any way to collaborate this extension with Proofread page extension? I need to get an image on the right side and semantic forms on the left. It is for the purpose of digitising a dictionary. Please help --Balasankarc (talk) 09:45, 16 May 2013 (UTC)

SemanticForms: Exclude special characters in #forminput
Hey, I've got a question concerning #forminput and would be pleased, if you could help me: I want to exclude special characters like "@" or "ä" from new form pages. Currently, I'm using #forminput (two-step-process) to enter a page name and create or edit the page. So, I avoid that an existing page will be overwrote. From the input form field ({{{field...) I know that it is possible to define regular expressions inside them. This works fine. Is it possible to use regular expressions in combination with #forminput as well? Or can you recommend other solutions to exclude special characters inside #forminput? Thank you very much in advance! BR AArnold


 * I don't think you can do that in SF, unfortunately. However, you may be able to accomplish the same thing in a different way by modifying $wgLegalTitleChars. Yaron Koren (talk) 18:09, 21 May 2013 (UTC)


 * This seems to solve my problem. Thank you very much Yaron!

problem passing a url string to template
I recently upgraded from MW 1.16 to 1.20 with associated php and extension upgrades. Not sure what the previous version of SMW and forms were but now they are latest.

There is a form which worked fine on the previous setup but now has a problem. It involves assigning a default value to a field in the form:

I've been tweeking spaces, pipes and parameter order to try to fix so the precise string that previously worked may have been slightly different. However, when the field value is passed to its associated template, it is converted into a full html style embedded url link in the form:

where 'test1' is the PAGENAME.

The behaviour can be seen here.

The associated template is here.

Any help/suggestions etc much appreciated. --Sabretache (talk) 19:50, 21 May 2013 (UTC)


 * Clarification: The form has other fields for manual completion/editing with standard url strings. These are passed to the template without conversion to the full html  format. The issue therefore seems to be connected with the 'default' parameter. --Sabretache (talk) 06:47, 22 May 2013 (UTC)


 * Yes, I remember looking into this issue a month or two ago. Unfortunately, I don't think there's any way around it - URLs in the "default" parameter just no longer work. Yaron Koren (talk) 13:28, 22 May 2013 (UTC)


 * It is clear that Mediawiki is simply converting a url string to an html link with the string as its name. This did not happen with my earlier installation. Neither does it happen when passing non-default url fields to the template. What is required is the ability to inhibit this conversion. I've tried various #NOWIKI and nowiki tags, including building the string from another template (that produces a very odd result which can be seen here), but all to no avail. Any chance this will be addressed in the near future? or is my only option to revert to an earlier release? --Sabretache (talk) 07:28, 23 May 2013 (UTC)


 * Actually, I think the simplest solution is to change line 828 of /includes/SF_FormPrinter.php from:


 * to:


 * As to whether this will be addressed, I don't know, but I hope so. Yaron Koren (talk) 12:08, 23 May 2013 (UTC)


 * Thanks Yaron. That works a treat. Your technical knowledge and willingness to help is very much appreciated. --Sabretache (talk) 19:44, 23 May 2013 (UTC)

Partial form bug in SF 2.5.2
Hi, we recently upgraded to SF 2.5.2 version and noticed that when saving partial forms, the entire page would get overwritten with just the partial form content (in our case this is only small part of the page). We did not have this problem with the previous version of SF using the same partial forms. We are use it as edit of page subtopic. Betwean main page form and subform edit areas are big free text area and after subform edit area are free text area. --Vpovilaitis (talk) 05:08, 22 May 2013 (UTC)


 * Partial forms in SF are barely maintained at this point, and they may be getting removed entirely in the not-too-far future. I would recommend switching to another solution, like "pseudo-partial" forms, that are standard forms, but only contain the subset of fields that you want to edit. Yaron Koren (talk) 13:31, 22 May 2013 (UTC)
 * But how I can change to the "pseudo-partial" forms solution, if my templates witch I wont edit is on free text and not on the begining of the article. This templates are not in the other template field. --Vpovilaitis (talk) 05:21, 24 May 2013 (UTC)


 * Can you explain why you have templates embedded within your free text? Are these SMW-based templates? Understanding that may help me to offer an alternate solution. Yaron Koren (talk) 16:11, 24 May 2013 (UTC)


 * In my site are several templates of articles. One type of article example is:

, chordinių (Chordata) tipo (Actinopterygii) klasės (Cypriniformes) būrio (Cyprinidae) šeimos (Ballerus) genties rūšis.

Free text

Išvaizda
Free text

Biologija
Free text

Mityba
Free text

Paplitimas
Free text

Free text

Literatūra
Free text

Nuorodos
Free text

Šaltiniai
In this example are is using one master form for editing complex "Auto taxobox" template. Partial form is are using for editing templates "Sins" and "ESinonimas". Template "Sins" generate special link for call this Partial form. --Vpovilaitis (talk) 05:41, 28 May 2013 (UTC)


 * That is a rather complex page structure. Depending on how consistent this structure is across all pages that use the "Auto taxobox" template, the planned addition of the may help somewhat, in allowing an entire page structure like this to be edited by a single form. For now, though, you may be better off reverting to your previous version of SF. Yaron Koren (talk) 15:30, 28 May 2013 (UTC)


 * Thanks. Revert to the previous version of SF I don't can. After upgrade MW inposible was create new Semantic forms, edit it and don't work several forms. Our site are very big ad we are using many diferens SF. There are bad idea, that is not suported "Up" compobility. I think that will be needed change master form, that with this form may be edit full article text and after that change all 400000 articles, that was used it. This is very huge work, and after that vill be needed other participants teach in new how use this form. --Vpovilaitis (talk) 05:40, 30 May 2013 (UTC)

Issue with "show on select"
Hi Yaron,

I want to use "show on select" to change the caption and the placeholder of a certain field. I tried something like  but since this didn't work I just duplicated the field definition - like so:

This works fine when displayed in the form, but unfortunately it generates two times the field "Anker" in my page. This is somehow logical since the id only makes the div invisible, the input is still there (two times in my case).

How can I solve this issue?

Thank you so much for your support!

Stefahn (talk) 10:43, 22 May 2013 (UTC)


 * Unfortunately, "show on select" can't be used for that purpose, of having alternate tags for the same field. I don't think there's a good solution to this problem - other than making that placeholder text be just standard text, outside of the form input. Yaron Koren (talk) 13:39, 22 May 2013 (UTC)

Use hook to show help box
Hi Yaron,

for user guidance I show a help box next to the edit window (see an example here). For showing the box I used the hook EditPage::showEditForm:fields - this works fine in usual editing mode. Now with SF's formedit the help box doesn't appear. Can I use a different hook and if yes which one? Thank you so much! Stefahn (talk) 21:47, 28 May 2013 (UTC)


 * I don't know - if you look through the SF code, you can find a lot of hooks, most of them called during the printing of a form - look for "wfRunHooks". One or more of them should work, I hope. Yaron Koren (talk) 01:23, 29 May 2013 (UTC)

#formlink broke with subtemplates after updating Semantic to 1.8
The following code worked just fine until I updated to the new version of semantic from 1.7:

Now it just redirects to the wiki's main page instead of the form for creating the specified page. The following code works just fine but doesn't do want I want:

Any ideas on how to fix this?


 * #formlink now requires names for all its parameters - my guess is that that's the issue. Yaron Koren (talk) 01:25, 29 May 2013 (UTC)


 * I tried switching it to
 * , but it still isn't working. Unixninja92 18:02, 29 May 2013 (UTC)


 * You need a "target=" value in there. Yaron Koren (talk) 18:50, 29 May 2013 (UTC)


 * That was it. Thanks for the help. Unixninja92 6:24, 30 May 2013 (UTC)

Custom buttons with WikiEditor in Forms
Same problem as "Custom buttons with WikiEditor in Forms". But I don't see generated textarea id's: 

How I can add custom buttons to the WikiEditor, witch is are used in SF. --Vpovilaitis (talk) 06:05, 30 May 2013 (UTC)

Empty Forms after CAPTCHA
Hello, when I enter content to my SF and hit save everythings works fine and all data appears on my template-created pages. But if there is a link within these fields (in my case an e-mail-address), there appears a new page with a CAPTCHA for spam-protection after clicking "save". Unfortunately all fields are saved empty after saving again with correctly solved CAPTCHA question. Is it a bug? Does anyone know this issue? Is there a solution/workaround? I am running MediaWiki 1.19.7, PHP 5.2.17 (cgi-fcgi), MySQL 5.1.58, SF 2.5.2 -- 141.35.213.221 07:04, 6 June 2013 (UTC)

Any ideas anyone?? I discovered, that it works, when enter data without a link (and without captcha) but change the entry afterwards by adding a mailing-Address. -- 141.35.213.221 07:26, 12 June 2013 (UTC)


 * Sorry I didn't respond before. There are some problems with the workflow related to saving in SF 2.5.2, as a result of changes made in order to remove the now-obsolete Sajax library. Stephan Gambke is working on fixing these, and hopefully everything will be working again soon. Yaron Koren (talk) 13:06, 12 June 2013 (UTC)

Issues with multiple-instance templates
Hi Yaron,

I found two issues with multiple-instance templates: Thanks, Stefan Stefahn (talk) 00:11, 12 June 2013 (UTC)
 * When using subobjects SF doesn't seem to recognize the property automatically (there is no autocompletion). I described a workaround here. Is this a bug or expected behavior?
 * Within the multiple form the text entered in  is not shown when hovering above the question mark (which is shown).


 * The first one sounds like a bug, yes, although it happens in a variety of circumstances - my recommendation whenever SF can't figure out what the relevant property is is to use "property=" (not that different from your "values from property=" suggestion). The second one is a known bug, due to some Javascript problem. Yaron Koren (talk) 01:49, 12 June 2013 (UTC)

Found two more bugs
Hi Yaron, hope I'm not bugging you ;) I found two more issues with SF (2.5.2) : Thanks for your feedback on this. Stefahn (talk) 09:06, 21 June 2013 (UTC)
 * Added wikitext in the system message Mediawiki:Minoredit is not parsed when using "edit with form" (it seems all special characters are escaped). If one uses "edit source" the wikitext is parsed correctly.
 * If I enter text into the summary field and then hit "show preview" the summary text vanishes.


 * Hi - thanks for the bug reports! The first one was fixed by Stephan in the latest Git code, and the fix will go into the next version. For the second one: I assume it's happening because your form definition does not contain a '&lt;div id="wikiPreview"&gt;' tag. If that's the case, and if you add one in, the problem should hopefully go away. It's still a bug, though, and it will hopefully be fixed at some point. Yaron Koren (talk) 17:02, 26 June 2013 (UTC)

Enclosing the "Additional query" in &lt;div&gt; block
I'm trying to make the "additional query" form line up the the result of the previous query. To do this I added a new &lt;div&gt; tag as the last line in the template displaying the query result. However, it looks like the parser closes all open tags before starting the "additional query" form.

I.e. My template ends with this line:

However, when looking at the resulting code I see the following:

Additional query    Is there any way to prevent the &lt;div&gt; from being closed automatically? Is a feature or a bug?

MathiasLidal (talk) 10:22, 26 June 2013 (UTC)


 * Whether it's a feature or a bug is a matter of opinion, I suppose. What do you mean by "line up the result"? Yaron Koren (talk) 17:04, 26 June 2013 (UTC)


 * I'm enclosing the query result in a &lt;div&gt; which is narrower than the wiki page itself. I would like the "additional query" form to have the same width, but the div is automatically closed and the form takes up the entire width of the page. Not sure if that made sense, I can probably try to set up an example (the actual page is on a company internal wiki) MathiasLidal (talk) 20:13, 26 June 2013 (UTC)


 * Ah, I see. Maybe it's possible to do that via CSS (placed somewhere like MediaWiki:Common.css) instead, rather than using divs? I'm not sure if it's possible, but I'd say it's worth looking into. Yaron Koren (talk)