Extension talk:Page Forms

Break between allowed values
In a form I want to have the checkboxes among each other. How does it work?


 * Do you mean you want them to display like a list, instead of in a wrapping line? Badon 20:43, 2 January 2012 (UTC)


 * I'm not sure I understand the question, but this might help. Yaron Koren 23:48, 2 January 2012 (UTC)


 * It helps! Perfect! Thank you!

Templates only at entered values
My form refers to two templates.

Is it possible that the templates only come into effect if the user has entered a value?

Example: In the form I ask for an author. But my users doesn´t select an author.

Now I want that the line:

Author: disappears in the articles.

80.149.179.2 13:30, 4 January 2012 (UTC)


 * That doesn't sound like a form issue - but you can use #if in the template for that. Yaron Koren 13:38, 4 January 2012 (UTC)

Edit with form tab; based on namespace
Hello,

i want to use the Edit with form tab, based on namespace in the Main namespace (german: "Seiten"?).

How i have to name the article with this text:  has default form::Test 

I thought: "Meta-Pagename":Seiten, but that does not work.

With the namespace "Hilfe" it works...

Thank you!


 * I'm not sure, but try "Project:Main". Yaron Koren 14:27, 5 January 2012 (UTC)
 * No, that also does not work...


 * Sorry for the long delay - it turns out that the German translation you should use is 'Startseite'. Still, the word "Main" should also work - that's a bug. Yaron Koren 16:57, 10 January 2012 (UTC)


 * Now, we have change the default language from "de" to "en" and now it does work with "Project:Main"

Replicating section edit edit summary
A nice feature I think would be to replicate the automatic edit summary which is included upon normal section editing, but which would be included for Semantic Forms based upon which field is updated, if it were one field. I know for me that would really help out with tracking revision histories and what was updated, since section editing is not possible. Thorncrag   19:07, 5 January 2012 (UTC)


 * I doubt that's possible - with regular MediaWiki editing, it's known in advance which section the user is editing, but with a form, you don't know which fields they've edited until the moment they hit "save". Yaron Koren 19:20, 5 January 2012 (UTC)

PAGENAME magic word not displaying in forms
When any of the family of magic words ( ,  , etc) are used in a form definition, they are not displayed in the form. However, other magic words, such as and , display in the form just fine.


 * What versions of SF and MediaWiki are you using? Yaron Koren 13:46, 9 January 2012 (UTC)


 * Thank you for your reply. I am currently running MediaWiki 1.17, SMW 1.6.1, SF 2.3.2 -Jay


 * This should definitely work in 2.3.2. Is your wiki public somewhere or could you reproduce the problem on http://scratchpad.referata.com ? --F.trott 09:00, 10 January 2012 (UTC)


 * Not working for me either...
 * I am using: MediaWiki 1.18.0, PHP 5.3.8 (cgi-fcgi), MySQL 5.5.19, Semantic Forms (Version 2.3.2), Semantic MediaWiki (Version 1.6.1). My wiki is behind VPN, but everything works as expected in Scratchpad Trial -- SJR


 * I experienced similar results after upgrading to SMW 1.7; however, does function in scratchpad forms: [Example] -Jay

Editing a form places the template above all section headers
Consider the following scenario where you have a template contained between section headers such as the following:

=Header 1=

=Header 2=

Next, using the 'edit with form' option, you make modifications to the input parameters referenced in the template. Upon saving these changes, the wiki formatting is spit out like this:

=Header 1=

=Header 2=

Is there a way to keep the template between those headers and still use the 'edit with form' option?

Thanks in advance. Morguen 14:42, 9 January 2012 (UTC)


 * No, unfortunately - you can do something like that with partial forms, though it won't be with the "edit with form" tab - it would just be a link on the page. A true solution for this would involve editing of sections - see here. Yaron Koren 16:30, 9 January 2012 (UTC)

Dealing with the "Preview box" white background
I'm using a heavily modified Vector skin with dark background and white font and when I preview my forms the preview comes with a white background, making the font simply unreadable. I've done some research and I found where it is located HTML wise:

Note that I've not pasted all the code but more or less that should be some help. Reading the last div we find this:

This is the only clue i've been able to find so I assume that is the source of my problems, but after lurking each single (.php and .css) file from the whole extension I wasn't able to find anything. I would like to provide more information, screenshots or links but I'm under a contract and I'm not allowed to unveil the content of the wiki yet. Does anyone know how to get rid of that white background? 79.148.8.127 02:16, 12 January 2012 (UTC)


 * Forgot to say that I'm using SMW v1.6 and SF v2.3.1 79.148.8.127 02:29, 12 January 2012 (UTC)

Warning message when including
Hello everybody,

