Extension talk:Page Forms/Archive January to February 2010

Append "Media:" before the names of uploaded files

After a file is uploaded, I want to create a link to the uploaded file automatically. For example, if you upload a file named "hoge.jpg" and save the page, then the page contains a red link to "hoge.jpg". But, we cannot see the uploaded image by clicking the link. So, I want to change the link to "Media:hoge.jpg". Does anyone have a good idea to do that?

You could achieve this using an Array Map Template. First, create a template with a form that updates a parameter in a template (which you probably already have done). In the example below, this parameter is called files, and the Array Map Template (which is a standard wiki template) is called Formfile.

{{#arraymaptemplate:{{{files|}}}|Formfile|,|}}

Then I created a template called Formfile which looks like this:

{{#ifexist: Image:{{{1}}}|[[Media:{{{1}}}|{{{1}}}]] <small>([[:Image:{{{1}}}|source]])</small>
|  
| '''[[Media:{{{1}}}|Click to upload "{{{1}}}"]]'''}}

The way the template above works a user can either upload the file using Semantic Forms, or just type the name of the file into the field. If the file exists (they uploaded it) it will display a link. Otherwise they'll get a "click to upload" message. --Gkullberg 15:21, 5 January 2010 (UTC)

Autocompletion for multiple properties/namespaces?

Is it possible have autocompletion for more than one property or namespace? For example, it would be nice to be able to have autocompletion on the main namespace and another namespace called "Activity" like this:

autocomplete on namespace=,Activity

Is this possible? --Gkullberg 21:37, 5 January 2010 (UTC)

Unfortunately, no... and I can't think of any hacks around it, either. Yaron Koren 21:56, 5 January 2010 (UTC)

Issue with query string and the two steps process with #forminput

Hi Yaron

I am having difficulties getting #forminput to work with pre-set query strings. I would like to use a #forminput to force certain values to a form (namely, a login name).

If I use a page name that already exists, the query string seems to be lost once the form switched to Edit instead of Add.

If I do add a new page, the query string is preserved and the form fields are populated with the values from the query string.

Is that an intended behavior ?

I am using version 1.8.6

- Laurent Alquier

Hi, yes, this is intended behavior - you can't override what's in the page already using the form. The principle is that just going to the form and hitting "save" should never change the data in an existing page. If you disagree with that, we can talk about that. Yaron Koren 04:11, 7 January 2010 (UTC)

Thanks for the clarification. I agree with the principle - it is safer that way. However, some features of the forms already break that principle (having a field of type List overwrites values in the field that do not match the list for example), and I can see cases where it is beneficial to have a form provide values by query string in edit mode. Maybe having a check for empty values before overwriting with query string parameters could help ? - Laurent

It's true that the principle sometimes gets broken... though that, by itself, isn't a reason to break it further. I'm confused, though: do you agree with the principle or not? Yaron Koren 04:34, 7 January 2010 (UTC)

I do agree it is safer to have this default behavior :) - Laurenr

Return Free Text with #ask

I would like to be able to return the value in Free Text when using #ask to create a table or a map.

For a little more background: I started out with a description field of the type text. It was having problems with wrapping and displaying content. The Free Text field works really well, but I do not know how to access that data outside of calling the form.

Unfortunately, you can't do that - you'll have to go back to using the "Text" type. What were the problems you had with displaying content? It could be that using $smwgLinksInValues could help. Yaron Koren 16:59, 7 January 2010 (UTC)

Upload file tag broken via #formlink

When I add a page by setting an automactic page name, using #formlink, the floatbox to upload a file doesn't appear after clicking the 'upload file' link behind the field.

I made an example of this problem on referata.com:
If you fill out the form the usual way the regular floatbox does appear.
However if you add a page with #formlink: http://www.referata.com/wiki/Linkformlinktest
Clicking 'upload file' opens the upload window as whole page instead of a floatbox.

Is there a way to make the floatbox appear? -JosCo 09:50, 12 January 2010 (UTC)

That's odd, although it's a bit of a minor bug, since the query string you have in there (the last parameter) is incorrect - it's just "Formlinktest", but it needs to be either empty or of the form "template-name[field-name]=value", etc. Yaron Koren 23:10, 14 January 2010 (UTC)

Thanx for the help. It works like a charm indeed. -JosCo 14:48, 16 January 2010 (UTC)

Page content showing up at bottom of form after upgrading to latest version of SF

In my old version of SF, when I'm in a form and I view the source of the page I see a hidden variable like this:

<input type="hidden" name="free_text" value="{{portalheader}}
{{OfferingContentNav}}
The '''Statement Of Work Library''' is a list of SOWs that have been uploaded to the Wiki. (content truncated) 

[[Category:Pages with DPL Queries]]" />

Note: I can't seem to get the above text to display without wiki evaluation so you will need to edit this comment to see what I'm talking about.

However, after upgrading to the latest version, I see a bunch of page content down at the bottom of the form coming from the page that the form is editing. When I view the source of the page it seems that this content is from a hidden form variable that item isn't converting the {'s and ['s to their HTML equivalents anymore:

<input type="hidden" name="free_text" value="{{portalheader}}
{{OfferingContentNav}}
The '''Statement Of Work Library''' is a list of SOWs that have been uploaded to the Wiki.

(content truncated)

[[Category:Pages with DPL Queries]]" />

Any idea what's wrong? --Gkullberg 20:40, 12 January 2010 (UTC)

You've indeed found a bug - this will be fixed in the next version of SF, but it can be fixed now by changing line 1183 of /includes/SF_FormPrinter.inc from:

    $form_text = str_replace('!free_text!', $free_text, $form_text);

to:

    $escaped_free_text = Sanitizer::safeEncodeAttribute( $free_text );
    $form_text = str_replace('!free_text!', $escaped_free_text, $form_text);

Yaron Koren 19:20, 21 January 2010 (UTC)

I still have this problem with partial forms in version 1.8.8. With a regular form it appears to work fine, but if I add the

{{info|partial form}}

tag at the beginning of a form it replaces, for example, a "{" with the corresponding character code. (I'll space it out so it displays: & # 1 2 3). It likewise replaces all vertical pipes and brackets. End result is the template that goes with the form no longer works. I was upgrading all the way from version 1.6: it worked fine there. -- Chris 03:33, 4 February 2010 (UTC)

I was using partial forms fine in version 1.8.5, but when I upgraded to 1.8.8, I ran into the same problem, so I think this bug is due to a recent development.--MiamiVolts 18:13, 5 February 2010 (UTC)

Class 'SMWPropertyValue' not found

After adding the include_once()-line to LocalSettings.php I got:

Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

With error_reporting set to E_ALL I get:

Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183
Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183
Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183
Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183
Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 153
Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10
Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10
Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

Any ideas what could be wrong?

I took the MediaWiki from stable debian package and it's version 1.12.0. The SemanticMediaWiki is also from stable debian package and it's version is 1.2. The SemanticForms is version 1.8.7. I've set the mediawiki to be finnish (not sure if it has something to do with this.)

-- Tero Laxström, 26 January 2010

Hi, the issue is that SF no longer supports versions of SMW before 1.4. I would recommend upgrading your version of SMW (upgrading MediaWiki itself wouldn't hurt either); and if you have any contact with the Debian people, please tell them they're packaging an old version. Yaron Koren 18:03, 26 January 2010 (UTC)

Transclusion of forms (i.e., treating them like templates)

I've created a test form, Form:A. There's nothing special about Form:A; it contents are typical. Now I create a second form, Form:B. The contents of Form:B are:

{{Form:A}}

Now when I visit Form:B, the expected behavior would be that I'd see precisely the same thing that I'd see if I visited Form:A. But that's not the case.

Here I've treated Form:A like a template, "transcluding" it into Form:B. We might like to go farther and perform additional substitution on Form:A, giving it parameters like any template. Why would one want to do such a thing? For situations when it is necessary to dynamically generate a form:

• Complicated data-entry scenarios
• Data pre-processesing steps
• Multi-step data "wizards"
• etc.

My specific use-case requires that I do some complicated pre-processing in order to decide a page name. So, I'd like to have an initial form take care of the page-name-entry steps and dynamically generate a second form where the user inputs the remaining data. Sadly, it seems that forms cannot be treated as templates. Am I correct in this? It is certainly possible that I'm missing something in my attempts to make form transclusion work. If I'm indeed correct, are there any work-arounds or maybe some more concise machinery for doing what I want to do?

Thanks all! And great work on this software! 189.153.80.253 04:40, 27 January 2010 (UTC)

What you're talking about should work, in theory - see here for what may be the problem. Yaron Koren 04:54, 27 January 2010 (UTC)

Yaron, can you recommend a method for creating a multi-step data entry process of the kind mentioned above? I'd like to use Forms to walk the user through some decision steps to make sure they add data the appropriate category. Cheers! 24.206.104.84 21:39, 31 January 2010 (UTC)

You could check out the "Header Tabs" extension - it's a way of separating out form sections that can function sort of like a wizard... Yaron Koren 23:53, 31 January 2010 (UTC)

What would be ideal would be to have one form create another, the second form being of a "temporary" nature in that it would be deleted at the end of the data-entry process. Is something like this possible? 24.206.104.84 16:29, 3 February 2010 (UTC)

That's not possible, although it doesn't sound all that ideal, either... it sounds like a hack. Though then again, I think wizards only make sense when one's input in one set of fields influences what other fields are shown later on - and SF can't do that at the moment either. Yaron Koren 20:26, 3 February 2010 (UTC)

Space in query string #formlink; upload tag not working

When adding a page via #formlink with a space in the query string the upload tag doesn't work.
For an example see this form.
The Formlink is: "http://www.referata.com/wiki/Special:AddData/Formlinktest?Setpagetitle[City]=City with space in name"
The floatbox doesn't appear. I noticed a related bugfix in version 1.2.5. My current SF version 1.8.5.
-JosCo 14:41, 29 January 2010 (UTC)

My guess is that you're using the IE browser - is that true? This seems to be a problem on IE (which I always forget to test on), but not in any other browser. Yaron Koren 16:23, 29 January 2010 (UTC)

Yeah, that's true. I see now in FF it works fine, but I'm afraid I can't really expect all users in the company to change the browser because of this. Would it be possible to make a fix for it, or maybe can you think of a possible workaround for this issue?
-JosCo 15:59, 30 January 2010 (UTC)

No, I can't rely on anyone to give up IE, much as I would like to. :) This will be fixed in the next version. Yaron Koren 13:42, 2 February 2010 (UTC)

Ok, I will check it out. :) Thank you for the great help. -JosCo 15:16, 3 February 2010 (UTC)

"Edit with form"-Tab missing

I've just installed a fresh svn version of mediawiki (1.16alpha, r61710), Semantic Mediawiki (Version 1.5h-SVN, r61710) and Semantic Forms (Version 1.5h-SVN, r61710). After that I used "Create Class". Everything looks fine, except that no "edit with form" tab is shown. --ThomasKalka 12:44, 30 January 2010 (UTC)

This was resolved on the mailing list; the problem was that the current SVN version of SMW is buggy. Yaron Koren 13:38, 3 February 2010 (UTC)

mandatory check stopped working properly

Hi,

I have some forms with a field marked as mandatory.

When the form is saved, and this mandatory field is empty, the error message flashed briefly beside the field, but the then form saves itself anyway.

Any idea what could be wrong? Thanks Jon

Is there a URL for this, or could you reproduce it on a public wiki? Yaron Koren 04:57, 2 February 2010 (UTC)

Problem with the "One-Step-Progress" after Extension Update

Hi, I have a little Problem after updating to the newest Extension Version.

We are using buttons like "Add Person" to create a new Person in our Wiki.

{{#formlink:Person|link text=Add Person|link type=button|query string=super_page=Person}}

The Page name is normally the Persons Name so we use the INFO-Tag like this:

{{{info|add title=Add a Person|edit title=Edit a Person|page name=<Person[Name]>}}}

Before the Update a Person created by the "One-Step-Progress" got the Page name of the Person, but now the Page name is "Person/Your-Name" ???

Can someone help me to change it back to Normal?

-- Simon Bachenberg 11:05GMT+1 - 03.02.2010

I found my error! the "super_page=" Tag seems to work now it should, so everything makes sens :-) after removing it i got what i wanted to have.

-- Simon Bachenberg

The "one-step process," template parameters, and their default values

Form:TestB

<noinclude>
[[Special:AddData/TestB]]
</noinclude>
<includeonly>
{{{info|page name=<TestB[Page name]>}}}
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|TestB}}}
{| class="formtable"
! Page name:
| {{{field|Page name}}}
|}
{{{end template}}}

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

Template:TestB

{| class="wikitable"
! Page name
| [[Has page name::{{{Page name|Default}}}]]
|}

Here, I attempt to set the page name by using the "one-step process." The idea is that, in the event that the user fails to supply the page name via the form, a default name is set. What is relevant, though, is that I attempt to set this default at the level of the template rather than the form. That is, I would like the default name to be retrieved from the default value of the "Page name" parameter in the template. Using such a technique, we could use the template to do complicated pre-processing in order to set the page name. Unfortunately, even this small example fails. Does anyone know why?

Thanks! 24.206.104.84 18:37, 3 February 2010 (UTC)

Note that this is a much simpler use-case than the one I am actually interested in. What I'd REALLY like to do is have a form that requests a "page prefix" and a "page suffix" and sets the page name as a complicated function of the two. The idea is to implement this "complicated function" at the level of the template, where its output would supply the default value to the "page name" parameter for the template, a parameter that can be referenced in the form's info tag. Sadly, it seems that the template may not be fully processed - defaults applied, sub-templates called - before the page name is set. Does anyone have any thoughts on the situation? Thanks again. 24.206.104.84 19:13, 3 February 2010 (UTC)

Hi, you can't set the default in the template - it has to be in the form, as you've discovered. If there's some specific formula you want applied to create the page name, and it's not currently doable in SF, please write to the semediawiki-user list about it - it might require a discussion about how best to implement it. Yaron Koren 17:50, 4 February 2010 (UTC)

Will do. Should I also update the Forms documentation so that it's a little clearer about this lack of capability? 24.206.104.84 18:45, 4 February 2010 (UTC)

Sure - wherever you think there's a clearer way to express something in the documentation, feel free to change it. Yaron Koren 21:28, 4 February 2010 (UTC)

Is the #formlink documentation up to date?

The example from the documentation

{{#formlink:form=Country|link text=Push this button to go to the form!|link type=button|query string=title=Semantic Forms&action=formedit#tab=Summary}}

does not produce a button. Instead, it produces a standard link that looks like link text=Push this button to go to the form! (but minus the little external linky thing). 24.206.104.84 05:02, 5 February 2010 (UTC)

Did you upgrade to the new version 1.8.8. In older versions it worked without the 'Form=', 'link text=', etc. -JosCo 12:56, 5 February 2010 (UTC)

Property sort order for drop down selection box

Is there a way to change the sort order of properties in a form? I've noticed that right now they are listed alphabetically.

{{{field|House size|property=List of sizes‎‎|mandatory}}}

The List of sizes property is: Extra Large, Large, Medium, Small, Minuscule

Yet it becomes this in the select box: Extra Large, Large, Medium, Minuscule, Small --Kjoz 21:38, 5 February 2010 (UTC)

That certainly sounds like a bug, though I can't reproduce it - what versions of SF, SMW and MW are you using? Yaron Koren 07:32, 7 February 2010 (UTC)

Got it fixed. It was an older version of SMW that was the culprit. I should have checked that in the first place. --Kjoz 18:17, 9 March 2010 (UTC)

Adding new Ajax calls

Hi. I would really appreciate if someone can guide me towards JavaScript/Ajax calls inside a form that will enable me to receive values from category based on some other value that was filled in the same form in another field.
So, for example, if I have two fields: field A, field B and field A picks values from category, for example "colors" category, than after I choose "blue", field B will change it's type to "values from category=blue".
I know it's possible in a simple HTML form through js and Ajax, but can this be achieved through semantic forms?
--Gregra 20:03, 6 February 2010 (UTC)

Unfortunately, that's not possible, although it's a great idea, and I hope to add this capability into Semantic Forms at some point in the next, say, six months. Yaron Koren 02:46, 7 February 2010 (UTC)

OK, great! Looking forward for this ability.--Gregra 13:34, 9 February 2010 (UTC)

latex equations in semantic properties failing to convert?

I'm trying to do a SMW with forms setup that defines a property: Basic Equation I've simply set this to [[Has type::Text]] Then added to template ok and to form (I've other properties on form that fill in ok and maths render's fine if put it in the free text area so I know it's not my Tex setup.) Then I try and use form to create or edit page with a form and include some wiki maths in the property value called Basic Equation e.g. <math>\frac{a}{b}</math> When viewing page this then displays an error icon with "The given value was not understood" as a pop-up. I installed SMW via Semantic Bundle version 0.2.1.20091104 giving SMW 1.5g, SMW Forms V1.8.5 Any clue as to getting Tex to render correctly, if not supported then that's fine - help / setup text needs to make that clear though :-)

Update: I've got the property in it's own template and then included in form as follows to get textarea - still not rendering: {{{for template|Basic Equation|label=Basic Equation(s)|multiple}}} '''Basic Equation:''' {{{field|BasicEq|input type = textarea|rows=15}}} {{{end template}}} Many thanks --Rob C 13:02, 8 February 2010 (UTC)

Update2: Math Images Project uses SMW forms and has maths rendering BUT this appears to be because they keep the full image description (which often includes wiki math markup) out of the SMW properties area and simply include in template and create/edit forms as a textarea. This could give me a way out BUT I lose the semantic search then for "Basic Equation" property to find all basic equations across all articles... --Rob C 14:22, 8 February 2010 (UTC)

Hi - this sounds like a Semantic MediaWiki issue, not a Semantic Forms issue, no? Yaron Koren 15:25, 8 February 2010 (UTC)

Sorry - not sure, I've not tried to look into the code for SMW vs Semantic Forms and was not sure which was handling the text from the form text box so started with forms :-) - are you confirming that this is the underlying SMW parsing that I need to report bug on? Thanks for quick response --Rob C 16:44, 8 February 2010 (UTC)

Maybe I misunderstood the question - do the formulas not show up when looking at the form, or the page itself, or both? Yaron Koren 18:58, 8 February 2010 (UTC)

When inputing the text e.g. <math>\frac{a}{b}</math> in the form text box, there is obviously no rendering - which I sort of expected it's a text box.. then when I preview or commit form, the page does not display text just the title of the text box plus error message described above; what I'm not sure of is whether it is the Semantic form that is failing to handle the tex i.e. mangling it in some way as it saves or the parsing of the page afterwards.--Rob C 09:32, 9 February 2010 (UTC)

Well, if you look at the formula in the regular "edit" tab, does it look correct? Yaron Koren 18:40, 9 February 2010 (UTC)

Page source shows {{Basic Equation |BasicEq=<math> \frac {a}{b}</math> }}, so it is not semantic forms mangling data - I guess that answers the issue - I'm off to look at SMW to investigate/report it... thanks very much for prompt help. Just for interest, I've tried out a quick hack at the forms scratchpad site mentioned to make sure it is not my MW setup....and that site has same issue... Referata Basic_Equation_TestPage2 --Rob C 13:56, 11 February 2010 (UTC)

Autocomplete on category is not fully functional

Hi, I love the Autocomplete on category feature, but for me it auto completes on category only for regular pages and not subcategories (opposed to the description on the extension page). Has somebody else encountered that issue?

--Gregra 20:00, 10 February 2010 (UTC)

I can't duplicate this problem. What versions of SF, SMW and MW are you using? Yaron Koren 20:52, 10 February 2010 (UTC)

MW - 1.15.1 in Hebrew, SMW - 1.4.2, SF - 1.8.8.--Gregra 06:58, 11 February 2010 (UTC)

Let me be more specific - it works for regular pages that are located in these subcategories but it doesn't work for the subcategories themselves.So for example if I'll create a category "Color" (Category:Color) and a subcategory "Blue" (Category:Blue). Now if I will add inside some form the "autocomplete on category=Color" syntax in a field and try to type "Bl" it won't auto complete to "Blue" even though this is a subcategory of "Color".--Gregra 14:29, 11 February 2010 (UTC)

Ah, I see. It's not supposed to autocomplete on category names - if there's something in the documentation that gives that impression, that should be changed. Yaron Koren 15:47, 11 February 2010 (UTC)

OK. Well, this feature is pretty important if you have more than one level for categories... Is this something that can be added in the next version?--Gregra 15:49, 11 February 2010 (UTC)

It doesn't make sense to me to have category names autocomplete in the same places as they pages they hold - the two aren't interchangeable. You would never choose between "Cities" and "Geneva", for instance. Yaron Koren 15:58, 11 February 2010 (UTC)

I don't agree. It depends on the architecture of knowledge structure on your wiki. For example, if I want a high inter-connectivity between articles, I will use sub-categories as knowledge items and not just a meaning to define the knowledge structure. For example if I want to manage organizations in my wiki than I'll create "Organization" category and every organization will be a subcategory of this category. It is very helpful when you want to connect certain pieces of information (for example "divisions") to each organization. If I'm not creating all my organizations as categories, then to connect between a division and organization is pretty complicated - you should put a simple link in both of them that lead each to the other. The category solves this.--Gregra 16:18, 11 February 2010 (UTC)

Well, I think a better solution for that connectivity is semantic properties - you should check them out. Yaron Koren 16:35, 11 February 2010 (UTC)

Thanks for the hint, but I'm familiar with semantic properties, and it can't help me with what I need... Anyway, maybe you can point me to the right direction and I'll try to alter the required functions?--Gregra 20:36, 11 February 2010 (UTC)

I encountered this problem too. CategoryTree input type wasn't what I wanted, so I developed a solution that extends the API sfautocomplete action. It alters what happens when you do a combined namespace=Category and category=YourCategory search, which (by definition) should never contain any non-category pages, imho. I e-mailed new code to Yaron regarding this last night so he could consider adding it (or a derivation of it). It also fixes a couple other problems I encountered with limits and parsing of remote autocompletion.--MiamiVolts 21:39, 18 February 2010 (UTC)

Sounds great! Maybe you can upload the code here or send the file to me?--Gregra 21:47, 18 February 2010 (UTC)

Yaron and I are discussing some changes to it, and whether to add it as a patch to Semantic Forms or a new extension. If we go with a new extension, I should be able to upload the code next week. If you want, though, you can leave me your contact info. on my talk page and I'll send you the change we decide upon (patch or new extension).--MiamiVolts 21:10, 19 February 2010 (UTC)

Special page:Template disarrangement ?

Hello

I upgrade to current version from 1.8.6. I notice in my "Special:Template page" that for every templates in the list it ask for "define category" if a template doesn't have one it tries to show the syntax of the template resulting for my default css disturbance (change font size,etc.).

# Media entry defines category: Media (right)
# Misc defines category: Job pictures]][[Client id::Page Forms/Archive January to February 2010...and so on

I don't know if miss something,screw something or if it is a bug?

Msevero 00:15, 12 February 2010 (UTC)

That definitely looks like a bug... Yaron Koren 04:18, 12 February 2010 (UTC)

Free text Position in Template

Hi,

is it possible to position the free text in a template? Otherwise it is alway shown at the bottom of a page.

Hi, yes: if you put it between two templates in the form, it should show up between those two templates in the resulting page. At least in theory: I haven't tested that one out in a while. Yaron Koren 19:21, 14 February 2010 (UTC)

Okay, thank you. I now just used a field with type textarea. I think there is no big difference to using the free text input (except not having annotating possibilities?!).

That should work fine, unless you have template calls within that field - that could cause problems. Yaron Koren 19:54, 16 February 2010 (UTC)

YUI Problems on Autocomplete

I had some problem with trying to get autocompletion working correctly and in the end got it sorted by:

• downloading YUI2, YUI3 does not include the "autocomplete" path in the build folder (specified in SF_Utils.inc).
• setting the path as follows

  $sfgYUIBase= $wgScriptPath."/extensions/yui/build/";
  

  , where

  $wgScriptPath
  

  is the base folder of my wiki install.

--Rob C 15:13, 16 February 2010 (UTC)

Form render bug when using SimpleForms and SemanticForms together

I have a situation where I am using SF for an AddData form, and at the top of that form I'm including a template that has a SimpleForms form in it. Here is the SF form:

{{Template:TemplateWithSimpleForm}}

{{{for template|DataFieldsTemplate}}}
...
{{{end template}}}

I would expect the entire contents of TemplateWithSimpleForm to be rendered to the HTML output page before anything to do with the SF form is rendered to the output page, as such:

<form ....>       <- form rendered from TemplateWithSimpleForm
...
</form>

<form ....>       <- form rendered from SF form using DataFieldsTemplate
...
</form>

However, that is not what gets rendered. Instead, I get this in the rendered HTML sent to the browser:

<form ....>       <- form rendered from TemplateWithSimpleForm
...
<form ....>       <- form rendered from SF form using DataFieldsTemplate
...
</form>
...
</form>

This will obviously not work correctly.

It appears at first glance that this problem stems from SF_AddData.php::printAddForm() generating HTML that includes the <form ...> tag for the SF form. I would have expected this tag to not get generated until later on, possibly when SF_FormPrinter.inc::formHTML() is called?

-Al

Partial forms converting symbols when saving

I'm having a problem when saving a page using a partial form. For some reason, symbols get converted into unicode. When the edit view is supposed to display this:

{{Infobox
|title=Testing
}} 

it displays this instead:

{{Infobox
|title=Testing
}}



and as a result the text of the template call is displayed instead of the template.

The page saves fine when it's not a partial form. Any help would be appreciated. Thanks. --128.54.162.143 03:52, 22 February 2010 (UTC)

Yes, this is a bug that was added into SF around version 1.8.6 or 1.8.7. It'll (hopefully) be fixed in the next version. Yaron Koren 02:34, 23 February 2010 (UTC)

Ah, I see. I just downgraded to 1.8.5 and it works perfectly. I'll keep an eye out for the next release. Thanks for the help. --128.54.162.143 03:29, 23 February 2010 (UTC)

This was fixed in version 1.9, by the way. Yaron Koren 15:17, 15 March 2010 (UTC)

Listbox sort order "values from concept"

I'm getting an apparently arbitrary order of items in a listbox which gets values from a concept which is simply [[has color::+]] - the property object type is Page. Is there a way to get alphabetical sorting? Thanks! 155.198.150.201 11:37, 24 February 2010 (UTC)

Good point! This has been added in the latest version, 1.9. Yaron Koren 14:18, 11 March 2010 (UTC)