Jump to content

Extension talk:Page Forms/Archive February to March 2011

From mediawiki.org

Show preview button doesn't work

The preview button does work in MW 1.15.3!

After upgrading to MediaWiki 1.16.1 "Show preview" button stopped working in all of the forms, it still works in other pages suck as discussion and other pages that don't have nothing to do with SF.

I am running MW 1.16.1, Semantic Forms (Version 2.0.9) and Semantic MediaWiki (Version 1.5.5)

I don't know if it is relevant but I will mention it anyways, I don't use Properties in my updated MW, just saying maybe somehow Properties are helping to Preview the page.

There was a recent change to the script, try replacing extensions/SemanticForms/libs/SF_ajax_form_preview.js by the latest dev version. (Remember to make a backup copy of the original file.) --F.trott 10:04, 3 February 2011 (UTC)Reply
Unfortunately it still doesn't work! I do have $wgUseAjax = true; in my LocalSettings and no I don't have my wiki online! I know other people have the same problem, so it is not just me!
What exactly happens when you hit the Preview button? Is there any reaction? Javascript errors (Under Firefox see the error console)? Are other people's wikis online, by any chance?
Found the problem one of mine extensions were intervening with the SF.

Copying a form result into an another on submission

I saw that there is often some recurring demands for a nested form feature that would allow to edit a template with a form, and populate some of this template fields with "list of templates" that would also have their forms and would be set on a "multiple" setting.


An example of situation where it would be used was posted earlier in the discussions, here


I made a few modifications that allow to use the "multiple" form parameter with a new "replace" parameter. When the form is submitted, the contents of this multiple templates (a series of {{template1}}{{template1}}{{template1}}... string ) is copied into the template used by the main form instead of having these contents hanging outside of the main template. That way, the user can keep a main template without having to split it into many parts (which would made layout modifications difficult).


Note that the current modification doesn't allow to really have nested forms into the main form. Unfortunately, the other forms will still have to appear outside of the main form, but at least the content will be copied into the corresponding template field, and when this template is edited this field's contents will be taken out of the main form and put as multiple form. Being able to have a real nested form would only require to do a few additional changes in the printing method on top of these modifications.

With all respects to Yaron for this great extension, the code in the formHTML function could benefit from some refactoring, 1000 lines in one single function makes it hard to decipher, even with the comments.


To use, in the form add a hidden field mapped to the template field to populate and declare a replace parameter. After the main form, add a multiple form, having a replace parameter equal to the one declared in the main form.


 

{{{for template|TestTown}}}
...
{{{field|town_events|hidden|replace=town_events_field}}}
...
{{{end template}}}

{{{for template|TestEvent|multiple|replace=town_events_field}}}

{| class="wikitable"

! Event name !! Attendance

|-

| {{{field|event_name}}} || {{{field|event_attendance}}}

|}

{{{end template}}}


The changes are in extensions/SemanticForms/includes/SF_FormPrinter.php, function formHTML . I have put a zip here with the modified SF_FormPrinter.php (version 2.0.9), and a txt file describing a test set(each ****** delimiter indicates a new page to make). The parts modified are marker with //addition and //removal comments (9 areas modified)

--MgLy 08:09, 5 February 2011 (UTC)Reply

Hi - this looks very interesting. It's true that the formHTML() function is way too large - it's the part of the extension most in need of refactoring, though I'm a little afraid to touch it. :( I'd like to ask you some questions about this code - could you email me so we can start a discussion, or find me on the #semantic-mediawiki IRC channel? Yaron Koren 01:56, 8 February 2011 (UTC)Reply

Making Map Input Required

The code below doesn't seem to force the user to enter in coordinates. Is this a bug? Am I doing wrong? Link to Actual Form

{{{
 field 
| Coordinates
| input type=googlemaps
| height=500
| width=100% 
| autozoom=off 
| zoom=6
| mandatory
}}} 

Timothy Clemans 22:44, 6 February 2011 (UTC)Reply

That sounds like an issue with the Semantic Maps extension - I would ask there. Yaron Koren 15:34, 7 February 2011 (UTC)Reply

Embedded "ask" possible

Hi

I am very happy with SF. I would like to do a little trick, but for now am an not successful. I want do embedd a query but I need to substitute a varaible. What I have tried is this template:

{{System
|ClientServer=
|Allgemeinekategorie=
|Banksoftwarekategorie=
|System_kunde_qry=
}}