I'm about to upgrade SemanticForms from version 2.0.9 to 2.3.2 and noticed some strange behaviour that I couldn't understand even after browsing to the responsible source code.

Basically, I have a query form included into a portal page by means of  . When the portal page loads, the warning This page already exists, but does not use this form gets displayed above the form.

What is puzzling me is that I used the same construct under version 2.0.9 and the warning never showed up then. The responsible code is at line 1509 in SF_FormPrinter.php (in version 2.3.2):

// Add a warning in, if we're editing an existing page and that // page appears to not have been created with this form. if ($this->mPageTitle->exists && ( $existing_page_content !== '') && ! $source_page_matches_this_form ) { $form_text = "\t". ' ' . wfMsg( 'sf_formedit_formwarning',        $this->mPageTitle->getFullURL ). " \n\n". $form_text; }

This code is identical in version 2.0.9 and I didn't find significant difference in the way the flag $source_page_matches_this_form is set before reaching above code. Nevertheless the warning does show up under version 2.3.2 but not under 2.0.9. I could workaround this issuing by adding the condition !is_query to above if-clause but I'd prefer to learn what else I'm doing wrong or whether this is a bug.

I appreciate your help. Many thanks in advance.

OUA 11:39, 12 January 2012 (UTC)


 * Yes, this seems to be a new bug. I've seen it, too. Incidentally, I suppose you mean not  . Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 13:09, 12 January 2012 (UTC)


 * Actually I really had the latter in my wikitext but it doesn't seem to make a difference. Correcting it to the former didn't change the situation. OUA 13:18, 12 January 2012 (UTC)


 * Hi, sorry about that - this was fixed in SVN, but I haven't released a new version yet since then. You can see the fix here (it's exactly what OUA proposed) - if you apply that same change, the problem should go away. Yaron Koren 13:27, 12 January 2012 (UTC)

Wysiwyg support
Hi, I would like to have wysiwig editing in free text in forms. Here it says that the FCKEditor extension can do the trick, but that extension is obsolete and seems to be 'replaced' by the WYSIWYG extension.

What should I do?

Thanks! AdSvS 15:08, 12 January 2012 (UTC)


 * In my opinion, for people using MediaWiki 1.18 and higher there's no good WYSIWYG solution at the moment, and there might not be until VisualEditor is completed, maybe by the end of 2012. The best approach I know of at the moment is to use the WikiEditor extension. Yaron Koren 02:45, 13 January 2012 (UTC)


 * That is a pity, although the Visual Editor is of course a very good initiative. What would you advise if wysiwig is important? Go back to MW 1.17 and use FCKEditor? AdSvS 09:18, 16 January 2012 (UTC)


 * Yeah, that's the only solution I know of, short of fixing FCKeditor to work with MW 1.18. Yaron Koren 13:31, 16 January 2012 (UTC)

Forms no longer loading
At Bugzilla, User:Badon has posted a critical bug report about forms which refuse to load in the latest version, SF 2.3.2. The bug appears to be triggered by the presence of section headers in a form. I assume Yaron is already aware of this, but maybe others have been hunting in vain for similar reports on this issue. Just so you know. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 19:49, 12 January 2012 (UTC)


 * Cavila - does this happen on your wiki as well? Yaron Koren 14:14, 17 January 2012 (UTC)


 * I've more than one wiki, but yes, it happens on a private wiki of mine (ignore the info in my signature, which is relevant to another website). Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 20:31, 17 January 2012 (UTC)


 * Ah, okay - what version of PHP is running on that wiki? I'm guessing/hoping 5.2. Yaron Koren 21:25, 17 January 2012 (UTC)


 * Yes it is, see my answer on Bugzilla. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 17:56, 22 January 2012 (UTC)

Editing already created templates/Adding "
Additional Information== to free text ==

Hi, I've created some forms and templates, I would like to know how to edit these if I need to add more property fields.

Also is there a way for the free text section to automatically add "==Additional Information==" to the top so it looks neater when a page is created.

Thank you in advance!


 * You can set that text in a "default=" or "preload=" parameter for the free text tag. Yaron Koren 05:26, 15 January 2012 (UTC)

Thank you so much! This really helps! My biggest question now is where I can I set the default or preload parameter? This also goes back to my, where can I edit forms/templates I've already created?

Thank you again!


 * Well, clearly it hasn't helped yet. :) Look for the "" tag, and you can change it something like " "", and then you can create a page called "Free text preload" containing the text "==Additional information==". Sorry, I missed your first question - there's no way to automatically edit them, unfortunately; you would have to do it by hand. You could try out the Page Schemas extension, though - it's intended to allow automatic editing. I don't think it allows for setting free-text parameters yet, though. Yaron Koren 22:06, 15 January 2012 (UTC)

