Extension talk:Page Forms/Archive April 2011

I have a field where users are able to insert a value and corresponding unit:

{{{field|energy|size=3}}}{{{field|energy unit|input type=dropdown|values=Calories,kJ|default=Calories}}}

The the units are in a dropdown box, can only be from the list of provided values, and one must be selected. I'm using the above code, but the problem is it also lists a NULL option ("") at the top of the list. Can I get rid of this option? --Jer Hughes 12:15, 23 April 2011 (UTC)Reply

Yes - you just have to make the dropdown field "mandatory". Yaron Koren 14:53, 24 April 2011 (UTC)Reply

Error then adding New Template with russian locale

Then I add new template with page Special:CreateTemplate and press "Save page", and I get this text "Недопустимое название (Bad title in english) Запрашиваемое название страницы неправильно, пусто, либо неправильно указано межъязыковое или интервики название. Возможно, в названии используются недопустимые символы. ". With English locale OK. I have Semantic Forms - 2.1.2 installed. But Semantic Forms ver. 2.0.9 works fine.

I can't reproduce this problem, unfortunately - I set the wiki's language to Russian, and was able to create a template with a Russian name. What database encoding are you using? That might be the issue... also, could you try creating a new wiki on http://referata.com, with Russian as its language, and see if you get the same problem there? (It shouldn't take that long to do.) Yaron Koren 14:54, 24 April 2011 (UTC)Reply

(My apologies for posting in the wrong place) I am attempting to migrate a wiki from one architecture to another (Windows to Linux). I copied over my mediawiki folder, and I exported and imported over the database with no problems. All of my pages come up with no problems. I can create new content using forms and templates. Everything seems to work except the "edit with form". Page categories have the "Have default form" property, and the tab shows up, but any time I click it on any page I'm trying to edit, I get a "HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request." I can edit the page directly, and manipulate the template data, but trying to edit with the form fails for every page. The "edit with form" functionality works as expected in the Windows server environment.

I have run a Semantic Mediawiki database "Data repair and upgrade".

I feel like I'm missing something obvious with it, but I really can't find it. I also suspect it is more Semantic Mediawiki related than Semantic Forms, but because thus far it only seems to affect the "edit with form" functionality, I'm starting here.

  • MediaWiki - 1.15.3
  • PHP - 5.3.2-1ubuntu4.7 (apache2handler)
  • MySQL - 5.1.41-3ubuntu12.10
  • Semantic Mediawiki - 1.5.0
  • Semantic Forms - 2.1.2

Versions of the scripts, because I copied them directly, are the same on both servers. The windows server is running PHP - 5.2.14(isapi) and MySQL 5.1.47-community.

Please let me know if you need anything more. Thank you! --Glitch25 20:23, 7 April 2011 (UTC)Reply

I assume the problem is some Apache configuration. Does the problem happen only with "action=formedit" in the URL, or also for URLs that start with "Special:FormEdit" (i.e., when adding new pages)? Also, does it happen if you change the action in the URL to something random, like "action=blah"? Yaron Koren 21:10, 7 April 2011 (UTC)Reply
The "Special:FormEdit" URL's work just fine. As I say, I can add new pages with forms just fine. I just can't edit them with the form once they are created. If I change the action to something random, I get the "No such acton" page. And yes, I moved from IIS/6.0 to Apache 2.2.14. --Glitch25 21:34, 7 April 2011 (UTC)Reply
Do you have a custom skin? If so, try it with one of the regular skins. Also, did you make any relevant changes to the Apache configuration? Yaron Koren 21:54, 7 April 2011 (UTC)Reply
No custom skins. Everything is default. The apache configuration is default as is installed by the Ubuntu package. I can certainly try installing it manually, but I wanted to rule out any other easier possibilities --Glitch25 22:05, 7 April 2011 (UTC)Reply
Okay, I no longer think this is an Apache issue. Now I think the issue is somehow coming from Semantic Forms. If you're willing - could you try creating a very simple "class", using Special:CreateClass, with just one or two fields, create a page with that new form, and see if that problem still happens? I think the issue might be an infinite loop of categories, or something like that. Yaron Koren 22:43, 7 April 2011 (UTC)Reply
Ok. I used the Special:CreateClass, included two fields, used the form to create a new page, and from that page, the "edit with form" link results in the same Error 500. --Glitch25 16:28, 8 April 2011 (UTC)Reply

