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)


 * I fear it correlates to a bug dating May2011 (No.2 in May-June 2011 archive) "Bug with non-english letters in category-selector?". My only difference is that I am populating the values from properties, not categories. Thats why i keep coming back. -- Christian Tasler 84.169.192.183 12:24, 8 July 2011 (UTC)


 * I don't know - I still think it's been fixed. Either way, I think you should upgrade. Yaron Koren 17:14, 8 July 2011 (UTC)


 * I really wish i could. All i can do is wait till it gets done some day. I kinda found a workaround: 7bit encoding of the values (ü=ue, etc.)while selecting and recoding in all templates *yikes*. I hope i get rid of this when company finally upgrades. -- Christian Tasler 84.169.192.183 00:45, 9 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)

Well, I've upgraded SF and SMW as you suggested, and nothing changed. I think there's something basic that's wrong. I tried running the code from here demonstrating the "show on select" feature of a field, and even that did not work. The field on the RunQuery page was simply displayed without the dropdown list. Since I'm using MW 1.16.5 which should be compatible, then the only thing that's left as the source of the problem is what? MySQL? I'm at a loss here. Any suggestion would be appreciated. Thank you 89.139.177.43 19:40, 10 July 2011 (UTC)


 * My guess is that there's a Javascript error on the page - maybe because of interference from some other extension, or from the skin. Try looking at the form page with Firefox, with the "Firebug" plugin installed - that's my preferred debugging tool - and see if there are any Javascript errors at the bottom. Yaron Koren 01:39, 11 July 2011 (UTC)


 * I tried disabling all other extensions and reload the page, but this did not improve anything. I then installed firebug, and indeed there are several dozens of javascript errors when I load a RunQuery page, some of them from the semantic extensions. No errors though, and anyway the warnings are deep inside the code. If I find a way to save the log from firebug, would you be willing to take a look at teh warnings?


 * Sure, yeah. Yaron Koren 00:34, 18 July 2011 (UTC)

Pass values dynamically to RunQuery
I apologize if this is a question that has been asked before, but being a newbie to SemanticForms I could not figure it out from the instructions.

Is it somehow possible to pass values to a RunQuery page dynamically (I guess you might say this is Ajax-like)? I want to have a query who creates the response content dynamically, so it contains links to the same query with other parameters. I should point out that the data is retrieved from an external DB (i.e. the data is not pages in my wiki, that can somehow be categorized etc.).

An illustrative example would be a form in which I can ask to list all employees. The form filler can ask to view the list of female/male/all employees. The response would also contain links to all lists, one to a list of all male employees, and another link to the list of female ones, etc.

Ideally these links would simply be directly to the query page, with the field already filled so the query can be executed. I did not figure out a way to do so, and would greatly appreciate help on this matter. I hope I made myself clear 89.139.180.229 22:40, 7 July 2011 (UTC)


 * Quoting Yaron's email, This is already possible, with an undocumented feature: add "wgRunQuery=true" to the query string. Here's an example. This has been now added to standard documentation.


 * Thanks, this looks like what I was looking for. But it seems I can't create a wiki link with this syntax. I'd like to have something like

Here's an example
 * To appear as a regular internal link. But the parser does not accept this, probably because the '[]' characters get parsed as wiki markup somewhere along the way. Is there a way around this? 89.139.180.229 08:17, 8 July 2011 (UTC)


 * You might want to try the following solution while the second example uses to hide the fact that it is an external link.

[ Here's an example] [ Here's an example]


 * Worked like a charm. Thank you for your help


 * This can also be done more simply by changing [ and ] in the URL to &amp;#91; and &amp;#93;, respectively. By the way, I mistyped it before: it should be "wpRunQuery", not "wgRunQuery". Yaron Koren 17:11, 8 July 2011 (UTC)

Could we have fields in forms 'without' properties?
I find the autocomplete-functions very nifty, and have set up fields (lets call them "helpers") in some of my forms which sole purpsoses are to help the user to find links and templates using the autocomplete. The properties of these helpers doesnt contain any data of interest after the forms have been submitted, though.

An example of how I use these helpers is to autocompletes on a concept which contains all content articles on the site: the user will get a list of all current articles, and easily makes a copy-paste operation or such to insert to article link in the freetext field.

My question if it would be possible, in a future release, to have fields that works without actually transmitting property values into the article, when the form is submitted? Such as it is today, I use dummyproperties in my forms, but the downside of that is that my pages contains extrafluous data, and also that these dummyproperties of course are picked up by SF on subsequent edits with form, and my users have to clear out the previous helpers data when they make a new edit.

So it's basically a feature request to
 * 1) using a sf-field without submitting the property value
 * 2) a field which is always empty when you edit with form

To say this is a bit outside the scope of SF may not be wrong ;-) Anyway, SF is pretty flexible, maybe there are more out there who has done or thought somthing similar...?

--Ovoned 21:02, 8 July 2011 (UTC)


 * Hmm I missed that I can remove the property assignments from the templates to avoid adding s

emantic data. To clear an existing form field value when you edit with form seems impossible though. Maybe another field option, something like "alwaysreset" or "forcedefault=", so the value is overwritten when you make another edit with form? --Ovoned 21:26, 8 July 2011 (UTC)


 * That's an interesting problem. The cleanest solution to this might be simply a "do not store this field in the page" option - that doesn't exist either, but maybe it should. Yaron Koren 13:54, 10 July 2011 (UTC)


 * It would be nice to see it in a future version. I'm think there are many other users that take advantage of SF to do similar things. --Ovoned 09:30, 11 July 2011 (UTC)


 * Just do something like this:
 * It will not be saved and consequently will show up empty on every edit.
 * --F.trott 08:05, 12 July 2011 (UTC)


 * Ooh - I hadn't thought of that! The one downside of hacks like this is that there's no guarantee that they'll work with future versions of the software - but still, that's clever. Yaron Koren 13:24, 12 July 2011 (UTC)


 * Nice catch. Thanks! --Ovoned 21:28, 13 July 2011 (UTC)