Bearbeite diese Seite, um den Vorlagentext zu sehen.
{| class="wikitable"
! ClientServer
| [[ClientServer::{{{ClientServer|}}}]]
|-
! Allgemeinekategorie
| [[Allgemeinekategorie::{{{Allgemeinekategorie|}}}]]
|-
! Banksoftwarekategorie
| [[Banksoftwarekategorie::{{{Banksoftwarekategorie|}}}]]
|-
! System_kunde_qry
| {{#ask:[[Category:Semantic_Kunde]] [[Verwendete_systeme::>>>NEED_TO_PUT_NEW_ARTICLES_NAME_HERE<<<]]|format=broadtable|limit=20|offset=0}}
|}

[[Kategorie:Semantic_System]]

Is this possible with some little hack? Thanks Chris --178.82.196.210 11:41, 7 February 2011 (UTC)Reply

You could just use the {{PAGENAME}} variable, instead of hardcoding the name... Yaron Koren 15:36, 7 February 2011 (UTC)Reply
Oh, yes this works! Thx! Chris--178.82.196.210 16:51, 7 February 2011 (UTC)Reply

How to deploy SF?

I have 3 media wikis: prod, test and dev. Now I have made a data model in dev and want to deploy the whole thing into test. How do you recommend to do this? Using Special:Export seems not the best way to me because you only can filter the export by category. And using export entry namespace extension seems to have the problem with the "Category" namespace. This is because I want to export semantic categories but not the whole bunch.

Thanks Chris --178.82.196.210 12:53, 7 February 2011 (UTC)Reply

This doesn't sound like a Semantic Forms question, but in any case, if you're just talking about the pages for the "data model", it's probably not that many, so you could just manually enter their names into Special:Export. Yaron Koren 15:38, 7 February 2011 (UTC)Reply
Hmm ... in fact there are enough pages ... but you are right, I can manually export them. It would be neat if someone could do "export semantic form: xyz" and a "program" is taking care of categories, templates, attributes and forms. Thx, Chris--178.82.196.210 16:55, 7 February 2011 (UTC)Reply
When I've had to do this in the past I've tagged each template, form and category (and sometimes main namespace articles that contain queries and business logic) with a category. That then allows me to quickly dump the data model and business logic to an XML file and load it into another wiki. If the category causes problems on some pages, you can tag all the pages with an empty template, and just add the category to that template for the export, and remove it afterwards. - Borofkin 00:51, 8 February 2011 (UTC)Reply
Thats a good idea Borofkin, thanks for the tip! Chris--85.124.73.210 09:41, 8 February 2011 (UTC)Reply

Why do "Text"-Fields get brackets when I use wiki words/tags

I have a simple attribute of type text:

 {| class="wikitable"
 ! Tätigkeiten EN
 | [[Taetigkeiten_EN::{{{Taetigkeiten_EN|}}}]]
 |}

But when I enter into the testfiled something like "lala [[foo]] ..." the result page is showing

Tätigkeiten EN [[ lala foo ...]], where foo is a clickable wiki word.

Thanks Chris --85.124.73.210 14:10, 8 February 2011 (UTC)Reply

Hi - I bet this is the issue. Yaron Koren 18:16, 8 February 2011 (UTC)Reply
Hi, yes sounds in fact like this. "lead to PHP crashes (!) when very long texts are used as values.", would just be cool to know how long "very long" is :-) But I think I can test this out :-) ... tomorrow ...
I have setted this to true but its still like before. I cleared browser caches and did a modification on the property .... no luck ...
Did you set it to true below the inclusion of SMW? Yaron Koren 19:04, 9 February 2011 (UTC)Reply

populate field from #forminput

Is there a way to populate a field within a form with what is entered in the #forminput text field? --Dgennaro 19:48, 9 February 2011 (UTC)Reply

I do not think so. Maybe you could use the one-step process? --F.trott 20:28, 9 February 2011 (UTC)Reply
Actually, I think it's possible, if you add stuff like "template-name[field-name]=value" to the "query string=" parameter. Yaron Koren 21:01, 9 February 2011 (UTC)Reply
Oh, never mind, I misunderstood the question - you're talking about setting other fields to the page name. You can't do that, but maybe you don't need to, if you tell people something like "leave this field blank to have it be set to the page name", and then use a combination of #if and {{PAGENAME}} in the template. Yaron Koren 21:04, 9 February 2011 (UTC)Reply
Yeah, I wish I could do that, but they want instant gradification. The best I can do is have two forms. One to add and one to edit (the edit would contain the editable "page name" field). Thanks for getting back to me so quickly. --Dgennaro 22:52, 9 February 2011 (UTC)Reply

Related to this, I would like to set a field's default value to the current page using default={{PAGENAME}} or something similar to what's done with now and current user. I'm using multiple Semantic Internal Objects created by the page's form, and need to set a parent field inside each of these objects to the current page. I figure the best method is to have the page's form pass a hidden field set to the current page name to the internal object template. Is this possible? Maybe there's an easier way to refer back to the parent page for an internal object? Does it make sense as a feature request? --Dmulter 19:46, 23 February 2011 (UTC)Reply

