Extension talk:Page Forms

Tab in textareas
I wrote a small script in order to enable tabs in a textarea. But unfortunately. It works fine if I use it. But there's a problem. After I've typed the text by using tabs and save the document, The tabs are being parsed as single whitespaces in the resulting article.

So instead of: "1   2    3"

I get: "1 2 3"

The javascript function looks like this: function validate_tab_textarea(field_id) { if (event != null) { if (event.srcElement) { if (event.srcElement.value) { if (event.keyCode == 9) { // tab character if (document.selection != null) { document.selection.createRange.text = '\t'; event.returnValue = false; }					else { event.srcElement.value += '\t'; return false; }				}			}		}	} }

Does somebody know how to fix this?


 * Hi, I'm not planning to add support for tabs in textareas - having tabs move the user to the next input is a standard browser convention that I'm happy to follow. Yaron Koren 12:45, 29 August 2008 (UTC)
 * Not even if it would be optional by using a parameter if the user wants tabs or not?
 * It would just be setting a parameter in the form definition. It worked for me.

.... ...
 * The choice could be left to the user and make SF even more powerful. I think I don't understand this convention.
 * Why is it a problem?


 * I assume that solving the problem above involves:
 * finding the right piece of code that parses textareas to browser html
 * and enclose the output in tags.
 * But I don't know where this piece of code is located. I suppose it is not in the SF library but somewhere in SMW
 * Do you think my idea is feasible, even if you don't want to add the tab patch? And if yes, where actually is
 * that parsing code that generates the HTML
 * Oh.. and there's sth. else. A user always has to press the Enter key twice in order to have a line break represented
 * in the parsed web page. I can imagine that this is rather annoying for new users.
 * I really don't want to push you or anything but I wonder how it is possible in lets say simple forum thread textareas, where you use the Enter key just once and you get a line break?!
 * So there has to be a way to solve it, I guess.--ElSir 13:53, 29 August 2008 (UTC)

Well, what kind of input would want to support tabs for - representing code? As for line breaks, that's a MediaWiki issue - you should bring it up with those guys. :) Yaron Koren 14:00, 29 August 2008 (UTC)

Possible Bug?
If I want to generate a page with a page formula using the unique number tag by setting "start=1".

The page name formula looks like this:

Now if I add a page with form,(The very first "MyDocument" page.) the new page title actually should like this: MyDocument 1

But instead the title becomes: MyDocument

...missing the start number

If I generate a page afterwards, it get's named: MyDocument 2

Thus I get 2 pages:
 * 1) MyDocument
 * 2) MyDocument 2

I tried to fix this and found out that after a small tweak it worked out as I wanted!!!

By changing the regex expression in SF_AddData.php. New code: (just replace the similar looking line with the one below and it's done!) preg_match('/{num.*start=([^;]*).*}/', $target_name, $matches);


 * That's strange - this works for me. Could it be due to other changes you've made to the SF code? Yaron Koren 17:19, 28 August 2008 (UTC)


 * Indeed it is strange. I just had a look at the backup copy of SF_AddData.php, the one I didn't change and there the code is correct.

But in the file I was working with the code was slightly modified. Instead of the last "}" bracket in the regex there was a ">" which is absolutely wrong. I'm pretty sure that I didn't touch this line of code before. Anyhow it is fixed now. --ElSir 23:43, 28 August 2008 (UTC)

SOLUTION: How to set the width and height of a listbox
Just like with the textarea modification I added new parameters to the part in the code where the listbox html-tags are generated.

So you only have to set the parameters in the wiki source code of the form. The parameter being "style" is used to set the width of the listbox and "size" for the count of rows to be displayed.

...

...

For this purpose I had to modify the following piece of code in SF_FormInputs.inc:

$text =<<

by replacing it with:

$size; $style;

if (array_key_exists('size', $other_args) && array_key_exists('style', $other_args)){ $size = $other_args['size']; $style = $other_args['style']; $text =<< END; }   else{ if(!array_key_exists('size', $other_args) && array_key_exists('style', $other_args)){ $style = $other_args['style']; $text =<< END; }       else{ if(array_key_exists('size', $other_args) && !array_key_exists('style', $other_args)){ $size = $other_args['size']; $text =<< END; }           else { $text =<< END; }       }

}

It looks a bit complicated but it's not. It just checks if there any extra parameters passed on to the function. Namely "size" and "style". If this is the case they simply get added to the " "-statement.


 * Thanks for the idea; I'll add something like this in. Yaron Koren 17:27, 28 August 2008 (UTC)
 * Cool --ElSir 23:43, 28 August 2008 (UTC)

I'm very pleased to hear that my contribution is gonna be part of the next release. Thank you Yaron! Regarding the documentation it would be cool to have a kind of model of the classes that are implemented in the SF, how they interact with each other. It's difficult to say which part exactly cause it's all more or less connected. So an overall class diagram or sth. like that would be great in order to get an overview. The workflow is not very clear and sometimes it takes hours to find out how some parts function. I know it is also due to the very short documentation by the Semantic mediawiki guys, because SF is intertwined with it.


 * It sounds like what you want is a "developer's guide" for SF and SMW - is that fair? Check out this - it was just created yesterday. Does that help at all? Yaron Koren 17:27, 28 August 2008 (UTC)
 * That's great! In fact what I was thinking of. :) --ElSir 23:43, 28 August 2008 (UTC)

Would it be possible to add this one to the extension too? In my company it seems to be the case that all Mediawiki extensions are being overwritten by the new releases from time to time. Which means that most custom modifications I make won't be available after an update! Which is terrible!!! I don't wanna rewrite everything. Therefore I'd be glad if some of my modifications could be added to the official release, as long as everybody's happy with it of course.


 * Sure, just let me know what they are - you can send patches to the SF or SMW-developer mailing list, depending on the extension.

There are few other questions I have:

current one which is mm/dd/yyyy? It would be great if one could just adjust it by setting a boolean variable or sth. like that. with a specific page formula in my form definiton:
 * Is it possible to make a date field be parsed in dd.mm.yyyy format instead of the
 * And furthermore: I would like to be able to the following if I want to generate a new page

....    ....

So the name of the newly generated article would be: "MyDocument 1 - 2008" That would be great. You only would have to modify this piece of code in SF_AddData.php:

if (preg_match('/{{{info.*page name=([^\|}]*)/m', $form_definition, $matches)) { $page_name_formula = str_replace('_', ' ', $matches[1]); } elseif (count($alt_forms) == 0) { $wgOut->addWikiText( "" . wfMsg('sf_adddata_badurl') . ' '); return; }

But I don't know how yet. I just know that the regex cuts off the last 2 brackets of the the magic word {{CURRENTYEAR}} Hence the new value of $page_name_formula is: "MyDocument 1 - {{CURRENTYEAR" instead of: "MyDocument 1 - {{CURRENTYEAR}} " If the statement would not cut off the last 2 brackets of {{CURRENTYEAR}} it could be easily replaced by the actual current year and it would work!!! Wouldn't that be brilliant?!

So this is my suggestion:


 * 1) Changing the regex so it checks if there's a currentyear magicword inside of it
 * 2) Replace {{CURRENTYEAR}} with the actual current year, if it exists.

The pseudo code would be:

//SOMEREGEX considering the last 2 brackets too or sth. likewise if (preg_match(SOMEREGEX, $form_definition, $matches)) { $page_name_formula = str_replace('_', ' ', $matches[1]); //CURRENTYEAR really is inside of the formula //replace it by the actual current year if(CURRENTYEAR is in $page_name_formula){ $current_year = date('Y'); $page_name_formula = str_ireplace('{{CURRENTYEAR}}', $currentyear, $page_name_formula); } } elseif (count($alt_forms) == 0) { $wgOut->addWikiText( "" . wfMsg('sf_adddata_badurl') . ' '); return; }

Cheers


 * Thanks for the suggestions. Yaron Koren 17:27, 28 August 2008 (UTC)
 * Your welcome. I solved it but in a different, very simple and maybe unintelligent way than the one above:

I added the following piece of code to SF_AddData.php somewhere in line 114

//checks if the string '{{CURRENTYEAR' is included in $page_name_formula if(strpos($page_name_formula, '{{CURRENTYEAR')) { $current_year= date('Y');

//replaces the {{CURRRENTYEAR with the actual current year $page_name_formula = str_ireplace("{{CURRENTYEAR", $current_year, $page_name_formula); //$form_definition still has got the closing 2 brackets of the currentyear magic word //so these, just get erased out of the $form_definition $form_definition = str_replace("}}\n{{{for template", "{{{for template", $form_definition); }

In my opinion this solution is not good. There are too many specific requirements. Like: (see the last in the above code)
 * {{CURRENTYEAR}} has to occur at the very end of the page name formula and the start number tag has to be placed before it.
 * In the form definition there has to be a line break after the "{{{info|page name...}}}"-line before "{{{for template..."

It would be far better to have it flexible and generalised. Does anyone have any ideas how to manage this? I would love a functionality which enables placing magicwords anywhere in the page name formula. Not just at the end or in the middle or. sth. restrictive like in my simple solution.

A code that would consider all kinds of magicwords inside a page name would be much more sensible. But I don't have a clue how to write it.

As I am a noob regarding mediawiki development, do you know how I could write code that would provide the desired functionality I described above, Yaron??? I'm asking because I don't know how to implement it in the easiest and most intellegent way. So that in the end it can be added to future releases.

By the way I totally appreciate how you care about this discussion. You respond very quickly. It's motivating. :) --ElSir 23:43, 28 August 2008 (UTC)

SOLUTION: How to set a fixed maxlength for textareas
Hi! I have a form with several textarea input boxes and I would like to set a maximum character limit like for string textboxes. By just adding a new parameter to a field declaration in the wiki source code of a form.

sth. like this:

...

...

I used javascript for this. I tweaked the code in SF_FormPrinter.inc and in SF_FormInputs.inc.

First I added(->no need to change any existing functions!!!) the following Javascript function into SF_FormPrinter.inc somewhere in in line 1134 and it looks like this: //very simple function that trims the text in the field if it exceeds maxlength function validate_maxlength_textarea(field_id, maxlength){ field = document.getElemenById(field_id); if (field.value.length > maxlength) { field.value = field.value.substring(maxlength); } }

Then in SF_FormInputs.inc in the function textAreaHTML somewhere in line 445: replace the Old Code: $cur_value  END;

with the New Code: //Tweak: Textarea maxlength $maxlength; if (array_key_exists('maxlength', $other_args)){ $maxlength = $other_args['maxlength']; //$sfgJSValidationCalls[] = "validate_maxlength_textarea('$input_id', $maxlength)"; $text =<<$cur_value  END;

}   else { $text =<<$cur_value  END; }

Maybe there's a better solution for this. I really would appreciate it, if someone has a better idea to fix the maximum characters in a textarea! Hope this can save you folks some time, if you have the same problem.

And... Keep up the good work Yaron! Semantic Forms is genious. Though it would be a lot better if there was more documentation.


 * Thanks, and thanks for the code contribution. You managed to submit it in time for it to be included in the latest version, 1.2.10. I simplified the code quite a bit, but the essence is the same. Also, what specifically would you like to see documented better? Yaron Koren 17:48, 25 August 2008 (UTC)

Problem with preload function in Free Text Field
In my form I used the following entry to get some preloaded text into a text field:

This worked fine until I added the following lines after this line

Category:

The contents of T-Category are

Does anyone have an idea what the problem is? Thanks, Kappa, 09:15, 15 August 2008 (UTC)

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: correctly makes a textarea of two rows by 50 columns, however, if I change it to: Title: 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:

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:]]" 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!):

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:

produces the following output: , ,

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: 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:  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: 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)
 * 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


 * 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:


 * 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:


 * I haven't tested this. Hope it helps. --Tosfos 03:02, 24 June 2008 (UTC)
 * Having the 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)

Drop Down Menu
I know this is a fairly simple question, but for the life of me I can't get it to work. This is a great extension, but I have been trying to get a form to have a dropdown menu of options that people can select from or write their own answer. But I cannot get it to work. I have seen something similar on another site but could not get access to their code to see how they did it. Can anyone provide some sample code I could look at, or some advice on how to do it? Thanks --99.155.199.113 04:37, 2 July 2008 (UTC)


 * What you're asking about is a combo box - a combination of dropdown and autocompleted text input. Unfortunately, SF doesn't support this kind of input; hopefully it will eventually. Yaron Koren 19:15, 2 July 2008 (UTC)


 * Thank you very much. I was mainly looking for a combo box, thank you for the term, because I can't get the "multiple" functionality to work on any forms on my site. I was going to use the combo box as a work-around. I suppose I should have just asked about "multiple", instead. Every time I make a form with a multiple in it, whether inputed manually or through the automatic form creation process, I cannot click the "Add another" button. It just sits there and does not allow me to cliick it and add anything. And ideas? You can see one of the forms in question here. Thanks again.


 * Ah, it's great to see that the software is being used for churchly purposes. I looked into it and indeed there's a problem - all the Javascript that Semantic Forms adds to the page is getting removed before the page is actually displayed. This is being caused by the default skin on the wiki, named 'clean' - I'm guessing that it's a bug. If you change to any other skin in your user preferences, the Javascript will work correctly. I would change the wiki's default skin to another one, much as 'clean' looks nice. Yaron Koren 02:52, 4 July 2008 (UTC)
 * You are amazing, thank you very much.

