Extension talk:Page Forms/Archive January to February 2012

Break between allowed values

In a form I want to have the checkboxes among each other. How does it work?

Do you mean you want them to display like a list, instead of in a wrapping line? Badon 20:43, 2 January 2012 (UTC)

I'm not sure I understand the question, but this might help. Yaron Koren 23:48, 2 January 2012 (UTC)

It helps! Perfect! Thank you!

Templates only at entered values

My form refers to two templates.
Is it possible that the templates only come into effect if the user has entered a value?

Example: In the form I ask for an author. But my users doesn´t select an author.
Now I want that the line:

Author:

disappears in the articles.

80.149.179.2 13:30, 4 January 2012 (UTC)

That doesn't sound like a form issue - but you can use #if in the template for that. Yaron Koren 13:38, 4 January 2012 (UTC)

Edit with form tab; based on namespace

Hello,

i want to use the Edit with form tab, based on namespace in the Main namespace (german: "Seiten"?).

How i have to name the article with this text: [[has default form::Test]]
I thought: "Meta-Pagename":Seiten, but that does not work.
With the namespace "Hilfe" it works...

Thank you!

I'm not sure, but try "Project:Main". Yaron Koren 14:27, 5 January 2012 (UTC)

No, that also does not work...

Sorry for the long delay - it turns out that the German translation you should use is 'Startseite'. Still, the word "Main" should also work - that's a bug. Yaron Koren 16:57, 10 January 2012 (UTC)

Now, we have change the default language from "de" to "en" and now it does work with "Project:Main"

Replicating section edit edit summary

A nice feature I think would be to replicate the automatic edit summary which is included upon normal section editing, but which would be included for Semantic Forms based upon which field is updated, if it were one field. I know for me that would really help out with tracking revision histories and what was updated, since section editing is not possible.    Thorncrag   19:07, 5 January 2012 (UTC)

I doubt that's possible - with regular MediaWiki editing, it's known in advance which section the user is editing, but with a form, you don't know which fields they've edited until the moment they hit "save". Yaron Koren 19:20, 5 January 2012 (UTC)

PAGENAME magic word not displaying in forms

When any of the {{PAGENAME}} family of magic words ({{PAGENAME}}, {{BASEPAGENAME}}, etc) are used in a form definition, they are not displayed in the form. However, other magic words, such as {{SITENAME}} and {{CURRENTTIME}}, display in the form just fine.

What versions of SF and MediaWiki are you using? Yaron Koren 13:46, 9 January 2012 (UTC)

Thank you for your reply. I am currently running MediaWiki 1.17, SMW 1.6.1, SF 2.3.2 -Jay

This should definitely work in 2.3.2. Is your wiki public somewhere or could you reproduce the problem on http://scratchpad.referata.com ? --F.trott 09:00, 10 January 2012 (UTC)

Not working for me either...

I am using: MediaWiki 1.18.0, PHP 5.3.8 (cgi-fcgi), MySQL 5.5.19, Semantic Forms (Version 2.3.2), Semantic MediaWiki (Version 1.6.1). My wiki is behind VPN, but everything works as expected in Scratchpad Trial -- SJR

I experienced similar results after upgrading to SMW 1.7; however, {{PAGENAME}} does function in scratchpad forms: [Example] -Jay

This issue seems to have been corrected in Semantic Forms Version 2.4. Cheers! -Jay

For SF 2.3.2: Edit the following file: SemanticForms/includes/SF_FormUtils.php (function: getFormDefinition).--JBE (talk) 08:44, 6 August 2012 (UTC)

Remove:

$title = new Title();

Set:

$title = is_object( $parser->getTitle() ) ? $parser->getTitle():new Title();

Editing a form places the template above all section headers

Consider the following scenario where you have a template contained between section headers such as the following:

=Header 1=
{{Template With Form}}
=Header 2=

Next, using the 'edit with form' option, you make modifications to the input parameters referenced in the template. Upon saving these changes, the wiki formatting is spit out like this:

{{Template With Form}}
=Header 1=

=Header 2=

Is there a way to keep the template between those headers and still use the 'edit with form' option?

Thanks in advance. Morguen 14:42, 9 January 2012 (UTC)

No, unfortunately - you can do something like that with partial forms, though it won't be with the "edit with form" tab - it would just be a link on the page. A true solution for this would involve editing of sections - see here. Yaron Koren 16:30, 9 January 2012 (UTC)

Dealing with the "Preview box" white background

