(Translated by https://www.hiragana.jp/)
Extension talk:Page Forms - MediaWiki Jump to content

Extension talk:Page Forms

From mediawiki.org

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)Reply

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)Reply
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)Reply
I don't know - I assume it has, since the bug was reported three years ago... Yaron Koren 03:01, 7 July 2011 (UTC)Reply
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)Reply

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 if ($wgUser->getOption('minordefault')) and 'checked'= 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)Reply

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)Reply
-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 Html::Hidden 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)Reply
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)Reply

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)Reply

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)Reply

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)Reply
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)Reply
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)Reply
That is my plan. Thanks for working this through with me. --Dgennaro 15:26, 6 July 2011 (UTC)Reply

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#Info_tooltip_does_not_work_in_multiple_instance_templates

Hi Shirl, I also stumbled upon this problem with {{#info:tooltip text}} 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 {{{info|partial form|edit title=...}}} part from the beginning of the multiple-instance forms the problem was solved. --Achimbode 07:26, 6 July 2011 (UTC)Reply

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 <div class="page_name_auto_complete" id="div_6"></div> 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)Reply

You can probably guess my response, but: you should upgrade your version of SF. Yaron Koren 10:46, 6 July 2011 (UTC)Reply
I know - sometimes not that easy ;) in this case: they are working on it... -- Thanks nevertheless! Achimbode 11:34, 6 July 2011 (UTC)Reply

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)Reply

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)Reply
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)Reply

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

 {{{field|team|values from category=teams|input type=combobox}}} 

and the original in hebrew

 {{{field|קבוצה|values from category=מועדוני_כדורגל|input type=combobox}}} 

89.139.166.172 19:10, 6 July 2011 (UTC)Reply

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)Reply
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)Reply
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)Reply

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)Reply

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)Reply

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
[[Special:RunQuery/Item_query?ItemQuerier[author]=A&ItemQuerier[source]=New&wpRunQuery=true|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)Reply
You might want to try the following solution while the second example uses <span class="plainlinks"> to hide the fact that it is an external link.
[{{fullurl:Special:RunQuery/Item_query|wpRunQuery=true&ItemQuerier%5Bauthor%5D=A}} Here's an example]
<span class="plainlinks">[{{fullurl:Special:RunQuery/Item_query|wpRunQuery=true&ItemQuerier%5Bauthor%5D=A}} Here's an example]</span>
Worked like a charm. Thank you for your help