Extension talk:Page Forms/Archive July to August 2012

Can't seem to get "info|page name=" working?

I'm currently unable to get the "info" tag working partnered with a "page name" variable... My form code is copied below, any hints would be most welcome:

{{{info|add title=Create a new suggestion|edit title=Edit a suggestion|page name=Suggestion <unique number;start=1>}}}
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Sug line}}}
{| class="formtable"
! Username:
| {{{field|username|mandatory}}}
|-
! Suggestion:
| {{{field|suggestion|mandatory}}}
|-
! Status:
| {{{field|status|mandatory}}}
|}
{{{end template}}}

'''Free text:'''

{{{standard input|free text|rows=10}}}


{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}

and the call for the form:

{{#formlink:form=Suggestion
| link text=Make a suggestion
| link type=button
| query string=namespace=User
}}

Clicking the button just directs you to the "main" frontpage of the wiki site. Ashimema (talk) 12:06, 5 July 2012 (UTC)

-OK, I've just narrowed this down to being a problem with "link type=button".. if I leave that out it seems to work as expected? Ashimema (talk) 12:28, 5 July 2012 (UTC)

What version of SF are you using? Yaron Koren (talk) 18:15, 5 July 2012 (UTC)

Sorry Yaron, should have included that detail in the original post.. Silly me. MW 1.19.0, SMW 1.7.1 and SF 2.4.2 (Also have Results Formats 1.7.1 and Form Inputs 0.5 Installed to.. but don't think they're affecting this issue?) Ashimema (talk) 08:09, 6 July 2012 (UTC)

Correction to above, I noticed that Semantic Forms Inputs had a new release i hadn't spotted.. just updated to 0.6. Problem with button type is still apparent. Ashimema (talk) 08:18, 6 July 2012 (UTC)

It's definitely not related to SFI. Actually, my guess is that it's due to your URL structure, in one way or another. What's the URL it take you to when you press on the button - is it literally ".../Main_Page"? Yaron Koren (talk) 18:17, 6 July 2012 (UTC)

Had a feeling it wasn't anything to do with those related plugins but thought it worth adding them in to give a complete picture. Removing any extra parameters (i.e. pre-fill options) the URL the button takes me to is "http://wiki.sedar.org.uk/index.php?title=Main_Page". With any of the pre-fill bit's added, they just get appended to the url as expected (and work perfectly if no "link type=button" is present). It's a private wiki, but i don't think there' any sensitive data on there yet so I'de happily add you an account if it helps for tracking down the problem? Ashimema (talk) 07:26, 9 July 2012 (UTC)

Ah, I didn't know this was a public wiki. Yes, an account would be very helpful - please create an account, and send me the details at yaron57 -at- gmail.com. Yaron Koren (talk) 12:43, 9 July 2012 (UTC)

Cheers Yaron.. I've just sent requested login details to your email... Ashimema (talk) 12:57, 9 July 2012 (UTC)

For future reference: this turned out to be caused indirectly by the fact that the URL contains a '?'; so it's a bug in SF, but one that's somewhat difficult to fix. Switching to "link type=post button" made the problem go away. Yaron Koren (talk) 13:01, 10 July 2012 (UTC)

Hi again Yaron. I've just discovered that using the 'post button' option seems to cause an error with the 'namespace=' declaration. It no longer seems to apply? Ashimema (talk) 13:27, 8 August 2012 (UTC)

Unintended Behaviour of parameter?

When using a combination of input type=dropdown and values from category=category name I was expecting only the pages in said category to be displayed in the resulting dropdown field, however all pages and sub-categories were included instead. Is this the intended behaviour and if so, is there any way to achieve the behaviour I'm attempting to achieve explained above? --Ashimema (talk) 14:30, 12 July 2012 (UTC)

I can't reproduce that. Is this behavior viewable on a public URL, or could you replicate it on a public wiki? Yaron Koren (talk) 20:24, 12 July 2012 (UTC)