I'm using a heavily modified Vector skin with dark background and white font and when I preview my forms the preview comes with a white background, making the font simply unreadable. I've done some research and I found where it is located HTML wise:
<!DOCTYPE html> <html class="client-js" lang="en" dir="ltr"> <head> <body class="mediawiki ltr sitedir-ltr ns--1 ns-special mw-special-FormEdit page-Special_FormEdit_*form name*_*article name* action-view skin-vector" style=""> <div id="mw-page-base" class="noprint"></div> <div id="mw-head-base" class="noprint"></div> <div id="content"> <a id="top"></a> <div id="mw-js-message" class="js-messagebox" style="display:none;"></div> <div id="siteNotice"> <h1 id="firstHeading" class="firstHeading">*article heading*</h1> <div id="bodyContent"> <div id="contentSub"> <div id="jump-to-nav"> <form id="sfForm" class="createbox" method="post" action="" name="createbox"> <div id="wikiPreview" style="display: block; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid rgb(170, 170, 170);"> <iframe id="ifrPreview" frameborder="0" style="width: 100%; height: 107px; margin: 0px; padding: 0px; border: 0px none; display: block;"> <html class="client-js" lang="en" dir="ltr"> <head> <body class="mediawiki ltr sitedir-ltr ns-0 ns-subject page-*article name* action-submit skin-vector" style="position: static;"> <div id="mw-page-base" class="noprint" style="display: none;"></div> <div id="mw-head-base" class="noprint" style="display: none;"></div> <div id="content" style="width: 100%; height: 107px; margin: 0px; padding: 0px; border: 0px none; background: none repeat scroll 0% 0% white;">

Note that I've not pasted all the code but more or less that should be some help. Reading the last div we find this:
<div id="content" style="width: 100%; height: 107px; margin: 0px; padding: 0px; border: 0px none; background: none repeat scroll 0% 0% white;">

This is the only clue i've been able to find so I assume that is the source of my problems, but after lurking each single (.php and .css) file from the whole extension I wasn't able to find anything. I would like to provide more information, screenshots or links but I'm under a contract and I'm not allowed to unveil the content of the wiki yet. Does anyone know how to get rid of that white background? 79.148.8.127 02:16, 12 January 2012 (UTC)

Forgot to say that I'm using SMW v1.6 and SF v2.3.1 79.148.8.127 02:29, 12 January 2012 (UTC)

Warning message when including {{Special:RunQuery/Form}}

Hello everybody,

I'm about to upgrade SemanticForms from version 2.0.9 to 2.3.2 and noticed some strange behaviour that I couldn't understand even after browsing to the responsible source code.

Basically, I have a query form included into a portal page by means of {{:Special:RunQuery/QueryForm}}. When the portal page loads, the warning This page already exists, but does not use this form gets displayed above the form.

What is puzzling me is that I used the same construct under version 2.0.9 and the warning never showed up then. The responsible code is at line 1509 in SF_FormPrinter.php (in version 2.3.2):

 // Add a warning in, if we're editing an existing page and that
 // page appears to not have been created with this form.
 if ($this->mPageTitle->exists() && ( $existing_page_content !== '') && ! $source_page_matches_this_form )  {
     $form_text = "\t" . '<div class="warningbox">' . wfMsg( 'sf_formedit_formwarning',
         $this->mPageTitle->getFullURL() ) . "</div>\n<br clear=\"both\" />\n" . $form_text;
 }

This code is identical in version 2.0.9 and I didn't find significant difference in the way the flag $source_page_matches_this_form is set before reaching above code. Nevertheless the warning does show up under version 2.3.2 but not under 2.0.9. I could workaround this issuing by adding the condition !is_query to above if-clause but I'd prefer to learn what else I'm doing wrong or whether this is a bug.

I appreciate your help. Many thanks in advance.

OUA 11:39, 12 January 2012 (UTC)

Yes, this seems to be a new bug. I've seen it, too. Incidentally, I suppose you mean {{Special:RunQuery/QueryForm}} not {{:Special:RunQuery/QueryForm}}. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 13:09, 12 January 2012 (UTC)

Actually I really had the latter in my wikitext but it doesn't seem to make a difference. Correcting it to the former didn't change the situation. OUA 13:18, 12 January 2012 (UTC)

Hi, sorry about that - this was fixed in SVN, but I haven't released a new version yet since then. You can see the fix here (it's exactly what OUA proposed) - if you apply that same change, the problem should go away. Yaron Koren 13:27, 12 January 2012 (UTC)

Wysiwyg support

Hi, I would like to have wysiwig editing in free text in forms. Here it says that the FCKEditor extension can do the trick, but that extension is obsolete and seems to be 'replaced' by the WYSIWYG extension.

What should I do?

Thanks! AdSvS 15:08, 12 January 2012 (UTC)

In my opinion, for people using MediaWiki 1.18 and higher there's no good WYSIWYG solution at the moment, and there might not be until VisualEditor is completed, maybe by the end of 2012. The best approach I know of at the moment is to use the WikiEditor extension. Yaron Koren 02:45, 13 January 2012 (UTC)

How do you enable the WikiEditor for semantic forms? 14:59, 3 February 2012 (UTC)

That is a pity, although the Visual Editor is of course a very good initiative. What would you advise if wysiwig is important? Go back to MW 1.17 and use FCKEditor? AdSvS 09:18, 16 January 2012 (UTC)

Yeah, that's the only solution I know of, short of fixing FCKeditor to work with MW 1.18. Yaron Koren 13:31, 16 January 2012 (UTC)

Forms no longer loading

At Bugzilla, User:Badon has posted a critical bug report about forms which refuse to load in the latest version, SF 2.3.2. The bug appears to be triggered by the presence of section headers in a form. I assume Yaron is already aware of this, but maybe others have been hunting in vain for similar reports on this issue. Just so you know. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 19:49, 12 January 2012 (UTC)

