Extension talk:Page Forms

parser function support for values=
Hi Yaron, Just wondering if we could allow parser functions to populate the values= parameter (e.g., #ask, #var, etc.). Currently it does not appear to support it. Perhaps something to add in a new version.

Longphile (talk) 15:20, 2 October 2013 (UTC)

different forms but same template?
Sorry for a newbie question....

Hopefully I can describe my scenario clearly: 2 different groups of editors are working on the the article. Group A do lots of text and semantics with a form A. That's fine so fare. Group B should add geodata to the articles. Because headertabs and maps don't work together I want to set up a second form B just for the geodata but it should complement the data in template/form A.

should I add in form B ?

Thanks for help.


 * Hi, yes - if you have multiple forms for the same page type, they should contain the same templates - although the set of fields for each can be different, including a template possibly having no fields. Yaron Koren (talk) 14:53, 9 October 2013 (UTC)

How to hide the "additional query" form in query results?
Is it possible to hide the additional query form when displaying the results of a query form? I want only the results to be displayed, not another query form, and haven't found this issue in the documentation here on this site. Thanks in advance! --Daniel5000 (talk) 14:56, 9 October 2013 (UTC)


 * I don't understand - why do you want users to only be able to run a query once, and not change it after seeing the results? Yaron Koren (talk) 02:08, 10 October 2013 (UTC)
 * It is for a query with many steps (about 30 with 3 semantic queries each) in a row, like in a quiz (it's actually not a quiz, so the Quiz extension doesn't help, SF/SMW does it fine). The "additional query" field would confuse the user in this case. It's not the most standard use case for SF, I know, but is there a method to disable this form, perhaps if I touch the code a bit? --Daniel5000 (talk) 03:33, 10 October 2013 (UTC)


 * Ah, okay. I don't think there's any way to do it with the current code, but if you're willing to modify the SF code, it shouldn't be that hard to do. Yaron Koren (talk) 20:13, 10 October 2013 (UTC)


 * I have now figured out how I would have to change the code. But I have discovered a parameter additionalquery=false (in SF_RunQuery.php at line 127 in SF 2.6) which can be passed to the Special:RunQuery page to hide the form. It can be passed via #queryformlink or via the URL string, but then the form disappears before the first query. It seems the parameter must be passed to the result page to hide it there. Is there a way to do this, so I can use the code without modifications? Anyway thank you, if this is a too complex question I now have an idea how to achieve my goal. --Daniel5000 (talk) 23:58, 10 October 2013 (UTC)


 * Oh yes - that's right, that parameter is used to prevent user input entirely. I still think there's no way to do it without modifying the code. Yaron Koren (talk) 18:22, 11 October 2013 (UTC)
 * OK, I will modify the code then. If you are interested in the modifications (it's 5 lines more or so, I thought to resolve it similarly to the "query form on top" parameter) I have no problems to release it here as a patch, but I have no dev access to SF as my PHP knowledge is very rudimentary. Regards, Daniel5000 (talk) 21:18, 11 October 2013 (UTC)

Sure, it would be good to see the patch! Yaron Koren (talk) 19:49, 13 October 2013 (UTC)
 * Here I have described the modifications: User:Daniel5000/SemanticForms-HideAdditionalQuery. (As I hadn't used a stable SF version in my installation, I did't know if a patch file would be really useful, so I did it this way.) Regards --Daniel5000 (talk) 23:39, 22 October 2013 (UTC)

Popup forms in Firefox
I am getting erratic behavior using popup forms in Firefox. Chrome and IE seem to work fine though. I am guessing that the issue lies in SF_popupform.js, as I have played around quite a bit with the CSS to no avail. Basically, in Firefox, the vertical scroll bar is associated with the inner frame (but the outer for other browsers). Horizontal scroll bars are also buggy in FF. Likewise, saving sometimes works and sometimes does not. Can anone confirm strange behavior of popups in FF? In my experience, playing with editing, saving, reloading editing, saving, etc., produces strange behavior at some point, and this behavior is not predictable. I am running the latest alpha version of SF from Git. ~z929669 Talk 04:58, 10 October 2013 (UTC)

Embed Special:RunQuery bugs
I've encountered two bugs when I've embedded a query form into a page. One has already been identified (Bug 49302) and I've downgraded as a workaround. The other is only small but rather annoying. I'm using the date input and for some reason it wraps the dropdown box and the last input box in a  tag. This leaves out the first input box and so the the date input is split into two lines. It doesn't do this on the RunQuery page. You can see the problem here. Can anyone suggest a workaround/fix?--176.251.5.55 12:44, 16 October 2013 (UTC)

Including time for properties with type 'Date'
When specifying a field with property type 'date' the default behavior on Special:CreateForm is to provide 3 x input boxes, one each for day, month and year. Is there a simple way to get the form to include a box or boxes for time as well? I've searched the talk pages back to October 2012 and can't find anything relevant. Likewise the relevant SMW help and talk pages. I am aware of the Inputs extension but would prefer not to have to install it if possible. Thanks in anticipation. --Sabretache (talk) 14:27, 16 October 2013 (UTC)


 * Yes - add "|input type=datetime" to the field tag. Yaron Koren (talk) 16:26, 16 October 2013 (UTC)


 * Thanks Yaron. You're a brick. Much appreciated. --Sabretache (talk) 19:53, 16 October 2013 (UTC)

Another connected item: I cannot get the form to stop populating at least the current month box. I would like all date values to be initially blank but cannot get that to work using default= anything. --Sabretache (talk) 12:02, 17 October 2013 (UTC)

Automatic page naming with #switch
On my wiki we extensively make use of the feature. Today we needed a more complex page naming scheme, where the structure of the page name depended on the value of a field. We tried many things, including this:

However, when we removed newlines it worked:

The example above works, but is very temperamental. If the use of spaces is adjusted it will not work. See the three simplified examples below. Note that none of them have any newlines.

A) WORKS:

B) DOES NOT WORK:

C) WORKS:

So (A) and (C) work, but (B) does not. Anyone have any thoughts as to why this is the case? Thanks in advance!

--Jamesmontalvo3 (talk) 17:56, 16 October 2013 (UTC)


 * To be honest, I'm surprised that any of it works. :) Personally, I never put padding spaces (or newlines) within parser functions like #if or #switch. Yaron Koren (talk) 21:15, 16 October 2013 (UTC)

Popups including result format excel will not properly close
Hi,

using MW 1.21, SMW 1.9 alpha-3, Semantic Result Formats 1.9 alpha and SF 2.6:

I have set a queryformlink to open a query in a popup. The result format is set to excel. If I klick on the download link of the excel, the popup tries to cloas, but is stuck to the loading picture, so I have to reload the whole page to get back to a usable view.

Firebug doesn't show errors apart from TypeError: rules[r].selectorText is undefined of ext.headertabs, which should not be a concern here. I have tested it with FF 24 and Chrome 30, showing the same behaviour.

Is there a way to let the popup close properly (or at least stay open)?

Thanks for the great extension, Yaron!

Regards --92.50.70.114 11:55, 17 October 2013 (UTC)


 * Ah, Javascript collisions between extensions... those can be a tough nut to crack. I hadn't heard of the excel result format, by the way - it looks like it's new in SRF 1.9. Could you try disabling the Header Tabs extension, just to make sure that that's not the cause? Yaron Koren (talk) 14:04, 17 October 2013 (UTC)

Allowed values loaded into form are being changed
I am having an issue with semantic forms where I set a field in the form that contains a list of allowed values set in the property page. One of the values has an underscore character in it. The values are presented in the droplist (or radio button list) but the underscore is converted to a space. If that value is selected the resulting page has an error that the value selected is not in the list of possible values.

This does not happen if you set the list of values in the form with values=, only when pulling the values in from the property page. The form should not modify the values it reads in from the property.

Any ideas?

--Rbonser (talk) 18:47, 18 October 2013 (UTC)

Here is an example property:

Property:Arch This is a property of type Has type::String. The allowed values for this property are: * Allows value::x86 * Allows value::x86_64


 * MediaWiki (Version 1.21.2)
 * Semantic MediaWiki (Version 1.8.0.5)
 * Semantic Forms (Version 2.6)

Property based on Usernames
I'd like to be able to leverage the extremely useful property-search-as-you-enter feature when associating users with text properties. Is there a way to do with without either:
 * 1. Manually maintaining a list of users on a property page
 * 2. Having to create a user page for every user (would enable allows value from namespace). Most of my users don't have/maintain a userpage.

I suppose some way to automatically create some kind of user page for all existing users would do, but I suppose isn't SF related. Thanks! - Lbillett (talk) 13:20, 19 October 2013 (UTC)


 * The only other real option that I know of is to use "values from url", and then to create a web page (in PHP or some such) that accesses the wiki database, or API, to get the set of users, then displays it in the JSON format that "values from url" requires. (The JSON format that "values from url" looks for is unfortunately similar, but not identical, to the JSON format that the user list API query outputs.) If you instead decide to have a user page for each user, you could use the SemanticSignup extension so that, in the future, user pages will get created automatically. Yaron Koren (talk) 00:36, 20 October 2013 (UTC)

Error with Semantic Forms, WikiEditor, and standard input tag
Greetings, I'm running the latest version of Mediawiki (1.22wmf21) and Semantic Forms 2.6. In Internet Explorer 8 I see an odd behavior.

I have a form that ends with the following syntax.

Upon entering a page name and clicking create/edit (two step process) editors are presented with a error in a dialog box. Message from webpage
 * ext.semanticforms.main: [object Error]

WikiEditor then fails to load. Editors can still edit text, but it is hard to discern where the editable text field is as there is no border to the field.

If I remove the tag or "editor=wikieditor" then the error does not appear. However I obviously loose the functionality of either. Also curious is that the tag also does not appear with a label like the "save" or "changes" tag. Instead it is a small labelless button that does not work.

This does not happen in IE 9 and Safari 6/7. While I would love to tell my editors to upgrade to a different browser this is not feasible. In the short term I have removed the preview button. Does anyone have any suggestions?