Aggregation
I would like to be able to use the aggregation function to group together related pages such that they each link to each other rather than each linking to another single page. Rather than having a series of pages about films, each linked to its director by the ‘Was directed by’ property I would like an ‘Is related to’ type property.......

Can I have a template that contians both a property called ‘Is related to’ and an aggregation of that property that only shows the aggregation when the page displays?

Martin Gough 14:59, 10 July 2008 (UTC)


 * I think the answer is 'yes', although this sounds like just a Semantic MediaWiki question, as opposed to an SF question. Yaron Koren 04:45, 11 July 2008 (UTC)

Semantic Search Form
Hi. Thanks for your work. I have been using Semantic Wiki with your Semantic Forms for some weeks now and it meets my expectations. Now, yours is an "Add&Edit" Semantic Forms. Is there a similar "Search" Semantic Forms? I mean, you create a template like yours, but for Searching, including ajax autocompletion, and containing a "Search" button instead of a "Save", and displaying the list of the search results pages (maybe even including the property that was filled in) after hitting that Save button? Thanks again, JdV 15.July.2008


 * I think you're asking two questions in one - if you want search that uses autocompletion, I think the next version of MediaWiki, 1.13, will come standard with that - you can see it in action on Wikipedia already, from the search input in the sidebar. If you want to search based on properties, check out the Semantic Drilldown extension for one convenient way to do that. Unfortunately, there's no way to combine text search and property search yet. Yaron Koren 11:25, 16 July 2008 (UTC)


 * Hi Yaron, thanks for answering. I know about the autocompletion feature of MW 1.13, and I also had a look at your Semantic Drilldown. Drilldown goes already in the direction, but it does not have the "final look" I am thinking of. What I mean is, to have the exact power of your "edit semantic forms" to create a "search semantic form". e.g., if somebody defined a "Car Template Semantic Form", a "Car Template Search Semantic Form" is automatically created. It looks exactly like your Semantic Form, it behaves also similarly (autocompletion), however the submit button is now a "Search button", and the result is a table-like list of "Car" pages including some pre-defined fields (think of excel). I will install Drilldown and try it more (I have only clicked through sites using it), however I don't think it is suitable if one of your properties has many values since it will clog the pages. Regards, JdV 16.July.2008


 * Ah, I see. If I ever implement something like this, it will probably be through additions to Semantic Drilldown that let it take in free text as opposed to just clicking on values; but I have no immediate plans to do that. Yaron Koren 05:47, 17 July 2008 (UTC)