Hi again Yaron.. I seem to be asking allot of you at the moment, Sorry! I'll try to replicate this on a public URL, but as you've probably guessed this is on the same private wiki as the above query was related to (I've not yet updated it to use short url's as i'm not 100% familiar with how to do it in my subdomain setup). I've not yet removed your account on that wiki though so your welcome to take a look in there if it helps again? The form in question is [1] --Ashimema (talk) 11:10, 13 July 2012 (UTC)

Hi, I just looked at the form - did you mean to say that the problem is that the input includes all pages in subcategories? And did you mean "in addition" instead of "instead"? If so, that's not a bug - that's the desired behavior, to include pages in subcategories as well. If you think that's bad behavior, it's worth discussing it - maybe there should be a setting for it. Yaron Koren (talk) 12:19, 13 July 2012 (UTC)

Hi Yaron, that is correct (Sorry for the poor description). I see now where I'm going wrong, I'de interpreted as in category to mean just those pages within the top level category, not the sub-categories as well. Now that I understand that, I can probably manipulate my category structure such that the problem is alleviated, although I do think an option would be an nicety on the feature itself. I wonder what anyone else thinks? --Ashimema (talk) 12:46, 13 July 2012 (UTC)

Conflict with xcache?!

I've added xcache to my php installation. And suddenly I cannot access SpecialPages main page, and get an error

Fatal error: Cannot redeclare class SFUploadWindow2 in ...\extensions\SemanticForms\specials\SF_UploadWindow2.php on line 1117

Is there any explanation for that?! that is definitely the only change I've made. Once I remove xcache reference from php.ini, the problem is resolved. My wiki is on MW 1.18.0, PHP 5.2.17, IIS, SMF 2.3.2, SMW 1.6 Osishkin (talk) 03:25, 18 July 2012 (UTC)

Hi - other people have reported that problem before, but no one has come up with a solution yet. If you upgrade SF, you'll at least get a different error message - it'll refer to "SFUploadWindow" instead of "SFUploadWindow2". I have a hunch, though, that if you upgrade PHP, the problem will go away: in all three cases I know of now for that issue, PHP was at 5.2.17. Yaron Koren (talk) 03:57, 18 July 2012 (UTC)

I see. I'll try having a go at PHP 5.3 just in case, though that obviously may break other code...is there perhaps a simple hack to just remove the reference to the SemanticForms special page, so that SpecialPAges won't parse it? or is it embedded too much in the code?

You definitely don't want to remove the UploadWindow special page - it's important. Yaron Koren (talk) 01:21, 19 July 2012 (UTC)

I dont mind doing that, I have no use for it myself. Osishkin (talk) 04:36, 19 July 2012 (UTC)

One link->two autoedits?

I need to have a single link generate two autoedits, where the sequence is important. Is there a trick to doing this? So far, I have tried:

• nesting two {{#sfautoedit tags (one is the link text of the other). Only the inside one runs; it looks like the HTML generated by the parser function gets all muddled.
• creating a hook function on the ArticleSaveComplete hook of the first one, calling the second one from PHP. It appears that when ArticleSaveComplete is triggered, we are still inside the edit session, and mediawiki refuses to initiate one edit session inside another (I think).

Any other ideas? I'm thinking of creating a new parser function that will call the two autoedits from PHP in series, but I would prefer to put as much of it into wikicode as possible, rather than PHP.

My guess is that a new parser function would be the only way to do that, but I could be wrong. Yaron Koren (talk) 05:32, 23 July 2012 (UTC)

Different form behaviors when creating or editing

Hello,

I´d like to implement a different behavior to forms when they are creating a new register or editing an existing one. For example, when creating I want all fields to be non restricted, but once the page is created I´d like to block users from editing some fields (used to define the page name).

I´ve tried to use parserfunctions to echeck if the title had the Edit word but unfortunatelly {{PAGENAME}} doesn´t return anything.

Any suggestions?

I don't believe that there's any way to do that. But are you sure that it's a good idea in the first place? Obviously, it's good for the page name and the data on the page to match up. But on the other hand, if there's an error in one of those fields, shouldn't it be fixed? Yaron Koren (talk) 05:35, 23 July 2012 (UTC)

Yes, for sure! Unfortunatelly I couldn't find a way to change page's title after the creation process so any changes the user may add to the fields in question won't update the page's title. Two things I though about: using a GET variable and parsing it in the form so I can add the restricted parameter when required or using DISPLAYTITLE magic word, but this way the link for the page won't fit the title. (Gabriel Simões - 23 July 2012)

Creating Form issues

First let me just say that I LOVE this extension. It is amazingly helpful so please don't let my comments sound like an ungrateful jerk. I am having a couple of issues with wehn using the Special:CreateForm.

The first issue is the dropdown menu that appears when I try to "add a template" does not appear in alphabetical order most of the time.

Second, the values do not seemed to be mapped correctly. So if for the first field I give it a form label of "FIELD ONE", the second field I give a label of "FIELD TWO" and so on, Those labels get all jumbled up so that the first field has a label of "FIELD EIGHT" for example.

Finally, one thing that is very frustrating is that when I click on "show preview" I get a wonderful look at how the form will appear when I am done, and I can see the code associated with it, but I am no longer able to use the AWESOME form to create the form. One of the reasons I love this tool so much is the interface that it gives you to create a form. It would be nice to be able to continue to edit these forms using this same interface.

--Zackmann08 (talk) 16:32, 30 July 2012 (UTC)

Hi - great, I'm glad you like SF. For the first issue - that's an issue I hope to look into. The second issue sounds like a very major one, if true: are you saying that you select some value in the form, and then a different value shows up on the resulting page when you save? The third issue is true - you can only use Special:CreateForm to create forms, not edit them. The Page Schemas extension was created in large part to get around this issue - it might be worthwhile for you to try it out. Yaron Koren (talk) 19:05, 30 July 2012 (UTC)

Well this is just great. A MONTH after you respond, I get around to looking back here. :-( Sorry about that... You interpreted my 2nd issue correct. That is exactly what happens. I am looking into Page Schemas right now. Thanks! --Zackmann08 (talk) 19:13, 27 August 2012 (UTC)

SemanticForms_registerInputValidation under MediaWiki 1.19.1

I'm seeing a strange bug that I would appreciate some assistance with. While the information below may not be enough for you to diagnose the problem, I'll at least initially attempt to be brief in the hopes that somebody else will recognize that they have had a similar problem and solved it.

I am building a SematicForms input type extension. I need to do some custom validation on the field, so I am registering an input validation routine using SemanticForms_registerInputValidation. I am using SemanticForms version 2.4.2 with Semantic MediaWiki 1.7.1. Under MediaWiki 1.18.0, my code works fine. Under MediaWiki 1.19.1, all other things remaining the same, I find that the SemanticForms_registerInputValidation function is not being bound to my field. That is, when I use FireBug to examine jQuery('#input_2'), which correctly points to my field using both versions of MediaWiki, none of the SemanticForms_* routines that appear in the list of entries for the object under MediaWiki 1.18.0 are there under MediaWiki 1.19.1. Perhaps this is due to the different jQuery version? Here's the segment of code in question:

  var field = jQuery('#input_2');
  var registerInputValidation = field.SemanticForms_registerInputValidation;
  registerInputValidation(
    input_2_sfuniqueproperty_validate,
    ['info_2', 'ABC', 'Long Name', '[[Category:Organizations]]']
  );

In this code, field gets set correctly. However, the registerInputValidation function is undefined in MediaWiki 1.19.1 but correctly defined in MediaWiki 1.18.0. Any suggestions would be much appreciated.

I was able to fix the problem. There was a race condition where the code above was being called before the code that attaches SemanticForms_registerInputValidation to the input field was executed. I'm guessing that the change in jQuery version between MediaWiki 1.18 and 1.19 subtly changed the initialization order. My code was not following strictly the same pattern as that in SemanticFormsInputs. I went back and restructured my code using TimePicker as a model, and now it works perfectly. It appears that I was just lucky that it worked in MediaWiki 1.18.

WYSIWYG worked in SF 2.3 but is not working in SF 2.4

Hi,

I added the one-line-patch from ontoprise to get the WYSIWYG extension work for the free text field in SF 2.3 and it was working fine when adding ?mode=wysiwyg to the url. After updating SF to version 2.4 it is not working anymore.

Error message in Firebug (ResourceLoader in debug mode): uncaught exception: [CKEDITOR.editor.replace] The element with id or name "undefined" was not found.

Any idea? Thanks a lot for support! --Filburt (talk) 10:00, 1 August 2012 (UTC)

Hi - personally, I don't know anything about setting up the SMW+ stuff. Have you tried contacting the SMW+ developers? Yaron Koren (talk) 13:43, 2 August 2012 (UTC)

Hi Yaron, thanks for the reply. As I know ontoprise (the SMW+ developers) became insolvent in June, therefore it is not possible to contact them anymore. But there are some community folks making the WYSIWYG extension better and also working with MW 1.19. The mentioned patch for SF is only to add $output->addModules( 'ext.wysiwyg.core' ); in /extensions/SemanticForms/includes/SF_Utils.php line 292. Nothing else needed to be changed in Semantic Forms 2.3 that WYSIWYG was working with it. It would be really great to get it working again in SF 2.4 and independent from the former SMW+ stuff. Probably it needs only some samll changes in SF 2.4 ...

Thanks in advance!

--84.50.58.57 07:13, 3 August 2012 (UTC)

Conflict with Extension:Inputbox

I haven't done too much testing but after I added an <inputbox> tag inside my form definition is borked the save mechanism. Instead of just saving the page it would to to the standard edit page without the changes and the URL was very long. I created a much simpler test form and included an <inputbox> tag. This time clicking save just did nothing. Removing the tag resolved the issue immediately. -MikeB

Enhancment/Query

I'de like to create a formlink/forminput with an input box that fills one of the form fields as apposed to becoming the page title. I'm not sure if this is already possible but if it is, i've not worked out how.. Any tips? Ashimema (talk) 15:13, 2 August 2012 (UTC)

Form fields can be set via the query string - so I suppose you could put in an entire form manually into a wiki page, that had inputs with the correct field names - you could use the Widgets extension for that. Yaron Koren (talk) 20:09, 2 August 2012 (UTC)

OK, so i've acutally decided this is a silly idea and just let it be a normal button link without an input box.. but thanks for the suggetsion Ashimema (talk) 09:01, 3 August 2012 (UTC)

Redlink on Formedit

Another silly question... I've created a pre-filled formlink in a template to enable the creation of new pages simply using data from an existing page. It uses the parser-function "ifexist" to display a form if the page doesn't already exist, or display the page if it does. Is there any way to get my formlink to display red like other redlinks in mediawiki using this pre-filling solution? Ashimema (talk) 09:01, 3 August 2012 (UTC)

Yes - instead of using #ifexist and #formlink, just link to the page with a property, and then associate that property with a form. Yaron Koren (talk) 17:44, 3 August 2012 (UTC)

I've used that approach in a number of places, but in this case I wanted to prefill the form for the new page with some value form the linking page... Hense using the ifexist and formlink with prefills? Ashimema (talk) 09:45, 4 August 2012 (UTC)

Oh, I see. Well, you could potentially use "default=" in the form definition instead, depending on what else you're using the form for. Yaron Koren (talk) 03:35, 5 August 2012 (UTC)

Has default form, based on namespace

I am using 1.19.1 and try to get familiar with SMW, which looks great. Presently, I am trying to use namespace-specific form-tabs in custom namespaces. This helppage says „You can do that by placing a 'Has default form' property in the page defining that namespace“. I never heard of such pages "defining a namespace", but I understand it's a page in the project NS with the pagename of the NS under consideration. But that did not work, nor the same in MediaWiki NS. I created, for instance: "project:Literatur" and added [[Has default form::Literatur]] (namespace and form existing, of course) but to no avail.

Not compatible with 1.19.x? Or did I get something wrong?

Btw., the trick works with categories, but for some reason I need it in NS.

Thanks in advance for advise.

Bernhard

Hi Bernhard. I have a similar setup working on one of my local wiki's. The Wiki name is "Sedar" so there is a default namespace with that name (i.e. pages "Sedar:*") It is in this namespace that your custom namespace definition needs to reside. Example: So, in my wiki, we've got a customer namespace defined called "Suggestion" (i.e. in the Localsettings.php file we have

# Custom Namespace for Suggestions #
define("NS_SUG", 500);
define("NS_SUG_TALK", 501);
$wgExtraNamespaces[NS_SUG] = "Suggestion";
$wgExtraNamespaces[NS_SUG_TALK] = "Suggestion_talk";

You may also want

$smwgNamespacesWithSemanticLinks[NS_SUG] = true;
$smwgNamespacesWithSemanticLinks[NS_SUG_TALK] = false;

to enable semantics on in that namespace.

And then on the page - Sedar:Suggestion:

[[Has default form::Suggestion]]

Ashimema (talk) 08:48, 6 August 2012 (UTC)

Using tables with 'input type=textarea'

If someone tries to use table syntax inside of a text area, it will obviously break, since the input is being fed to a template, and it interprets the | characters in the table syntax as a new template parameter. The usual way around this in a wiki would either be to use {{! }} or HTML tables. However, from a user perspective, this isn't really intuitive; the average user using the semantic forms isn't going to realize that tables will break inside the text areas without formatting it a specific way... even more so, since the average user won't equate that the input is being fed to a template.

Is there any way around this? Like, is it possible to add a text area that just adds text straight into the article without first parsing through a template? There's the free text input, but that won't help if I need more than one textarea within the form. --143.85.199.241 17:24, 6 August 2012 (UTC)

I don't think there's a good solution... though if you know in advance what the structure of the table will be, you could have the form actually create the table, using multiple-instance templates. Yaron Koren (talk) 13:02, 13 August 2012 (UTC)

Free Text field and interaction with other extensions

Hi, I was trying to modify the MsUpload extension so that it could be used with the Free Text input in Semantic Forms. Is there any sort of hook or something I can check to get the extension to run it's initialization properly when the free text box in a form loads? I've already got it using sf_free_text in the js code, instead of wpTextbox1, but I was unsure what to check for in MsUploads main php file.

Thanks!

Field with preformatted text don't work

Hi, I use some forms in our MediaWiki-installation and it works fine, so far. But today we add a field, which shall contain preformatted text. I add a property of datatype code but my preformatted text contains signs like vertical bars ( | ). So the field-content is not correct after saving the form (only the part until the first vertical bar was saved). Is there another way to save text like this?

Yes, pipes/vertical bars will mess up the formatting, unfortunately. I think the only solution may be to replace pipes with their HTML equivalent, "&#124;". Yaron Koren (talk)

Thanks a lot. The replacement works fine.

SemanticForms and preprocessing?

Hi,

is there any way to change (by ParserFunction or StringFunction) the input data after save by user but before save in template?

Thx Daniel

I don't think so. Yaron Koren (talk) 21:41, 9 August 2012 (UTC)

Multiple fields for a single value

Is there a way to have multiple fields output a single value, in this case i am looking for a field to enter the value "25", and a seperate field to be a dropdown to select the unit type, in this case "Kilograms", the result on the final page should be "25 Kilograms" (with the space) as a single value. This single value is the value of property:weight

Another example would be to define the brand and model of a product, in this case I would want a field to select the manufacturer, in this case "Weldwood", and another field to type the model, in this case "3702-1300", when saving the form, the value would be "Weldwood 3702-1300" (again with an intentional space between brand and model). this result will be the namspace of the page, Is there a way to do this?

You could write something like this in the template:

[[Weight::{{{value|}}} {{{unit|}}}]]

--143.85.199.241 18:02, 6 August 2012 (UTC)

OK Tried that, however, now the combobox shows the numerical values which the property page defines as "corresponds to::". e.g.

• corresponds to::1 tons, ton, short ton, short tons, American ton
• corresponds to::2000 lbs, lb, pound, pounds
• corresponds to::907185 g, gram, grams
• corresponds to::907.18474 kg, kgs, kilogram, kilograms
• corresponds to::0.892857143 long ton, long tons, weight ton, weight tons, imperial ton, imperial tons, British ton
• corresponds to::0.90718474 metric ton, metric tons, tonne, tonnes
• corresponds to::62.1619003 slug, slugs

The values in this combobox are 1, 2000, 907185, 907.18474, 0.892857143, 0.90718474 & 62.1619003

instead of showing, tons, lbs, g, kg, longton, metricton, slug

Is there a way around this so, without having to define the allowed values in the form? (this is to prevent having to define the allowed values in every form that uses this property and allows the selectable options to be defined by the property page itself)

If I understand the issue correctly, you could always store the value and unit with their own semantic properties, in addition to storing them as one thing. You can use #set to store a semantic property without displaying anything on the screen. Yaron Koren (talk) 18:43, 14 August 2012 (UTC)

In this case there would be 3 proporties? 1. The Value 2. The Unit 3. the Value and Unit combined,

could you show an example of how this would work in the syntax?

e.g. would this be right?

:

[[Weight::#set{{{value|}}} #set{{{unit|}}}]]

No, it would be: "[[Weight::{{{value|}}} {{{unit|}}}]]{{#set:Value={{{value|}}}}}{{#set:Unit={{{unit|}}}}}". Yaron Koren (talk) 19:30, 14 August 2012 (UTC)

Ok this is great, however this now forces me to create a mass of proporties which I had not planned for, most of which have the same data. is there now a way to duplicate or mirror pages. so that when I change the contents of the property length, the property width, height and depth also change? I can use subs however this only changes the contents on when the page is saved and not dynamicall when the source page is changed.

I don't really know what the ultimate goal of what you're trying to do is, but it might be worthwhile to use the Semantic Internal Objects extension to store the data, instead of regular SMW tags. Yaron Koren (talk) 15:11, 15 August 2012 (UTC)

Query form: Determine wether query has been run

I have a large query form in a collapsible table. This table is visible when the query form is initially opened. After the query is run the table is shown above the results and it should be collapsed. But I didn't find a way to determine whether the form is presented with or without the results of a previously performed query.

Is there any way to do that? Robertseetzen (talk) 10:25, 15 August 2012 (UTC)

Unfortunately, I don't think there's any way to do that at the moment. Yaron Koren (talk) 15:12, 15 August 2012 (UTC)

Values from property: Number format

I have a query form with some dropdowns that are filled with numeric values via "values from property". Some of the values have decimals and these are show with a decimal point - but, since the site uses a german locale, they should be presented with a ",". In result, the query delivers invalid results whenever a non-integer value is chosen. Is this a bug? Did I do anything wrong? Is there a way to fill the dropdown with correctly formated numbers? Robertseetzen (talk) 10:35, 15 August 2012 (UTC)

These are two unrelated problems, I think. For the first one - does a regular SMW query on those values show them with a ","? If yes, then it's an SF bug. The second one, if it's a bug, would be an SMW bug - I would send an email to the semediawiki-user mailing list about it, ideally with more information. Yaron Koren (talk) 15:14, 15 August 2012 (UTC)

Default forms

Is there a way to exclude a namespace (e.g. Template), from a default form set by a category?

I don't think so. If the template is only accidentally being added to the category, you should use <noinclude> and <includeonly> in the template. Yaron Koren (talk) 20:03, 15 August 2012 (UTC)

The category was being added from the template documentation, which uses the parent template as an example. I tried to work around it by checking the Namespace. That worked for the documentation subpage, but not the actual template itself (Which is itself used by the default form for that category).

I see - the template is being accidentally added to the category, but not in a way that's easy to get rid of. One possibility is to add another parameter to the template, called "display only" or something, and have the category tag get applied only if that parameter is not set; and then, when the template calls itself, to call it with that parameter. Yaron Koren (talk) 14:03, 17 August 2012 (UTC)

Semantic Forms Javascript scrolling problem with popup form

Hi, I am using the latest SMW+ 1.17 with the built-in SF 2.3.2. Using all the versions of Firefox and Chrome that I have tried, I get what appears to be a reproducible Javascript error with scrolling in a popup form. When I scroll in the popup form all the way to the bottom and click on a field or drop down, the form automatically returns/scrolls back all the way to the top, not allowing me to visualize what I am editing at the bottom of the form. Using Internet Explorer 8 or the latest Opera browser does not give this problem. I prefer to use FF or Chrome. Our wiki is almost perfect except for this one problem. Any help? Longphile (talk) 05:08, 16 August 2012 (UTC)

Hi - I don't know if I can help with this, since I know very little about SMW+. However, if you can find any error messages in the Javascript console, that might be helpful. Yaron Koren (talk) 15:19, 16 August 2012 (UTC)

Forms One-Step Process

Hello. I am attempting to take advantage of the One-Step Process for creating a page where the form defines the title of the page based on a formula. I have noticed that if you attempt to use this procedure to create a page that already exist, it will override the existing page. Is there any way around this? Is there perhaps a way to use parser functions to say "If this page already exists, then give an error"? --Zackmann08 (talk) 17:03, 18 August 2012 (UTC)

Unfortunately, no. Yaron Koren (talk) 03:44, 20 August 2012 (UTC)

Autogrow bug

There seems to be a bug in the autogrow function (SF 2.4.2). When specified, it causes the width of the text field to increase and to override the width value that's defined in the form. As a result, the entire form may 'step' beyond the width of the content menu. Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 08:55, 22 August 2012 (UTC)

The width isn't supposed to change with "autogrow" - it's supposed to be only the height. I've never seen that happen; it definitely sounds like a bug. Is this viewable on a public wiki? Yaron Koren (talk) 13:37, 22 August 2012 (UTC)

I'll see if I can reproduce it on scratchpad. For the record, it's not that the width grows as you type. There appears to be a default width for textareas once autogrow is selected. It's immune to a value of 1 for the "columns" parameter (although "rows" work just fine) as well as to widths set within the table itself. I’ve seen this behaviour on both a MW 1.17 and MW 1.18 installation (MW 1.7.1 + SF 2.4.2).

Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 09:14, 23 August 2012 (UTC)

See now http://scratchpad.referata.com/wiki/Form:Cav. Regards, Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 15:08, 26 August 2012 (UTC)

Hi - that's quite a form! I don't know if this is the issue, but the parameter is "cols", not "columns". Yaron Koren (talk) 18:43, 30 August 2012 (UTC)

Ouch, this must be one of those *head desk* moments. You're right, that's probably it! Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 22:12, 30 August 2012 (UTC)

Provide alternate link name for long urls in input forms

I'm looking for a way to avoid having long URLs break the layout of infoboxes. I saw in a previous talk page that a link name would work, however I'm not able to find out how to implement this. Do anyone have an example or would care to explain how I can let users specify an url and a link name in a form.

If you have fields like "URL" and "link name" in the form and template, then the template can hold something like "[{{{URL|}}} {{{link name|}}}]". Yaron Koren (talk) 18:44, 30 August 2012 (UTC)

Embed in field / holds template

I finally got to try the function for embedded templates (embed in field/holds template) and it wonderfully solves a usability issue that I've had for some time. This is very much appreciated! Nitpicky as I may be, I found two bugs or limitations, whichever way you want to look at it:

1. The form cannot handle numbered (unnamed) template parameters. It's not an insurmountable obstacle though if you can add a named parameter to the template that performs the same behaviour.
2. A little more seriously, the form does not allow for the same template to be embedded in the main template more than once. I have two different sections, i.e. fields in a template, where the same template is required. So after the main template, there's two sections for the template to be embedded (each beginning {{{for template|<templatename>|...|embed in field=<maintemplatename>[<fieldname>]}}}, but referring to different field names of the same template). Nothing appears to be wrong the first time round when you load and use the form, but when the page is saved, the new data are combined and occur twice, once in each field. To clarify this schematically, this is approximately what you get:

{{main-template
|field1={{embeddedtemplate|X=Dataforfield1
}}{{embeddedtemplate|X=Dataforfield2
}}
|field2={{embeddedtemplate|X=Dataforfield1
}}{{embeddedtemplate|X=Dataforfield2
}}
}}

When you load the form again, the new data are found under the first field only. Would this be fixable? Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 14:39, 26 August 2012 (UTC)

Number 2 is true, and no, I don't think it's fixable. The solution is just to give a different name to each set of templates. In this case, you can create a template called "embeddedtemplate2" that's just a wrapper for "embeddedtemplate". Yaron Koren (talk) 18:46, 30 August 2012 (UTC)

Thanks again! It might look clumsy but it works for me. Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 22:13, 30 August 2012 (UTC)

format of RunQuery results

Hi, I have created a query-form and I link to it via {{Special:RunQuery/<formname>}}. That works fine. But the tableheaders of the result-table are links to the relating property - I need plain text. So I have found a parameter (header=plain) to change this.
Now my question: How I need to modify my RunQuery-statement to include that parameter?

You can use #queryformlink - see here. Yaron Koren (talk) 18:48, 30 August 2012 (UTC)

Templates defining Categories

I have noticed that on the page listing all the templates (Special:Templates), there are a number of templates that define categories that don't actually exist. I determined that for the most part this happens when one template redirects to another. For example if I have "Template:Temp 1" redirecting to "Template:Temp 2", then on the Templates page, "Temp 1" will be listed as defining the category "Temp 2". Any idea why this is?

--Zackmann08 (talk) 16:10, 28 August 2012 (UTC)

That's a bug. :) Yaron Koren (talk) 18:48, 30 August 2012 (UTC)

refreshLinks.php fatal error related to SF_ParserFunctions.php

Hi,

I am running the latest 1.7.0 version of SMW+ (MW 1.17.0 and SMW 1.7.1). I have tried the SMW+ version of SF 2.2.1 and 2.3.2 as well as the latest community version 2.4.2 of SF. When I run runJobs.php and more specifically refreshLinks.php, a fatal php error is thrown when refreshLinks reaches page ids containing forms. Here's the error code:

PHP Fatal error: Call to a member function getTitle() on a non-object in C:\SMWPLUS\htdocs\mediawiki\extensions\SemanticForms\includes\SF_ParserFunctions.php on line 277

Line 277 is referenced when SF 2.4.2 is used. Line 347 is referenced when SF 2.3.2 is used.

I imagine this is a significant problem if I can't run refreshLinks on a routine basis. Any help?

Thanks,

Long

I don't know - my strong guess is that this has something to do with SMW+. I would try contacting its developers about this. Yaron Koren (talk) 21:28, 30 August 2012 (UTC)