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)


 * One of the drawbacks of the "pseudo-partial" forms approach is that when the form is used for the first time on a page the user gets the message Warning: This page already exists, but it does not use this form. Is there a solution to avoid this warning. The next time the form is invoked there is no message. Is you delete the data on the page managed by this form and you want to enter new data again, the message reappears. --Toine Schijvenaars (talk) 13:52, 28 June 2013 (UTC)


 * I just checked in a patch by Sebastian Richter that is supposed to solve the current issues with partial forms. If any of you are still reading this - please try it out, and let me know if it solves your problems. Yaron Koren (talk) 18:30, 3 July 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)


 * Not sure if that will work, I'm afraid, doesn't look like the form has any css class that it is possible to utilize (and in any case, what makes things more difficult is that I would like the layout do be different in the "additional query" and the initial query form. I've been looking into the code and seems like the problem is that the result template is processed by a call to Parser->parse which does html sanitizing (including closing open tags). Would it be possible to parse the entire page instead (both template and additional query form)?


 * I don't think so... the only solution I can think of is to add HTML "class" attributes in the relevant places, so that the display can be modified. Yaron Koren (talk) 18:33, 3 July 2013 (UTC)

Problem: Creating Page with Inherited Page Name via #formlink - Fatal error: Call to a member function exists on a non-object
What I am trying to accomplish here is: generating a page that has a button which generates a page with inherited qualities that I can then query on the same page.

[]

And this is from the template.

This is the error I get. Fatal error: Call to a member function exists on a non-object in /home/content/50/8262350/html/openthinklab/community/extensions/ SemanticForms/includes/SF_AutoeditAPI.php on line 674

It imputes the page name into the form no problem, but I would like to add a unique identifier or something similar that would allow me to then find and query it right away on the parent page. Anyone able to help? McDoku (talk) 11:09, 27 June 2013 (UTC)


 * Could you try if tis works in the last development version, please. I think I fixed this already. --F.trott (talk) 11:37, 27 June 2013 (UTC)


 * I just updated the extension to the lastest version from https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FSemanticForms. Same error occured.McDoku (talk) 12:07, 27 June 2013 (UTC)


 * Does the error occur on the same line as before? Because line 674 contains comment: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FSemanticForms/496eacae4e366ea0eaf91f02f6951ea579b1f52d/includes%2FSF_AutoeditAPI.php#L674 --F.trott (talk) 12:42, 27 June 2013 (UTC)


 * Apologies, my bad it is 679 now McDoku (talk) 13:23, 27 June 2013 (UTC)


 * Hello McDoku. We do the same thing on our Wiki. You just need to get the syntax right like this:


 * When I use your syntax I get the same Fatal error. Regards --Jongfeli (talk) 13:38, 27 June 2013 (UTC)


 * Perfect! Thank you very much! Sorry for the trouble McDoku (talk) 13:44, 27 June 2013 (UTC)


 * Ah, yes. Good that that's worked out. Still, SF should not just bail out, even if the page name is invalid. I'll fix it. Thanks for spotting this. --F.trott (talk) 14:12, 27 June 2013 (UTC)

Working with WikiDB extention
I'm using Mediawiki v1.16. I am wondering if there is a way to integrate between Semantic forms and the WikiDB extension.

I'll explain by simple example: I created a new semantic form called "Form:Books" which contain 2 fields: book number and book name. In addition, I created a related template called "Template:Books" and contain a simple tag that based on "Books" table (WikiDB table). Can I pass the form field and use it as a parameter for the repeat tag? In other words, I want to have a form that is based on a simple tables I defined under this WikiDB.

(booknum is the field name on "Books" table. booknumber is the field name on "Books" form): 

(I don't know if the above problem is related to wikiDB or SemanticForms. I'm trying to attack this on "both sides") TNX a lot.


 * I don't know the answer to this (and I don't know the WikiDB syntax), but my guess is no. Yaron Koren (talk) 18:18, 27 June 2013 (UTC)

Dynamically loaded subcategories can't be selected
I'm trying to use the categories input type. As I have a rather large category hierarchy I only want to show the top-level categories initially (using the depth parameter).

