Extension talk:Page Forms/Archive April to June 2008

Erratic template markup

I have a form that will create a page just fine, but if the markup for the page contains a template with undefined parameters, the form breaks upon editing it the next time around. For example, compare the form editing the page to a regular edit. RadicalHarmony 17:06, 9 April 2008 (UTC)

Yeah, templates within templates aren't parsed correctly; it's a known bug. Yaron Koren 18:37, 9 April 2008 (UTC)

Is there anything I can do to help resolve this issue more quickly? RadicalHarmony 22:03, 9 April 2008 (UTC)

Well, you (or someone else) could go into the page-parsing code in /includes/SF_FormPrinter.inc, figure out the necessary changes and send them to me; the problem is the reliance on regular-expression matching, instead of going through the page character by character, which is probably what's needed. Barring that, I hope to have the time to look at it at some point soon; I suppose you or anyone else could contact me privately about funding the development, which would definitely speed up the process. Yaron Koren 16:29, 10 April 2008 (UTC)

Preloading new form name into a field?

Hi Yaron, first of all, thanks for an excellent extension!

I have a form for adding bars to the wiki. If the user adds the bar "Revolver" is there a way I can default load the bar name into a field? E.g. I have a gallery template with the field "image" in it. I'd like the default of that form field to be Revolver.jpg so when the user submits the form that image link is created. I've tried playing around with inserting PAGENAME (with the curly braces) but it just seems to interfere with the functioning of the forms. Thanks man! Rodeoclash 12:37, 25 April 2008 (UTC)

Hi, thanks. Unfortunately, I don't think there's any way to do it; you'll have to ask users to enter the page name manually. Although, if they upload the image before they fill out the form, you can have autocompletion on the image name, which should help somewhat. Yaron Koren 13:22, 25 April 2008 (UTC)

Ok, thanks for that :) 59.167.71.222 04:28, 26 April 2008 (UTC)

Mandatory textareas lose column width capability

Hi there. I have noticed that when making a form entry mandatory, the cols variables seem to be ignored. For example:

Title:</th> <td>{{{field|Title|input type=textarea|rows=1|cols=50}}}</td></tr>

correctly makes a textarea of two rows by 50 columns, however, if I change it to:

Title:</th> <td>{{{field|Title|mandatory|input type=textarea|rows=1|cols=50}}}</td></tr>

I get a textarea of two rows but 84 columns wide. Any idea why this is?

Thanks Mitchelln 15:02, 25 April 2008 (UTC)

Hi, you discovered a bug. I'll fix it for the next version. Thanks. Yaron Koren 14:16, 27 April 2008 (UTC)

Great! Thanks Yaron. Mitchelln 10:42, 1st May 2008 (UTC)

Restricted totaly nonsense

The restricted field in the forms is total nonsense when the page can be edited in normal textmode. There should be a possibility to denie normal editing without the formedit beeing denied. DaSch 23:28, 25 April 2008 (UTC)

In my case even the viewtab permission does not work. DaSch 23:41, 25 April 2008 (UTC)

Hi, 'viewedittab' permissions should work. What calls are you making to set those permissions? Yaron Koren 14:20, 27 April 2008 (UTC)

First I tried with Lockdown Extension to make it only for one namespace, that did not work, then I tried $wgGroupPermissions[*]['viewedittab'] = false; and it did not work. DaSch 20:48, 27 April 2008 (UTC)

Okay I think I see where the problem was. I've set the permission before requiering the extension. DaSch 20:56, 27 April 2008 (UTC)

And in fact this permission only hides the edittab but does net prevent user to enter the page manualy. So in my opinon there should be another solution. The best solution would be to make a formedit permission. When the edit permission is false but the formedit permission is true the user could edit the page with the form. In fast then protected pages also must have the formedit permission denied. Not easy and not that important, something for later releases I think. And will only work with Lockdown Extension I think. DaSch 21:14, 27 April 2008 (UTC)

