Extension talk:Page Forms/Archive October to December 2013

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)

It seems to be a regression. Version 2.5.1 works fine ! Impossible to set a default value (as the current date with {{#time..}} for example). --195.101.137.127 11:14, 27 October 2013 (UTC)

Hello, I've tested back to version 2.4.2, and cannot seem to get this to work. I've tried with both a simple template (for example setting "values={{Sandbox1}}", which results in the text "{{Sandbox1}}" being the only item in the dropdown list. More advanced functions like semantic queries work similarly. Should we expect this to work? Patelmm79 (talk) 18:06, 13 November 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 {{{for template|Template A}}} ?

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 <p> 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 {{{info|page name=TEMPLATE_NAME<FIELD_NAME>}}} 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:

{{{info|page name={{#switch: <OCAD[OCAD Type]>
| OCAD = ISS OCAD <OCAD[OCAD Number]>
| Operational Constraint = Operational Constraint <OCAD[Applicable Hardware]> <OCAD[OCAD Number]>
| Operational Consideration = Operational Consideration <OCAD[Applicable Hardware]> <OCAD[OCAD Number]>
| No OCAD type established
}} }}}

However, when we removed newlines it worked:

{{{info|page name={{#switch: <OCAD[OCAD Type]> | OCAD = ISS OCAD <OCAD[OCAD Number]> | Operational Constraint = Operational Constraint <OCAD[Applicable Hardware]> <OCAD[OCAD Number]> | Operational Consideration = Operational Consideration <OCAD[Applicable Hardware]> <OCAD[OCAD Number]> | No OCAD type established}} }}}

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:

{{{info|page name={{#switch:AAA|AAA=You chose AAA|BBB=You chose BBB|CCC=You chose CCC|WRONG ANSWER 2!}} }}}

B) DOES NOT WORK:

{{{info|page name={{#switch: CCC| AAA = You chose AAA| BBB = You chose BBB| CCC = You chose CCC| WRONG ANSWER!}} }}}

C) WORKS:

{{{info|page name={{#switch: CCC | AAA = You chose AAA | BBB = You chose BBB | CCC = You chose CCC |  WRONG ANSWER 3! }} }}}

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)

Wizard! Messed around with this a little bit. Managed to get the user list from the api shaped to look like the expected output with a php like this (barbaric, but seems to give the right output):

<?php
  $ch = curl_init();
  curl_setopt ($ch, CURLOPT_URL, "http://mywiki/api.php?action=query&list=allusers&aulimit=500&format=json");
  curl_setopt ($ch, CURLOPT_HEADER, 0);
  ob_start();
  curl_exec ($ch);
  curl_close ($ch);
  $string = ob_get_contents();
  ob_end_clean();
  $import=json_decode ($string, true);
  foreach ($import['query']['allusers'] as $row) {
      $export[]['title'] = $row['name'];
  }
echo "{\"sfautocomplete\":".json_encode($export)."}";
?> 

Problem is it doesn't seem to want to pick up the values. The throbber shows up... Likely related to the issue mentioned here with my v2.5.1. Tried v2.6 but it still blows up the output of my queryforms bug 49302. Thanks for the options. I'll have to try one of the others, or sit tight for a while. - Lbillett (talk) 17:15, 7 November 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.

{{{end template}}}

{{{standard input|free text|editor=wikieditor}}} 

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|preview}}}

{{{standard input|save}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

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 {{{standard input=preview}}} tag or "editor=wikieditor" then the error does not appear. However I obviously loose the functionality of either. Also curious is that the preview 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?

I personally don't think I have the time or resources (i.e., access to IE 8) to look into this issue, but hopefully someone else can. I would suggest adding a "&debug=true" (or "?debug=true") to the URL, by the way, if that's possible - it might lead to a more useful error message. Yaron Koren (talk) 09:08, 25 October 2013 (UTC)

Just an update, this appears in IE 10 as well. I was mistaken in my testing. It's curious that removing "{{{standard input|preview}}} seems to fix the problem.

Autocomplete not displaying with Forminput or RunQuery

I'm trying to use the forminput "autocomplete on category=" function, but autocompletion isn't showing anything when typing a value in. When not using remote autocompletion I can see the values being loaded in the script, but no suggestion drop down shows up when typing them in. If I use remote autocompletion, I see the calls to the api for the values, but still no drop down. I have tried setting $sfgAutocompleteOnAllChars to true as well.

Another page with a Special:RunQuery that uses "values from category=" works fine for autocomplete and shows the drop down while typing. The only problem with autocomplete on query forms though, is that it stops matching once you enter a space. So "San Antonio" only matches until you get to "San".

I'm using the newest version of Semantic Forms. Any ideas? Thanks!

This may be two different issues. For the autocomplete not working at all, this may be due to the fact that you're using old, deprecated syntax. Instead of "autocomplete on category", you should now use "input type=text with autocomplete" (or "textarea with autocomplete"), plus "values from category". The second one sounds like a bug, though - maybe it's due to the use of sfgAutocompleteOnAllChars? Yaron Koren (talk) 08:55, 25 October 2013 (UTC)

Thanks for the reply Yaron. Unfortunately still not working. The documentation for Linking to Forms shows forminput using "autocomplete on category", and it seems to not process "values from category" if I try to use that instead. Added "input type=text with autocomplete" in both instances, and no change. Setting "$sfgAutocompleteOnAllChars = false;" also doesn't fix either problems, and space still stops the autocomplete. I tried seeing if it would match on _, +, or others, but nothing matches the space. Any other ideas?--66.25.74.224 17:10, 25 October 2013 (UTC)

Oops - I misread "forminput" as "form input" - two different things. :) So my advice before was incorrect. I don't know... this isn't a public wiki, is it? The only thing I can think of is that it might be a Javascript issue - check the Javascript console to see if there are any error messages. Yaron Koren (talk) 08:20, 27 October 2013 (UTC)

No problem Yaron :). So this is what I've figured out so far. On the #forminput api request, it's using "api.php?action=sfautocomplete&format=json&undefined=input_1&substr=", and so category wasn't defined as the property, and input_1 is set for autocompletesettings. This is using "autocomplete on category=States". I'll play around with #forminput, and see if I can get it to act correctly, but I'm sure you have a much better idea of what's happening than I do.

On the space matching issue, it matches fine when autocompleting a category, so something like "category=State&substr=New+York" matches "New York" just fine. When using properties though, "property=State&substr=New+York" doesn't match, but "property=State&substr=New York" does match. Any ideas how to fix this one?--66.25.74.224 16:26, 27 October 2013 (UTC)

Given that this (I assume) isn't a public wiki, could you try to replicate this bug on http://scratchpad.referata.com? It could be that it's something specific in your data structure that's causing the problem. Yaron Koren (talk) 22:52, 28 October 2013 (UTC)

You can check out the space matching problem here http://www.wikiocity.com/Special:RunQuery/Search by entering "San Antonio" into the City field. I tried to replicate it on scratchpad, but couldn't get autocomplete to work at all there. The other problem can be found here http://www.wikiocity.com/Texas/San_Antonio/Restaurants , where you can see it tries to query "undefined=input_1". --66.25.74.224 17:43, 16 November 2013 (UTC)

Ah, it was a public wiki all along! Well, I'm not exactly sure what's going on there - there are various things I would call weird in the current data structure, like category-like pages, called "categories", that aren't actually categories - but my guess is that at least some of the autocompletion issues are caused by many of your properties, like "CityName", being defined as type "Text" when they should be type "String". Yaron Koren (talk)

Tried both String and Text, and it doesn't seem to make a difference :( . I changed everything to type Text since I read String is deprecated in 1.8, and gone in 1.9. The site structure is certainly a bit weird, but there shouldn't be anything conflicting to cause the errors. I am creating properties using pagename functions, so I'm thinking the space problem has something to do with using &nbsp instead of whatever it's expecting. A simple str_replace in the extension might be an easy fix, but I'm not sure where the best place to put it would be? Thanks again! --66.25.74.224 17:15, 17 November 2013 (UTC)

I don't know - I can't reproduce the problem. Yaron Koren (talk) 18:55, 19 November 2013 (UTC)

Well I'm dumb, and back at square one. :( I was thinking it was matching &nbsp, but the ampersand was just stopping the query. Duh. I tried every iteration of space I could, but no such luck. Space just plain doesn't match on anything. Do you have autocomplete with property working somewhere that I can take a look at, and see what I'm doing differently? I couldn't get anything to work at all on referata.--173.173.102.166 23:54, 21 November 2013 (UTC)

Sure - the "Item" form on Discourse DB has all manner of working autocompletion. By the way, if there's a specific place where autocompletion is failing on Referata, it would be helpful to see. Yaron Koren (talk) 01:54, 22 November 2013 (UTC)

You were starting to make me feel like I was a crazy person Yaron! :P Here's a page someone made, and it has the problems as well. http://discoursedb.org/wiki/Special:RunQuery/Autocompletion_test If you look at field 3 on Autocomplete on Property, autocompletion doesn't work at all. Then if you look at field 3 on Values from property, autocompletion works, but breaks when you type in the space for "left wing". Interestingly, field 4 with page type property works fine on both. So see, not crazy...ok, just less crazy, but still. :) --173.173.102.166 16:56, 22 November 2013 (UTC)

Ah, good find! I hadn't looked at that test form in a long time (I created it). I'm not concerned about "autocomplete on property", because it's deprecated functionality. But there was a problem with space handling - it happened only for remote autocompletion on properties not of type "Page". I believe I just fixed this in the source code, so if you get the latest version of the code from Git, it should work correctly, I hope. Yaron Koren (talk) 15:07, 24 November 2013 (UTC)

Sweet, that works great now! Thank you so much! I also added an example of the forminput issue to that same page at http://discoursedb.org/wiki/Special:RunQuery/Autocompletion_test . The autocomplete on property doesn't seem to work at all, and the autocomplete on category works, but isn't doing the autocompletion remotely. Oh, and do you have a place to donate for the extension? I'd love to send you some money for a 6 pack. :)

Okay, cool. I got worried about the property autocompletion not working, but then I realized that "autocomplete on property" is just not supported - only "on category" and "on namespace" are. (Let me know if you think that's a problem.) The remote autocompletion thing is definitely an issue, though - I'll have to look into it. Thanks for your offer to donate! There used to be a Semantic Forms tipjar, but there isn't any more. You can donate to the SMW effort in general, though, at the bottom of this page. I may or may not be able to get a beer out of that. :) Yaron Koren (talk) 14:12, 26 November 2013 (UTC)

Autocomplete for property would be nice, but I can work around it. Remote autocompletion is definitely needed in my case though. I'd already planned on donating some more money to SMW once the site was officially up, so I'll just throw in some extra this time with the requirement that it be spent on booze. :D Thanks again!

Show on select not filled?

According to Extension_talk:Semantic_Forms/Archive_January_to_February_2013#.22embed_in_field.22_and_Header_Tabs I try to work around editing my Fields by showing them with a Show-on-select-Combobox and let the parts fade in and out. This works fine so far, causing me to the problem that only the shown fields are saved. All other fields hided by selection will be emty. I assume there is no reason to save fields, witch are hidden in a normal form, because information filled in befor seems not to be needed if the user select another option. In my case - ofcause a workaround - it would be usefull - any solutions? --Letofred (talk) 07:50, 25 October 2013 (UTC)

Hm - if the goal is just to hide complexity, maybe it would work better to use collapsible elements instead? Yaron Koren (talk) 08:58, 25 October 2013 (UTC)

Leading me to the old Problem, the multiple parts have to apear in front of normal fields --Letofred (talk) 10:52, 25 October 2013 (UTC)

Sorry, I don't understand. Yaron Koren (talk) 14:35, 25 October 2013 (UTC)

Display multiple instances in tabs

Hi Yaron, it`s great to work with your extensions. It enables a non-programmer like me to create great solutions. :) I have got a question concerning the headertabs in semantic forms. I would like to display multiple instances in tabs - not in the form but in the template. But when I put the syntax for the headertabs in the template it seems like the headertabs are ignored and the heading is displayed as h1. Is it even possible to do this? Thanks in advance! Dadai12 11:39, 29 October 2013 (UTC)

That's great! Hm, that seems like it should work... two questions: do the tabs work when you put the headers directly into the page? And do they work when you put headers into a standard, non-multiple-instance template? Yaron Koren (talk) 12:43, 29 October 2013 (UTC)

Thanks for your quick reply. Yes, the tabs are working when I put the headers directly into the page and also when I put them in a non-multiple-instance template. That`s what my template looks like - maybe I did something wrong:

<includeonly>
=Gültig ab Version [[Has version::{{{Gültig ab Version|}}}]]=

{| class="wikitable" id="standard_table" style="cellpadding=10;" "cellspacing=0;" "color=red;"
|-
| '''Gültig bis Version''' || [[Has actuality::{{{Gültig bis Version|}}}]]  
|-
| '''Kategorie'''|| {{#arraymap:{{{Kategorie|}}}|,|x|[[Has category::x]]}}
|}

<headertabs/>

__NOTOC__
</includeonly>

Dadai12 12:57, 29 October 2013 (UTC)

Okay, cool. My guess is that it's the SMW tag within the header that's causing the problem - but perhaps I can solve two problems in one here, and recommend that, instead of direct SMW tags, you should use either #subobject or (from the Semantic Internal Objects extension, #set_internal, to store the data - it's ideal for arrays of data like this one. Yaron Koren (talk) 13:54, 29 October 2013 (UTC)

Okay, thanks for the tip. That`s new for me - I will look into it. Thanks for your help so far. :) Dadai12 14:20, 29 October 2013 (UTC)

Saving Partial Forms with SF 2.6

I noticed this back with 2.5.3 and hoped that it would be fixed with this latest version. Whenever I try to save a page based upon a partial form, it does not save any of the changes. Everything else works as normal.

My code:

{{{info|partial form|edit title=Add or change a repair log entry}}}
{{{for template|Repair Log Entry|multiple}}}
{| class="wikitable"
! Repair Description:
| {{{field|Repair Description|mandatory|size=120}}}
|-
! Repair Call Date and Time:
| {{{field|Repair Date and Time|input type=datetime}}}
|-
! Notes:
| {{{field|Notes|input type=textarea}}}
|}
{{{end template}}}

Partial forms haven't been fully working in a long time, and my hope is to actually get rid of them eventually. Instead of partial forms, I would recommend, if possible, to make this a "quasi-partial" form - a form that includes the other template or templates from the main form, but simply doesn't include any of their fields, if that makes sense. Yaron Koren (talk) 16:40, 1 November 2013 (UTC)

Do you have a sample?

Hm, I can't think of one. But the idea is just to have one or more pairs of "{{{for template|...}}}" and "{{{end template}}}" tags, with nothing in between, if that makes more sense. Yaron Koren (talk) 20:03, 1 November 2013 (UTC)

Installation won't work

Hello, I am having a very strange problem, and I seem to be the only one: The installation steps have been done - but the special pages & extension in "version" just won't show up. I work on MediaWiki 1.21.2, have installed Semantic MediaWiki 1.8.0.5 and then downloaded and installed the latest version of Semantic Forms. In the localSettings.php I have included the desired line as stated below Semantic MediaWiki etc etc. Everything was done like stated, but. Any hints what I could have been missing/what could be wrong? (I hope this is the right place to ask, if not, please point me somewhere else.) There is set another namespace (500, 501) so I wrote $smwgNamespaceIndex = 100; in the Localsettings. --Zabien (talk) 02:19, 2 November 2013 (UTC)

Is it only SF that's not showing up, or also SMW? Yaron Koren (talk) 13:04, 3 November 2013 (UTC)

SMW is working fine, everything there. Only SF not showing. --Zabien (talk) 19:37, 3 November 2013 (UTC)

What's the relevant set of lines you have in LocalSettings.php? Yaron Koren (talk) 20:57, 3 November 2013 (UTC)

Only this one: include_once("$IP/extensions/SemanticForms/SemanticForms.php");, as stated on the Installation page (below the ones from SMW)--Zabien (talk) 00:02, 4 November 2013 (UTC)

I don't know - my guess is that it's something else in LocalSettings.php that's causing the problem, but without more information that's all I can say. Yaron Koren (talk) 01:30, 4 November 2013 (UTC)

Thank you anyway! --Zabien (talk) 14:19, 4 November 2013 (UTC)

Just did a clean installation with MW 1.21.2 only with extension Semantic Wiki, Validator and Semantic Forms - same result, Semantic Wiki is there but no Forms, strange...Donxello (talk) 16:45, 4 November 2013 (UTC)

"Create pages with form" and sfEditFormPreloadText

Do pages created via [[Creates pages with form::<whatever>]] normally utilize sfEditFormPreloadText extensions? If not, is this possible? Or is there an alternative for creating pages besides rigging up some <curl>-based script or something?

Also: When I attempt this (which led to a facepalm, then installing the "Nuke" extension -- happily, I used a bot account), the originating page is filled with a whole bunch of UNIQ-this and UNIQ-that strings and the resulting pages are getting "Some very long page name that will hopefully never get created ABCDEF123" substituted for {{PAGENAME}}. I'm assuming neither phenomenon is a feature.

You may be talking about three different issues here. For the first one, I would think that hook should be called - if it isn't, please create a bug report for that on Bugzilla, if possible. For the second two - is that bad text showing up in the form, the page wiki-text, or just getting displayed when you view the page? Yaron Koren (talk) 14:29, 4 November 2013 (UTC)

I'm an idiot; nowiki-ed the description of the third issue to clarify. The UNIQ stuff seems to show up whenever a property is given the Creates_pages_with_form property. The first I'm going to double-check again and then file a bug report.

Okay, thanks for the bug report. My question still applies for the second two, though, I think. Yaron Koren (talk) 17:17, 4 November 2013 (UTC)

Ah, sorry. The UNIQ strings are displayed when I view a page. There are many template calls in any given page on my wiki, and the general structure of the page looks right, but the template calls seem to be replaced with the UNIQ string. Editing-with-form or just editing reveals no unusual text, nor are there any problems saving or doing anything else. It looks like intermediate parser data, I guess.

Note -- this seems to appear when the [[Creates age with form::<whatever>]] is first inserted in the property definition and the jobs are created. When the jobs are finished processing, it then disappears. It might be like this pending a refresh-links job.

The "Some very long page name..." text is inserted into the wikitext; I see it in the runJobs.php output and it is in the finished page as well. Each page has a couple of properties based on some variant of {{PAGENAME}} -- e.g. a sort-friendly version of the page name without A/An/The.

Okay, cool. The "UNIQ" thing happens sometimes in MediaWiki displays - it doesn't seem to be a bug in SF. And thankfully it only happens temporarily, if I understand you correctly. The "Some very long page name..." thing sounds like an SF bug - although, just to clarify, is {{PAGENAME}} part of the text that the property in question points to? Yaron Koren (talk) 22:05, 4 November 2013 (UTC)

Yeah, I can deal with the UNIQ thing -- it makes me wonder though if some parser function is bailing inappropriately when it encounters the hook, since it only happens when the property is set. Ideally, though, with SMW popping up on GitHub I'll be able to develop a closer relationship with the code :-)

is {{PAGENAME}} part of the text that the property in question points to?

Nope, just default values in some of the form elements, e.g. {{{field|Has Canonical Title|mandatory|property=Has Canonical Title|default={{#titleparts:{{PAGENAME}}|}}|}}}

Add Field button does not work

I'm using Semantic Forms, and the Add Field button in my Create a Template and the Create a Class pages doesn't do anything. The version page for my wiki is at:

http://microbewiki.kenyon.edu/index.php/Special:Version

Please help ASAP.

Thanks.

Barichd (talk) 02:56, 5 November 2013 (UTC)

As I suspected, the issue is a Javascript error - you can see it if you look at the Javascript console, in Chrome or Firefox. Specifically, the problem is in your wikibits.js file. You should probably also upgrade your version of SF, but that's unrelated. Yaron Koren (talk) 11:57, 5 November 2013 (UTC)

What is the solution for this issue? I am having similar problems Wade.courtney (talk) 22:10, 20 November 2013 (UTC)

Are you seeing any Javascript errors? Yaron Koren (talk) 22:25, 20 November 2013 (UTC)

No sorry, I thought he was talking about something else. Wade.courtney (talk) 18:37, 21 November 2013 (UTC)

Implicit link between form field and property

When a form field is defined like:

{{{field|Has direction|input type=dropdown}}}

And Property:Has direction has the following:

[[Allows value::Right]][[Allows value::Left]][[Allows value::Up]][[Allows value::Down]]

The dropdown generally works, showing the four allowed values of Up, Down, Left and Right. However, it appears that sometimes something can change in the associated template that causes this implicit link between the field and the property to break, and then the following change is required in the form:

{{{field|Has direction|property=Has direction|input type=dropdown}}}

How does this implicit link between form field and property work? Under what circumstances is "property=Has direction" not required?

--Jamesmontalvo3 (talk) 18:42, 7 November 2013 (UTC)

Basically, SF tries to parse the template every time, to figure out the connection - if it's a simple template, it usually succeeds, but if there's anything complicated, like #if statements and the like, it can fail. Yaron Koren (talk) 18:51, 7 November 2013 (UTC)

Does specifying "property=Has direction" give a performance advantage since it doesn't have to check the template?

--Jamesmontalvo3 (talk) 19:00, 7 November 2013 (UTC)

No - it does the parsing for all the fields in one go. Yaron Koren (talk) 19:14, 7 November 2013 (UTC)

Remote autocompletion

Is this really intended to give a comprehensive list of results [edit: as the documentation states]? I have a case where pages need to be selected from a list of 10,000+ items, but the autocompletion function is very far from comprehensive. Are there any special requirements we should be aware of? Cavila (MW 1.19.7, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2} 22:06, 13 November 2013 (UTC)

First of all - are you really using SF 1.5.2? Or is that a typo, and should it read "2.5.2"? Yaron Koren (talk) 13:46, 14 November 2013 (UTC)

Thanks for alerting me of the typo. As you suspected, it ought to have said SF 2.5.2. I guess I'm hitting a limit. Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 22:42, 14 November 2013 (UTC)

Alright - that's good to hear. :) It depends on what you mean by "comprehensive" - the autocompletion shows a relatively small number of values at any one time (10 or 20 or something), but as the user keeps typing, they should eventually see the value that they're looking for. Is that not happening? Yaron Koren (talk) 23:49, 14 November 2013 (UTC)

It isn't, unfortunately. I've also tested remote autocompletion on #forminput and got the same behaviour:

• FWIW: according to Firebug (DOM), "wDiffBlankAfterMax" is set to "1000" and there are only 1000 results listed under "values".
• Many relevant results still do not turn up when you keep typing, apparently because the values available for autocompletion remain restricted to a list of 1000 (those listed by Firebug under "values"). P.S. I'm not sure this is any different from a situation without remote autocompletion.
• Side-note: along the way, I noticed that adding "remote autocompletion" to #forminput is interpreted as button text (i.e. the text shown on the edit button, like "create/edit this page") if you don't specify any button text yourself. Just a minor bug.

Let me know if there's any information you need. Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 13:26, 15 November 2013 (UTC)

Sorry, I didn't really understand any of your notes. Is the issue that, at a certain point after you start typing, no values are shown? Or are some values shown, just not the one you're looking for? And could the issue be related to the handling of spaces or accented characters? Yaron Koren (talk) 14:38, 15 November 2013 (UTC)

OK, rephrased. On hindsight, it simply looks like adding 'remote autocompletion' to the form field achieves nothing. Maybe the ajax call to the server fails somewhere along the way. I can't tell if spaces have anything to do with it. Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 16:12, 15 November 2013 (UTC)

Alright. Is this happening for both regular form fields and #forminput, or just #forminput? Yaron Koren (talk) 16:47, 15 November 2013 (UTC)

This behaviour also applies to form fields, yes. I decided to do some further testing and found that there can be more than one cause for this:

1. "remote autocompletion" works fine with "text with autocomplete" or "textarea with autocomplete", but not with "combobox". Having "combobox" as the input type for the field will produce the same behaviour that I described for #forminput.
2. When there is more than one field on the same page that autocompletes on a given category, all fields need to have the "remote autocompletion" parameter added in the form syntax in order for this function to work. It took a while for me to figure that out.

Mystery solved! In addition to this, remote autocompletion can also partially 'fail' in that pages in lower-level categories are not shown to the user. Any idea how many category levels are taken into account during autocompletion? Is there a configuration option to increase the number? Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 22:25, 15 November 2013 (UTC)

I wasn't aware of that - no, there's no configuration for it; it sounds like a bug. At how many levels does it stop working? Yaron Koren (talk) 15:47, 17 November 2013 (UTC)

As far as I can see atm, it's still working at three levels (the top one and two lower levels), but sub-categories lower down the hierarchy are not included I'm afraid. Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 20:55, 17 November 2013 (UTC)

Just two other limitations with autocompletion in general, if you can bear with me : ) Because I wanted to have autocompletion on two subproperties (both of type "Page"), I thought I could add the parent property to "values from property=", but no results are shown to the user. The next option I imagined would be to create and use a concept that contains the two properties separated by OR. This does produce a list of selectable values, but typing has no effect other than boldening the typed phrase. Because the list otherwise remains the same, the user needs to scroll down to select a value. Luckily, there is a third alternative: having two declarations of "values from property=" within the same form field seems to work I think. Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 1.8.0.5, SF 2.5.2) 16:36, 24 November 2013 (UTC)

Create a Class link doesn't work

I fill out all the fields, then click create. A page is displayed telling me that " Properties, template, form and category will be created. "

But nothing happens

I have:

• SMW 1.8.0.5
• Semantic Bundle 1.8.0.5
• Semantic Forms 2.5.3
• Mediawiki 1.21.1
• php 5.3.24
• on IIS 7

I have this in my localSettings.php $wgMaxShellMemory = 512000;

Been working on this all day.

Thanks

Wade

It could be that your job queue is stuck, for one reason or another - running runJobs.php might help. Yaron Koren (talk) 13:13, 20 November 2013 (UTC)

My runJobs.php seems to be hanging. How do I see a list of jobs that are waiting to be run?Wade Courtney (talk)

Unfortunately, I don't think there's a way to do it from the wiki, but if you have access to the database you can look at the contents of the "job" table. Yaron Koren (talk) 19:20, 20 November 2013 (UTC)

Thanks I'll give that a try

Wade Courtney (talk)

Bar graph from Sum?

I'm trying to figure out how to get the jqplotchart to display a simple bar chart based on a "sum" from a property. I figure it must either be done by a) putting an #ask query in a template and calling that template in another query with format jqplot chart - or b) using a compound query - or c) this functionality is built into the jqplotchart result format and I'm not bright enough to figure it out yet.

Sorry if this is the wrong discussion page to ask this but the Results format discussion page doesn't seem to get much attention and I really just need someone to point me in the right direction. Searching all the discussions and email list I haven't been able to find any mention of how to do this. Thanks in advance DaveL (talk) 14:42, 22 November 2013 (UTC)

Yes, this is not the right place. Did you try asking there? Anyway, (a) seems like the right approach - there's no SMW equivalent yet to doing a "SUM()... GROUP BY". Yaron Koren (talk) 15:47, 22 November 2013 (UTC)

ok, thanks DaveL (talk) 17:04, 22 November 2013 (UTC)

Placeholders and Internet Explorer

In several of the forms I have created, I use the "placeholder" parameter to set help text. Typically it looks something like "Example: EVA Ratchet". In Chrome, it appears gray and once the user begins typing in that field the text goes away. In Internet Explorer, though, the text appears as black "real text" and does not disappear upon selecting that field or typing a character. To make things worse, when the user tries to select the placeholder text and delete it, autocompletion values pop up in a list. No matter how the user tries to avoid entering a value, it forces a value into the field from the list. The only workaround we could find was to enter a space to keep the field "empty" (even though that probably now has a value of a space).

I could modify the form to hard-code the help text above or below the field instead of using the placeholder feature, but I was hoping there was a way to get IE to play nicely. Any thoughts?

--Darenwelsh (talk) 23:22, 26 November 2013 (UTC)

Oh - I wasn't aware of that problem; it turns out that IE only started supporting "placeholder" in IE 10. What version of IE are you using? And does this problem only occur when you also have autocompletion enabled for that field? I couldn't quite get that from your question. Yaron Koren (talk) 15:31, 27 November 2013 (UTC)

I just compared Chrome 31.0.1650.57, Firefox 17.0.9 (enterprise version) and IE10. I think a table will make it easier to view. I was expecting to be testing placeholder but found a problem with autocomplete, too, relating to IE10's many different browser modes. Sigh...

Browser	Overview	Placeholder	Autocomplete	Autocomplete list	Placeholder + Autocomplete	Placeholder + Autocomplete list
Chrome 31	Placeholder text is light gray. Regular text is black.	Works as expected	Works as expected	Works as expected	Works as expected	Works as expected
Firefox ESR 17	Placeholder text is light gray. Regular text is black.	Works as expected	Works as expected	Works as expected	Works as expected	Works as expected
IE10 (Browser Mode = Compatibility View)	Placeholder text is black, very very close to the same color as normal entered text.	Text disappears immediately when field is given focus, rather than disappearing when user begins typing. Textareas do not show placeholder text (Only works on input type=text).	Autocomplete not working. See error below.	Autocomplete not working.	Placeholder functioning same as placeholder-only. Autocomplete not functioning.	Placeholder functioning same as placeholder-only. Autocomplete not functioning.
IE10 (Browser Mode = IE10)	Placeholder text is black, very very close to the same color as normal entered text.	Text disappears immediately when field is given focus, rather than disappearing when user begins typing. Textareas do not show placeholder text (Only works on input type=text).	Works as expected.	Works as expected.	Placeholder functioning same as placeholder-only. Autocomplete works as expected.	Placeholder functioning same as placeholder-only. Autocomplete works as expected.

IE10 Javascript Console Errors:

• HTML1202: https://example.com/wiki/index.php?title=Special%3AFormEdit/OCAD is running in Compatibility View because 'Display intranet sites in Compatibility View' is checked. (I replaced my domain with example.com)
• SEC7115: :visited and :link styles can only differ by color. Some styles were not applied to :visited.
• Exception thrown by ext.semanticforms.main: Member not found.

The above is from when I had the Browser Mode set to "IE10 Compatibility View" and document mode in "Standards". When I switched to browser mode "IE10" it made autocomplete work. So everything FYI, I still get these errors, but they don't appear to affect anything:

• HTML1509: Unmatched end tag. index.php, line 153 character 1
• HTML1509: Unmatched end tag. index.php, line 176 character 1
• HTML1509: Unmatched end tag. index.php, line 188 character 1
• SEC7115: :visited and :link styles can only differ by color. Some styles were not applied to :visited.

I don't have IE<10...so someone else please feel free to add rows to the table.

--Jamesmontalvo3 (talk) 18:53, 27 November 2013 (UTC)

Um, wow, thanks. That's pretty comprehensive! The IE "compatibility view" thing is a known issue - all Javascript breaks. It's mentioned here. That's good to know about the textarea problem, though. Yaron Koren (talk) 20:35, 27 November 2013 (UTC)

Column format for multiple instance forms

Hi,

I'd like to have a form that has rows that can be added via the "Add another" button. I've got it all to work except for the fact that I want the fields to be displayed horizontally instead of vertically with one header row describing each column. I've seen the Extension:Semantic Forms/Defining forms#Sample form which is fine for having the fields vertically but this is not what I want.

I've also seen these discussions which elude to the same thing but solution is not forthcoming:

• Extension talk:Semantic Forms/Archive September to October 2010#Pivot and combine multiple instance template tables on final saved page
• Extension talk:Semantic Forms/Archive September to October 2012#Multiple instances with one header row

I've used the first item's suggestion of creating a template for the header and the footer:

The header template called Template:Attribute Header:

{| class="wikitable"
|-
! Attribute Number !! Attribute Name

The footer template is called Template:Attribute Footer:

|}

Then in my form I have the following:

{{{for template|Attribute Header‎}}}
{{{end template}}}
{{{for template|Attribute Detail|multiple}}}
|-
| {{{field|Attribute Number}}} | {{{field|Attribute Name}}}
{{{end template}}}
{{{for template|Attribute Footer}}}
{{{end template}}

But this does not work as the output seems to ignore the fact that it's all one table. What am I doing wrong?

Is there an example somewhere like this for me to view?

Any help would be greatly appreciated! --Ironswalt (talk) 13:23, 3 December 2013 (UTC)

Hi - you can't do that within a form (the template instances will have to be above and below one another), but you might be able to do that within the page itself - which might be the only thing you were asking about. If so, I would think that's just an HTML/CSS issue, when putting that template together; and thus not really an SF issue. Yaron Koren (talk) 15:45, 3 December 2013 (UTC)

Hi Yaron. Thanks for the quick reply. Yes, I really just need the column widths to be respected. I've tried creating the multiple instance template that contains a table with specific column widths. However when fields are placed in the cells, the column widths are changed and there's lots of white space after the field but before the end of the cell. Do you have any suggestions on how to fix the widths better? --Ironswalt (talk) 06:03, 4 December 2013 (UTC)

Again, this isn't an SF issue, but if you put the template on a public wiki, like http://scratchpad.referata.com, it might be easier to diagnose. Yaron Koren (talk) 12:14, 4 December 2013 (UTC)

I found this example at Referata.com and it's sorted out my page layout nicely but since you've confirmed that fixing the form to behave similariy answers my question. Thanks again for your help. Cheers! --Ironswalt (talk) 12:16, 5 December 2013 (UTC)

Objects duplicates with multiple templates

Hi, I found an old entry in archive talk (2010) describing a de-duplicates problem when two SIO objects have the same data. The bug is said to be fixed, but I'm experiencing the same bug! My wiki is private so I won't be able to provide URL... My versions are: MW 1.17 SF 2.51 SMW 1.8

This sounds like an SIO issue, no? Yaron Koren (talk) 12:14, 4 December 2013 (UTC)

Hi, thx for reply. I can't tell whether it is SIO or SF. The problem appear when I save a form-edited page containing identically filled templates. Those templates are containing SIO. If I have two identical SIO, saving produces four!

I'm guessing it's an SIO issue - there's no reason why saving the page with a form vs. with the regular edit page would have any effect on that kind of thing. Yaron Koren (talk) 04:11, 12 December 2013 (UTC)

Conflict with WikiEditor

I'm seeing a SF conflict with wikieditor. When I add "editor=wikieditor" to a form element I get additional "edit summary", "minor edit" and "watch this page" inputs at the very bottom of the page. See this screenshot.

I get the following two messages in the Chrome JS console:

Exception thrown by ext.wikiEditor.publish: Cannot call method 'split' of undefined
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130525T1…:151

TypeError {stack: (...), message: "Cannot call method 'split' of undefined"} 
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130525T1…:151

And the following from the Firefox JS console:

Use of getAttributeNode() is deprecated. Use getAttribute() instead.
...defined){if(hooks&&"set"in hooks&&(ret=hooks.set(elem,value,name))!==undefined){...
load.p...140436Z (line 34)

Use of attributes' specified attribute is deprecated. It always returns true.
...defined){if(hooks&&"set"in hooks&&(ret=hooks.set(elem,value,name))!==undefined){...
load.p...140436Z (line 34)

Exception thrown by ext.wikiEditor.publish: copyWarnHTML is undefined
load.p...140436Z (line 151)

TypeError: copyWarnHTML is undefined
...m.nodeName.toLowerCase()===name.toLowerCase();},each:function(obj,callback,args)...
load.p...140436Z (line 8)

I've tested this on SF v2.5.3, 2.6 and git master (8856ae6) with the same result. It occurs whether I apply wikieditor to the free text field, other text fields, or both.

EDIT: Per Special:Version I was using WikiEditor v0.3.1, but to check all avenues I pulled git master (also v0.3.1). The problem persists.

EDIT 2: The issue goes away if you don't have WikiEditor's publish/cancel buttons enabled, i.e. if you don't have the following in LocalSettings.php (or certain preferences set I'm guessing):

$wgDefaultUserOptions['wikieditor-publish'] = 1;

Could this preference be disabled by force only in forms?

EDIT 3: I attempted to solve the issue with the following two changes to __construct() in SF_FormEditPage.php, but neither worked:

global $wgWikiEditorFeatures;
$wgWikiEditorFeatures['publish']['user'] = false;

global $wgWikiEditorFeatures;
$wgWikiEditorFeatures['publish'] = false;

--Jamesmontalvo3 (talk) 19:16, 9 December 2013 (UTC)

Good find with the 'wikieditor-publish' setting - I just added a note about that to the documentation. Yaron Koren (talk) 02:32, 10 December 2013 (UTC)

Issues with categories input type

Utilizing the categories input type is returning the following javascript error, making it unusable:

Exception thrown by ext.semanticforms.dynatree: Object function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery);} has no method 'widget'
TypeError: Object function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery);} has no method 'widget' {}

This was a bug, that was fixed a few weeks ago, and will go into the next version of SF. If you're using Git, you should just update the code - otherwise, you can see the necessary change here. Yaron Koren (talk) 04:09, 12 December 2013 (UTC)

Preloading data when red link is clicked

Hi Yaron, I'm using a default form for my main namespace (with "Has default form"). When a red link is clicked this form is used, which works well. Now I would like to add some wikitext (a draft notice) automatically to all new articles. Can I modify "Has default form" in any way to preload data into the form? Thanks, Stefahn (talk) 20:42, 19 December 2013 (UTC)

I think you can do that by adding "preload=" or "default=" to the "free text" input. Yaron Koren (talk) 22:31, 19 December 2013 (UTC)

Thanks. I know do my preloading directly in the form (with "preload" in the free text and "default" for another field). It works fine :) Stefahn (talk) 20:21, 2 January 2014 (UTC)

[[Creates with form...]] Will a job to autocreate a new page be aborted if the page gets manually created before the job runs?

Or, will the job overwrite the first revision of the page?

I believe the job only creates/edits the page if the page doesn't exist yet. If not, that's a bug. Yaron Koren (talk) 02:18, 23 December 2013 (UTC)

I didn't see an overwrite; I was just asking. Al Johnson (talk) 23:06, 23 December 2013 (UTC)