Text Property and character limit
Is the text property supposed to be unlimited? It seems to cause an internal server error for me when it gets beyond about 4000 characters...  though I guess that could be a limit in MySql perhaps?

Just thought I'd mention it here in case it is a bug.

Keep up the great work with Semantic Forms. Cheers

125.237.124.157 03:36, 9 July 2011 (UTC)


 * It does sound like a MySQL problem - but in any case, this is probably an issue for Semantic MediaWiki, not Semantic Forms (unless saving those same values works via the normal "edit" tab). Yaron Koren 13:57, 10 July 2011 (UTC)

Standard Input Saving Large Text Issue
Hello: When using Semantic Forms to save a large amount of text data, it fails to save. The below code works nicely when field ArticleText has minimal data (ie less than about 300 characters). But when more text is entered (ie over 350 characters), it fails with the message: (20024)The given path is misformatted or contained invalid characters: Cannot map GET /wiki/Special:FormEdit/Article/Article0000003 HTTP/1.1 to file, referer: http://cody/wiki/Article0000003 (20024)The given path is misformatted or contained invalid characters: Cannot map POST /wiki/Special:FormEdit/Article/Article0000003 HTTP/1.1 to file, referer: http://cody/wiki/Special:FormEdit/Article/Article0000003 Form Code:

I have tested with LocalSettings.php $wgArticlePath = $wgScriptPath.'/index.php?title=$1' and with $wgArticlePath = "/wiki/$1" ie to eliminate the short URLs and colons as a problem. In both cases, MediaWiki hangs, and the page is not saved.

Installation details: Semantic Forms (v2.1.2), Semantic MediaWiki (v1.5.6), MediaWiki (v1.16.5), PHP (v5.2.17), MySQL (v5.5.13), Windows Vista (SP2, 64bit)

Thank you for developing and supporting Semantic Forms


 * A quick web search reveals that this seems to be a bug for Apache running on Windows, having to do with the colon in the URL. But it appears that that error isn't a fatal one - in other words, though you're seeing that message, that's not what's actually causing the save to fail. Could it be something else, like going over the PHP memory limit? Yaron Koren 18:30, 12 July 2011 (UTC)


 * I appreciate your thought about the Apache bug, but I don't believe this is the issue. Here's why: When editing a page directly (ie not through a Semantic Form), the error occurs when supplying large text to a property (ArticleText is defined as - This is a property of type Has type::Text.)  But when supplying the same large text to the page outside the template, it works without issue.  Something fishy is occurring with the Semantic Property.  See below for clarity.

...350 chars works here... Template:Article ArticleText::
 * I have tried changing the php.ini memory_limit and .htaccess php_value memory_limit, but with no positive effect. My term of "large text" might be misleading, as it is only 350 chars, so I don't believe this is a server memory issue.  Maybe this is a Semantic MediaWiki issue?  Are there array bounds or other processing of properties that contain limits?
 * Thank you for your great assistance.


 * Ah - it sounds like you're having the same issue as the person in the section above this one. And yes, it sounds like a Semantic MediaWiki issue. Yaron Koren 02:20, 14 July 2011 (UTC)

Combox values with quotes
I want to have a combobox where some of the options contain quotes. However, there is a weird error. When query is run with such an option selected, on return the combobox appears with the selected option cut off. I was able to reproduce the error in the referata wiki, see here. Is there a solution? Thank you 89.139.187.127 19:50, 13 July 2011 (UTC)


 * Hi - that page you linked to actually seems to work for me, across various browsers. What's the specific problem you're seeing? Yaron Koren 03:06, 14 July 2011 (UTC)


 * Try to select to first option which contains quota, and hit Run Query. On return, the select box appears with that option selected, but all the text after the quote sign is gone.
 * Tried it on FF3.6, IE8.


 * Did you see the problem? 46.116.251.244 20:00, 17 July 2011 (UTC)


 * Hi - yes, I saw the issue (I forgot to actually try hitting "Run query" :) ). I think I just fixed it in SVN, and on Referata. Yaron Koren 20:45, 17 July 2011 (UTC)


 * My fix before wasn't very good, but I think I fixed it correctly now... Yaron Koren 00:33, 18 July 2011 (UTC)

SMW not recognizing property declarations by Semantic Forms
Rather than the content of text properties being displayed in my template it shows my property::my contents and that instance of the property isn't showing up in Special:Properties. I had edited the form after creating it with Create a class so I assumed I'd messed up the form, but the thing is that sometimes it creates a property and shows properly in the template and sometimes it doesn't. When I manually enter a property into the template it works, but otherwise there doesn't seem to be any pattern to whether it will or not. I've got one property that's only worked once, but generally I just get 3 or 4 random properties (out of 18) on each page that have this problem. Thoughts? I'm converting the content from a Word document, could there be special characters or formatting or something that it doesn't like?

Thanks,

Bteed 02:05, 16 July 2011 (UTC)


 * Sorry, I don't understand what you're talking about here. Could this be the issue? If not, I would try reproducing this problem on a public wiki, like http://scratchpad.referata.com. Yaron Koren 12:56, 17 July 2011 (UTC)
 * Looks like that was it. I didn't have any links, but there were places where something like "agree[d]" was written and using parentheses instead of square brackets seems to have fixed it. Thanks. Bteed 23:49, 17 July 2011 (UTC)