Extension talk:Page Forms

Property values are not loaded into the SF fields
Hi Yaron, I have a semantic form that uses a template, with a property of type String, and allows several values (an enumerated property). One of the fields was showing automatically these values. The thing is that I change the type of the property form String to Page, and the field stopped showing the values. Then I change back to type String, to fix it, but it remains not showing the values.

Is this a known bug? by the way, Im using SF version 2.5.1.

Cheers, Chei.


 * I definitely haven't heard of such a thing... are you sure the property type was the only thing you changed? Yaron Koren (talk) 15:36, 27 November 2012 (UTC)


 * Yes, Im sure. Inside the template, I've defined a semantic internal objects(SIO extension) that uses this property. Maybe that helps. I was wroking great, until I change its type, then it broke, and I change its type back to fix it, but it is still broken.


 * It could be that adding "|property=property name" to the field tag in the form definition would fix the problem. I don't know why it would have worked before, then stopped working - it could be a bug in SF - but this might be an easy workaround. Yaron Koren (talk) 06:25, 28 November 2012 (UTC)

placeholder for {{#formlink... resp. {{#forminput
Hi,
 * proposal for {{#formlink... resp. {{#forminput
 * add the placeholder-Attribute (like in forms, see http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms)
 * thx ;)

Cheers, --213.33.94.194 14:30, 5 November 2012 (UTC)


 * That makes sense for #forminput, but how would it work for #formlink? And what does "resp." mean? Yaron Koren (talk) 14:59, 5 November 2012 (UTC)

Makes no sense for #formlink though :) --Stefahn (talk) 10:33, 15 November 2012 (UTC)
 * Hi Yaron. I just wanted to suggest the same: add the placeholder parameter to #forminput. It would be great to have that feature - since the placeholder text helps pointing the user into the right direction.

Suggestion: Remove hard-coded background colors for various elements
Hi,

I have installed Semantic Forms and am using it since quite some time. One particular thing I noted is that the various elements are getting assigned usually white or light grey background colors.

It seems that is happening EITHER in one of the CSS or is even hard-coded into the PHP files, such as in specials/SF_CreateForms.php where it says:

// 3 values per row, with alternating colors for rows if ( $i % 3 == 0 ) { $bgcolor = ( $i % 6 ) == 0 ? '#eee' : 'white'; $text .= ""; }

For most wikis that work with a light background color and a dark font that should have no complications, however for wikis with dark skins (such as my own), and very light fonts (white) you will get a white box with all text in white, until you manually disable the color functions.

Suggestion: - Move all color attributions into classes and create one single CSS file title "skin-related.css" where these classes (and its colors) are defined. - For wikis with more than one template and more than one style (various background colors), they could delete these individual classes or leave them empty and re-declare them in their individual skin CSS files

--180.94.145.167 02:31, 7 November 2012 (UTC) Azchael of Rock in China


 * It's a good idea to un-hardcode all the CSS. Most of the CSS already is in CSS files - SemanticForms.css and others. Wouldn't it work to just move the remaining CSS into those files? Yaron Koren (talk) 05:27, 7 November 2012 (UTC)


 * It would work for all elements that are marked up with CSS styles in the PHP files. But for the example as shown above, one would have to change the PHP code to switch from an automatically created table background (either white or eee) to two individual classes that are being assigned (e.g. row_even and row_uneven). --180.94.145.167 07:30, 7 November 2012 (UTC) Azchael of Rock in China


 * Yes, of course. Yaron Koren (talk) 15:04, 7 November 2012 (UTC)

Forward or redirect to result of 1 page query
I could have sworn I saw this somewhere, but I've searched everywhere with no luck. I'm trying to make a short RunQuery that takes you straight to a page with the entered information. So for example, if someone Selects Texas for state, and Austin for city, the search will take them to the page Texas/Austin. I tried making a template with the redirect #REDIRECT [/]], but the redirect doesn't initialize. It seems the redirect is thrown into a &lt;p&gt; or turned into a list item. Anyone know how to do something like this? Thanks for the help.

Multiple embedded query forms on same page
Seem to be having a little trouble with this. I have two embedded query forms with different names and different templates on the same page. The user can run one or the other, depending on what they're looking for. This doesn't seem to be working though. When I enter in the information and click search on the first form, the second form on the page complains that there are required fields missing. Is this possible to do, or can you only embed one per page? Thanks


 * That sounds like a bug - though one I'm not surprised by. My guess is that you can get around this, though, by (1) removing all "mandatory" requirements from the query forms, and (2) using #if in the query templates to not display anything if no fields were filled out. Yaron Koren (talk) 16:32, 9 November 2012 (UTC)

Thanks. I'm sure I can figure out something, just wondering if it was a bug or me missing something.

ConfirmEdit integration
Couldn't find anything on this. I have ConfirmEdit with questy captcha on edits and creations. When I go to change a page with semantic forms and click save, it changes the page to a source edit with the captcha question and an Error: A MediaWiki extension prevented the modification of the target page. Is there some settings available to integrate these two extensions that I missed? If not, is there a way to disable source editing for anonymous users, but keep forms editing? Thanks


 * What versions are you using of ConfirmEdit, Semantic Forms and MediaWiki? Yaron Koren (talk) 16:53, 13 November 2012 (UTC)

MediaWiki	1.19.0, Semantic Forms (Version 2.5.1), ConfirmEdit (Version 1.1)


 * Oh, I think I understand - it's not that you can't save the form, it's that the saving happens over two pages, and you want it to all happen on one page. Unfortunately, I don't think there's any way to do that. You can basically do the second thing, though, with the 'viewedittab' permission - see here. Yaron Koren (talk) 22:18, 13 November 2012 (UTC)

Exactly. I saw the ability to get rid of the viewedittab, but I assume the bots would just go straight to the edit page without the button anyway. Surprised the ConfirmEdit guys haven't added support for FormEdits. I'll have to see what I can do to make it a little more user friendly, while keeping it bot unfriendly.

Multiple instance templates using "holds template" and "embed template"
Hello, I've found the link to Extension_talk:Semantic_Forms/Archive_December_2011 and am trying to implement. It's a pretty good example,except it's unclear what content is to be placed into the form, and what exactly should go into the (sub)templates pages. I believe the main content described there goes into a form, but am unsure. I've somehow created a template loop when setting this up, so some more clarification on this functionality would be useful. Patelmm79 (talk) 17:03, 13 November 2012 (UTC)


 * Do you understand the basic difference between forms and templates? Yaron Koren (talk) 22:19, 13 November 2012 (UTC)


 * Of course, I've set up and edited both as well. What's not clear though, when creating a template of templates and then implementing via form, is how the template would look (especially in the case of trying to create a header row of multiple instance templates). The loop does not exist anymore, and the list of instances now appears in the form, but now my trouble is that I'm unable to save new instances to the list (I hit save, but nothing happens, nor does an error message result.) So there's still something off in my code, and I believe it has something to do with how I set up the templates.Patelmm79 (talk) 22:53, 13 November 2012 (UTC)


 * Sorry, what do you mean by a "template of templates"? Yaron Koren (talk) 23:46, 13 November 2012 (UTC)


 * Quoting from Semantic froms archive mentioned above: "The page itself in this case would use 4 templates. A main one called  with 3 variables,, , and , which actually call a template themselves"


 * Oh, I see - you're talking about a template field that holds multiple templates. If it's not working with you, I'd suggest copying your form over to a public wiki, like http://scratchpad.referata.com, so that it's easier to debug the problem. Yaron Koren (talk) 14:24, 14 November 2012 (UTC)


 * Yaron, thanks a lot for your help. Here is the page: http://scratchpad.referata.com/wiki/Multipleinstancetemplate  Patelmm79 (talk) 17:32, 14 November 2012 (UTC)

Okay - you could have actually set up the form, but this is fine. Your #forminput call, and the "wikiPreview" div, both seem to be in the wrong place - either of those could be issue. Yaron Koren (talk) 18:06, 14 November 2012 (UTC)


 * Gotcha. I set up the form and made changes as you suggested. I'm able to save the form now.  But my remaining issue is, how do I apply formatting so that I can get a table of information to appear?  If I apply a wikitable class to the main template, only the first row of data is formatted.  If to the subtemplate, the subsequent rows are formatted.  Both at the same time does not quite work either See http://www.referata.com/wiki/BankBranchData Patelmm79 (talk) 20:58, 14 November 2012 (UTC)


 * Hi - you shouldn't put stuff on referata.com, but only scratchpad.referata.com. Anyway, I think I mostly fixed the problem in your template. Yaron Koren (talk) 21:56, 14 November 2012 (UTC)


 * Oops sorry, In any case, that fixed the issue perfectly, thanks for your help! It's clear that there's actually nothing complicated about the templates which would be caused by the extra complexity in the form, it's simply a matter of having the table contained in the main template, and the fields in the subtemplate. Patelmm79 (talk) 14:59, 15 November 2012 (UTC)

how stop creating new pages through #forminput
We are trying to control the naming convention of our pages. I have given the users #forminput to do searches but they are inadvertently creating new pages through this...

Should I being using a different call? Maybe I could answer this myself by testing. Just thought I could get a quick answer. let me know. Thank you again. Margaret--Amblerllc (talk) 02:51, 14 November 2012 (UTC)


 * Hi - you definitely shouldn't use #forminput to do searches. Do you know about Special:RunQuery? Yaron Koren (talk) 13:36, 14 November 2012 (UTC)

Performance issues with pauses
I'm getting a lot of pauses when filling in Search RunQuery forms. Typically the page takes quite a while to load, then each of the fields and drop downs take about 2.5 seconds to actually blur the field or drop down. Autocomplete on or off doesn't seem to matter. Filling in regular forms don't have the problem either. This is all on a pretty beefy dedicated server with only a few pages for testing. I've been modeling my search after the one on www.wdoc.org, and don't see anything obviously different in the code, except for use of the "values dependent on". I even noticed the skin's search box will take a few seconds to blur when on a RunQuery page. Any idea what it could be, or how to fix?


 * I assume all the slowness is due to JavaScript, which is client-side, so the server isn't causing the slowness; it's your computer. Maybe you have too many applications running? That's always my problem. Yaron Koren (talk) 21:58, 14 November 2012 (UTC)

I Noticed on selecting the field it loads api.php from load.php before showing the cursor in the field. With wdoc.org's site, it doesn't try to load api.php until you start typing into the field. It also takes a little over a second to load on mine vs 231ms on wdoc. Not sure if it matters, but mine also doesn't have the little thinking gif when typing in the field. Did I miss a setting for choosing when it attempts autocomplete?


 * Autocompletion is set within the form definition. Are you using the same versions of MW, SMW and SF in both? Yaron Koren (talk) 16:01, 15 November 2012 (UTC)

wdoc.org isn't my site, but he is running MW 1.17.0, SF (Version 2.2), and SMW (Version 1.6.1). I'm running MW 1.19.0, SF (Version 2.5.1), and SMW (Version 1.8 beta 2). So obviously his versions are a good bit older. I was referring to there maybe being a setting that determines after how many characters it loads the autocomplete. Maybe between the different versions it was set to 0 characters instead of 1, or something like that?


 * No - but there's the "remote autocompletion", which uses Ajax (and api.php) to do autocompletion. My guess is that WDOC is using it for that field. Yaron Koren (talk) 17:16, 15 November 2012 (UTC)

Ok, so we both have "remote autocompletion", but he doesn't have "values dependent on". I just removed it on mine, and now it's behaving similar to his and only auto-completing on a character press. I really need the "values dependent on" feature though, so hopefully there's a way to get it to behave right with the option in there?


 * What do you mean, "behave right"? I thought the issue was just the speed. Yaron Koren (talk) 17:59, 15 November 2012 (UTC)

Sorry, I just mean for it to only start requesting autocomplete when the user inputs a character like it does without the "values dependent on" isn't in there.


 * Just to clarify: what you're saying is, with SF 2.5.1, when you have "values dependent on" and "remote autocompletion" in the same field, it doesn't actually seem to be doing remote autocompletion? Yaron Koren (talk) 19:52, 15 November 2012 (UTC)

Sorry if I'm not explaining this well. It does seem to do the remote autocompletion just fine with "values dependent on", it's just doing it too early. When you have "values dependent on" set, it does the ajax query for autocomplete results before a character has even been entered into the field. So just selecting the field causes a query for autocomplete on nothing. When you don't have it set, it does it on each character press. So selecting the field does nothing, but entering an "a" does a query for everything starting with an "a", and so on.

Error after install
I am getting this error   after a new install. Here is the wiki's version page as it was during the error. As you can see Semantic MediaWiki is installed and working. Database setup ("Database installation and upgrade") & Automatic data update ("Data repair and upgrade") were successfully completed. I apologize I could not find this subject in the archives. Mlpearc ( powwow ) 03:40, 15 November 2012 (UTC)


 * My guess is that you just put the SF inclusion in LocalSettings.php before the inclusion of SMW, instead of after. Yaron Koren (talk) 14:53, 15 November 2012 (UTC)
 * DUH :P Thanx  Mlpearc  ( powwow ) 17:44, 15 November 2012 (UTC)

auto complete not working on category????
I'm struggling.

I have two fields. Both are suppose to be auto completing on a category. One is working and the other is not.

But here is the weird part. The one that isn't working does find all the entries that I imported using data transfer.

I am using a two different forms to populate the two different categories.

I am using a tabbed form with the fields that are suppose to auto-populate.

I am using embedded templates in the tabbed form.

Can you help? Thanks, Margaret User:Amblerllc

Tabbed form: = Providers =

{| class="formtable" ! Provider: ! Other Contact:


 * What do you mean by "The one that isn't working does find all the entries..."? Is it autocompleting, or not? Yaron Koren (talk) 15:39, 29 November 2012 (UTC)
 * My form that is populating the category... those entries are not being found by the auto-completion. I see the entries in the category though. The Provider name field is NOT auto completing and the Other Contact Agency is auto completing.


 * Well, I'm still not sure I totally understand, but - try adding "|input type=text with autocomplete" to the "Provider Name" field. Yaron Koren (talk) 04:24, 30 November 2012 (UTC)

Ill try again cause this is strange. I used Data Transfer to bring records in to the db. The template places them in Category:Provider. I have a form that creates new records and places them in the same category, Category:Provider. When I do a search using a field that auto completes on Category:Provider only the records that were brought in using Data Transfer are found. But I can see ALL the records in Category:Provider. So they are there, just not in auto-complete.


 * Ah! Now it's about 10 times clearer. My guess is that there's a bug here where MediaWiki thinks there are two different categories, both named "Provider"; that sometimes happens. Assuming the category is set by the template, I would try making a small change to the template, and resaving it - that might fix the problem. Yaron Koren (talk) 15:22, 2 December 2012 (UTC)

Form vanishes after preview
Hi Yaron,

when previewing a page one is transferred away from the form input and only sees the usual wikitext editor. I found this problem described here and you said you would fix this. What is the status of this fix if I may ask?

My users get confused if they don't see the form after previewing their input...

Thanks!

--Stefahn (talk) 15:49, 29 November 2012 (UTC)


 * Hi - yes, that functionality was added into SF years ago. You just need to add the "wikiPreview" div to your form, as described in that talk page section. Yaron Koren (talk) 16:53, 29 November 2012 (UTC)

Thanks so much for your excellent extension and support, Yaron!! Stefahn (talk) 17:57, 29 November 2012 (UTC)
 * Thanks for your quick reply! Okay, now I see why I need this div. I once deleted the div because of this issue (if I hit "Save page" in the preview I get a popup asking me if I want to quit the page). What is the status of this issue? Also, do you know how I can get rid of the scrollbar within the preview?


 * Ah, right, now I remember. Well, the scrollbar issue was recently in the fixed in the code, and it could be that the popup issue has been fixed as well. There have been a bunch of changes to the form-preview Javascript code recently, and they're all going into the next version of SF, which will hopefully be released within a week or so. So I'd recommend upgrading when that happens, and trying everything out then. Yaron Koren (talk) 19:21, 29 November 2012 (UTC)

Multiple-instance templates, new items added on top of the list
When creating new items in a multiple-instance template, the default behavior adds them at the bottom of the existing list. Would it be possible to have the new item added on top of the list instead (newest first rather than oldest first)? Thanks --Xavier Atero (talk) 19:11, 2 December 2012 (UTC)

Form definitions disappear when new a namespace is added to LocalSettings.php
I am adding the following namespace definition to my LocalSettings.php: define("NS_TRANSACTION", 800); define("NS_TRANSACTION_TALK", 801); $smwgNamespaceIndex = 800; $wgExtraNamespaces[NS_TRANSACTION] = "Transaction"; $wgExtraNamespaces[NS_TRANSACTION_TALK] = "Transaction_talk"; $wgNamespacesWithSubpages[NS_TRANSACTION] = true;

This change makes all my previous form definitions disappear:
 * Special:Forms is empty
 * There is no record of the previous form definitions in the deletion log

If I revert back to the old LocalSettings.php the form definitions appear again

My version:
 * MediaWiki 1.20.0
 * Semantic Forms (Version 2.5.1)
 * Semantic MediaWiki (Version 1.7.1)

Anyone?

Thanks --Xavier Atero (talk) 07:28, 4 December 2012 (UTC)


 * There's no reason to reset $smwgNamespaceIndex there - I'm pretty sure that's what is causing the problem. Yaron Koren (talk) 13:48, 4 December 2012 (UTC)