Extension talk:Page Forms/Archive October to December 2009

This is a great extension. However, it may be not easy for some visitors to notice the pages are editable if we remove the "Edit Section" links. I am wondering if I can direct the "Edit Section" links to editing form? Thanks.

I can't think of any way to do that, unfortunately... Yaron Koren 13:02, 8 October 2009 (UTC)

Export to pdf

This wonderful extension could be used to write reports using inline queries. However, it seems not to be easy to produce a pdf of such text. I tried the Wiki2LaTeX and the Collection extensions, and both result in pdf's without the inline query results. Is there a way to produce a pdf from text with semantic query results? Any hint is very much appreciated! Tomy 8 Oct 2009 20:42.

That seems like a Semantic MediaWiki question, not a Semantic Forms one - I would write the mailing list with that question. Yaron Koren 01:55, 9 October 2009 (UTC)

Is it possible to have form whose information won't automatically generate links ? The problem is that the form I created contains some "textarea" inputso it can contain paragraphs... And I don't want these to became links...

Thanks in advance if you ave any thoughts about it.

It sounds like you just need to define the properties you're using in the templates - if they're not defined, then by default they're of type "Page", i.e. links. Yaron Koren 16:04, 12 October 2009 (UTC)
Ok I was using "string" and I changed it to "Text" but that was not the problem (I was using accents and I don't really know why but when I removed them from my properties it worked well). Only thing now is that the "edit boxes" became very small. So I have several rows but the size is only like 30. I tried to change it adding "|size=150" but in the form page but it doesn't do anything (this command worked before...). Do you have any idea? Also only the edit boxes fron the form are small: the free text box has a normal size.
That should work; is the right size showing up in the HTML source, at least? Yaron Koren 19:24, 14 October 2009 (UTC)
I tried to delete all my form and do it again (just in case) but it didn't change anything (even with different names). Anyway, on IE, my boxes are takins into account the "rows" parameter but not "size nor "cols". So I have a box with a size of 1 character but as many rows as I ask. The HTML code gives this:
table class="formtable">
tr>
th> Environnement du probleme:
/th>td> 	textarea tabindex="2" id="input_2" name="Fiche[Environnement du probleme]" rows="5" cols="80" class="mandatoryField"  >/textarea> 
span id="info_2" class="errorMessage">/span>
/td>/tr>
(I removed the "<" cause I don't know how to show the html here)
And then I have 3 other properties that looks the same. Weird thing is that I just tried on firefox and it works well... (I was testing on IE and I'd like it to work on IE)

{{#forminput}} and page name

Hi

I want to use the {{#forminput}} to create new pages, but after hitting the submit button, I want to change the name of the page which will be created e.g. if I enter "pagename" in the input field, I want a page like "example pagename example" to be created.

Is this possible?

Thanks for your help, Yves

That's a good idea, but unfortunately it's not possible - you'd have to use the one-step process instead. Yaron Koren 16:05, 12 October 2009 (UTC)
Thank you very much for the fast answer, Yves
Hi again, I found a workaround which works for me:
I use the widget extension with which I can create html code with javascript and forms.
I use the widget to create a form with some javascript which construct me a link for the one-step process
Here an example:
<script>
  function myformtest(){
    jQuery("#forminput")
      .attr("action","/index.php/Special:AddData/NameOfTheForm/PageName"+jQuery('#mytext').val()+"MoreText");
  }
</script> 
<form id="forminput" action="" method="POST"> 
  <input id="mytext" type="text" onChange="myformtest();"/> 
  <input type="submit" value="Submit" /> 
</form> 
Yves
Wow, that's very interesting. Yaron Koren 20:38, 12 October 2009 (UTC)

Proper placement of $sfgYUIBase

The documentation reads: in your LocalSettings.php file, below the inclusion of Semantic Forms, add the following line:

$sfgYUIBase=...

My experience is that it only works if including above the inclusion of Semantic Forms. I am using Semantic Bundle. Could that be the difference? --Tosfos 16:44, 13 October 2009 (UTC)

That seems very odd; I have no idea. Yaron Koren 19:25, 14 October 2009 (UTC)

I am attempting to preload a field using the #formlink parser which, as I have read, is supposed to be possible.


Example:
{{#formlink:Form Page|Link Text|Link|Template Name[fieldname]={{PAGENAME}} }}


My end result is to populate a hidden field with the page name that the #formlink is on. I keep receiving a "Bad title" error. I am currently using Semantic Forms v1.8.3

Thanks in advance.

--Dgennaro 19:29, 16 October 2009 (UTC)


UPDATE:
Another way I have tried this is to use "super_page", but this is also not operational. I am just looking for a way to click a link on a page (that I have already created using another form) that will create a sub-page. This sub-page name will be determined when the form has been submitted.
--Dgennaro 19:07, 19 October 2009 (UTC)
{{#formlink:Form Page|Link Text|Link|Template Name[fieldname]={{PAGENAME}} }} works for me. Maybe you use some template name or page name containing characters not allowed in the query string of a URL? F.trott 06:46, 20 October 2009 (UTC)

mediawiki upgrade, loss of forms

I recently upgraded my wiki http://www.queenstown.net.nz from 1.9.3 to MediaWiki 1.15.1

I also upgraded to the latest version of Semantic Forms (Version 1.8.4)

But now my forms have disappeared! It's not that they don't work, it's just that there's redlinks where the links to the forms used to be.

e.g. http://www.queenstown.net.nz/index.php?title=Form:Add_Business_Form The templates for the forms still exist however.

However in my custom namespace 'staff' the forms appear although they do not work.

I am not an expert user but I created these forms through trial and error and I would like them back.

Any ideas?

--Andrewrutherford 22:22, 18 October 2009 (UTC)

How to show the edit toolbar above the free-text area?

Hi, How to show the edit toolbar above the free-text area? It would be great if the free text area looks like the original editing view. Thanks for help.

Getting HTTP 500 error when adding category/categories to forms

Hello, i'm getting a 'HTTP 500 error' when I try to implement my categories (categorytree) to a semantic form. I have the extension: Categorytree, SemanticForms and SemanticMediawiki. I used this source as example: Source 1 and added both the template and the form to my own wiki (which is unfortunatly private).

Anyone had similar problems and/or an suggestion to fix this problem? Cheers

Changing the size of the 'Form:add' field

Hello all, i spend forever trying to adjust the size of the text input field (example), where you enter the title of the page to be created with the semantic forms. I tried a bunch of css settings, but i just can't seem to find the right one. Anyone can help me out? Thanks a bunch!

I don't know if there's any way to do it... you'd be better off using the #forminput function, which should be located right on your "Form:..." page. Yaron Koren 16:31, 3 November 2009 (UTC)

Hi, I have a form that automatically generates the name of the pages, via

{{{info|page name=<Topic[Research topic]>|add title=Topic}}}

These pages are supposed to end up in a namespace called Topic. This works perfectly for the pages that are newly created via

{{#formlink:Topic|New research topic|button|namespace=Topic}}

It does not seem to work, however, for red links. One of our templates sets the property Topic to the "topic pages" and the property:topic page states [[Has type::Page]] and [[Has default form::Topic]]. Also the category of the topic pages states [[Has default form::Topic]].

Now, clicking on a red link brings up the form as expected, but the resulting page is *not* put in the namespace topic. The function *info* does not seem to have a namespace argument, and when I add "Topic:" in the beginning of the info page name argument, then new pages created by the formlink function yield pages called "Topic:Topic:xxx". Is there a work around, or did I not follow the instructions properly? Any help is very much appreciated! User:tag 27 Oct 2009 (09:06).

The problem is that the red links aren't pointing to the right page - you should change the call in the template itself, so it looks something like "[[Topic::Topic:]]". Yaron Koren 16:32, 3 November 2009 (UTC)

Edit with form in categorypage doesn't work

To be able to use a form on a categorypage itself and use the 'edit with form'-tab for it I placed the 'page has default form' property into the page. The 'edit with form'-tab does appear but after cliking on it I get a 'Page Cannot Be Displayed'-error. On regular pages 'page has default form' works fine, only in the categorypage itself it doesn't.

Recently I upgraded SMW from 1.1.2 to 1.4.3 and Forms from 1.2.4 to 1.8.4. Am I doing something obvious wrong, or is there a solution/workaround for this?
Thanx. JosCo 08:23, 29 October 2009 (UTC)

What is the exact error message? Yaron Koren 16:35, 3 November 2009 (UTC)
It is the regular Internet Explorer cannot display the webpage" error as if there's no connection or something wrong with the security settings. Firefox leaves the page just blank. Before the update to Forms 1.8.4 I was still able to edit the form on a categorypage though (via a selfmade link).-JosCo 08:09, 6 November 2009 (UTC)

Usage of "subtemplates" broken in 1.8.5

If you use templates with names of the form "template/subtemplate" the slash lets SF_FormPrinter.inc break on line 331. Fix that line as follows:

$found_instance = preg_match('/{{' . '''str_replace('/','\/',$search_template_str)''' . '\s*[\|}]/i', str_replace('_', ' ', $existing_page_content));

Maybe the backslash needs some consideration, too.

--F.trott 07:16, 3 November 2009 (UTC)

Thanks for this fix. The backslash probably isn't worth worrying about - MediaWiki currently doesn't allow it in page names. Yaron Koren 19:09, 3 November 2009 (UTC)

Uplodable textarea list?

I created a multiple instance uploadable form, and soon realized that the names weren't populating the fields after uploading a file. I saw your note about this being a JavaScript limitation, so I configured a single list field. It works fine when I have a text input box, but not for a text area. Whenever I use a text area the "Upload file" link goes away. Is there any way to get uploads to work with a text area? --Gkullberg 18:00, 3 November 2009 (UTC)

That's a good idea... it sounds like a bug in SF. In any case, I should note that, in the latest version of SF, 1.8.5, that first problem you encountered has been fixed - you can now have multiple uploadable fields. Yaron Koren 19:08, 3 November 2009 (UTC)

Suppress 'Additional query' form in printouts of Special:RunQuery results

To hide the 'Additional query' form in printouts go to the bottom of SF_RunQuery.php and insert the noprint class where appropriate as shown in the following fragment:

				$text = "";
				// override the default title for this page if
				// a title was specified in the form
				if ($form_page_title != NULL) {
					$wgOut->setPageTitle($form_page_title);
				}
				$noprint="";
				if ($wgRequest->getCheck('wpTextbox1')) {
					global $wgParser, $wgUser, $wgTitle;
					$wgParser->mOptions = new ParserOptions();
					$wgParser->mOptions->initialiseFromUser($wgUser);
					$text = $wgParser->parse($content, $wgTitle, $wgParser->mOptions)->getText();
					$additional_query = wfMsg('sf_runquery_additionalquery');
					$text .= "\n<h2 class=\"noprint\">$additional_query</h2>\n";
					$noprint = "noprint";
				}
				$text .=<<<END
	<form name="createbox" onsubmit="return validate_all()" action="" method="post" class="createbox $noprint">
	<input type="hidden" name="query" value="true" />

END;

(This has been tested with SF 1.8.5 and may need tweaking for other versions.)

--F.trott 10:21, 5 November 2009 (UTC)

Looks good, but why would you want to do that? Yaron Koren 16:10, 5 November 2009 (UTC)
I'm generating reports from my data. When I give away the printouts I need them to be nice looking. Basically, the form is not part of the requested data and it has no function on printouts, so I do not want it to show up. I do not know, if this is a problem anybody else has. --F.trott 07:44, 6 November 2009 (UTC)

Semantic form issues

Hello,

I have a form that is currently using multiple templates. I need the need to autocreate an ID for the first template, and then refer to it in the other templates. I can't seem to find a good way to resolve this, and was hoping somebody could offer some advice.

The current case is: I have one form that is used to add or edit a task, task have it's own template defining the name, owner, date, description and status. I also have another form (multiple) that is used to add activities to the task. This template is called activites and includes properties as name, data and activity. I need the activities template to somehow refer to the task that it belongs to.

When I enter a form using #formlink the 'uploadable'-tag doesn't seem to work. It doesn't open the 'upload file' screen in a pop up so after uploading the file the user doesn't return to the form.
When I edit the page using 'edit with form' or create the page using the normal forminput the tag does work as it's supposed to. Is this a bug? I know the multiple instances bug was solved (thanx for that).
I use the latest version 1.8.5
-JosCo 12:06, 13 November 2009 (UTC)

Formatting category input tree appearance

Is there any certain syntax that can format the appearance of the Category Tree shown for category input in Semantic Forms? Every example I can seem to find shows the category tree fully expanded when it first appears in the form, so if you have a relatively large category tree it looks quite confusing when it is all expanded out. Just want to try to simplify that experience for the user.

Unfortunately, no. Yaron Koren 22:51, 15 November 2009 (UTC)

Thanks for your prompt response. Anyway I can have the "no subcategories" line not display after each terminal category?

Ah, that's a reasonable request. If you change the contents of the page "MediaWiki:Categorytree-no-subcategories" to blank, it should do it. Yaron Koren 00:07, 19 November 2009 (UTC)

how to display the free-text input below the form input

As title, I wander to display(output) the free-text below rather than above the form input. How can I do this. Thank you very much.

By "form input", do you mean the "save" button, etc.? If you so, I think you can do it just by rearranging those elements in the form definition. Yaron Koren 22:37, 15 November 2009 (UTC)
Thank you for your help. However, My question is about the result after clicking the save button. The free-text would be above the properties by default. I want to display the free-text below the properties. Thank you for your help again.

Ampersands in forminput parameters

How do I avoid the truncation that occurs when a forminput template/field/parameter value contains an ampersand?

An example is

{{#forminput:formname|50||Find/add|namespace=User&User[Is_employee]=yes&no}}

yields

<input type="hidden" name="User[Is_employee]" value="yes">
<input type="hidden" name="no" value="">

The parser stops at the next ampersand, rather than at the next occurrence of the pattern template_name[field_name]=value

Thank you.

Try replacing "&" with "&amp;" - I don't know if that'll work, but it might. Yaron Koren 00:07, 20 November 2009 (UTC)

Doing so yields

<input type="hidden" name="User[Is_employee]" value="yes">
<input type="hidden" name="amp;no" value="">
Ah, okay, I wrote the wrong thing... how about replacing "&" with "%26" instead? Yaron Koren 23:00, 22 November 2009 (UTC)

OK, Inputting {{#forminput:formname|50||Find/add|namespace=User&User[Is_employee]=yes%26no}} to special:ExpandTemplates yields

<input type="hidden" name="User[Is_employee]" value="yes%26no">

This seems strange to me (ie wouldnt it be &#38; ?), plus I'm wondering if this isn't a bug in general -- how do you handle &#160;, within the value, for instance? -- I don't see any advantage and several disadvantages from this requirement.

Okay, this is definitely a bug, then - %26 should work (that's the URL-encoding, as opposed to the HTML-encoding, for "&", and this is a URL-based value). It'll hopefully be fixed in the next version, one way or another. Thanks for the testing help. Yaron Koren

Thank YOU for being so helpful, and for putting this one into the hopper for the next rev. - regards.

Alignment Of Text With Field

LOVE the extension! Be months until I figure out its long range implications. Anyway, this is the site and the name of the page is YIAVL. It gives me an error when I try to link it directly. You will note that in areas where I have large areas of text, it 'seems' to center the field name with the data. You will note that like in the field Scanner Freq, the 160 should line up w/Scanner Freq and in the Resources field, Greene's Market should line up w/Resources. Is there any way to make the first sentence of the data align with the field itself? I used the textarea option for the areas I want large amounts of text. Thanks for all ya'll do!--Ibrrorg 05:18, 19 November 2009 (UTC)

Hi, thanks. This is a CSS issue, of how table elements are laid out. You can change the CSS by adding content to the page "MediaWiki:Common.css". I recommend going to this page, copying the contents of the text area, and pasting it all into your "MediaWiki:Common.css" - it results in nice-looking tables. You can, of course, change any part of it afterwards, if you know CSS. Yaron Koren 08:01, 19 November 2009 (UTC)

I followed your instructions and added the page into my wiki; copying the file from the link to my new page and saw no change. I also went to the talk section on MW and there is no clear statement on whether I create a page in my wiki by the title you list or do I go into my server; /extensions/skins/common and create a file in code called MediaWiki:Common.css? I went ahead and created the file in /extensions/skins/common/common.css and there was no change either. this is the precise page, but I don't know if it will load directly. Thank you.--Ibrrorg 13:41, 19 November 2009 (UTC)

Hi - yes, it's a page in the wiki. You did (almost) the right thing - you created a page called MediaWiki:Common.css", but it should be MediaWiki:Common.css - no quotation mark. If you move it, it should work. Yaron Koren 18:51, 19 November 2009 (UTC)

As usual (I presume) the novice's (me) lack of attention to detail! :-) Works like a charm and I really like the colors it adds! I want to also thank you for taking the time to do that bit of troubleshooting as I would have never thought to look at the file name! Thank you so very much and have a nice day!--Ibrrorg 21:20, 19 November 2009 (UTC)

Upload pop up doesn't pop up

I have added the |uploadable option to my form, and it does show next to the entry box. However when I click on it, it does not access floatbox and does not pop up the upload box. Instead it loads the upload page in the main window. When you click upload at the end of browsing for the file, it gives you a blank white screen. The only thing that can be done is use the back button, to return to the form. However the file never uploaded. Boufa 05:04, 23 November 2009 (UTC)

My guess is that one or more of the Javascript or CSS files isn't getting loaded, due to a problem with one of your settings like $wgScriptPath. Please go to the relevant form, view the HTML source and see if the references to "floatbox.css" and "floatbox.js" are to URLs that actually exist on your wiki. Yaron Koren 14:04, 23 November 2009 (UTC)

That was my problem, somehow, and only on that extension, a /wiki/ was being added to the link. I was in early testing, so I am reinstalling from scratch to see if it was in the system (unlikely) or if it was my fault during the initial install (likely) ... I reinstalled and had the same errors. I know that I set it up right this time. So I reinstalled a third time, this time I put the entire wiki in the /wiki/ sub-folder rather than the root directory, and it worked. Not sure where, but the /wiki/ is added to the call for the floatbox.

Upload problems

I am struggling with the upload function. Since I am doing a wiki based on photography, people have to be able to upload some images to their entries. I think I have set it up right. At first I had a problem with the floatbox call always having a /wiki/ being added to the url. I reinstalled and put the install into /wiki/ and that was fixed. Then i hit the license error on the floatbox. Since that is occuring on your site also, I am pretty sure that is a 1.16 issue (shame too, I like the 1.16 look). Now, I get the box to work (1.15.1) and it pops up, and i browse tot he directory, select my file, everything looks good, I press upload and the box stays and is empty. The only option is to "x" out of the floatbox, and then my image is not there. i checked the directory and it is not uploaded at all. Any ideas. Boufa 20:42, 23 November 2009 (UTC)

- figured it out, I tried to load a image via the standard upload page, and when it did not work, it gave me a memory error. So I found the localsettings.php command to raise the memory available. it worked like a charm then.

I know the 1.16 is still in prerelease, but if you can get the upload thing working, that would be great. like I said before the usability improvements are really great. Boufa 20:59, 23 November 2009 (UTC)

Hi, sorry, I didn't see this question until now. I just discovered that 1.16 bug a few days ago; it's fixed now in the SVN version of SF, and will also be fixed in the next released version, whenever that comes out. Yaron Koren 19:38, 3 December 2009 (UTC)

Conflict with Glossary/Terminology extensions

I'm getting an error after installing glossary extension, which appears after submit or preview on a Special:CreateForm SWM page.

wz_tooltip.js must be included INSIDE the body section, immediately after the opening <body> tag

Both Glossary and Terminology require this wz_tooltip.js file, which needs to be included also in the special pages. Does any of you know how to solve this issue?

Creating Files with Unique Number as Starting Characters

If you want to create a file with a unique number, that is the start of the new page title, you have to change the following line (SF_AddData.php):

if (strpos($target_name, '{num')) {

to

if (strpos($target_name, '{num') >= 0) {

arraymap seems to skip empty elements?

I'm using arraymap in such a way that I want to supply a default value whenever any element in the array is empty (i.e. if the value is empty, begins or ends with a comma, or has two consecutive commas). However, it seems that the arraymap function skips any empty elements. Is there any way to get around this and force arraymap to execute the formula even when the variable is equal to an empty string?

For example, say I have an arraymap for a property Foo, but if there is an empty element in the arraymap I want to add [[Foo::{{PAGENAME}}]]. I would expect this to do the trick:

{{#arraymap: {{{1|}}}|,|x|{{#if: x|[[Foo::x]]|[[Foo::{{PAGENAME}}]]}}|\n}}

However, while [[Foo::x]] is indeed output for each non-empty element in the input, nothing is output for any empty elements, even if the entire input is empty.

"Watch this page" checkbox not mirroring page watches

If I am watching a page and have a partial form that modifies a section of a page, "Watch this page" isn't checked off in the form. Only when I have a form that defines the entire page does "Watch this page" show the correct value. Is it possible for a partial template to look at page watches? --Gkullberg 20:21, 14 December 2009 (UTC)

Hidden fields bug?

I had some hidden fields defined as so:

{{{field|escLP|hidden|mandatory|list|default=.}}} 
{{{field|esceffort|hidden|mandatory|default=Low}}}
{{{field|escstatus|hidden|mandatory|default=Stable}}}
{{{field|escbusinessimpact|hidden|mandatory|rows=4|cols=35|default=Minor Escalation}}}
{{{field|escclosed|hidden|default=Yes}}}
{{{field|escresolutioncode|hidden|input type=listbox|size=6|default=Other}}}
{{{field|escresolution|hidden|default=Minor Escalation}}}
{{{field|escminor|hidden|default=Yes}}}

...along with some other fields in the form that were mandatory. However, the mandatory fields weren't being checked as expected, and you could submit the page without entering data into the other mandatory fields. In order to fix the problem, I had to remove all of the other field declarations so that it was only the field name, the fact that it was hidden, and the default value, like so:

{{{field|escLP|hidden|default=.}}} 
{{{field|esceffort|hidden|default=Low}}}
{{{field|escstatus|hidden|default=Stable}}}
{{{field|escbusinessimpact|hidden|default=Minor Escalation}}}
{{{field|escclosed|hidden|default=Yes}}}
{{{field|escresolutioncode|hidden|default=Other}}}
{{{field|escresolution|hidden|default=Minor Escalation}}}
{{{field|escminor|hidden|default=Yes}}}

I don't know if this should be classified as a bug, but perhaps the documentation on the main page could be updated. --Gkullberg 15:52, 18 December 2009 (UTC)

What does it mean for a hidden field to be mandatory? Yaron Koren 17:22, 18 December 2009 (UTC)
Nothing, really. I just thought that if you were to change a field from visible to hidden you could simply add "hidden" without having to strip the additional content. I'm not arguing that all the additional content shouldn't be stripped out, but it would be nice if it didn't break the visible mandatory fields. --Gkullberg 22:59, 22 December 2009 (UTC)

character change ?

Hi Yaron

I upgraded the SF from 1.8.5 to 1.8.6. I have these in the form in the free text through "preload=":

 ==notes==
 = Summary =
 ==cost breakdown==
Template:SWOcostbreakdown
 ==issues==
Template:SWOissues
==files==
Template:SWOfiles
<headertabs />

Everything work until my upgrade. then the above syntax added or changes to HTML characters. change to these:

==notes==& # 1 3 ; & # 10 ; = Summary = & # 13 ; & # 10 ;==cost breakdown== & # 13 ; & # 10 ; & # 123 ; and so on.....

Note that it only happens if the page is edited with the forms.

thanks Msevero 03:41, 28 December 2009 (UTC)

Hi, yes, that was a major bug in SF that was discovered and fixed about 10 hours after version 1.8.6 was released. Sorry about that; if you re-get version 1.8.6, :) that bug should go away. Yaron Koren 07:13, 28 December 2009 (UTC)
Right on Yaron. Thanks Msevero 00:54, 29 December 2009 (UTC)

1.8.6 problems

I just upgraded and now receive: Notice: Undefined index: value_labels in .../SemanticForms/includes/SF_FormInputs.inc on line 267. Any help?

I've just received the same error, but around line 620.

'wikiPreview' div tag

Surprisingly, if this tag is left out of a form definition, then SF does not correctly create a page from the form.
There is no workaround. The <div> tag is a requirement.

I'm not able to reproduce this bug. Is this happening on a public wiki? If not, can you specify the versions you're using of MW, SMW, and SF; and what browser(s) you've seen it happen for? Yaron Koren 08:30, 1 January 2010 (UTC)

Forminput formatting

It'd be nice to remove the p-tag from the formatting of the Forminput widget (in SF_ParserFunctions). The user should determine how best to display it. Thanks!

It's already out, in the latest version (1.8.6). Yaron Koren 18:00, 31 December 2009 (UTC)
Return to "Page Forms/Archive October to December 2009" page.