Cavila - does this happen on your wiki as well? Yaron Koren 14:14, 17 January 2012 (UTC)

I've more than one wiki, but yes, it happens on a private wiki of mine (ignore the info in my signature, which is relevant to another website). Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 20:31, 17 January 2012 (UTC)

Ah, okay - what version of PHP is running on that wiki? I'm guessing/hoping 5.2. Yaron Koren 21:25, 17 January 2012 (UTC)

Yes it is, see my answer on Bugzilla. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 17:56, 22 January 2012 (UTC)

Editing already created templates/Adding "==Additional Information== to free text

Hi, I've created some forms and templates, I would like to know how to edit these if I need to add more property fields.

Also is there a way for the free text section to automatically add "==Additional Information==" to the top so it looks neater when a page is created.

Thank you in advance!

You can set that text in a "default=" or "preload=" parameter for the free text tag. Yaron Koren 05:26, 15 January 2012 (UTC)

Thank you so much! This really helps! My biggest question now is where I can I set the default or preload parameter? This also goes back to my, where can I edit forms/templates I've already created?

Thank you again!

Well, clearly it hasn't helped yet. :) Look for the "{{{standard input|free text}}}" tag, and you can change it something like ""{{{standard input|free text|preload=Free text preload}}}", and then you can create a page called "Free text preload" containing the text "==Additional information==". Sorry, I missed your first question - there's no way to automatically edit them, unfortunately; you would have to do it by hand. You could try out the Page Schemas extension, though - it's intended to allow automatic editing. I don't think it allows for setting free-text parameters yet, though. Yaron Koren 22:06, 15 January 2012 (UTC)

Yaron, Thank you so much for the help again, Because I'm dense I still don't get one thing and I would like to ask but I appreciate the help. I don't know where to manually templates or forms. For instance in the book example, what if two weeks down the road I decide I need to add ISBN and price as a property. How can I manually edit the template to reflect that?

Each template and form has its own wiki page - if you look in "Recent changes" you can probably see where those pages are. Yaron Koren 17:20, 16 January 2012 (UTC)

Fatal error: Cannot redeclare class SFUploadWindow2 in (path to file) SF_UploadWindow2.php on line 1117

I reported this issue last month, and ultimately removed all SMW-related extensions to try fresh installations. Still getting the same error message. The only clue I might offer is that I was experimenting with SMW+ a couple of months ago before ultimately removing it, clearing out the DB and installing MediaWiki / SMW instead. Is it possible that some extraneous bit of stuff stayed stuck in the MySQL DB even though I dropped all the tables?

Installed software

MediaWiki 1.18.0

PHP 5.2.17 (cgi-fcgi)

MySQL 5.1.39-log

Installed extensions

Semantic MediaWiki (Version 1.7.0.1)

Nuke (Version 1.1)

Renameuser

ParserFunctions (Version 1.3.0)

ConfirmEdit (Version 1.0)

Gadgets

Validator (Version 0.4.14 alpha)

Vector (Version 0.3.0)

WikiEditor (Version 0.3.0)

--Davydog 02:01, 15 January 2012 (UTC)

Hi - no, this isn't a DB issue. The file SF_UploadWindow2.php was removed from Semantic Forms a few weeks ago, in SVN, since it was no longer necessary - so if you can get the latest version, it could be that that will just fix the problem on its own. Otherwise, I really have no idea... Yaron Koren 05:29, 15 January 2012 (UTC)

Did as you advised. Installed Semantic Forms (Version 2.4-alpha) (r109016) from SVN checkout. Now getting this:

Fatal error: Cannot redeclare class SFUploadWindow in (path to file) SF_UploadWindow.php on line 1116

One thing I keep forgetting to mention: up to now I've triggered each error only after clicking on the Special pages menu item. Otherwise the wiki seems to function normally. Don't know if that sheds any light...

--Davydog 02:03, 16 January 2012 (UTC)

I really have no idea. I would try commenting out all the extensions except for SF and seeing if that makes a difference, and if it does, re-installing them one by one until you find the culprit. Yaron Koren 03:28, 16 January 2012 (UTC)

Bug when creating form from template

Has any one else have this problem with the extension? After I create a form from a template, everything will look good, except the second text field label will take on the name of the last field label. Every other field is properly labeled. Not a huge deal because it's easy to manually fix it, but it hasn't happened on every form, so I was wondering if anybody else noticed it.Lost Student 09:00, 15 January 2012 (UTC)

I'm not sure if I understand you correctly, but it sounds like you have some duplicate in your template or form. All field names should be unique. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 10:07, 15 January 2012 (UTC)

That's the thing--all the field names are unique in the template. When the extension creates a form from the template, one of field labels (and only the label--field names remain correct) was not correct.

The crazy thing is that it doesn't happen every time; in fact it only occurred twice. (The first time it happened, I chalked it up to user error, but then it happened again on another template, leading me to believe it is a bug.) Am I the only one it happened to?Lost Student 23:56, 19 January 2012 (UTC)

Hi - this has happened to me too. :) It's definitely a bug in Semantic Forms, but I never bothered to try to fix it. I should. Yaron Koren 02:46, 20 January 2012 (UTC)

Depth parameter to Category tree on autocompletion