I don't know, then - I'm out of ideas. I'd suggest writing to the SMW mailing list about it - it could be that someone else has experienced this same problem. Yaron Koren 20:03, 8 April 2011 (UTC)Reply

I'll see what i can do. I just tried a clean install on a new virtual server with no existing data. I built the class page, created a new page, and still have the failure. Not entirely sure what that tells me, but it gives me a few things to try. Thank you for your help! --Glitch25 21:34, 8 April 2011 (UTC)Reply
And just as a follow-up, I flattened the database, flattened the install directory, installed Mediawiki 1.16.2 and configured it, installed SM 1.5.6, and SF 2.1.2, and tried the Class page again and I'm getting the same issue. Something fundamental is broken. I'm guessing it has to be Apache. --Glitch25 22:31, 8 April 2011 (UTC)Reply

FIXED IT! (Well, resolved the issue for now, but have raised a few questions). I hit up the server logs to see what more I could get from them, and the two errors that occur with the Error 500 are

  • PHP Warning: Parameter 1 to Parser::startExternalParse() expected to be a reference, value given in/var/www/mediawiki/includes/StubObject.php on line 58, referer: xxxxxxxxxxxxx/mediawiki/index.php/Test
  • PHP Fatal error: Call to a member function getMaxIncludeSize() on a non-object in /var/www/mediawiki/includes/parser/Parser.php on line 2714, referer: xxxxxxxxxxx/mediawiki/index.php/Test

Digging on those errors, I see that other extensions have problems related to this as a result of using PHP 5.3. Rolling my php back to 5.2 on my scratch virtual server seems to resolve the problem. Semantic Forms works once again. Unfortunately on the original server in question, this process seems to break Mediawiki with a blank page. NO errors even with error logging turned on. Nevertheless, I think I'm close. --Glitch25 20:33, 11 April 2011 (UTC)Reply

That's great detective work! I bet those are the two issues, especially the second one. I'm pretty sure where in the SF code it's coming from, so I'll look into it. Yaron Koren 22:17, 11 April 2011 (UTC)Reply

Problem with form used on page containing multiple templates

I've been trying to debug a problem involving a form that is used to edit data contained in several different templates (some of which are set up as multiple-instance templates that use SIOs). If I simply click on edit with form, and then on save, and then click on edit to get a raw view of the wiki text, I see that the fields from the first template on the page have also been copied into the other templates further down the page. An example page where the problem can be duplicated is here.

I've upgraded to SF 2.1.2, and still have the same problem. There's a couple things I could be doing wrong which may be causing this. First, I'm running mediawiki 1.18alpha from the mediawiki svn trunk. Secondly, some of the templates use the same field names. If needed, I can try to duplicate the behaviour using a different version of MW, etc. Let me know if there's anything I can do to further help figure this out.

ChrisDavis 21:19, 7 April 2011 (UTC)Reply

