Extension talk:Page Forms/Archive July to September 2008

Creating new pages for specific namespace


I want to create pages which automatically get associated to a specific namespace.

I read that this is possible through the forminput statement. But I'm using
formlink because I don't want the users to be able to determine the title of the
article. It gets generated automatically.

Is there a way to specify a namespace for articles which are generated through
formlink, hence by using SF_AddData instead of formlink, using SF_AddPage?

I believe if you add 'namespace=' to the query string parameter, the fourth argument for #formlink, it should work. By the way, if you have any more questions, the mailing list is a better place for them. Though if you do add more sections to this page, it would be better to add them at the bottom rather than the top. Yaron Koren 14:10, 3 September 2008 (UTC)Reply[reply]
I'm working with a template and form called "Document".

My #formlink statement looks like this:

 {{#formlink:Document|New Document|button|namespace=Documents NS&Document[Year]={{CURRENTYEAR}}}}

and it still doesn't work. I also tried these ways:

{{#formlink:Document|New Document|button|Document[Year]={{CURRENTYEAR}}&namespace=Documents NS}}
{{#formlink:Document|New Document|button|Document[Year]={{CURRENTYEAR}}|namespace=Documents NS}}

But no success.

Can you be a bit more specific about how to set the namespace? There's also another issue I have with the textarea maxlength javascript that you modified for the current release. It doesn't work. Maybe it is browser dependent. I'm using IE 6.0.2900.2180. And thanks for the tip. I will subscribe to the mailing list.

Ah, yes indeed, that's a bug in Semantic Forms. It'll be fixed in the next version. As for 'maxlength', it works for me, on IE 7. Try upgrading your browser, I guess. Yaron Koren 17:09, 3 September 2008 (UTC)Reply[reply]

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)Reply[reply]
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.
 .... {{{field|Comments|input type=textarea|tab=true}}}...
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:
  1. finding the right piece of code that parses textareas to browser html
  2. and enclose the output in <pre></pre> 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)Reply[reply]

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)Reply[reply]

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: {{{info|page name=MyDocument<unique number;start=1>}}}

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:

...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)Reply[reply]
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)Reply[reply]

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.

{{{field|Consulters|input type=listbox|style=width:500px;|size=10}}}

For this purpose I had to modify the following piece of code in

    	$text =<<<END
	<select id="$input_id" tabindex="$sfgTabIndex" name="$input_name" class="$className" multiple $disabled_text>

by replacing it with:


    if (array_key_exists('size', $other_args) && array_key_exists('style', $other_args)){
      $size = $other_args['size'];
      $style = $other_args['style'];
      $text =<<<END
      <select id="$input_id" tabindex="$sfgTabIndex" name="$input_name" class="$className" multiple $disabled_text size="$size" style="$style">
        if(!array_key_exists('size', $other_args) && array_key_exists('style', $other_args)){ 
            $style = $other_args['style'];
            $text =<<<END
            <select id="$input_id" tabindex="$sfgTabIndex" name="$input_name" class="$className" multiple $disabled_text style="$style">
            if(array_key_exists('size', $other_args) && !array_key_exists('style', $other_args)){
                $size = $other_args['size'];
                $text =<<<END
                <select id="$input_id" tabindex="$sfgTabIndex" name="$input_name" class="$className" multiple $disabled_text size="$size">
            else {
                 $text =<<<END
                 <select id="$input_id" tabindex="$sfgTabIndex" name="$input_name" class="$className" multiple $disabled_text>


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 "<select>"-statement.

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

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)Reply[reply]
That's great! In fact what I was thinking of. :) --ElSir 23:43, 28 August 2008 (UTC)Reply[reply]

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:

  • Is it possible to make a date field be parsed in dd.mm.yyyy format instead of the

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.

  • And furthermore: I would like to be able to the following if I want to generate a new page

with a specific page formula in my form definiton:

     {{{info|page name=MyDocument <unique number;start=1> - {{CURRENTYEAR}}}}}

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( "<p class='error'>" . wfMsg('sf_adddata_badurl') . '</p>');

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 - 2022"
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( "<p class='error'>" . wfMsg('sf_adddata_badurl') . '</p>');


Thanks for the suggestions. Yaron Koren 17:27, 28 August 2008 (UTC)Reply[reply]
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:

    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..."

(see the last in the above code)

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)Reply[reply]

SOLUTION: How to set a fixed maxlength for textareas


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:

{{{field|Personal comments|maxlength=100}}}

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:

     <textarea tabindex="$sfgTabIndex" id="$input_id" name="$input_name" rows="$rows" cols="$cols" class="$className" $disabled_text>$cur_value</textarea>
    <span id="$info_id" class="errorMessage"></span>

with the New Code:

    //Tweak: Textarea maxlength
    if  (array_key_exists('maxlength', $other_args)){
        $maxlength = $other_args['maxlength'];
        //$sfgJSValidationCalls[] = "validate_maxlength_textarea('$input_id', $maxlength)";
        $text =<<<END
    <textarea tabindex="$sfgTabIndex" id="$input_id" name="$input_name" rows="$rows" cols="$cols" class="$className" $disabled_text onKeyDown= "validate_maxlength_textarea('$input_id', $maxlength);" onKeyUp = "validate_maxlength_textarea('$input_id', $maxlength);">$cur_value</textarea>
    <span id="$info_id" class="errorMessage"></span>

    else {
    $text =<<<ENDc
    <textarea tabindex="$sfgTabIndex" id="$input_id" name="$input_name" rows="$rows" cols="$cols" class="$className" $disabled_text>$cur_value</textarea>
    <span id="$info_id" class="errorMessage"></span>

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)Reply[reply]

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:

{{{field|free text|preload=Template:intro}}}

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

{{{for template|T-Category|multiple}}}
'''Category:''' {{{field|Cat}}}
{{{end template}}}

The contents of T-Category are


Does anyone have an idea what the problem is? Thanks, Kappa, 09:15, 15 August 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 -- 04:37, 2 July 2008 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
You are amazing, thank you very much.


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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

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 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?


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)Reply[reply]

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 16:15, 28 July 2008 (UTC)Reply[reply]

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)Reply[reply]
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? 16:15, 28 July 2008 (UTC)Reply[reply]
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)Reply[reply]

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 [[Has type::String|String]].

The allowed values for this property are:
* [[Allows value:=[[Category:someCat]]]]

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 [ ] 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]] 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)Reply[reply]

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)Reply[reply]
I also have this issue on a wiki, but I cannot figure out what causes the problem. My template is very regular and so is the form. I run the latest MW, SMW and Semantic Forms (at the time I write this of course). Does someone have more details ? --Pannini 13:54, 29 September 2008 (UTC)Reply[reply]


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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
That's great to hear, because I had no idea what was causing that problem. :) Yaron Koren 02:43, 27 August 2008 (UTC)Reply[reply]
I had a similar problem in MediaWiki 1.13.1. I solved it by granting "CREATE TEMPORARY TABLES" to the wiki user in the database.