This is wanted feature. My category tree grows very large. Hence it would be desireable to limit the initial display to first two levels. The CategoryTree extension already provides parameter depth. However, this not supported in SemanticForms. Could this be added? There was a discussion in June already. Tomaschwutz 19:43, 17 January 2012 (UTC)

Hi - that's a very good idea, and it was surprisingly easy to implement. I just added it to the Semantic Forms code in SVN. Yaron Koren 18:48, 23 January 2012 (UTC)

Two feature requests for query forms

Hi Yaron, the query forms are among the most useful innovations that I've seen from the SMW family. Do you think the following two features are feasible?

1. Especially in the case of queries, it would make sense to have a reset button which clears all the input fields. Would it possible for you to create and add an optional reset button, e.g. one specified by a 'standard input' tag?

2. I know that preloading data is already possible through URLs, but it comes with many limitations (try property values with spaces, for instance). What about enabling this functionality in an embedded format like {{Special:RunQuery/<query form name> |A=bla bla bla |B=…}}?

All the best, Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 18:34, 22 January 2012 (UTC)

A "reset" button sounds like a reasonable idea. For spaces and the like in query strings, you can always use the URL-encoded value - try replacing " " with "%20", for instance. Yaron Koren 20:42, 22 January 2012 (UTC)

For enabling spaces in Special:RunQuery or any other {{fullurl:page name}} combination, you can use {{urlencode:string}} which does the input encoding for the strings selected. In your case {{urlencode:bla bla bla}} convert's into bla+bla+bla which Special:RunQuery does understand. --MWJames 23:10, 22 January 2012 (UTC)

Thanks, and thank you both for the tips on writing URLs. While I still think some cleaner looking syntax would be friendlier to the average user, this works for me. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 08:10, 23 January 2012 (UTC)

Probably the ideal solution for this, by the way, would be to either modify #formlink, or have something analogous to #formlink (#runquerylink ?), that would link to Special:RunQuery. It seems to me like overkill at the moment, but who knows, maybe it makes sense. Yaron Koren 19:13, 23 January 2012 (UTC)

I would like the idea of a #runquery parser function as it would reduce some hustle with the form parameters for the Special:RunQuery. Right now, any RunQuery form has an corresponding template that converts all parameters and create a Special:RunQuery link. --MWJames 00:54, 24 January 2012 (UTC)

A patch has been provided to add a new #querylink parser function that follows the #formlink specification. --MWJames 23:37, 9 February 2012 (UTC)

Bug

Hello,

if I want to edit with form, I get the bug you can see bellow.
Can me help someone?
We use also the extension BlueSpice. Is that the reason of the bug?

Meldung: Das Objekt unterstützt diese Eigenschaft oder Methode nicht.
Zeile: 54
Zeichen: 54
Code: 0
URI: ....wiki/load.php5?debug=false&lang=de&modules=ext.semanticforms.autogrow%2Cfancybox%2Cimagepreview%2Cmain%2Csubmit%7Cjquery.checkboxShiftClick%2Cclient%2Ccookie%2Cplaceholder%7Cjquery.ui.autocomplete%2Cbutton%2Ccore%2Cmouse%2Cposition%2Csortable%2Cwidget%7Cmediawiki.language%2Cutil%7Cmediawiki.legacy.ajax%2Cajaxwatch%2Cwikibits&skin=bluespice&version=NaNNaNNaNTNaNNaNNaNZ

Thank you! Speedtook 12:32, 31 January 2012 (UTC)

Hi Speedtook, could you set debug=true in that URL and open it in Firefox? What's the error message there? --F.trott 12:50, 31 January 2012 (UTC)

Anyway to use tags in text properties?

I'd like to use tag-based extensions in the contents of text properties, but when I try that I get an exclamation mark viewing the page, instead of the property value.

I know that it's not the usual way to use SMW, but in our case I have a text property whose content may be related to some pages in our intranet. To ease thinks for users, I've created a tag-based extension to receive a parameter and return an URL pointing to the desired location. Works like a charm in usual MW pages, but don't work when used in property values like the example below:

{{MyTemplate
|myproperty=this is a simple example, go to <myext>12345</myext> to learn more
}}

Could anybody help me getting this to work? Or is this usage not allowed in SMW?

I have no problem when I put the link directly in value (with smwgLinksInValues enabled), and I'm using MW 1.17.

Thanks, Matheus Garcia 14:43, 1 February 2012 (UTC)

This isn't really a Semantic Forms question, but anyway - try using #set instead of the brackets notation to store the value - maybe that will work. Yaron Koren 15:38, 1 February 2012 (UTC)

Thanks, Yaron! But I enter values using a semantic form, which is tied to the template I mentioned. The value of property myproperty is filled into a textarea on the form. How could I used #set in that case? Matheus Garcia 10:54, 2 February 2012 (UTC)

You'e entering the values using a form, but that's irrelevant - the problem is in the template itself. And the #set call should be in the template, replacing the current setting of that property. Yaron Koren 15:43, 2 February 2012 (UTC)