It makes sense as a feature request in general, but for your case it seems to make more sense to take the same advice I gave above - use {{PAGENAME}} directly in the template. Yaron Koren 21:45, 23 February 2011 (UTC)Reply
I can't do it in the SIO object template since the PAGENAME there is the name of the object (PAGENAME#1, etc) instead of the parent page name, and I don't see how the template for the parent can test for field values across multiple SIO objects created using their SIO forms/templates. I understand how I could do a #if for a parent field and then set it to something different. If it helps, the parent is a company page, and the SIO objects are multiple activity entries with fields for date, type, description, plus the parent field. I created a basic example based on my question here, that I'm also using to track down an SIO duplication problem as well. --Dmulter 22:53, 23 February 2011 (UTC)Reply
Okay, forget what I said before; the answer's even simpler than that. #set_internal already stores a property pointing to the page it's on - the first one, i.e, "Is activity" in your case. I would rename that property to something more meaningful, like "Is activity for company". Yaron Koren 02:50, 24 February 2011 (UTC)Reply
Awesome! I figured it was something simple like that, but never saw it in the docs. I actually use activities for more than just companies, but I fully understand the need for good names. Thanks for the great responsiveness as well. --Dmulter 03:11, 24 February 2011 (UTC)Reply

MW 1.16.2 and FancyBox

I have just upgraded from MW 1.16.0 to 1.16.2 and I have noticed that the FancyBox upload window is now not working correctly. They upload screen now takes up the entire screen and does not navigate back to the form after uploading a file. Please help. Thanks, --Dgennaro 19:50, 10 February 2011 (UTC)Reply

Hi - I thought this was fixed in a recent version of SF. If you're not using the latest version (2.0.9), I'd suggest upgrading. Yaron Koren 07:07, 11 February 2011 (UTC)Reply
I am running too many wikis. I thought this one had the most up to date version of SF, but I was wrong. Thanks for helping me through this tough time. :) --Dgennaro 15:32, 11 February 2011 (UTC)Reply

Multiple forms → accidental remove?

Hi,

when I use the “multiple” form variant and click remove, there is no warning. I already removed accidentally a form. What about to introduce a JavaScript confirm or step back? I know remove means remove, but just in case … --Andreas Plank 14:43, 11 February 2011 (UTC)Reply

Hi - I assume you mean multiple *templates* (actually, the usual term is "multiple-instance templates"). You can, of course, use the history page to restore whatever was deleted accidentally, thought that's sometimes a pain. It would be nice to have an "undo" feature, though I don't think that's possible. And having a "confirm" popup on every removal seems like overkill. Yaron Koren 17:54, 11 February 2011 (UTC)Reply

Do I have to have class="wikitable" in my template?

When I create template using SF i get this line of code added to the template