Modifying the text on a upload box

Hi, EmuWikiAdmin writing,

Thanks a lot for this great extension.

Where do you think I could modify the text that appears in the upload form when a field is uploadable ? is it in Semantic Forms or directly in mediawiki ?

Just found it out in /extensions/SemanticForms/special/SF_UploadWindow.php. Here's how if someone else is interested I just changed the line :
$wgOut->addWikiText( wfMsgNoTrans( 'uploadtext', $this->mDesiredDestName ) );
for $wgOut->addWikiText( 'mytext' );
Or if you want to keep it internationalized just change the values for the wfMSG of 'uploadtext'

Hi, you can also accomplish this by changing the contents of the page "MediaWiki:Uploadtext". Yaron Koren 02:11, 4 September 2008 (UTC)Reply[reply]

Standalone fields doesn't work

Fields, that's don't belong to any template (standalone fields) didn't show themselfs. More over, if I put standalone field - it dublicates previous field. For example:

{{{field|free text|rows=20}}}
{{{field||input type=text|default=111}}}

gives two free text fields with the same content.

Hi, the idea of a standalone field doesn't make sense - fields can only be found in templates. Yaron Koren 19:46, 7 September 2008 (UTC)Reply[reply]
That's a pity. I just wanted to insert some hidden fields in the form that's put some hidden text in article which was edited with that form.
Well, I don't know what you mean - what would this "field" look like in the page that was created? Yaron Koren 13:19, 8 September 2008 (UTC)Reply[reply]
In my form I have
{{{for template|Category|multiple|label=Categories}}}
'''Category:''' {{{field|1|autocomplete on namespace=Category|remote autocomplition}}}
{{{end template}}}

And I want to wrap this content in <noinclude> tags. What I want to achieve? I don't want to see categories-list box in a page that contains inline querie. I thought that this can be done by wrapping above code in two hidden standalone fields with default values "<noinclude>" and "</noinclude>". < Template:Category contains [[Category:{{{1}}}]]

If there is another way to achieve my aim, I would be glad if you help. :) -- 08:28, 9 September 2008 (UTC)Reply[reply]

Okay, thanks, now it makes a little more sense. But why don't you want the category name to show up at the bottom of the page? Yaron Koren 14:26, 9 September 2008 (UTC)Reply[reply]
I want to construct mediawiki-based blog system. I have a blog-posts articles, each of which may belong to any categories. And I have a page named "Blog" that contain inline querie, which embed 10 latest posts. On that page I see categories that belongs to each of 10 latest blog-pasts. The bottom categories-list box become large and senseless. -- 05:37, 12 September 2008 (UTC)Reply[reply]
It might make sense to get around that by using a property to define those subjects, instead of categories; see the first point here. Yaron Koren 13:25, 12 September 2008 (UTC)Reply[reply]
No. I use categories as fields of knowledge, it can be organized into a tree.
Well, this might take more discussion than really belongs on this page. If you want to discuss it further, you should probably write to the Semantic Forms mailing list about it. Yaron Koren 16:43, 16 September 2008 (UTC)Reply[reply]