OK, in the template I replaced [[myproperty::{{{myproperty|}}}]] with {{#set: myproperty={{{myproperty|}}}}} {{#show: {{FULLPAGENAME}} | ?myproperty}}. But I got the same results, works perfectly when value contains just normal strings or html tags (like <b></b>), but does not work with my custom tags extension. By the way, I changed the output value of my extension to just return a plain string, but got the same result. IF you had another idea, I would appreciate your help pointing me to the right direction. Matheus Garcia 11:28, 3 February 2012 (UTC)

Preloading data into multiple instance template

I'm trying to preload data into a form containing multiple instance template (in this case, the target page already has existing instances of this template). The behavior I was expecting was to see a new form instance automatically appear with the pre-loaded data. What I am seeing is the data pre-loaded, but I have to manually click the "Add another" button to see it.

Related, if I want to use a formlink to create a new instance, is there any way just to show the form fields for the new instance template and not the pre-existing instance templates?

That first one is a bug, although in general preloading data for multiple-instance templates doesn't work very well. And unfortunately, there's no way to do the second. Yaron Koren 21:20, 1 February 2012 (UTC)

Suggestion

Maybe, it would be interesting having a parameter to the field tag that restrict the input of some characters. For instance, an "onlynumbers" parameter or something like that.
Or something like this page: Special:BookSources where when you put the ISBN with "-": 978-1-4200-9050-5 MediaWiki removes the "-" and delivers 9781420090505. | Jaider ^Msg 22:49, 2 February 2012 (UTC)

Hi - the first one is already possible with the 'regexp' input type, from the Semantic Forms Inputs extension. The second one might be a bad idea - I've tried to structure Semantic Forms to never alter the user input. But you could have the template itself remove the dashes, using a string function... Yaron Koren 03:41, 3 February 2012 (UTC)

Thanks, Yaron! About de first ideia: I completely forgot the Semantic Forms Inputs extension. Thanks for remember. About de second ideia: Yes, I use {{#replace:978-1-4200-9050-5|-}} to achieve that. | Jaider ^Msg 11:51, 3 February 2012 (UTC)

Another suggestion or question: how can I get a "noinclude free text" parameter in the info tag? In other words, the the opposite of the currently onlyinclude free text parameter. | Jaider ^Msg 15:21, 3 February 2012 (UTC)

That would require a change to SF; it's not currently supported. What would be the purpose of that, by the way? Yaron Koren 15:50, 3 February 2012 (UTC)

Here's the scenario: I have:

• Template:X
• Form:X
• Page: X1 (in free text, I have [[Category:X]])
• Page: A

I want to transclude page X1 inside page A, but not categorize the page A with category X. I need that [[Category:X]]] only categorize the page X1, not the page A via transclusion. To achieve this, I need exactly the oposite of the onlyinclude free text parameter. | Jaider ^Msg 16:36, 3 February 2012 (UTC)

Oh - I see. Yes, that would be nice, but unfortunately it's not possible right now. Yaron Koren 19:35, 3 February 2012 (UTC)

Will it be possible in the next release of SemanticForms? By the way, is there a date (aproximately) to the next release of SemanticForms? I love your extension! | Jaider ^Msg 21:19, 3 February 2012 (UTC)

It won't be in the next release - which is coming out in a few days. Thanks! I have no immediate plans to add this feature in, though if someone creates a patch for it, I'll add it in. By the way, I forgot to mention that people have talked about this problem before, and someone actually came up with a workaround for it - see here. Yaron Koren 14:57, 5 February 2012 (UTC)

Wow! This workaround works to me. Thanks a lot, Yaron! If I were a programmer, I would make a patch for it, but I am not a one. :-( | Jaider ^Msg 17:00, 5 February 2012 (UTC)

Every template generated by a form introduces a line of whitespace into the page

I have a form that generates a main template and multiple instances of a second template (with the 'multiple' option). The resulting page looks like this:

{{Template1

...

}}

{{Template2

...

}}

{{Template2

...

}}

{{Template2

...

}}

Rest of the page content

The problem is that because each of those templates ends with a newline after the closing '}}', they each introduce 1 line of whitespace. If the form generates a lot of templates, the resulting page looks quite unattractive as there is a huge blank area before the text starts.

Template2 contains absolutely no whitespace. Deleting the newlines after each template so that the brackets run together '}}{{' solves the problem, but this would necessitate manually editing each page after using the form.

Is this a bug? Does anyone know of a trick to get this whitespace to disappear? Eeeickythump 19:21, 3 February 2012 (UTC)

Yes - there's a way to avoid that, if you embed all the multiple instances in one field of another template (probably Template1), using "embed in field" and "holds template". See here. Yaron Koren 19:37, 3 February 2012 (UTC)

Thanks for the tip, but I can't seem to get the form to work correctly when I make that change. All I see where the secondary template's input fields used to be, is a single bare text input box. Here is the code (abridged): Eeeickythump 21:49, 3 February 2012 (UTC)

  {{{for template|Plantbox}}}
  ...
  {{{field|Companions|holds template=Companion plant}}}
  {{{end template}}}
  
  {{{for template|Companion plant|label=Companion plants|multiple|embed in field=Plantbox[Companions]}}}
  ...
  {{{end template}}}

I think it should also be possible to somehow employ <nowiki> for that. --F.trott 21:23, 3 February 2012 (UTC)

Oh yeah, that too. Yaron Koren 21:44, 3 February 2012 (UTC)

Can either of you elaborate? Eeeickythump 21:49, 3 February 2012 (UTC)

Hi - sorry, I missed your previous comment. I think "embed in field" is the better solution - that's a recent feature, though, that was only added in version 2.3. Maybe you just need to upgrade your version? Yaron Koren 22:42, 3 February 2012 (UTC)

It's a wiki on referata.com, which is running Semantic Forms 2.4 alpha. Any suggestions re why the code above doesn't work? Eeeickythump 22:44, 3 February 2012 (UTC)

Can you link to the URL? Yaron Koren 14:43, 5 February 2012 (UTC)

Here: Permagarden. The relevant page is http://permagarden.referata.com/wiki/Form:Plant. It no longer contains the 'embed in field' changes because I could not get them to work. Eeeickythump 19:39, 5 February 2012 (UTC)

I see the issue - "holds template" should be by itself; it doesn't take any parameters. Yaron Koren 13:49, 6 February 2012 (UTC)

Yes, that fixed it, thanks! Eeeickythump 07:59, 7 February 2012 (UTC)

Cool! The documentation should probably be clearer on that. Yaron Koren 13:53, 7 February 2012 (UTC)

Action based on property setting

I would like to perform actions based on property values when a form is submitted.

For example:

I would like the form to email a recipient if the page's status property changes from "Submitted" to "Approved"

Or another example:

I would like the form to execute another function like a move function if the page's property for approved=true is checked by the user.

Is any of this possible? 13:49, 5 February 2012 (UTC)

The first one can be done with the Semantic Watchlist extension. The second one would require some custom coding, but it could be done with code that hooked into Semantic Watchlist. Yaron Koren 14:44, 5 February 2012 (UTC)

#formlink has problems with MAGICWORDS

Hello,

I´m trying to put in the target of a form link the magic word {{PAGENAME}} but it doesn´t work. In one field of the same form I used the same magicword and it works. Maybe a bug?

Here is the form:

{{{info|partial form}}}
{{{for template| Álbum |label=}}}
{| class="formtable"
! Name:
| {{{field|name|default= {{PAGENAME}} }}} <--- WORKS
|-
! <span class="editsection">[{{#formlink: 
   form = CronologíaExtraForm
 | link text = edit
 | target={{PAGENAME}} }}]</span> <-- EMPTY, following the link it fails
|-
|}
{{{end template}}}

Thanks,

monica A.

Actually, the fact that the first {{PAGENAME}} works is the surprising thing - since I assume you're not actually on that page when you're editing with that form (instead, I assume you're at "Special:FormEdit/Álbum/..."). I think that's because SF does special handling for "default={{PAGENAME}}". To get the page name into #formlink, you might need to use #titleparts. Yaron Koren 13:58, 6 February 2012 (UTC)

It doesn´t work. In fact, I did two tests: Put {{PAGENAME}} (you can try with any magicword) before #forminput tag and it get me the right page name. Put the exact #formlink: in the template definition and it works. There are differences between the target processing in forms and templates?, Because in the templates any magicword is recongized.

Right - that's because, when it's in the template, you're actually on that page when {{PAGENAME}} is called. When it's in the form, you're in Special:FormEdit - not on the page itself. I really think you would need #titleparts. Yaron Koren 13:54, 7 February 2012 (UTC)

Ok, I understand but forget the target attribute of #formlink. Try to get the {{PAGENAME}}'s value outside of the form. The problem is that I can´t use #titleparts over an empty string. {{PAGENAME}} is empty. I´m trying to get someting of this: {{#titleparts:{{PAGENAMEE}} | 1 | 1 }} outside, in the page and it´s empty :(. Am I doing something wrong? Monica, 8 February 2012

YUJU!!! It works with the 2.4 version. Thank you!!! Mónica, 8 febrero 2012

Okay - that was unexpected, but good news. :) Maybe I just misunderstood the question all along... Yaron Koren 15:38, 8 February 2012 (UTC)

no preload

Hello,

we use SemanticForms, the form is based on a namespace. If I create a new page, it loads the form. But I want not this preload, I only want that in this articles, the "editwith form"-tab is shown and user after their first saving can edit with form.

How is that possible?

Thank you! --80.149.179.2 14:29, 6 February 2012 (UTC)

Don't base it on the namespace - you can put "Page has default form" in the template, instead. Yaron Koren 14:44, 6 February 2012 (UTC)

Do I able to adjust, that "Page has default form" is written automatical on all pages of a certain namespace? --80.149.179.2 14:02, 9 February 2012 (UTC)

I don't understand the original question, then - what is it that you don't like about "based on namespace"? Yaron Koren 18:01, 9 February 2012 (UTC)

Based on namespace, but I want that users create a page without form and after creating they have the possibility to change the page with "edit with form"...

We only use the form for connecting languages, so we only need it sometimes, but we are not able to say whether we need the form for a page before we create it. --80.149.179.2 08:37, 10 February 2012 (UTC)

Hi - in that case, why did you write "all pages of a certain namespace" before, if you only want it for some pages? I'm still confused about what it is you want. Yaron Koren 16:39, 10 February 2012 (UTC)

Partially editing two pages with one form

Is the following scenario possible?

User A creates a new top-level page. He is taken to a form. He fills in a title "New Story 123" and text. The page is created. The created page has the title, text, and ALSO a link titled "Add a subpage".

User B reads this, and clicks "Add a subpage". He is taken to a form. He fills in the title "Subpage XYZ" and text. The page is created. The created page has the title, text, and ALSO a link titled "Add a subpage". Most importantly, the first page is automatically updated. Above the link to form "Add a subpage" is a new link to the new page, titled "Subpage XYZ".

After this, any user can add story branches at any level, and both relevant pages (The new page, and the page the new page branches off from) are automatically updated.

Please see my question here for more clarification: http://stackoverflow.com/questions/9177631/collaborative-choose-your-own-adventure-system-how-do-i-build-it

Any advice? Is this possible? Thanks.

--74.255.33.135 16:20, 7 February 2012 (UTC)

Definitely. You can use an SMW query, or the SubPageList extension. Yaron Koren 19:26, 7 February 2012 (UTC)

Thanks. I am relatively inexperienced, but the method for obtaining what I want isn't intuitive to me. Could you explain what you mean? In what way would I use the SubPageList extension to mark a page as a subpage when they choose to add a branch? How is using an SMW query comparable? Is there a walkthrough or example for similar situations? --74.255.33.135 19:35, 7 February 2012 (UTC)

Okay, never mind - when you say "subpage", I'm pretty sure you don't mean "subpage" in the MediaWiki sense. So queries are the way to go. You need to have each "subpage" (maybe "following page" is a better term?) point back, using a semantic property, to the page you were on. You'll need to use #forminput with the "query string" parameter for part of that - but for the actual property and querying stuff, I would read up about all of that on semantic-mediawiki.org. (It's not a forms issue.) Yaron Koren 19:50, 7 February 2012 (UTC)

I guess what I'm trying to do now is figure out how variables work in SMW/forms. Example: User A Clicks "add new story branch" and fills in a title. How do I make the title of this page to be [previous_page_title]/[new_title] , so it is a subpage and shows in the hierarchy? A query is just a search, right? It returns lists of all information that fits in a category. How does that help me? Queries can be used as variables when setting up the form, so it is different depending on how you were linked there (the parent page in the story)? In essence, when creating a new page, how do I reference the current page as predecessor? I really appreciate your time. Could you point me towards other venues where experienced users could answer questions? These questions aren't entirely related to specifically Forms. --74.255.33.135 21:04, 7 February 2012 (UTC)

Oh, so you do want them to be actual subpages? Won't that lead to very long page titles after, say, three or four steps? In any case, the best place to ask about such stuff is probably the SMW mailing list or IRC channel. Yaron Koren 21:22, 7 February 2012 (UTC)

Catchable fatal error: Argument 3 passed to Parser::parse() must be an instance of ParserOptions....

I get this error when I use the page Special:RunQuery using a query form. Here's the error: Catchable fatal error: Argument 3 passed to Parser::parse() must be an instance of ParserOptions, null given, called in /home/twinsenw/thisishowyouplay.com/extensions/SemanticForms/specials/SF_RunQuery.php on line 101 and defined in /home/twinsenw/thisishowyouplay.com/includes/parser/Parser.php on line 255

I'm running Mediawiki 1.17 and Semantic Forms 2.4. I think the bug is also the one being discussed here: http://www.mail-archive.com/wikibugs-l@lists.wikimedia.org/msg113086.html

I used the example query form data from the one posted on the Semantic Forms doc page found here: http://discoursedb.org/wiki/Special:RunQuery/Item_query

You can check the actual error message by going here: http://thisishowyouplay.com/wiki/Special:RunQuery/Browse_activities 162.89.0.60 21:53, 10 February 2012 (UTC)

I tried to fix this. I can not reproduce the bug, though. Could you try the latest development version of SF and see if it works now? --F.trott (talk) 18:36, 20 February 2012 (UTC)

Char Insert Not Working

I have been trying to get char insert working with forms. I have the menu bar appearing but i don't get anything inserted when i click the icons. I read this may be due to edit.js or edittools.js not loading but don't know how to load them. I tried adding them to common.js with no luck. Anyone know how to solve this?

Thanks!

I think the reason behind this problem is that a feature needs to be added to Semantic Forms so it can accommodate other extensions like CharInsert. I have already reported this issue here: https://bugzilla.wikimedia.org/show_bug.cgi?id=33600 Badon (talk) 20:49, 17 February 2012 (UTC)

I don't believe there's any connection between these two things. Yaron Koren (talk) 22:07, 17 February 2012 (UTC)

Right, I'm just saying there should be. Badon (talk) 00:20, 18 February 2012 (UTC)

Char Insert/Virtual Keyboard

Anyone know how to get char insert or a java virtual keyboard to work with forms? I need to allow input of some special characters for the Hawaiian language. I have an understanding of java and loading the files but am really looking for a walkthrough. I played with char insert and got it to display but can't get input to work. Some posts mentioned it not loading the proper script files but i couldn't nail down how to correct that.

Thanks!

This is not straightforward to do yet. But, maybe in a future version. Badon (talk) 02:11, 26 February 2012 (UTC)

Error with exception 'SMWDataItemException': No predefined property with "_SF_PDF"

After installing Semantic Forms 2.1.2 on MediaWiki 1.17.1 and SWM 1.6.1 I get the following error when including SF:

MediaWiki internal error.

 Original exception: exception 'SMWDataItemException' with message 'There is no predefined property with "_SF_PDF".' in C:\xampp\htdocs\glosebase2-dev\extensions\SemanticMediaWiki\includes\dataitems\SMW_DI_Property.php:81
 Stack trace:
 #0 C:\xampp\htdocs\glosebase2-dev\extensions\SemanticMediaWiki\includes\datavalues\SMW_DV_Property.php(80): SMWDIProperty->__construct('_SF_PDF')
 #1 C:\xampp\htdocs\glosebase2-dev\extensions\SemanticForms\includes\SF_FormLinker.php(125): SMWPropertyValue::makeProperty('_SF_PDF')
 #2 C:\xampp\htdocs\glosebase2-dev\extensions\SemanticForms\includes\SF_FormLinker.php(285): SFFormLinker::getFormsThatPagePointsTo('Hauptseite', 0, 3)
 #3 C:\xampp\htdocs\glosebase2-dev\extensions\SemanticForms\includes\SF_FormEditTab.php(26): SFFormLinker::getDefaultFormsForPage(Object(Title))
 #4 [internal function]: SFFormEditTab::displayTab(Object(SkinVector), Array)
 #5 C:\xampp\htdocs\glosebase2-dev\includes\Hooks.php(158): call_user_func_array(Array, Array)
 #6 C:\xampp\htdocs\glosebase2-dev\includes\SkinTemplate.php(888): wfRunHooks('SkinTemplateTab...', Array)
 #7 C:\xampp\htdocs\glosebase2-dev\includes\SkinTemplate.php(493): SkinTemplate->buildContentActionUrls()
 #8 C:\xampp\htdocs\glosebase2-dev\includes\OutputPage.php(1724): SkinTemplate->outputPage(Object(OutputPage))
 #9 C:\xampp\htdocs\glosebase2-dev\includes\Wiki.php(384): OutputPage->output()
 #10 C:\xampp\htdocs\glosebase2-dev\index.php(115): MediaWiki->finalCleanup(Object(OutputPage))
 #11 {main}

Of course I include Semantic Forms after including Semantic MediaWiki in LocalSettings.php. What's the problem? --130.75.245.116 10:19, 27 February 2012 (UTC)

Hi - my guess is that those versions of SF, SMW and MW are somehow incompatible with each other. Why not use the latest version of everything? Yaron Koren (talk) 13:21, 27 February 2012 (UTC)

They should work together. I am using HaloACL 1.6.0 which requires this Versions. The problem was that Semantic Media Wiki was included twice in LocalSettings.php. But after deleting the 2nd include I have this error:

Catchable fatal error: Argument 1 passed to SMWStoreAdapter::getInProperties() must be an instance of SMWDataItem, instance of SMWWikiPageValue given, called in /home/www/glosebaseftp/htdocs/glosebase2-dev/extensions/SemanticForms/includes/SF_FormLinker.php on line 36 and defined in /home/www/glosebaseftp/htdocs/glosebase2-dev/extensions/SMWHalo/includes/SMW_SMWStoreAdapter.php on line 71

--130.75.245.116 13:27, 27 February 2012 (UTC)

Ah - if you're using HaloACL, you should ask on one of the SMW+ forums - as far as I know, if you use any of the SMW+ extensions, you need to use their custom versions of SF, SMW and MW. Yaron Koren (talk) 14:01, 27 February 2012 (UTC)

I'm already asking on the SMW+ forums. But the problem ist still deals with Semantic Forms 2.1.2. Now I got the old error back. So still I've got this 'MWDataItemException'. I don't know why I thought it is solved. Maybe the Semantic Forms include line was commented out in LocalSettings.php. So what can I do?

I really don't think you can just use SF 2.1.2 with HaloACL - as I said, I believe it requires their custom version of SF, which I think is called 2.1.2_1. If that's correct, then I'd say you have two basic options: switch to the SMW+ version of everything, or forget about HaloACL and just use the latest version of everything. Yaron Koren (talk) 14:35, 27 February 2012 (UTC)

I am not running HaloACL now. I even don't have it installed yet. The problems I get are after installing Semantic Forms 2.1.2!--82.83.243.249 21:14, 27 February 2012 (UTC)

Okay, but - as I said, you should either upgrade to the latest version of everything, or change to the SMW+ version of everything. In either case, you shouldn't be using SF 2.1.2. Yaron Koren (talk) 21:33, 27 February 2012 (UTC)

Older Versions Of Semantic Forms

Where can I download older Versions of Semantic Forms. Espacially 2.1.0 and 2.1.1--130.75.243.45 11:48, 28 February 2012 (UTC)

I don't know why you would want to, but if you go to the "download" section, and take the current URL (either the .zip or .tar.gz file) and change the version number in the URL, that file should be there. Yaron Koren (talk) 14:57, 28 February 2012 (UTC)