Ooh, that looks bad indeed! I've heard of that problem happening in at least one other case, but haven't been able to reproduce it. If you're willing to, it would be great if you could try to replicate the problem on http://scratchpad.referata.com, by copying over the form, templates and page - that would make the problem much easier to debug. Yaron Koren 21:35, 7 April 2011 (UTC)Reply
I've been able to reproduce it on referata here. The form & templates are slightly stripped down from what's on my wiki. ChrisDavis 22:40, 7 April 2011 (UTC)Reply
Cool, thanks - that was quite helpful. I think I fixed the problem in SVN, so if you're willing to upgrade to the latest SVN version of SF (which has a bunch of other changes, though it seems to be stable), hopefully your problem will be fixed. Yaron Koren 03:31, 8 April 2011 (UTC)Reply
Awesome, thanks for the quick fix, and It's (almost) working. This fixes the original issue, although it now prevents the map from loading after I edit with form and then click on save page (javascript error - "Uncaught ReferenceError: addMapsOnloadHook is not defined"). To fix this, I tried upgrading some of my extensions to what's in use on referata (Maps & Semantic Maps to 0.7.6.1, Validator to 0.4.6), although no luck yet. Also, I'm running SMW 1.5.5. For what it's worth, my original version of SF was checked out from svn (a few months ago?), and when I updated it today, only SemanticForms.php, specials/SF_FormEdit.php, and includes/SF_FormPrinter.php where changed. ChrisDavis 08:29, 8 April 2011 (UTC)Reply
That's great that it works now. That second issue is weird - as is the small number of files that were updated. That sound like a Maps or Semantic Maps issue, though - I would ask in one of the venues for those extensions. Yaron Koren 15:10, 8 April 2011 (UTC)Reply

Warning message when trying “edit with form”

I have upgraded from Semantic Forms (Version 2.0.9) to Semantic Forms (Version 2.1.2) and I am getting the following warning message when editing or saving the form using “edit with form”:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'OutputPage::includeJQuery' was given in /home/user/public_html/adm/includes/StubObject.php on line 58

The form still works as expected and the data can be edited and saved with no problem. If I create the form (or save it) using #formlink the error message is not displayed I have installed:

  • MediaWiki 1.15.1
  • Semantic MediaWiki (Version 1.5.6)

Thanks in advance, great extension!

I'm not sure this error is coming from SF - do you have Semantic Forms Inputs or Semantic Maps installed? If so, what version? Yaron Koren 15:50, 8 April 2011 (UTC)Reply
I had Semantic Maps 0.7.1 installed. I disabled it, try "edit with form" and I got the same warning. Then, I disabled every extension except Semantic MediaWiki and Semantic Forms, but the warning message was still being displayed. Xavi 09:50, 11 April 2011 (UTC)Reply
I have upgraded to MediaWiki 1.16.4 and the warning message is no longer displayed. Xavi 11:39, 17 April 2011 (UTC)Reply
Hi - okay, that's good to hear. By the way, if you're still reading this, what version of PHP are you using? I think that's relevant as well. Yaron Koren 15:59, 17 April 2011 (UTC)Reply
I've read the posts talking about problems with PHP 5.3, but I was using PHP 5.2.13. Anyways, it works now. Thanks! Xavi 16:56, 17 April 2011 (UTC)Reply

Templates within Templates?

Hi there; First off, excellent work on this extension.

Now for my query... I've created a form to input details of customers into a business wiki and so far it seems to be working reasonably well. Most fields are fairly straight forward and fit within one fairly simple template. However, my final field is meant to be an array (using #arraymap) of "contacts", which in the sense of my wiki are input via a template and include the contacts name, email and position within a company. Is there any way to effectively embed a template as a repeatable field within another template using this extension. Ashimema 22:39, 11 April 2011 (UTC)Reply

Thanks. Unfortunately, no - but if I understand what you're doing correctly, I would recommend, instead of using #arraymap, using a multiple-instance template, and the Semantic Internal Objects extension within that template to store the data. Yaron Koren 23:01, 11 April 2011 (UTC)Reply

Wow, that was a quick response! I think you understood me right (which reading back and realising how cryptic I was, is pretty impressive). I've already discovered the SIO extension you mention and in fact am already using it in this way. So currently my form is implemented as one template for half the details (which don't need/want to be repeatable) and one multiple-instance template which implements the SIO extension. I was just hoping to consolidate them for aesthetics in the final page. My "Contact" template takes Name, Email and Position as variables, saves them as semantic properties and outputs the name as a mailto using the email address (i.e hiding the email in favour of linking the name). The "Customer" template takes various "one time" details AND the list of "Contacts" and outputs them as a neatly formatted table. I'm sure there's a way around it using multiple templates to build my table so maybe i'll invest the time in doing that.. but it was worth an ask first. Thanks for your reply and keep up the great work! Ashimema 23:18, 11 April 2011 (UTC)Reply