{| class="wikitable"

I was wondering do I really need to have that line of code or I can remove it? The reason i am asking is that the line of the code adds some kind of spacing/break on the top of the output page.

You can definitely remove it - you can basically structure the template however you want. Yaron Koren 04:51, 14 February 2011 (UTC)Reply

Size of Templates

Out of curiosity, when you use SF with templates, is it easier on the system to have multiple smaller templates, fewer larger templates,fewer partial forms, etc.. or does it matter and why?--76.233.8.127 23:45, 13 February 2011 (UTC)Reply

I've never done any real performance testing, but I don't think it matters. Yaron Koren 04:53, 14 February 2011 (UTC)Reply

How tight is the dependency to SMW ?

Hi, It seems (from looking at the documentation) that SF forms can be used to populates templates with no semantic markup at all. I don't want to use SMW on my wiki, but wish to use SF, so I was wondering which parts of SMW are required for SF to work (database tables ? PHP code ? both ? something else ?). --Kevin

All of SMW is required - the code and the tables. SF uses SMW for its operation in a number of ways, like the "Has default form" property. Yaron Koren 18:06, 16 February 2011 (UTC)Reply

Edit a existing form

If I would like to create a new form, I can easily create it using a select box to add templates. Is this also possible if I want to edit a existing form? -- Pieter

Unfortunately no - all subsequent editing of a form has to be done by hand. Yaron Koren 15:00, 17 February 2011 (UTC)Reply

How to use numbers in scientific number notation in Semantic Forms?

It seems that you can not use numbers in scientific notation ( -1.2e-3 ) in forms - you get "must be a valid number" error. Is there a workaround? SMW accepts scientific notation of numbers so I would expect that Semantic Forms would accept them too...

Possible workaround:

in file SF_FormUtils.php you need to change (works with MediaWiki 1.16.0 and Semantic MediaWiki Version 1.5.1_1 and Semantic Forms Version 2.0.0_1 [B216]):

} else if (type == 'number') {
			if (field.value.match(/^\s*\-?[\d\.,]+\s*$/)) {
				return true;
			} else {

to:

} else if (type == 'number') {
			if (field.value.match(/^\s*[\-+]?((\d+[\.,]?\d*)|(\d*[\.,]?\d+))([eE]?[\-\+]?\d+)?\s*$/)) { //Allows scientific number notation
				return true;
			} else {

Could someone comment on this change to code (for example if it breaks something)?

Thanks for this patch! I tested it, and it works great. I just added it to the code in SVN. Yaron Koren 19:03, 20 February 2011 (UTC)Reply

Allowing users to input URL's in form

Hello, I'm trying to set up a form where the user can input an URL. Problem is that URL's that contain an ”=” seem to break the whole thing.

I my form I have something like this:

{{{for template|Links|multiple|}}} Link name: {{{field|1}}} URL: {{{field|2}}} {{{end template}}}

calling a template that says something like:

{{#if:{{{2|}}} |*[{{{2|}}} {{{1|}}}] }}

Is it possible to have the form urlencode the input of a field? Or are there any other solution to the problem?

I think the only solution is to use named template parameters, instead of unnamed (numbered) ones. Yaron Koren 18:46, 20 February 2011 (UTC)Reply
thank you you a lot, that solved it! 213.89.102.42 21:22, 21 February 2011 (UTC)Reply

Passing templates and the Use of Partial Forms

My form is getting too large and I would like to utilize partial forms. I'm trying to figure out how to include/pass-along a template from the main form without actually including the fields in the form. Is there a page I can reference? I have been looking for quite some time. Thanks --208.127.139.166 22:07, 19 February 2011 (UTC)Reply

You can just have {{{for template}}} and {{{end template}}} without any fields between them, or have fields between them but make them all "hidden". Yaron Koren 18:48, 20 February 2011 (UTC)Reply

standard input|free text

for some reason test input: {{{standard input|free text|default=XXX}}} does not work in my form. The input box appears in the form, I can enter text in the box and save this text in the document created with this form, but the default string XXX does not appear in the input box. Is there anything wrong with my syntax? Kappa 17:24, 2 March 2011 (UTC)Reply

No, that should work... what version of MW and SF are you using? Yaron Koren 17:54, 2 March 2011 (UTC)Reply
Thank you very much for your quick answer - it already partially solved my problem: I changed SF from version 1.9.1 to 2.0.9, and now the example specified earlier works. The string, however, I really would like to enter is {{{standard input|free text|default=<noinclude><headertabs/></noinclude>}}}. Unfortunately this strings gets parsed before its insertion and accordingly nothing is included. Is there a possibility to prevent SF from parsing this string?
(The application I have in mind is the following: I would like to create a page containing HeaderTabs, which is meant to be common basic information for all users in different namespaces. This basic information then shall be transcluded in pages of the individual namespaces and enriched with further information in these namespaces. Therefore <headertabs/> shall end the page with the basic information but not the transcluding page. Kappa 21:25, 2 March 2011 (UTC)Reply
Interesting. Using "preload" instead of "default" might work, although an even better solution might be to include "headertabs" within a new template, and then put that below the free text field - you can do that; the free text input doesn't have to be the last thing in the page. Yaron Koren 22:11, 2 March 2011 (UTC)Reply
"preload" worked a little bit better, but still did not solve my problem: My aim: In the page generated by the form I would like to have the string <noinclude><headertabs/></noinclude>
I tried
1) to load this sequence completely with one standard input free text field with preload: in this case nothing is loaded. Obviously the sequence <noinclude>...</noinclude> has been interpreted before preloading took place
2) to load the beginning of this sequence with one standard input free text field and the end of the sequence with a second one. This did'nt work either: in this case the preload page specified for the second field was preloaded twice.
It would be nice to have a parameter for causing the preloaded text to be surrounded with <noinclude>...</noinclude> Kappa 21:07, 19 March 2011 (UTC)Reply

REL1_17

While the main trunk has SF2.0.9 at r83144 [1], the REL1_17 branch is still at 2.0.6 [2], so has not been updated for a while. Are you able to update please? Or am I using the wrong branch to prepare for the imminent release? It seems to be the most up-to-date.

$ svn info extensions/SemanticForms
Path: extensions/SemanticForms
URL: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/extensions/SemanticForms
Repository Root: http://svn.wikimedia.org/svnroot/mediawiki
Repository UUID: dd0e9695-b195-4be7-bd10-2dea1a65a6b6
Revision: 83018
Node Kind: directory
Schedule: normal
Last Changed Author: yaron
Last Changed Rev: 77626
Last Changed Date: 2010-12-03 00:25:35 +0000 (Fri, 03 Dec 2010)

Pete C 13:18, 3 March 2011 (UTC)Reply

Hi - I really should put something in the documentation about this, because it's caused problems for a lot of people: those branched versions are useless for most extensions, including SF, and shouldn't be used for SF. You should instead use either the latest code, or the latest tagged version from here. Yaron Koren 15:09, 3 March 2011 (UTC)Reply
Awesome. I will live on the cutting edge then. FYI I followed the instructions on the Subversion page, which is linked to from the top google result Download. I suggest you provide instructions on (or links from) those pages, as I would miss svn details on extension-specific pages. Pete C 16:28, 3 March 2011 (UTC)Reply

Passing two dimensional arrays to form

Hello, I was trying to make a forminput-article preset one of the values on the first row in a template with multiple instances like this:

{#forminput:form=<formname>|query string=<templatename>[<row>][<fieldname>]=<value>}}

At first FormStart loads with everything at the right place in the url, but when directed to FormEdit it changes &<templatename>[<row>][<fieldname>]=<value> to &<templatename>[<row>]=Array Would it be possible for me to hack SF somehow to avoid this. Hope this made sense, sorry for my English, and thanks in advance for any suggestions (and for the possibly best MW-extension ever!) Here's the page (using an extension to add the variable, but the result is the same regardless of method) //rotsee 15:32, 3 March 2011 (UTC)Reply

Hi - thanks. I understand what you're trying to do, but I don't believe it's possible at the moment. What I'd suggest instead is to use the "preload=" query string parameter, and make a wiki page that matches exactly what you want the starting form to look like. Yaron Koren 15:56, 3 March 2011 (UTC)Reply
Ok, thank you. I will not be able to use preload in this case, so I'll have to skip this feature. I was basically trying, in a wiki with recipies and ingredients, to make a link from all pages on an ingredient saying "create a recipie with XXX", and then prefill the first row in the ingredients table in the recipie form with XXX. Just a small thing to attract more editors, but not worth a lot of work, so I'll just leave it there. rotsee 16:19, 3 March 2011 (UTC)Reply

'Edit with form' tab not showing

Hi, I know this is a recurrent issue, but I've tried all that I could find, and am still unable to get the 'Edit with form' tab to show up on my page.

I tried to set the 'Has default form' property on the category page, with both [[ & {{#set: methods, and with FormName & Form:FormName style of arguments.

I also tried setting the 'Page has default form' property (with the same variations) on both the item itself, and in the template (within the <include> tags).

I checked the SF_Settings.php file and made sure no option prevented this link from showing up.

I ran the "update tables" and "repair data" admin scripts from SMW to no avail.

I re-re-refreshed my pages, and saved the items, forms and category pages countless times.

Editing the item by going to Special:FormEdit/FormName/ItemName works.

Going to index.php5?title=ItemName&action=formedit results in a "No such action" error.

I even restarted my apache server a few times, just to make sure...

I am running Mediawiki 1.16.1, with SMW 1.5h-SVN, SF 2.0.9, SFI 0.4, and SRF 1.5.3 among other extensions (CategoryTree, FlashMP3, Orifice Flash, ParserFunctions, SyntaxHighlight, TreeAndMenu, and FCKeditor).

Help please...

That sounds bad - thanks for the comprehensive info, though. If you go to the page "Property:Has default form", do you see anything there? Yaron Koren 20:18, 3 March 2011 (UTC)Reply
Yeah, tooltip says "Special Property", link is red. I tried creating it with "Hello world" inside. Facing failure again, I deleted it. Still says "Special property". "Has default form" and "Page has default form" are both listed as of type "sps" on Special:Properties, as red links too.
I added a link [[Special:FormEdit/FormName/{{PAGENAME}}|Edit with form]] on the template linked to those objects, and it works... but it's not pretty :/
Okay, that's definitely a symptom of the problem - the "Has default form" page should look like this. Could it be that you have a namespace collision? i.e., your wiki, or one of the other extensions, is using the same namespace IDs as SMW and SF? Yaron Koren 21:37, 3 March 2011 (UTC)Reply
I don't think so. Just to make sure, I disabled all the non-SMW-related extensions, with no positive effect. I also rolled back all the edits I made on the "Property:Has default form" and "Property:Page has default form" pages. They now look like yours, but still no "edit with form" tab.
Hi - well, that's even stranger, then. Some more questions: what version of PHP are you using? And what DB system (such as MySQL) are you using, and what's its version? Yaron Koren 15:44, 7 March 2011 (UTC)Reply

show on select not working in checkbox/es

It seems that in SF v2.0.9 and 2.0.7 show on select is not working with either checkbox or checkboxes. I had to revert back to SF v2.0.1. --Dgennaro 20:57, 3 March 2011 (UTC)Reply

That doesn't sound good... I should note that both of those work for me. If possible, could you try to reproduce this problem on a public wiki, like http://scratchpad.referata.com? That would definitely make debugging easier. Yaron Koren 21:33, 3 March 2011 (UTC)Reply
I have made a sample here. I hope this helps. --Dgennaro 14:55, 7 March 2011 (UTC)Reply
Hi - thanks for putting that together. It works for me, though - clicking on the first two checkboxes definitely has an effect. If it's not working for you - what browser are you using? Yaron Koren 15:41, 7 March 2011 (UTC)Reply
IE7...and I do not have the option of upgrading. Thanks for checking that for me. --Dgennaro 15:55, 7 March 2011 (UTC)Reply
Hi - indeed, it didn't work in IE8, either! I once again forgot to check whether it works in IE - I keep doing that. I just fixed the problem in SVN, and it'll go into the next version of SF, which (good timing) is coming out very soon. Thanks for letting me know about that. Yaron Koren 18:08, 7 March 2011 (UTC)Reply
Thanks! Works like a champ! --Dgennaro 21:18, 9 March 2011 (UTC)Reply

Styling the "free text" area and IE

I know this has already been discussed last month but i still can't find a satisfying solution that doesn't require me to edit SemanticForms.css manually after each update.

The problem is the "auto" width setting, which makes my "standard input" text field shrink in size when i start typing in IE8. Adding a class within the form's definition (class=formtextarea) with an assigned 85% width and 85% min-width parameter has a weird effect in IE8 (but is fine in FireFox, as usual). This is because of the fact that SemanticForms.css "auto" width seems to get a higher priority in IE just as soon as i start typing. The result is a "shrinking" form from 85% down to a certain value (i guess the auto defined is around 50% width).

Ideas:

A possible solution could be to allow assignment of CSS #IDs to SF form fields instead of just classes by adding a "id=" parameter. The ID has a higher priority than the default CSS class, which allows to overwrite certain values. This is also a very "clean" approach as the free text input field only appears once per form.

Changing the "auto" definition in SemanticForms.css is a bad solution since it makes all SF Text fields appear in that huge size and not just "free text".

Another approach would be to split the textarea-classes defined within SF a bit further, allowing to individually style the "free text" area whilst keeping all other SF-textareas within given proportion (aka "auto" width).

Any opinions or solutions on this matter? (Mike)

Hi, Mike - I don't understand; the free text area already has an ID, of "free_text". Isn't that enough? Yaron Koren 17:08, 4 March 2011 (UTC)Reply
Now i feel really dumb. I tried styling with IDs before but had no visible effect in IE8 (god do i hate that browser!). Dunno what i did wrong back then but now it works fine. Guess it was the "min-width" declaration that IE seemed to ignore. Thanks for the help. :) (Mike)
Cool! Yaron Koren 18:46, 9 March 2011 (UTC)Reply

Undefined variable: editButtonsText

Getting this error at the top of Special:CreateForm

Undefined variable: editButtonsText in D:\xampp\htdocs\riftwiki\extensions\SemanticForms\specials\SF_CreateForm.php on line 249

Running MW1.16/XAMPP on WinXP. I've disabled most other extensions looking for a conflict to no avail. Any clues to a fix would be appreciated. 18:45, 9 March 2011 (UTC)

Hi - yes, you've discovered a bug in the latest version of SF, 2.1. I just fixed it in SVN; if you have SVN, just do an update. Yaron Koren 00:07, 10 March 2011 (UTC)Reply
  • That seems to have done the trick. Thanks for the quick fix as usual Yaron. 14:12, 10 March 2011 (UTC)

I was doing some testing with the popup form and I noticed in IE7 there is no scrollbar and in Firefox 3.6.13 the form only displays in 25% of the popupbox, but there is a scrollbar (Firefox 3.6.6 all is fine). Example --Dgennaro 21:50, 9 March 2011 (UTC)Reply

The IE7 problem should be fixed now in the SVN version. Can't reproduce the FF problem on FF 3.6.13 (Linux). There was a change in the structure of popup forms lately. Using the old CSS (e.g. from the browser cache) would cause the effect you saw. --F.trott 22:14, 10 March 2011 (UTC)Reply

forminput and the new field definition syntax

The syntax for field definitions has changed with 2.1 - it's no longer 'autocomplete on ...' but 'values from ...' combined with 'input type=text with autocomplete' (or 'textarea with autocomplete'). But how is it with the #forminput field (as described in the two-step process documentation)? Specifying 'input type=text' there doesn't make sense, because that's given, I guess - but then how to activate autocompletion? --Patrick Nagel 05:29, 10 March 2011 (UTC)Reply

The syntax for #forminput didn't change - it's still "autocomplete on...". Hopefully that's not extremely confusing... Yaron Koren 15:34, 10 March 2011 (UTC)Reply

Font in forms very large

In my Netbook's Firefox, Semantic Forms have a huge font since the update from SF 1.9.x to 2.1. I found that changing font-size: 10pt; to font-size: 100%; in SemanticForms/skins/SF_jquery_ui_overrides.css, under ".ui-widget input, .ui-widget", remedies this, and it still looks good on my Desktop. I'm not sure this is the right approach though, any CSS experts who can comment on that? :) --Patrick Nagel 05:51, 10 March 2011 (UTC)Reply

First of all I don't really get how to achieve it even after i read Extension:Semantic Forms#Pointing red links to a form

Lets say I want red links that users added to the Main Page (or w.e. article) to point to the form. First I added a category into the Main Page

[[Category:MainForm]]

in the Category:MainForm page i added

[[Has default form::ArticleForm]]

that points to the ArticleForm form. Now for ex. i add

[[This is RedLink]]

in the Main Page, instead of pointing to the form, it the points to the regular MW add/edit page page. What am i doing wrong?

Basically, all three of those are incorrect. SF can only apply forms onto links that are actually property tags - like [[Has nationality::This is RedLink]]. You can't just apply forms onto arbitrary links. And, for those property tags, the "Has default form" declaration has to go on the page for that property. Yaron Koren 12:45, 15 March 2011 (UTC)Reply

One-Step process question

Hi... I'm a bit confused about the one-step process. The Manual says I should use Special:FormEdit/Form, but if I do this, all it does is ask me for the missing target.

You must specify both a form name and a target page in the URL

Uh... What? I thought it was the whole purpose of the one-step process to NOT provide a target page in the first place.

Hi - you're probably missing a page-name formula in the form; you need to specify one via "{{{info|page name=...}}}". Yaron Koren 13:07, 15 March 2011 (UTC)Reply
Oh wow, retarded me. Used page-name instead of page name... Doh.

It would be very nice if you could give me an example of how to preload data via formlink. I tried this:

{{#formlink:affiliation|link text=New affiliation|link type=normal|namespace=Affiliation|Affilation[Name]={{#var:name}}}}

but no effect, i.e. the field Name of Affiliation was not preloaded.

ps: In the section "The one-step process" of the extension at the first notion of the formlink parser function it would be useful to link to the manual page (I found it using google):

Extension:Semantic Forms/Manual/The formlink parser function

Thanks very much!

Thomas Gerds 17 Mar 2011 (08:43)

{{#formlink:affiliation|link text=New affiliation|link type=normal|namespace=Affiliation|query string=Affilation[Name]={{#var:name}}}} should work. --F.trott 08:46, 17 March 2011 (UTC)Reply

thanks for the suggestion, now the link at the form page looks like this:

/index.php5/Special:FormEdit/affiliation?Affilation[Name]=Collaborator:yyy%20xxx

but the field Name of the template Affiliation is still empty. also, according to the documentation there are only 4 arguments to formlink:

form, link text,link type, query string

so why does the 'namespace' work?

Thomas Gerds 17 Mar 2011 (15:34)

Ok, I got that wrong, the namespace parameter should be part of the query string. Regarding the preset value it should probably be Affiliation, so I would now try

{{#formlink:affiliation|link text=New affiliation|link type=normal|query string=namespace=Affiliation&Affiliation[Name]={{#var:name}}}}. --F.trott 14:52, 17 March 2011 (UTC)Reply

Checkboxes and show on select

I got a checkbox in my form with a show on select, but the components don't show/hide if I click it. Until I click somewhere else on the page or press tab...

Using IE7. Is this intended behavior or a bug on either IE or SF side? Maybe there is a workaround?

That's not intended behavior, no. What version of SF are you using? Yaron Koren 13:24, 17 March 2011 (UTC)Reply

Preformatted textarea

How can I make a preformatted textarea field? If I have a textarea field called Stuff

[[Has stuff::{{{Stuff|}}}]]

and I add a space in front of it in the template to make it preformatted, only the first line of the textarea content gets formatted. If I instead use the nowiki tag

<nowiki>[[Has stuff::{{{Stuff|}}}]]</nowiki>

the field obviously isn't rendered at all (the article just lists the markup). I also tried making two templates {{Nowiki start}} and {{Nowiki end}}, but that didn't work either.

{{Nowiki start}} [[Has stuff::{{{Stuff|}}}]] {{Nowiki end}}

Please help. --Hermhut 19:33, 18 March 2011 (UTC)Reply

I don't know, but I don't think this is a forms-related question - you're just talking about template formatting. Yaron Koren 19:49, 18 March 2011 (UTC)Reply

Error after update

I updated from 2.0.9 to 2.1.1 today by simply replacing the files.

After that, I wanted to edit a page with SF, but got this error

Notice: Undefined variable: title in C:\Wiki\Apache\htdocs\extensions\SemanticForms\includes\SF_FormPrinter.php on line 351

Warning: Parameter 1 to Parser::startExternalParse() expected to be a reference, value given in C:\Wiki\Apache\htdocs\includes\StubObject.php on line 58

Catchable fatal error: Argument 3 passed to Parser::parse() must be an instance of ParserOptions, null given, called in C:\Wiki\Apache\htdocs\extensions\SemanticForms\includes\SF_FormPrinter.php on line 372 and defined in C:\Wiki\Apache\htdocs\includes\parser\Parser.php on line 302

The page was created with SF 2.0.9, I changed the autocompletion in the form, nothing else.

//edit: Pages created with SF 2.1.1 also cause this error. Running MW 1.16.2 and SMW 1.5.6.

Could you try using the current dev version from SVN? If you do not have an SVN client, just replace C:\Wiki\Apache\htdocs\extensions\SemanticForms\includes\SF_FormPrinter.php with this file: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SemanticForms/includes/SF_FormPrinter.php --F.trott 13:57, 21 March 2011 (UTC)Reply
I can not use an SVN client, but your link worked. I once again see the edit form page and it works, but have this message
Deprecated:  Call-time pass-by-reference has been deprecated in C:\Wiki\Apache\htdocs\extensions\SemanticForms\includes\SF_FormPrinter.php on line 351
Ok, very good. You will have to live with the depricated call for the time being. It's either that or have the Warning: Parameter 1 to Parser::startExternalParse() expected to be a reference. To hide the message setting error_reporting(E_ALL); somewhere at the start of your LocalSettings should work (i.e. disable E_STRICT). --F.trott 14:11, 21 March 2011 (UTC)Reply
I can live with that if it's running again. Thanks for the quick reply! //edit: interestingly the message disapeared without me changing anything to the error reporting.

Compatibility with AbuseFilter

Any thoughts on how to make SF compatible with AbuseFilter so that the SF preview can include the filter warning?    Thorncrag   01:53, 22 March 2011 (UTC)Reply

HeaderTabs not Working after Update From 2.09 to 2.11

Hi, I have Updated my Semantic Forms Extension today. Now my Headertabs (0.8.2) doesnt work anymore and i get the error:

Deprecated: Call-time pass-by-reference has been deprecated in D:\Apache\htdocs\w\extensions\SemanticForms\includes\SF_FormPrinter.php on line 351

SBachenberg 09:49, 23 March 2011 (UTC)Reply

The Error has been Fixed in the latest SVN Version, Thanks to FTrott
SBachenberg 07:02, 24 March 2011 (UTC)Reply

I don't want my user to have to select a pre-determined category and I don't want them to have to worry about creating a category page themselves either.

Rather, I am trying to figure out a way to let my user merely type in a category into my form and for that category page to be created and good to go, including other pages with the same category.

In my Form, I have...

! Category:
| {{{field|Category}}}

At the bottom of the associated Template, I have...

[[Category:{{{Category|}}}]]

Everything works wonderfully (thank you!) but I don't want the user to have to deal with the Edit page as soon as they click on the redlinked category. The new category page includes the category listing featuring that new page (and any other page I've added), but it still prompts the user to have to edit and save the page with additional text which is then displayed in addition to the un-editable page listing.

Any way I can just turn these redlinks into automatically, pre-saved category pages? I can't really get "Has default form" to work because the Category isn't a Property. Basically trying to figure out an easy way for users to tag the pages submitted via the forms.

Tagging could also be done via a dedicated property Has tag, but ok, you asked for categories.
I don't know if this works, but you might try to employ the "creates pages with form" property. This is what I would try:
  1. Create a form and a template named Category for your categories. This might be some dummy form/template that do not actually do anything. It might even be possible to have no template and use an empty form. You'll have to experiment here.
  2. Create a Property:Has category. On its page include [[Has type::Page]][[Creates pages with form::Category]]
  3. In your Template next to the [[Category:{{{Category|}}}]] you put [[Has category::Category:{{{Category|}}}]]
That should be it. Come back and tell us if it worked, please. --F.trott 09:22, 24 March 2011 (UTC)Reply
Thanks for the reply! Unfortunately, it still didn't fix the redlink problem. However, I was able to fix the problem when a friend pointed me to Extension: Uniwiki Auto Create Category Pages. Works well with Semantic Forms so far.
Cool. Thanks. --F.trott 09:48, 26 March 2011 (UTC)Reply

Set default value with result of an inline query [solved]

I have an article, that has some annotated freetext about a project:

Yesterday I talked to Andy about project [[Project::SMW rules]].
I believe we start the project with a probability of [[Project Probability::50%]].

Because the project does not exist yet, it is red linked. Clicking the red link correctly opens the form for projects. What I would like to do now is to populate fields of the form with already existing properties. In this case I would like to populate the field Project Probability with the value 50%.

To achieve this, I use this definition within my form:

{{{field|Project Probability|property=Project Probability|default={{#show: {{PAGENAME}}|Project Probability|link=none}}}}}

As a result I get the field populated with {{#show:.

Any ideas?

--Planetenxin 10:04, 24 March 2011 (UTC)Reply

Update to latest version of SF. The default parameter was only recently enabled to process parser functions. --F.trott 10:22, 24 March 2011 (UTC)Reply
My versions: SMW 1.5.5, SF 2.1.1 --Planetenxin 10:33, 24 March 2011 (UTC)Reply
Then you found a bug in SF's parser, I guess. You could try to help it a bit, but that's really just experimenting, e.g. what about
{{{field|Project Probability|property=Project Probability|default={{#show:{{PAGENAME}}|Project Probability|link=none}} }}}

--F.trott 11:01, 24 March 2011 (UTC)Reply

Now I get an empty field. I also tried to set the default value to PAGENAME. This works as expected. Then i tried to replace the | by &#124;. But also no luck. --Planetenxin 11:28, 24 March 2011 (UTC)Reply
If PAGENAME works, maybe putting the show into a template and calling that template works. Else I am out of ideas. --F.trott 11:41, 24 March 2011 (UTC)Reply
The solution of the above mentioned problem is as follows: The original article page has as title test. The property Project has as type page so that SF opens the form with title SMW rules. PAGENAME gets SMW rules (not test) so that the result of the inline query is empty. In my case the following inline query works as expected:
{{#ask:[[Project::{{PAGENAME}}]]|?Project Probability=|mainlabel=-|link=none}}

--Planetenxin 18:11, 24 March 2011 (UTC)Reply

Querying form variables

I would like to use the values in a preloaded page to control the display of the form, but I don't see how to query those values in my form when the page has not yet been created. The values could be stored by the form's template and then queried using #ask, but that's not possible until after the page is created (and sure would be inefficient in many cases). I'm wondering if one approach is a new SF parser function to query those variables specified in the query string or in preloaded data, eg {{#formvar:templatename|varname}}. Maybe there's a workaround for the time being?
Hypergrove 20:59, 25 March 2011 (UTC)Reply

I responded on the Bugzilla feature request you created. Yaron Koren 17:11, 27 March 2011 (UTC)Reply