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)