Yeah, I agree that it would be nice to be able to embed multiple-instance templates within the "main" template. Given the current setup, you might need to have yet another template, after the multiple-instance one, to define the bottom of the template. Yaron Koren 23:52, 11 April 2011 (UTC)Reply

It would be really nice to have templates work as arguments for a field. For what I'm trying to do it would be the perfect solution. Is this a planned feature?

I suppose it's a planned feature, in that I would definitely like it to be added to Semantic Forms - but it's not something I have any specific plans to work on. Being able to handle embedded template calls might require a substantial amount of effort. Yaron Koren 04:07, 27 April 2011 (UTC)Reply

Warning and Fatal error when trying “edit with form”

MediaWiki 1.16.1 PHP 5.3.0 (apache2handler) MySQL 5.1.36-community-log Semantic Forms (Version 2.1.2) Semantic MediaWiki (Version 1.5.6)

I already tried disabling all of my other extensions in order to see if they cause these errors. Errors happen after updating to the newer SF

Warning: Parameter 1 to Parser::startExternalParse() expected to be a reference, value given in C:\wamp\www\WikiError\includes\StubObject.php on line 58

Fatal error: Call to a member function getMaxIncludeSize() on a non-object in C:\wamp\www\WikiError\includes\parser\Parser.php on line 2714
Thanks - yes, someone else just discovered this error earlier today; see the "error 500" message, above. Yaron Koren 23:53, 11 April 2011 (UTC)Reply
This is unfortunately difficult for me to debug, since I think it only shows up for PHP 5.3, and I have PHP 5.2. But I just checked in something to SVN that might solve the problem - see here. If possible, could you apply this change to your code, and see if it makes a difference? Yaron Koren 16:25, 12 April 2011 (UTC)Reply
Same errors both. No change for me.--Glitch25 16:49, 12 April 2011 (UTC)Reply
Okay - thanks for testing. I'm currently trying to upgrade my version of PHP. For now, I think you can get around the problem by just commenting out the startExternalParse() call... Yaron Koren 17:26, 12 April 2011 (UTC)Reply

That resolved the startExternalParse() error but not the getMaxIncludeSize() error. Still crashes with a 500. Thank you for your help with this. I really appreciate it, and really enjoy this extension! --Glitch25 17:41, 12 April 2011 (UTC)Reply

I don't know if you saw, but F.trott checked in another fix to SF on SVN, that seems to now fix the problem. Could you try this one out and see if it works for you? Yaron Koren 00:36, 15 April 2011 (UTC)Reply

I think I've found a bug?

Loosely related to my comments above I've been playing with creating a form field that accepts multiple "text" values as a comma separated list. (In the long run I was hoping to make each text entry a valid wikitext statement to pass through to the second template.. but that's another matter) So, In my template I have a bunch of statements including:

|-
! Other Contact(s)
| {{#arraymap:{{{Contact|}}}|,|x|x|\n\n}}
|-
! colspan=2 | '''Service Details'''
|-
! Product(s)
| {{#arraymap:{{{Products|}}}|,|x|[[PTFS Service::x]]}}
|-

So the first arraymap does not have a property attached to it, but the second arraymap has a property of type "text". What appears to be happening when I try to create a from using this template is that the first arraymap is linking itself to the property associated with the second arraymap.. and try as I might I don't seem to be able to undo that relationship. Worse is that the second array map does not seem to link to any property at all...

Any Ideas? Ashimema 12:12, 12 April 2011 (UTC)Reply

If that's indeed happening, that's definitely a bug, but it sounds very strange... could you try replicating this problem on a public wiki, like http://scratchpad.referata.com? (Also, the "String" type might be a better fit for that property than "Text"). Yaron Koren 13:39, 12 April 2011 (UTC)Reply

Sorry for the slow reply... It was a busy evening! I've created all the necessaries on your scratchpad wiki to duplicate the error. If you try to create a form using the template "Customer" now you'll find that the "Field 'Contact'" defaults to property "PTFS Service" which it shouldn't and the "Field 'Products'" which should be relative to "Property 'PTFS Service'" actually defaults to a text input with no property? I'll take you advice regarding Strings as opposed to text under consideration.. I think your right... I was in somewhat of a hurry while experimenting. Ashimema 10:29, 13 April 2011 (UTC)Reply

Ah, yes - that's a bug. I never tested the possibility of a call to #arraymap that doesn't set a property - I bet that's what's causing the issue here. I'll try to fix the problem, but until then you could work around the bug by adding a property setting to the "Contact" field; or, you can manually set the behavior of those form fields to be correct, including setting the right property, via the "property" parameter. Yaron Koren 13:09, 13 April 2011 (UTC)Reply

Cheers for taking a look into it Yaron. Just as some further information, (but maybe just polluting the information I've already given) I've already got a property (of type "page") called 'contact'. It's actually the SIO I set-up for holding contact information within pages.. Wonder if that's possibly causing any issues. But yeah, thought I'd mention it as an aside as you noted that a workaround should exist whereby making "contact" a valid property should solve the problem.. temporarily. unfortunately no cigar. Anyway, I continue to think this is an excellent extension... only wish my PHP was a little better; then rather than jsut pointing out bugs, I might be able to submit "patches".. Ashimema 13:19, 14 April 2011 (UTC)Reply

Hi Yaron, I was just wondering if you'd had a chance to look into this. I'm back to working on my wiki and am currently thinking of how to work round it at the moment.? Ashimema 05:43, 4 May 2011 (UTC)Reply

You can work around it using the method I described above. Yaron Koren 15:52, 6 May 2011 (UTC)Reply

PHP Notice:

Hi Yaron, my error log records the following notice when I create a page with a form: "Undefined variable: text in /.../extensions/SemanticForms/includes/SF_FormInputs.php on line 914" I does not seem to be a big issue since my page gets created an is queryabel. Still I would like to pass this information to you. Cheers --[[kgh]] 14:06, 13 April 2011 (UTC) NS I forgot to add that I am using SF 2.1.2 on MW 1.16.2 --[[kgh]] 21:58, 13 April 2011 (UTC)Reply

Thanks - I believe this has been fixed in SVN for a while, but it's good to know that it's in the current released version. Yaron Koren 00:06, 14 April 2011 (UTC)Reply
Cool and thank you. Cheers --[[kgh]] 07:34, 14 April 2011 (UTC)Reply

More help on using forms to creatre custom search query

HI, Any chance of some examples on how exactly to use Special:RunQuery? Or a walkthrough? With examples of a working template and form etc?

Workaround for values with commas in them?

Hello, I have a dropdown list that get it's values from a huge external database that changes now and then. My problem is that the values often include commas (,). If I remove the commas before printing them, I will have to keep an updated table of corresponding values to those strings without commas, which would mean a lot of maintenance. I could switch the commas for, say semicolons, before printing, but then any function that reads the resulting property value will have to know how to do the conversion backwards, which will sooner or later fail. There is also no guarantee that the fields will not, att some point, contain a semicolon (or whatever character I would choose). Does anyone have a clever workaround? Is it possible to hack SF to accapt other delimiters somehow? rotsee 08:22, 17 April 2011 (UTC)Reply

It's certainly possible to hack SF to do that, yes - and ideally, SF should be able to handle delimiters other than commas. Out of curiosity, how are you getting the values from the database into the form? Does that involve an SF hack as well? Yaron Koren 15:05, 24 April 2011 (UTC)Reply
Well, first I made a parser function to print out the values, but then I found out that the parser function wouldn't be processed. Until I have more time to do something about it, I just use the same parserfunction to generate the list, and then manually cut and paste into the form once a week or so. (It's not at all a critical function, just the data to automatially generate a map in the bottom of articles, as seen for instance here: http://xn--ssongsmat-v2a.nu/ssm/Aubergine ). rotsee 21:04, 24 April 2011 (UTC)Reply

Mandatory Checkbox

Hi, is there currently a way to make a mandatory checkbox "uncheck" each time you edit a page? I want to make users agree to a condition before submitting a page and I haven't been able to find a solution yet. Thanks --68.183.115.225 05:24, 24 April 2011 (UTC)Reply

No - the basic issue is that the form won't automatically overwrite what's already on the page. Instead of a checkbox, why not just have some legal text within the form? That's how this wiki and other wikis do it ("By editing this page, you agree to irrevocably release your contributions under the CC-BY-SA 3.0 License...") Yaron Koren 15:02, 24 April 2011 (UTC)Reply

Uploads clickable?

I used the "uploadable" option with success, but now I would like the files to be clickable. So, to be precise:

  1. I have a field file which is uploadble
  2. I upload a file, eg. A.doc
  3. A.doc succesfully is the value of file
  4. But I cannot click A.doc to get the doc

How can I make it automatically clickable? I know that it just needs "file:" in front to work, so is there a way to add that automatically?

I think this is behavior most people would expect from this option, so if someone let's me know I'll be happy to put it in the documentation.

Thanks a lot in advance!

In the template, you should have "[[File:{{{field name}}}]]" instead of just "{{{field name}}}". Yaron Koren 12:36, 26 April 2011 (UTC)Reply

Partial Form issues

I'm having some issues with partial forms. They don't place content where I want it to be. I have multiple partial forms for several sections of a page divided with headlines. I placed a formlink in each of this headlines to start the partial forms in a popup. The partial forms each contains a multiple instance template. If you remove all instances or have no instances of this template to begin with (or a placeholder text), added instances with the partial form simply gets placed at the start of the page and not under the headline where I wanted it to be. Is this intended or could the formlink parsertag be aware where it was placed?

It's not intended behavior per se, but it is indeed what happens, unfortunately. One option that might work for you is to create a quasi-partial form, which is a normal, non-partial form, that contains all the templates of the "main" form, but just doesn't have fields for any of the templates except the one that you want the form to edit. Yaron Koren 21:15, 28 April 2011 (UTC)Reply

Issue with Semantic Forms + Header Tabs + multiple instance templates

Apologies for cross-posting from here - haven't heard anything in a few days. I've run into an issue where using header tabs in conjunction with multiple instance templates in a form messes up the rendered HTML for some of the form elements. I found this when trying to figure out why autocompletion wouldn't work on fields located not on the first tab. I've been able to duplicate this issue on referata here, and when you view the rendered HTML for the input fields, you'll see that the field on the last tab has the same name as the field in the multiple instance template on the second tab... in other words, data will end up getting saved to a different field than expected.

Thanks in advance for your help, ChrisDavis 08:14, 27 April 2011 (UTC)Reply

That definitely looks like a bug in SF - I'll look into it. Yaron Koren 21:17, 28 April 2011 (UTC)Reply
Hi - I hope you're still reading this. I finally looked into the issue, and the form definition you're using has some invalid syntax - there's a "for template" tag that doesn't have a corresponding "end template", and the last field is outside of any template. I assume that's the basic cause of the problem - are these errors intentional? Yaron Koren 15:38, 5 May 2011 (UTC)Reply
Thanks for the help, and this was indeed user error on my part. I've gone back through and carefully specified start and end tags, and things are working properly now. ChrisDavis 11:08, 7 May 2011 (UTC)Reply

Textarea contents randomly disappearing in partial popup forms

Hi, I'm using a partial form with a textarea in it for a property with type text. I use a link to open it in a popup. In almost all cases, the textarea seems not to be editable or contain any content. I haven't pinned down the cases where it works yet, it seems completely random. If use a text input instead of a textarea or do not use the popup option, it works just fine.

Using MW 1.16.2, SMW 1.5.6 and SMF 2.1.2 on Apache2 with PHP 5.3.5. Tobias Rummelt 11:48, 27 April 2011 (UTC)Reply

Could you reproduce this on a public wiki, like http://scratchpad.referata.com? That would help a lot in debugging. Yaron Koren 21:17, 28 April 2011 (UTC)Reply
Hi, sorry it took me so long. But I recreated the problem on your scratchpad. Look here. It reproduces the problem for me. I should mention that I'm using Firefox 4. Tobias Rummelt 07:31, 4 May 2011 (UTC)Reply
I just tested it with IE7 and it does not reproduce the problem... I can not test it with other browsers, but maybe it's only a FF problem? Tobias Rummelt 07:48, 4 May 2011 (UTC)Reply
Hi - there seemed to be an error in your setup, that I think I fixed here. Are you still seeing a problem? Yaron Koren 16:12, 5 May 2011 (UTC)Reply
Unfortunatly, yes. This was just a little copy paste error on my side. Another thing I found out: FF 4 has the ability to resize textareas browser-side. When resizing the textarea in the popup window, the popup will adjust its size. While adjusting (takes about a secound) the text is visible. But after resizing itself, the text disappears again. Tobias Rummelt 12:00, 6 May 2011 (UTC)Reply
I think I fixed the bug. Could you replace extensions/SemanticForms/libs/SF_popupform.js in your installation with the latest file from the SVN repo and see if it works? --F.trott 21:35, 6 May 2011 (UTC)Reply
Yes! That fixed it. Thank you. Tobias Rummelt 10:44, 10 May 2011 (UTC)Reply

When I start a new article using forms I can't use links in the fields. If I try I receive the following information after saved: [[property::my text and my links]]

Is there a way to appear only the text and links?

We are using Mediawiki 1.17alpha. Anabarcellos 20:16, 28 April 2011 (UTC)Reply

$smwgLinksInValues might be the issue here. Yaron Koren 21:19, 28 April 2011 (UTC)Reply

Autocomplete on multiple types of value sets (eg category and property)

Hi Yaron, Thanks so much for this incredible extension. Question on autocomplete (I looked through the archives and didn't see any mention of my question elsewhere). Is it possible to set up autocompletion so that it will go off of both a category AND any previously entered values? (This is for a field with input type "Page"). The default behavior of the field is to autocomplete on any other values I have put in, but when I add "|autocomplete on category=Some category" it will only autocomplete on values that are in that category; if I add a new value that isn't yet a page in the category, and then go to a new form, the new value will not show up in the autocomplete results.

I would like users to be able to see what others have put in as values for the field, even if a page for those values has not yet been created. The purpose for this is to help minimize entry of new values that have similar names/spellings (e.g. if it were a field that specified companies I would not want one person to enter "Microsoft" on one page which used the field and another to enter "Microsoft Corp" on another page).

On the same topic, is it possible to have autocompletion on multiple categories, or a category and a property? Other combinations? Thanks for any help you may be able to offer.

Hi - I'm glad you like it! There's no direct way to do that within the form definition, unfortunately, but there are two possible indirect approaches: the first is to use a "concept" and then do "autocomplete on concept" within the field tag - that would work for some of those options (like multiple categories) but probably not all. The second is somewhat hack-ish: if every company page uses a template, you could have each of those pages point to itself using a hidden call to that same property, so that the property's values would always include all the pages in the category. Not semantically correct, but it would work. Yaron Koren 13:09, 1 May 2011 (UTC)Reply

The following drowdown definition doesn't default to value 0 as it is expected:

{{{field | transaction split | input type=dropdown | values=0, 1, 2, 3, 4, 9 | default=0 | mandatory}}}

inestead it creates a null value in the dropdown list. See exaple here. If the default value is other than 0 (e.g.: default=1) it works as expected. --Xavi 08:55, 30 April 2011 (UTC)Reply

Thanks for letting me know about that - it was a bug in the code. I just fixed it now in SVN - see here. Yaron Koren 13:21, 1 May 2011 (UTC)Reply
Thanks for the quick fix --Xavi 06:28, 2 May 2011 (UTC)Reply
Return to "Page Forms/Archive April 2011" page.