Form labels and HeaderTabs don't mix!

If you have label=SomelabelorOther and then use header tabs in a form then the page formatting gets severely messed up. No a biggie, but I just thought you'd like to know! Mitchelln 14:22, 2nd May 2008 (UTC)

Form Link no longer available?

Attemping to build a form using the one step process, however it seems that the formlink parser function no longer works? A quick check the of parser include doesn't seem to have it parsing the page. Thanks, Rodeoclash 06:45, 18 May 2008 (UTC)

I think you might be misunderstanding #formlink - it creates a link to a form - it's not meant to be included in the form page. Or did I not understand your question? Yaron Koren 15:21, 18 May 2008 (UTC)

Sorry, I should have included an example, see here. The #formlink is not getting parsed at all by the parser. I checked the parser include file in the SemanticForms/includes folder and it does no seem to be setup to handle the #formlink. Rodeoclash 22:04, 18 May 2008 (UTC)

Okay, I see. You should upgrade your version of Semantic Forms - you have the one right before #formlink was added. Yaron Koren 00:41, 19 May 2008 (UTC)

The most obvious thing to do really when I think about it ;) Thanks Yaron Rodeoclash 10:11, 19 May 2008 (UTC)

autocomplete does not work

Somehow the autocomplete does not work on my page (wecowi.org). I had some strang JavaScript problems in the last days, but I've fixed them all, but the autocomplete still does not work. --DaSch 20:44, 31 May 2008 (UTC)

Can you give a URL where I can see this problem, and the name of a field that isn't autocompleting? Yaron Koren 13:24, 1 June 2008 (UTC)

4example here the fields 'Region:' and 'Regierungsform:' are using a page and the Same Attribut is used at other pages. --DaSch 16:26, 1 June 2008 (UTC)

I think the resaon is here, this is the created JavaScript that should make the autocomplete. But it's empty. But i don't know why they are empty.

YAHOO.util.Event.addListener(window, 'load', attachAutocompleteToAllDocumentFields);
autocompletemappings[4] = 'Lage (Region)';
autocompletestrings['Lage (Region)'] = [['']];
autocompletemappings[5] = 'Regierungsform';
autocompletestrings['Regierungsform'] = [['']];
autocompletemappings[6] = 'Hauptstadt';
autocompletestrings['Hauptstadt'] = [['']];

--DaSch 17:46, 1 June 2008 (UTC)

Well, that's certainly odd. Did this work before? If so, have you made any major changes on the site recently? Did you upgrade your version of SF or anything else? Yaron Koren 02:00, 2 June 2008 (UTC)

I've moved my page to an new server, then it did not work, then I made an update to a new version and it still does not work. --DaSch 16:38, 2 June 2008 (UTC)

Okay I suggest that there is something with the "function createAutocompleteValuesArray" this creates the input for the