Temporary database tables
After installation I constantly got database errors when I was trying to create a template through Special:CreateTemplate. I tracked this down to not having the CREATE TEMPORARY TABLES</tt> right in MySQL.

Of course I removed this right after installing Semantic MediaWiki because I don't like to give permissions that are not needed.

Unfortunately it's not mentioned in the installation steps that this right is required for Semantic Forms, so others may be trapped by this too.

With kind regards, Frank Tegtmeyer

Edit properties
Hi, is editing the property page directly the only way of editing property details pls? Or is there 'edit with form' for properties too?

TIA -HF


 * No, the only way to edit properties, templates and categories (and forms, for that matter) is manually. Yaron Koren 19:25, 27 July 2008 (UTC)

Same Property, Two Templates
Hi. Awesome extension, thank you. I have a problem that I'm sure can be resolved, but I just can't seem to do it, and I was hoping someone here could help. I have two templates in one form, both of whom happen to share one property, "topic." I don't want to make the user fill in "topic" twice in the same form, however. Is there a way I can have the user only fill out the the property "topic" once and have the second usage automatically fill itself in? I can do it easily when both are in the same template, but is there a way when they are different templates but the same form? Thanks 99.155.199.113 16:15, 28 July 2008 (UTC)


 * Hi, thanks. The Variables extension might help; barring that, maybe it makes sense to change the data structure to eliminate this duplication. Yaron Koren 12:25, 28 July 2008 (UTC)


 * Thanks Yaron. The second use of the property "topic" is used in an "ask" statement to pull up a list of everything that uses the same topic as that particular page. Apparently that sort of thing doesn't work in ask statements, though, because even on the same template it isn't working right. Am I missing something, or does it not work in situations like that?99.155.199.113 16:15, 28 July 2008 (UTC)


 * That should be able to work, if I understand it correctly; though that's really a Semantic MediaWiki issue. If you can't get it working, you should probably write the SMW users list, including the specific markup you're using. Yaron Koren 16:56, 28 July 2008 (UTC)