Yaron, Thank you so much for the help again, Because I'm dense I still don't get one thing and I would like to ask but I appreciate the help. I don't know where to manually templates or forms. For instance in the book example, what if two weeks down the road I decide I need to add ISBN and price as a property. How can I manually edit the template to reflect that?


 * Each template and form has its own wiki page - if you look in "Recent changes" you can probably see where those pages are. Yaron Koren 17:20, 16 January 2012 (UTC)

Fatal error: Cannot redeclare class SFUploadWindow2 in (path to file) SF_UploadWindow2.php on line 1117
I reported this issue last month, and ultimately removed all SMW-related extensions to try fresh installations. Still getting the same error message. The only clue I might offer is that I was experimenting with SMW+ a couple of months ago before ultimately removing it, clearing out the DB and installing MediaWiki / SMW instead. Is it possible that some extraneous bit of stuff stayed stuck in the MySQL DB even though I dropped all the tables?
 * Installed software
 * MediaWiki 	1.18.0
 * PHP 	5.2.17 (cgi-fcgi)
 * MySQL 	5.1.39-log


 * Installed extensions
 * Semantic MediaWiki (Version 1.7.0.1)
 * Nuke (Version 1.1)
 * Renameuser
 * ParserFunctions (Version 1.3.0)
 * ConfirmEdit (Version 1.0)
 * Gadgets
 * Validator (Version 0.4.14 alpha)
 * Vector (Version 0.3.0)
 * WikiEditor (Version 0.3.0)
 * --Davydog 02:01, 15 January 2012 (UTC)


 * Hi - no, this isn't a DB issue. The file SF_UploadWindow2.php was removed from Semantic Forms a few weeks ago, in SVN, since it was no longer necessary - so if you can get the latest version, it could be that that will just fix the problem on its own. Otherwise, I really have no idea... Yaron Koren 05:29, 15 January 2012 (UTC)


 * Did as you advised. Installed  from SVN checkout. Now getting this:
 * One thing I keep forgetting to mention: up to now I've triggered each error only after clicking on the  menu item. Otherwise the wiki seems to function normally. Don't know if that sheds any light...
 * --Davydog 02:03, 16 January 2012 (UTC)
 * --Davydog 02:03, 16 January 2012 (UTC)


 * I really have no idea. I would try commenting out all the extensions except for SF and seeing if that makes a difference, and if it does, re-installing them one by one until you find the culprit. Yaron Koren 03:28, 16 January 2012 (UTC)

Bug when creating form from template
Has any one else have this problem with the extension? After I create a form from a template, everything will look good, except the second text field label will take on the name of the last field label. Every other field is properly labeled. Not a huge deal because it's easy to manually fix it, but it hasn't happened on every form, so I was wondering if anybody else noticed it.Lost Student 09:00, 15 January 2012 (UTC)
 * I'm not sure if I understand you correctly, but it sounds like you have some duplicate in your template or form. All field names should be unique. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 10:07, 15 January 2012 (UTC)
 * That's the thing--all the field names are unique in the template. When the extension creates a form from the template, one of field labels (and only the label--field names remain correct) was not correct.


 * The crazy thing is that it doesn't happen every time; in fact it only occurred twice. (The first time it happened, I chalked it up to user error, but then it happened again on another template, leading me to believe it is a bug.) Am I the only one it happened to?Lost Student 23:56, 19 January 2012 (UTC)


 * Hi - this has happened to me too. :) It's definitely a bug in Semantic Forms, but I never bothered to try to fix it. I should. Yaron Koren 02:46, 20 January 2012 (UTC)

Depth parameter to Category tree on autocompletion
This is wanted feature. My category tree grows very large. Hence it would be desireable to limit the initial display to first two levels. The CategoryTree extension already provides parameter depth. However, this not supported in SemanticForms. Could this be added? There was a discussion in June already. Tomaschwutz 19:43, 17 January 2012 (UTC)


 * Hi - that's a very good idea, and it was surprisingly easy to implement. I just added it to the Semantic Forms code in SVN. Yaron Koren 18:48, 23 January 2012 (UTC)

Two feature requests for query forms
Hi Yaron, the query forms are among the most useful innovations that I've seen from the SMW family. Do you think the following two features are feasible?
 * 1. Especially in the case of queries, it would make sense to have a reset button which clears all the input fields. Would it possible for you to create and add an optional reset button, e.g. one specified by a 'standard input' tag?
 * 2. I know that preloading data is already possible through URLs, but it comes with many limitations (try property values with spaces, for instance). What about enabling this functionality in an embedded format like ?