autocompletestrings. So maybe its the reason is that I`m using the SVN Version of SemanticMediaWiki. --DaSch 18:02, 2 June 2008 (UTC)

Wow, that's a major bug on my part; thanks for letting me know about this. I just found the problem, which is not a bug in SMW but rather a change in version 1.2 of SF. I'll release a new version soon, but if you (or anyone else) wants to quickly fix the problem, you can just change line 689 of /includes/SF_GlobalFunctions.php to:

$property = Title::newFromText($default_form_property, SMW_NS_PROPERTY);

Yaron Koren 18:46, 2 June 2008 (UTC)

kay no problem, really happy I could help you. Have picked the new Version from SVN and it works. Thanks :). And I thought it was something with my server. Okay very nice, so I think it's a real successful day :) --DaSch 19:20, 2 June 2008 (UTC)

Cool. I actually just made another fix that I checked in, to avoid those multiple identical values that you might be seeing in autocompletion, so if you get that fix it should be fully back to normal. Yaron Koren 19:56, 2 June 2008 (UTC)

Kay, Genius. Thank you --DaSch 20:32, 2 June 2008 (UTC)

Small thing "_" → " " :) --DaSch 22:13, 2 June 2008 (UTC)

Sorry, what do you mean? Yaron Koren 16:44, 3 June 2008 (UTC)

The Autocomplete Values are given with "_" and not with " ". --DaSch 17:40, 3 June 2008 (UTC)

Okay, wow, I clearly didn't do enough testing. I just checked in a small fix for this problem. Thanks again for the bug report. Yaron Koren 21:27, 3 June 2008 (UTC)

no Problem --DaSch 19:06, 4 June 2008 (UTC)

I when you want me something specific to test just ask me. One thing I've just seen. The format of dates is in American-Style. Can you plz give an option or somethin for changing this. --DaSch 19:25, 4 June 2008 (UTC)

File upload facility

Hello. This is a fantastic extension. Regarding the file upload facility. I was kind of expecting that once you've uploaded the file and saved the form that the filename would then be clickable to allow the user to open the uploaded content. As it is it just lists the filename. This does not seem particularly useful. Or perhaps I am doing something wrong?

Thanks --Mitchelln 16:47, 3 June 2008 (UTC)

You should modify the template to have either a semantic property or something like "[[Image:{{{fieldname}}}]]" around the field. Yaron Koren 16:42, 3 June 2008 (UTC)

Ah, okay. Got it. That's really great. Thanks for the fast reply. Now for the million dollar question, can you have an arraymap of these? Mitchelln 12:04, 4 June 2008 (UTC)

That's hopefully coming in the next version; currently the upload always overwrites whatever's in the field, instead of appending as it sometimes should. Yaron Koren 15:02, 4 June 2008 (UTC)

Thanks for the heads up Yaron. That capability would be really useful. Mediawiki's upload functionality is not intuitive for normal users and your functionality addresses this :) Mitchelln 11:54, 5 June 2008 (UTC)

File uploading for fields with multiple values has indeed been implemented in version 1.2.3 --Tosfos 20:50, 13 June 2008 (UTC)

This is fantastic news. This is the last major feature I needed. Thanks! Here's an example of use (as it took me a while to work it out!):

| {{#arraymap:{{{Review Report}}}|,|x|[[Review Report::[[Media:x]]]]}}

Where Review Report is a property of type string.

 Mitchelln 10:01, 16 June 2008 (UTC)]]

Compatibity with Halo Extension

I've just put version 1.1 of the Halo extension on to get the excellent Ontology Browser functionality. Everything initially seemed fine. I can create new pages as normal using Semantic Form's forminput function. However the "Edit with Form" tab has stopped working. Is Semantic Forms compatible with Halo or are you aware of problems Yaron? Many thanks Mitchelln 13:57, 6 June 2008 (UTC)

This came up before on the mailing list - see here. It looks like there's a bug in Halo - specifically, the function smwfAnnotateTab() in the Halo code returns 'true' at the end when it should return 'false'. Can you change that and see if that fixes the problem?

By the way, the mailing list is generally a better place for questions like these. Yaron Koren 18:56, 7 June 2008 (UTC)

Thanks for that Yaron. I put SematicForms before Halo in LocalSettings.php and this seemed to fix my problem, but it busts other things. I cannot find the smwfAnnotateTab() function to try your fix. Perhaps they have changed this with version 1.1. I have now joined the mailing list :) Mitchelln 11:07, 9 June 2008 (UTC)

Create Property: Language Problem

Hi, I've installed the latest version of Semantic Forms in the following German Mediawiki installation:

http://potsdam-infos.mecopo.de/index.php?title=Spezial:Version

The problem: When I want to create a new Property ("Erstelle eine Eigenschaft") I receive English terms:

http://potsdam-infos.mecopo.de/index.php?title=Spezial:CreateProperty

Instead "Seite" it shows "page" etc.

In other German installations these terms were in German language. See for example:

http://www.wecowi.org/view/Spezial:CreateProperty

Has somebody an idea how I could fix this language problem in the "Create Property" function?

Thanks and my respekt for this in its functionalities marvelous extension,
Hajosch, Potsdam/Germany

Hi, thanks. Hm, very strange... have you made any unusual changes to your copy of either LocalSettings.php or /includes/DefaultSettings.php? Yaron Koren 12:40, 12 June 2008 (UTC)

Der Yaron. Thanks for your quick feedback. No, I have not made any unusal changes in LocalSettings.php or /includes/DefaultSettings.php. I have used a fresh installation of the latest MediaWiki, Version 1.12.0. But the problem occurs also in MediaWiki, version 1.11.2. I have made you a PDF-printout of both files ("X"ing the sensitive data), so that you can have a look at my configuration. Perhaps you will find the cause of thos problem:

• LocalSettings.php
• /includes/DefaultSettings.php

Thank you,

Hajosch

That's helpful. In your LocalSettings.php, please try moving the includes for the extensions to the bottom of the file - I suspect that they might have to be placed below the setting of the language code. Yaron Koren 16:21, 12 June 2008 (UTC)

Hurrah, Hurrah! That was the solution for the problem. Thanks a lot for your help!

Hajosch

Single property in a form is blanked when updating

I've got a form that works pretty well. You fill it out, data gets populated into an infobox and in SMW. When you edit with form, everything is normal except for one property, which is blank each time you go to edit the form regardless of what was there before.

My wiki is here, the property in question is Property:License, and the form is Form:Virtual World. It uses the template Infobox Virtual World. Go to a page like Second Life and you can see that the data for license is there. However, if you edit the form, it is blank.

I created a duplicate property - Property:Licenses- that has the same issue. However, none of my other properties restricted by allows values and populated by arraymap are broken. Thanks for the help! Staeiou 15:24, 12 June 2008 (UTC)

Is this still a problem for you? The license fields look fine to me. The "platform" fields seem to not be working, though - I think it's because of the extra spaces in the field. That looks like an SF bug, by the way, but it's fixable on your side. Yaron Koren 16:32, 12 June 2008 (UTC)

Whoops, it was the platform field. I don't know why I said it was the license field. And that fixed the problem. I don't know why I had spaces in there, but I also wouldn't consider it a bug. I was telling the property that it should only accept " PC", " Linux", " Mac" and so forth, and was forcing the form to only give the property values "PC", "Linux", "Mac" through. SF worked perfectly in that case. Thank you very much! Staeiou 17:59, 12 June 2008 (UTC)

Cool. By SF bug, I mean that there's a problem with the #arraymap function's parsing, in that it can't handle whitespaces well - #arraymap is also part of SF. Yaron Koren 18:06, 12 June 2008 (UTC)

arraymaptemplate doesn't do transclusion

On mediawiki 1.12 with Semantic Wiki 1.1.1 and Semantic Forms 1.2.3 arraymaptemplate does not work for me. It does not seem to call into the template. Instead it leaves the text of the template call in the output. As an example:

{{#arraymaptemplate:Foo,Bar,Baz|TemplateName}}

produces the following output:

{{TemplateName|Foo}}, {{TemplateName|Bar}}, {{TemplateName|Baz}} 

With $wgParserConf['class'] = 'Parser_OldPP'; set in my LocalSettings.php it does work, but that breaks other template inclusions in my wiki with div tags that span multiple templates.

Hudson 18:53, 13 June 2008 (UTC)

Oh, that's a problem... it looks like it's cause by MediaWiki's new parser. Not having SSH access to a wiki that runs MW 1.12+, it's hard for me to debug this problem. Do you have any idea on how to get this working, i.e., how to get the output of the parser function to also be parsed? Yaron Koren 20:23, 13 June 2008 (UTC)

Okay, a solution may have been found: if you can, could you into the code, and in /includes/SF_ParserFunctions.php, change the second-to-last line from

return implode($new_delimiter, $results);

to

return array(implode($new_delimiter, $results), 'noparse' => 'false', 'isHTML' => 'false');

, and let me know if that works? Yaron Koren 20:36, 13 June 2008 (UTC)

In MW 1.12 it does not seem to make a difference other than maybe on the delimiter part. Matt 14:03, 18 July 2008 (UTC)

Problem with autocomplete and edit with forms

Hi Yaron. First of all, thank you for this great extension. It's really good stuff, but unfortunately I can't get everything to work :( Hope you can help me...

Autocomplete

First of all, the autocomplete function does not work. I created a template and a form, which looks like this:

 {{{field|parent|autocomplete|autocomplete on category=Category:IFRS Guideline|}}}

If I access the form and start to type however, nothing happens (the field is for assigning a page-type property). I looked at the page source for this input and it looks like this:

<input type="text" class="autocompleteInput yui-ac-input" size="35" value="" name="IFRS[parent]" id="input_7" tabindex="7" autocomplete="off"/>

As you can see, there is a parameter 'autocomplete="off"', maybe this is the problem, however I don't know where it does come from. Any ideas? (There are no JavaScript errors, and as far as I can tell, all scripts are included)

Edit with form

I created the default form annotation on a category page and I can see the "edit with form" tab on those articles. However, if I click on it, the page loads but does only show a normal "page view" (that is simply the rendered article with no inputs or other editing functionality) (the "edit with form" tab however is highlighted). Any ideas on this one? (Also no JavaScript errors)

System Information

I'm working on my local PC at the moment which is why I can not send you a link. But here's the information I have:

• FireFox 2.0.0.14
• MW 1.12.0
• SMW 1.1
• SF 1.2.3 (SVN 06-16)
• Halo Extension 1.1
• Treeview, Variables, ParserFunctions, MultiLang

Maybe I could put the wiki online, but I would have to provide the link to you via email since it is not supposed to go public at the moment. You can contact me via nitsche (at) ontoprise (dot) de (or, of course, here on the discussion page :) ) 85.182.196.2 12:11, 16 June 2008 (UTC)

Hi, it's nice to hear from you. For the autocompletion problem, there are a few things in that field definition that might be causing an error. Here is the definition I would use:

 {{{field|parent|autocomplete on category=IFRS Guideline}}}

Let me know if that works. For the "edit with form" tab, I believe that's (I hate to say it) a Halo bug. It's come up before for SF users, and even been discussed on this talk page. I wanted to write you guys about it - basically the Halo function that gets called by the 'UnknownAction' hook needs to return false instead of true. If you could fix that (assuming that's the problem), it would be helpful to quite a few SF users. Yaron Koren 12:53, 16 June 2008 (UTC)

Hi Yaron! First of all, the edit with forms tab _is_ a Halo problem, just found it :). The problem is that we do not check if the action that calls the hook actually is the action that we want to "listen to". To fix the problem in Halo, insert the following code in extensions/SMWHalo/includes/SMW_Initialize.php right at the beginning of the function smwfAnnotateAction (around line 950):

if ($action != 'annotate') {
 return true;
}

No luck however with the autocompletion. I used your code (which I think I already used at the very beginning) but still the same problem. There is still a parameter 'autocomplete="off"' in the source, I think that's not right, is it? Maybe also Halo-related, even though I can't really imagine why. I'll have another look and do some further investigations. Thanks for the help. 85.182.196.2 13:03, 16 June 2008 (UTC)

Well, it's great that you found a solution to that 'UnknownAction' problem - I'll add a note about that to the documentation. As for the autocompletion - I think that 'autocomplete="off"' is added by the YUI library, and it's actually much more innocent than it seems - the autocompletion it's talking about is the browser's own, which should be disabled. Still, you're having a problem, and, having just upgraded SMW on my site, Discourse DB, I'm having an autocompletion problem too, so it could be that you've discovered a bug. I'll look at this later today. Yaron Koren 14:09, 16 June 2008 (UTC)

Okay, it turns out that my problem with autocompletion has to do with SMW 1.2 (the alpha version), so it's unrelated to your issue. Yes, could you please email me the link, if this is still a problem for you? Yaron Koren 03:17, 17 June 2008 (UTC)

Errors after installation

I've just installed Semantic Forms, and before that I have made sure the SMW is working properly. However I always get the following error on my site:

Warning: Cannot modify header information - headers already sent by (output started at .../wiki/extensions/SemanticForms/languages/SF_LanguageZh_cn.php:26) in .../wiki/includes/WebResponse.php on line 10

Could you please help me solve this? I am using mediawiki-1.12.0, PHP 5.2, MySQL 4.1. Thanks a lot!

- June

It looks like there are some extra newlines at the end of that file. Since no one else has noticed the problem, yours might be the first mainland-Chinese wiki to use Semantic Forms... in any case, thanks for the bug report - it'll be fixed in the next version. If you want to fix it yourself until then, you can just remove the spaces from the end of that file. Yaron Koren 15:39, 18 June 2008 (UTC)

Oh yeah, it works now! Thanks for your help and the great extension you created!

Can SF automatically generate a "*" or "#" when people press ENTER in the field?

This is what wikihow does. Whenever people hit the enter key ,the field automatically generates a "*" or "#" at the beginning of the next line. This will facilitate the formating. I am wondering if SF has this capability. If so, how can I achieve that? Thanks a lot!

No, there's no way to do that in SF. Yaron Koren 14:27, 19 June 2008 (UTC)

In the preview mode, why the "edit source code" is turned on instead of the "edit with form"?

If I click on the "edit with form" tab, every change I made before the preview is gone (this is understandable since preview won't save the changes to the hard disk). Is there any way to modify the preview mode so the input form rather than the standard edit window with the source code is displayed? This is a critical issue to my website as the source code could easily be messed up by users unfamiliar with wikitext. Any solution? Thanks in advance!--24.6.151.20 08:35, 21 June 2008 (UTC)

No, there's no way to do that. If you're worried about users messing up the source code, you can just disable previewing by removing that button from the form. Yaron Koren 12:21, 22 June 2008 (UTC)

SF seems to have a bug when included in a table

I need to use tables to organize my webpage, however I notice that if an input field is included in the table, then the first * or # cannot be understood by the parser. So only the second * or # will be converted into a bullet or number 1. Can you please help me solve this? Your help is highly appreciated!--24.6.151.20 05:18, 22 June 2008 (UTC)

This isn't a bug in SF, it's an issue with templates; SF isn't involved in the display of pages. I've noticed the behavior you're talking about before, but I don't know how to fix it. Anyone else? Yaron Koren 12:23, 22 June 2008 (UTC)

Try putting a blank line above the bullets/numbers. --Tosfos 02:42, 23 June 2008 (UTC)

I've tried that, however it seems that the blank line is simply ignored by the parser.

If I understand the issue, the Template: page should look something like this:

{|
|-
|
{{{fieldname}}}
|}

I haven't tested this. Hope it helps. --Tosfos 03:02, 24 June 2008 (UTC)

Having the {{{fieldname}}} on a separate line fixes it. Weird, but hey. Thanks for the tip! --Mitchelln 03:02, 8th August 2008 (UTC)

Autocomplete parameters case sensitive

Maybe this is something quite obvious for most users, but for me it wasn't: the parameters for autocomplete on property, autocomplete on namespace and autocomplete on category are case sensitive. If you want to autocomplete for all users, use "autocomplete on namespace=User". I used the lowercase version simply because I'm used to MediaWiki's behaviour which is to always automatically uppercase the first letter and it took me quite a while to find out where the problem was. Maybe this should be included to the documentation (or SF should uc the first letter automatically in future versions :) ). - Markus 85.182.196.2 14:22, 30 June 2008 (UTC)