However, when I expand one of the categories, the sub-categories can't be selected. I assume this is because the regex processing of the html code done in SF_CategoriesInput.php is only done for the initial load. Would it be possible to hook into the ajax function and process the new subtree before it is shown? An alternative solution is to implement a new paramenter, displaydepth, which allows you to load all categories initially, but only show a part of it (looking into this now). Any ideas on what would be the best solution? MathiasLidal (talk) 20:10, 3 July 2013 (UTC)


 * Unfortunately, I don't think there's a good solution at the moment - the way the "category" and "categories" inputs are structured (derived heavily from the CategoryTree extension, and basically a hack), there's no way to have categories that are hidden but can then be expanded. It could be that the only solution is to do a rewrite of those input types - which is probably a good idea anyway. Yaron Koren (talk) 18:37, 3 July 2013 (UTC)


 * Ok, thanks for the reply. I might look into rewriting this sometime during the summer then. MathiasLidal (talk) 20:10, 3 July 2013 (UTC)

Some extra documentation
I started learning how to use SF and wrote down what I (think) that I learned. There is nothing new, but sometimes it helps to read a second text. The reason I started my own doc, is that learn when I write.
 * http://edutechwiki.unige.ch/en/Semantic_Forms

Maybe useful to be copied here (I changed the copyright to allow a simple cut/paste).
 * http://edutechwiki.unige.ch/en/Semantic_Forms#Form_input_types
 * http://edutechwiki.unige.ch/en/Semantic_Form_demo_page

For now, everything is in rough draft state and I am an absolute beginner. I will work on my pages as I learn more. Today I am starting a real project :)

Finally, I had trouble getting the category inputs to work, but now they do: This is my config file for MW 1.20.6: $wgUseAjax = true; require_once("{$IP}/extensions/CategoryTree/CategoryTree.php"); $wgCategoryTreeSidebarRoot = "Contents"; $wgCategoryTreeForceHeaders = true; $wgCategoryTreeSidebarOptions['mode']=CT_MODE_CATEGORIES; $wgCategoryTreeDynamicTag = false; $wgCategoryTreeDisableCache = false; $wgCategoryTreeMaxDepth = array(CT_MODE_PAGES => 2, CT_MODE_ALL => 2, CT_MODE_CATEGORIES => 3); The problem was a configuration issue. Basically, if it works in the sidebar, it should work with SF - Daniel K. Schneider (talk) 12:18, 4 July 2013 (UTC)
 * 1) Extension: Categorytree


 * Alright. In general, I think it's a bad idea to have more than one set of documentation for a piece of software, given that potential users can find the non-official ones with a web search, unless there's (a) some compelling difference between the different sets, or (b) some guarantee that the non-official documentation will be kept up to date. I also find the statement amusing that Wikidata/Wikibase is easier for end users to use than SF, but that's strictly a matter of opinion. Yaron Koren (talk) 22:39, 5 July 2013 (UTC)


 * In general, I agree. In our case there are three reasons (a) It's nice to have a ready text made oneself that one then can use to present in a class or a meeting. (b) I really don't feel confident about my understanding of SF and I do need to write things when I learn. I helps me to think. Doing that here would not be appropriate because you'd get really bad stuff at start. (c) I would NOT call our page a documentation of SF, it's more a kind of introduction with simplications, stuff missing etc. I clarified that in the beginning. Also, I have no clue about the ease of Wikidata/base (removed that bit). Finally, if we come up with something that we consider both safe and useful and missing here - e.g. a coworker is working on a diagram explaining SF - I'll copy it here:) - Daniel K. Schneider (talk) 10:00, 8 July 2013 (UTC)


 * Is this figure useful somewhere ? Its a simplification and again we don't feel so sure about semantic forms. Anyhow, its SVG can be edited with SVG-Edit.

- Daniel K. Schneider (talk) 17:29, 8 July 2013 (UTC)


 * Well, I certainly wouldn't begrudge anyone trying to learn how to use the software. Still, I think it would be good to have a disclaimer at the very top of the page, saying "This is not official documentation" or some such. As to that diagram - I would probably have a few things different if I were creating it, but maybe that goes without saying. Is it helpful to people trying to learn SF? I couldn't say. Yaron Koren (talk) 03:02, 9 July 2013 (UTC)

link type post button adds unwanted line break
I like the idea of useing link type=post button because it has to transfer a lot of data and one field could have line breaks, etc, but it adds an unwanted line break after the formlink call. Here is an example, http://cns.ath.cx/wiki/index.php/News and the template that has the formlink call is here http://cns.ath.cx/wiki/index.php/Template:Headline_Link_Date_Page_Description_Tags_Color

thanks

Updated I really dont like looking at the extra line breaks so I took it out for now. but take my work for it if I change the link type to link type=post button it adds an extra line feed and doesnt look right