All the best, Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 18:34, 22 January 2012 (UTC)


 * A "reset" button sounds like a reasonable idea. For spaces and the like in query strings, you can always use the URL-encoded value - try replacing " " with "%20", for instance. Yaron Koren 20:42, 22 January 2012 (UTC)


 * For enabling spaces in Special:RunQuery or any other combination, you can use  which does the input encoding for the strings selected. In your case  convert's into bla+bla+bla which Special:RunQuery does understand. --MWJames 23:10, 22 January 2012 (UTC)


 * Thanks, and thank you both for the tips on writing URLs. While I still think some cleaner looking syntax would be friendlier to the average user, this works for me. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 08:10, 23 January 2012 (UTC)


 * Probably the ideal solution for this, by the way, would be to either modify #formlink, or have something analogous to #formlink (#runquerylink ?), that would link to Special:RunQuery. It seems to me like overkill at the moment, but who knows, maybe it makes sense. Yaron Koren 19:13, 23 January 2012 (UTC)


 * I would like the idea of a #runquery parser function as it would reduce some hustle with the form parameters for the Special:RunQuery. Right now, any RunQuery form has an corresponding template that converts all parameters and create a Special:RunQuery link. --MWJames 00:54, 24 January 2012 (UTC)

Bug
Hello,

if I want to edit with form, I get the bug you can see bellow.

Can me help someone?

We use also the extension BlueSpice. Is that the reason of the bug?

Meldung: Das Objekt unterstützt diese Eigenschaft oder Methode nicht.

Zeile: 54

Zeichen: 54

Code: 0

URI: ....wiki/load.php5?debug=false&lang=de&modules=ext.semanticforms.autogrow%2Cfancybox%2Cimagepreview%2Cmain%2Csubmit%7Cjquery.checkboxShiftClick%2Cclient%2Ccookie%2Cplaceholder%7Cjquery.ui.autocomplete%2Cbutton%2Ccore%2Cmouse%2Cposition%2Csortable%2Cwidget%7Cmediawiki.language%2Cutil%7Cmediawiki.legacy.ajax%2Cajaxwatch%2Cwikibits&skin=bluespice&version=NaNNaNNaNTNaNNaNNaNZ

Thank you! Speedtook 12:32, 31 January 2012 (UTC)


 * Hi Speedtook, could you set debug=true in that URL and open it in Firefox? What's the error message there? --F.trott 12:50, 31 January 2012 (UTC)

Anyway to use tags in text properties?
I'd like to use tag-based extensions in the contents of text properties, but when I try that I get an exclamation mark viewing the page, instead of the property value.

I know that it's not the usual way to use SMW, but in our case I have a text property whose content may be related to some pages in our intranet. To ease thinks for users, I've created a tag-based extension to receive a parameter and return an URL pointing to the desired location. Works like a charm in usual MW pages, but don't work when used in property values like the example below:

Could anybody help me getting this to work? Or is this usage not allowed in SMW?

I have no problem when I put the link directly in value (with smwgLinksInValues enabled), and I'm using MW 1.17.

Thanks, Matheus Garcia 14:43, 1 February 2012 (UTC)


 * This isn't really a Semantic Forms question, but anyway - try using #set instead of the brackets notation to store the value - maybe that will work. Yaron Koren 15:38, 1 February 2012 (UTC)


 * Thanks, Yaron! But I enter values using a semantic form, which is tied to the template I mentioned. The value of property myproperty is filled into a textarea on the form. How could I used #set in that case? Matheus Garcia 10:54, 2 February 2012 (UTC)


 * You'e entering the values using a form, but that's irrelevant - the problem is in the template itself. And the #set call should be in the template, replacing the current setting of that property. Yaron Koren 15:43, 2 February 2012 (UTC)

Preloading data into multiple instance template
I'm trying to preload data into a form containing multiple instance template (in this case, the target page already has existing instances of this template). The behavior I was expecting was to see a new form instance automatically appear with the pre-loaded data. What I am seeing is the data pre-loaded, but I have to manually click the "Add another" button to see it.

Related, if I want to use a formlink to create a new instance, is there any way just to show the form fields for the new instance template and not the pre-existing instance templates?


 * That first one is a bug, although in general preloading data for multiple-instance templates doesn't work very well. And unfortunately, there's no way to do the second. Yaron Koren 21:20, 1 February 2012 (UTC)

Suggestion
Maybe, it would be interesting having a parameter to the  tag that restrict the input of some characters. For instance, an "onlynumbers" parameter or something like that.

Or something like this page: Special:BookSources where when you put the ISBN with "-": 978-1-4200-9050-5 MediaWiki removes the "-" and delivers 9781420090505. | Jaider Msg 22:49, 2 February 2012 (UTC)


 * Hi - the first one is already possible with the 'regexp' input type, from the Semantic Forms Inputs extension. The second one might be a bad idea - I've tried to structure Semantic Forms to never alter the user input. But you could have the template itself remove the dashes, using a string function... Yaron Koren 03:41, 3 February 2012 (UTC)