Extension talk:Page Forms

Dropdown doesn't autopopulate when editing a page & Foreign letters in values
There is an old unsolved question dating back to 2008 which describes perfectly what i am encountering right now.
 * For example, if I have a template with parameters A, B and C. If A and B are text boxes, and C is a dropdown. On the form, I put in values for A, B and C. If I then Edit using form, based on what I just made, it seems to erase entered C and makes it blank again, but A and B retain their values.

This is true if the value that gets blanked contains a foreign-language letter (e.g. ä/ö/ü etc.) In my case i have city names in field C. e.g. 'Berlin' and 'München'. When Berlin was saved and i edit with form everything works well. If i saved München before the field gets blanked. The values are populated from properties. Dating back to May there was a question/bug that had problems with fields popolated from categories with umlauts. Is this problem also true for dropdown inputs using Properties as source? Is this issue already fixed? The version i must keep using is Version 1.3.6 cause due to Company regulations i may not touch even a single line of code. Is there any workaround for such a issue? -- Regards Christian Tasler 195.88.117.31 14:35, 1 July 2011 (UTC)


 * Well, your company's regulations make no sense - there are known bugs, including security bugs, in the version of SF that you're using; it's in no way better than the current version. But to answer your question - no, I don't know of a workaround. Yaron Koren 03:05, 3 July 2011 (UTC)


 * Yeah, but thats not mine to change. As it is used internally only the security risc was evaluated and accepted by our it-security department. What a pity you dont have a workaround, so i have to cope with that bug till i get a version where it is fixed. By the way, as you didnt say anything about it, it is fixed in the more current versions, isnt it? -- Christian Tasler 84.168.124.250 22:25, 6 July 2011 (UTC)


 * I don't know - I assume it has, since the bug was reported three years ago... Yaron Koren 03:01, 7 July 2011 (UTC)

Minor edit setting not processed using Edit with Form, if FCKeditor is enabled
Just upgraded to 2.1.2. Very nice that NORICHEDITOR is parsed now, among other good things.

Seems that the flag for the user setting to mark an edit as minor per default is not processed when FCKEditor is enabled (tested on fckeditor 2.6.6 and 2.6.4, running MW 1.15) if you use 'edit with form' and have a freetextfield, and fckeditor enabled.

Maybe you could take a look at in for upcoming versions. I hacked it by adding an  clause in SF_FormUtils.php, but alas I'm no mediawiki wiz, so I wont be submitting that ;-)

--Ovoned 11:06, 2 July 2011 (UTC)


 * I can't reproduce that problem - maybe it's been fixed in SF 2.2 already (to be released soon); or maybe it's only a problem with MW < 1.16 - in either of those cases, I'm not worried about it. Yaron Koren 03:02, 4 July 2011 (UTC)


 * -OK, I checked out 2.2 today and see that this has indeed been fixed in SVN.
 * Though I cannot get SF 2.2 to work on MW 1.15.3 /SMW 1.4.3. I get: Fatal error: Class 'Html' not found in C:\xampp\htdocs\mediawiki\extensions\SemanticForms\includes\SF_FormInputs.php on line 798. Seems to be the call to   at the end of getHTML function. Any ideas? Nevermind, I switched html::hidden to xml:hidden, that solved it --Ovoned 08:37, 4 July 2011 (UTC)


 * Thanks for pointing out that MW 1.15 incompatibility - I fixed it in the code that's now in SVN. (Though that doesn't change the fact that you should upgrade your versions of both MW and SMW. :) ) Yaron Koren 02:03, 6 July 2011 (UTC)

Fancybox upload form redirects to plain form
Hey, I'm having the same problem as mentioned in this thread in the archives, when I click on the 'upload file' link in a semantic form, an empty fancybox comes up and then finally redirects to the plain uploadwindow form.

A page where this happens would be this page. I've tried the vector skin just to make sure that ain't related to the gumaxdd skin we're using. I'm on REL_1.16, revision 91358 for MW and the latest trunk of SemanticForms.


 * There was just a note added about this to the documentation recently - this can be caused by having "$wgBreakFrames = true" in LocalSettings.php. Is it possible that you have that? Yaron Koren 03:07, 3 July 2011 (UTC)