SOLUTION: Failsafe way to create an enumeration

I've recently spent several hours trying to create a property of type enum (to allow the use of a list in my Form), and for reasons unknown, it's not been working properly (always displaying something along the lines of "type unknown" when creating the form using a template with my property).

To solve this however, you can define your property as type enumeration manually by editing the wiki database.

mysql - u root -p (where root is the name of the mysql user with admin privileges)

use wikidb; (where wikidb is the name of your wiki database)

select * from smw_ids;

This should return a list of currently used Properties - write down the smw_id of the property which you'd like to be an enum, eg 477.

Now you need to insert the possible enumeration values into the smw_spec2 table.

insert into smw_spec2 values(477,14,'your value one');

insert into smw_spec2 values(477,14,'your value two');

insert into smw_spec2 values(477,14,'your value three');

That's it - now create your template and form. In the above example, I'm guessing the 14 refers to the datatype number, with 14=enumeration, so don't change it!

Hi - I believe this is a bad idea. You can add allowed values to a property by just adding "[[Allows value::..]]" calls to the property definition - you can even use the 'CreateProperty' special page to do that. No need for modifying the database directly. Yaron Koren 15:32, 8 September 2008 (UTC)Reply[reply]
I agree that it's not the ideal way to create enums, however I now realise the cause of my problem (which may or may not be related to the FCKeditor WYSIWYG extension) -
Upon creating an enum using the create property page, editing the source of the Property:<yourproperty> page to eg. add an extra enum value, caused the "[[Allows value::..]]" tags not to be displayed, causing any update to remove the semantic associations with <yourproperty>.
The solution is to ensure that any update to the Property:<yourproperty> page has the "[[Allows value::..]]" tags reinserted around your enum values.

compatibility with halo query interface

When I enable Semantic Forms extension, and try to navigate to Query Interface or Ontology Browser from the Halo (ontoworld) extension, I get the message:

“No such special page You have requested an invalid special page. A list of valid special pages can be found at Special pages. Return to Main Page.”

If I disable Semantic Forms, the Halo extension works as expected. I am using: Semantic MediaWiki (Version 1.1) & SMW+ Extension (Version 1.1)

Hm - try upgrading SMW and Halo. Yaron Koren 21:24, 8 September 2008 (UTC)Reply[reply]
Solved by moving the Semantic Forms include line to after the include line for halo (smw_initialize).

Loading Templatevalues into form fails

In one of my forms the values are not loaded into the form, the template is only displayed in the free text field. This is not a general problem. Did anyone had this problem before? Is there any solution?

  1. http://www.wecowi.net/formedit/Mexiko
  2. http://www.wecowi.net/formedit/Deutschland
  3. http://www.wecowi.net/formedit/Ecuador
  4. http://www.wecowi.net/formedit/Kuba

--DaSch 09:47, 11 September 2008 (UTC)Reply[reply]

Hi, this is most likely a problem caused by some bugs in the initial release of version 1.3 of SF. I fixed those bugs (I think) yesterday, so if you re-get version 1.3, this should go away. Yaron Koren 15:35, 11 September 2008 (UTC)Reply[reply]

Hide Edit Tab ist not working

Hi, I set $wgGroupPermissions['*' ]['viewedittab'] = false; (after call of Semantic Forms). But it does not work... - Bernhard

Form Inclusions

Is it possible to "include" form definitions? For most of the pages on my wiki, they share common details. It would be great to be able to define these details once, then pull them in for each of the forms associated with that category. Example:

Everything on the wiki shares the following details:

  • Address
  • Phone Number
  • Email

However some entries may have a additional details, a clothing store will have a "clothing type". I'd like to share the common details, Address, Phone Number between forms, but also have the option to add unique details. I'm will to fund this modification. Rodeoclash 04:29, 20 September 2008 (UTC)Reply[reply]

Hi, you can keep your money, I think. :) You can reuse form text by putting it within templates. This was explained in the SF documentation, but poorly - I moved the explanation, and tried to make it clearer - you can see it here. Let me know if it works for you. Yaron Koren 21:16, 21 September 2008 (UTC)Reply[reply]
Excellent! I did use templates but didn't realise you have to escape them (it was "rendering them). This is great news! Thanks Yaron! Rodeoclash 05:36, 29 September 2008 (UTC)Reply[reply]
Return to "Page Forms/Archive July to September 2008" page.