Edit form with category tags (usage of brackets) does not select proper drop down selection
I have created a form with a drop-down menu that is populated from it's template which calls a property tag of possible categories. The property tag uses the following syntax: This is a property of type String.

The allowed values for this property are:
 * Allows value:= This works fine for adding pages with the proper category, however when a user clicks the edit tab, the drop down menu has the first property value selected.  It appears that using brackets '[' ']' breaks the proper selecting of the chosen value.

I have tried the ascii equivalent &#91; &#93; which did not help. I also tried specifying the brackets later within the template. The parser apparently does not register this as a category tag then.

Any suggestions are great appreciated!

Thank you!


 * Joe D- I solved my own problem.

In the form I specify values=category1,category2 and in the template I use the following:


 * By the way, in Properties you must use  Allows value::This and That, Allows value::That and This </tt> and so on, even when the property type is Page. But for Cats you only can specifie the values in the form. --DaSch 14:32, 20 August 2008 (UTC)

Upload Floatbox doesn't work properly with multiple instances of a template
When you create a Form and you set a template to be multiple, if you configure a field to be uploadable and then you create a page with that form, the "upload file" link opens a new page in the browser, and it doesn't return to the edit page when you finally upload the file. Does somebody have any solution?

I'm using Firefox3, and the latest versions of Semantic Forms, Semantic MediaWiki and MediaWiki


 * It's a known problem; see here. Yaron Koren 16:25, 25 August 2008 (UTC)

CreateProperty
I'm just new to this extension. It looks promising but I'm running in some error messages that I can't solve. When I try to create a Property or a Template through the special pages "Create a property" / "Create a template" I get the next error message:

Database error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SMW::getUnusedPropertiesSpecial". MySQL returned error "1044: Access denied for user 'wgDBuser'@'localhost' to database 'wgDBname' (localhost)".

It sounds like a privilege thing with mysql so I tried the following but it the error message would not go away: GRANT ALL ON wgDBname TO 'wgDBuser' @ 'localhost' IDENTIFIED BY 'password';

Any other suggestions? System:MediaWiki 1.11.0; Php:5.2.6 MySQL 5.0.45 Thanks, --Albert Ke 17:40, 25 August 2008 (UTC)


 * Hi, when you try to create a regular page, or a regular page containing a semantic property, does it work? Yaron Koren 17:52, 25 August 2008 (UTC)


 * Hi Yaron, thanks for your patience. I added the Special:Types (semantic right?) property to a page and that works fine, it points to the 12 available datatypes.--Albert Ke 20:07, 25 August 2008 (UTC)


 * Ok, just upgraded to MW 1.12.0 and it looks like everything is working, creating properties, templates etc with SF. So problem solved. I'm gonna look more into the SF extension. Thanks, --Albert Ke 22:06, 26 August 2008 (UTC)


 * That's great to hear, because I had no idea what was causing that problem. :) Yaron Koren 02:43, 27 August 2008 (UTC)