Multiple instance templates and radio buttons
I just noticed when using multiple instance templates which includes a field with a radiobutton input type it will only accept ONE entry. I am finding it a little hard to explain in detail, but I made an example here. If you notice, when you select an option from the second set of radio button field the selections from the first set dissappears. I hope this helps. --Dgennaro 20:11, 5 July 2011 (UTC)


 * Hi - I can't reproduce this, not even on IE... everything seems to work fine. What's the exact set of steps you go through on that form before the problem happens? Yaron Koren 02:12, 6 July 2011 (UTC)


 * So strange. What version of IE are you testing with? Poop, it is probably an IE7 thing. No special steps, just having a radio button reoccur using a multiple instance template. --Dgennaro 14:40, 6 July 2011 (UTC)


 * Ah, that must be it! I was testing with IE8. I did a web search, and it looks like this might be the issue - dynamically-inserted radio buttons aren't checkable. If that's the problem, it turns out that there's a Javascript workaround for it; but of course it's easier for me to recommend to just use dropdowns instead. :) Yaron Koren 14:53, 6 July 2011 (UTC)


 * That is my plan. Thanks for working this through with me. --Dgennaro 15:26, 6 July 2011 (UTC)

Possible Solution to: Info tooltip does not work in multiple instance templates
This entry just moved to the archives: Extension_talk:Semantic_Forms/Archive_May_to_June_2011

Hi Shirl, I also stumbled upon this problem with in multiple-instance templates using Semantic Forms (Version 1.9) and found that I had erroneously declared the templates as partial forms when trying to fix something else. When I removed the part from the beginning of the multiple-instance forms the problem was solved. --Achimbode 07:26, 6 July 2011 (UTC)

Error in IE 7 when pressing "Add another" button
I repeatedly get errors when pressing the button "Weitere hinzufügen" (Add another?) of multiple-instance forms (Error message: Localized: Das Objekt unterstützt diese Aktion nicht, Unlocalized: Object doesn't support this action, on line 2572). The line of code reads if (children[x].type == 'select-one') in function addInstance - and no form appears.

Funnily the line above says // to get around a bug in IE. There is another error indicated already when loading the page which reads Object required (Localized: Objekt erforderlich) which points to    some random line of HTML code (different lines somewhere in the HTML part of the page each time after changing the content of the form).

I have another form with multiple-instance forms in the same wiki which works fine - and even the broken version works fine in Firefox... Does anyone happen to have encountered this before?

Context: Internet Explorer Version 7 (IE 7.0) / Semantic Forms (Version 1.9) / Semantic MediaWiki (Version 1.5.0) -- Achimbode 08:54, 6 July 2011 (UTC)


 * You can probably guess my response, but: you should upgrade your version of SF. Yaron Koren 10:46, 6 July 2011 (UTC)


 * I know - sometimes not that easy ;) in this case: they are working on it... -- Thanks nevertheless! Achimbode 11:34, 6 July 2011 (UTC)

Internal links disappearing
I'm now using the latest verson of SF and noticed that internal links which were formerly visible to editors using the form have disappeared all of a sudden. I'm not sure of this is a SF issue or something else, since I couldn't reproduce the problem on referata. Cavila 12:22, 6 July 2011 (UTC)


 * It's a bug in version 2.1.2, but not in earlier versions, or in 2.2 - which is hopefully coming out very soon... Yaron Koren 14:35, 6 July 2011 (UTC)


 * Don't worry, it's always to good to know that the problem wasn't me (meaning that I don't need to re-check everything). Cavila 09:25, 7 July 2011 (UTC)

Autocomplete, Hebrew and categories
I'm trying to have a field combobox with autocompletion from a category, in a wiki using MW 1.16.5/PHP 5. Semantic forms version is 2.1.2, and semantic MW 1.5.5.

The combobox with auto completion works, but it's not populated by values from the given category. I tried dropping the input type, and nothing happens either. The form does not autocomplete at all. So I think that something is wrong with the "values from category" attribute. Could this have something to do with me using a Hebrew language wiki?

This is the field definition

and the original in hebrew

89.139.166.172 19:10, 6 July 2011 (UTC)


 * Hi - this definitely sounds like a bug. Is there any way you could reproduce this problem on a public wiki, like http://scratchpad.referata.com ? Yaron Koren 21:06, 6 July 2011 (UTC)


 * Thank you Yaron. I tried to reproduce it here http://scratchpad.referata.com/wiki/Special:RunQuery/APITest but it seems to produce results as expected. Perhaps this bug something to do with MW 1.16 bug, I see that referata wiki uses 1.17. Any thoughts? 89.139.166.172 21:42, 6 July 2011 (UTC)


 * Thanks for trying to reproduce it. It could be the MW version, or the SMW version, or the SF version - Referata is also using SF 2.2, which is planned to be released in the next few days. (Or it could be something like the database encoding.) I guess I would recommend to try upgrading all of them, and see if that fixes the problem. Yaron Koren 22:11, 6 July 2011 (UTC)

FYI - I did a quick and dirty test on MW 1.17.0 with SMW 1.5.6, same as referata (still with SF 2.1.2, last released version). Problem still persists 89.139.166.172 08:02, 7 July 2011 (UTC)