Extension talk:Semantic Forms

Archives

2007 January to March 2008 April to June 2008 July to September 2008 October to December 2008 January to April 2009 May to July 2009 August to September 2009 October to December 2009 January to February 2010 March to May 2010 June 2010 July to August 2010 September to October 2010 November 2010 December 2010 January 2011 February to March 2011 April 2011 May to June 2011 July 2011 August to September 2011 October to November 2011 December 2011 January to February 2012 March 2012 April to June 2012 July to August 2012 September to October 2012 November to December 2012 January to February 2013 March to April 2013

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:

UPDATE page SET page_namespace=106 WHERE page_namespace=150;
UPDATE page SET page_namespace=107 WHERE page_namespace=151;

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

{{{for template|Issue|label=Issues|add button text=Issue toevoegen|multiple}}}
<table class="formtable">
<tr>
   <th width="100">Naam issue</th><td width="50">{{{field|Issuenaam}}}</td>
</tr>
<tr>
   <th width="600" colspan="2">Tekst</th>
</tr>
<tr>
  <td width="600" colspan="2">{{{field|Issuetekst|input type=textarea}}}</td>
</tr>
</table>
{{{end template}}} 

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)

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)

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:

{{{field|WpURL|default=http://en.wikipedia.org/wiki/{{PAGENAMEE}}|hidden}}}

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:

[<a rel="nofollow" class="external free" href="http://en.wikipedia.org/wiki/Test1">http://en.wikipedia.org/wiki/Test1</a> Test1]

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 <a></a> 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:

$default_value = $wgParser->recursiveTagParse( $sub_components[1] );

to:

$default_value = $sub_components[1];

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)

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 <div id="foo1">|placeholder=foo1</div> but since this didn't work I just duplicated the field definition - like so:

<div id="foo1">
{|
|-
! Foo1:
| {{{field|Anker|placeholder=foo1}}}
|}
</div>

<div id="foo2">
{|
|-
! Foo2:
| {{{field|Anker|placeholder=foo2}}}
|}
</div>

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)