Extension talk:Page Forms/Archive May to July 2013

Name Space

To make a former version of SF work with SMW prior to 1.8. I had the following namespaces defined in my localsettings:

$sfgNamespaceIndex = 150;
if (! defined('SF_NS_FORM'))
	define('SF_NS_FORM',       $sfgNamespaceIndex);
if (! defined('SF_NS_FORM_TALK'))
	define('SF_NS_FORM_TALK',  $sfgNamespaceIndex+1);

This seems to clash with the most recent versions of SF and SMW (which I'm running on MW 1.20.5), where in includes/SMW_setup.php the namespace is defined

$smwgNamespaceIndex = 100;
// 106 and 107 are occupied by the Semantic Forms, we define them here...
	define( 'SF_NS_FORM',            $smwgNamespaceIndex + 6 );
	define( 'SF_NS_FORM_TALK',       $smwgNamespaceIndex + 7 );
	define( 'SMW_NS_CONCEPT',        $smwgNamespaceIndex + 8 );
	define( 'SMW_NS_CONCEPT_TALK',   $smwgNamespaceIndex + 9 );

At the moment this results in the 'edit with form' tab not showing up.

What do I have to change to make it work? Wiki is http://de.wiki-products.org/ Thanks in Advance --Francishunger (talk) 11:55, 8 May 2013 (UTC)

Hi - I think this change happened in SMW well before version 1.8, but anyway - there might be an easier way to do it, but the most straightforward way I can think of is to call two database queries, if you have direct access to the database:

UPDATE page SET page_namespace=106 WHERE page_namespace=150;
UPDATE page SET page_namespace=107 WHERE page_namespace=151;

Hopefully that will fix the problem. Yaron Koren (talk) 12:19, 8 May 2013 (UTC)

Thanks, Yaron. It worked very well. Still some links to forms do not work but for the moment I'll try to figure it out myself. It was indeed from a legacy version. I think the problem just appeared with the change towards the new database storage concept. Thanks again. --Francishunger (talk) 08:57, 9 May 2013 (UTC)

Edit Conflict

Hello,

I have a client that is getting a red error message on a new wiki page when she goes to save her data and there is an edit conflict. All her data is lost so I was wondering if there is a solution for an edit conflict other than navigating away from the forms that were just filled out.

The tab that is the problem on the wiki page is a form driven by a form template.

Thanks,

Margaret Lee --144.15.255.227 16:47, 8 May 2013 (UTC)

By "new wiki page", do you mean that she went to create a page, and someone else created a page with that same name between the time she started editing and the time she hit "save"? Yaron Koren (talk) 19:44, 8 May 2013 (UTC)

On our production wiki (MW 1.17.0, SMW 1.7.1, SF 2.4.2, PHP 5.2.14), if I click "edit with form" on a page, then someone else clicks "edit with form" on the same page and saves, and then I save after them, I get a page with red letters saying "edit conflict". If I hit the back button (even in modern browsers that tend to remember form state) it will reload the form with the new data (i.e. the data the person saved while I was still working). So I lose my changes.

On our dev wiki (MW 1.20.4, SMW 1.8.0.4, SF 2.5.2, PHP 5.4.7) if I do the same test, when I click save (after the other person has saved) I am brought back to the form with my data still intact, but without any indication that there was an edit conflict. If I click save again it overwrites the previous persons data without any indication that I performed the overwrite.

--Jamesmontalvo3 (talk) 20:36, 8 May 2013 (UTC)

Okay. So... which one are you complaining about? :) Or is it both? Yaron Koren (talk) 21:01, 8 May 2013 (UTC)

Let's call it feedback :) I was confirming what Margaret saw with the red "edit conflict" page. That was a major issue since you would lose data, but clearly it's already been fixed. Perhaps somewhere in the documentation it should be noted, but that's the best you can do for an old version, right? With the new version you don't lose data, and the intermediate editor will see that their data has been overwritten after the second save is performed. To improve the way it's handled, when you click save and you're brought back to the same form, perhaps put a line that says "Someone has edited this page since you started working in the form. Right-click View History and open in a new tab to see changes made." or something like that. For a more thorough solution perhaps you could bring up a diff of all changes made since you started editing. Making SF work with Extension:AjaxShowEditors could help reduce conflicts, too. --Jamesmontalvo3 (talk) 21:38, 8 May 2013 (UTC)

Thank you James for going into specifics. You have explained it like you have had the same experience.

If two people are editing the same form page, the person who saves first wins. The second person who saves is directed to a page with the words in red "Edit Conflict". So, is the answer update to MediaWiki 1.20? I am not sure if the extensions I use can move up to MW 1.20.

Thanks again,

Margaret--Amblerllc (talk) 01:44, 9 May 2013 (UTC)

James - okay, thanks for the suggestions. Perhaps with forms, unlike with the regular edit page, there's no ideal solution for this problem; but I'm glad to hear that it's at least working better.

Margaret - I think it's the updated Semantic Forms version, rather than the updated MediaWiki, that's responsible for the difference in behavior. Yaron Koren (talk) 13:29, 9 May 2013 (UTC)

Asking about header tabs

Hi Yarin, how are you?

Im using seantic forms with header tabs extension. I have a very long form, which I divided in 2 tabs, and wanted to give my users a help text, which basically explains how to fill the form, some sort of a help. For this, I created another tab, with name "How to fill this form?".

I would like if possible remove the "save" and "summary" and "minor" button from the "How to fill this form?" tab, but keep it in the other 2. Is there some practical way to do that?

Thanks a lot in advance, and thanks for a marvelous extension.

Chei.

Hi - I don't think there's any way to do that, unfortunately; you can have inputs in one tab, or under all of them, but not anything else. And thanks! Yaron Koren (talk) 21:41, 13 May 2013 (UTC)

Multiple-instance templates om MW 1.19.6 and SMW 1.17 and SF 2.3.2

Hi,

I use Multiple-instance templates in combination with subojects in a form. The form is straighforward

{{{for template|Issue|label=Issues|add button text=Issue toevoegen|multiple}}}
<table class="formtable">
<tr>
   <th width="100">Naam issue</th><td width="50">{{{field|Issuenaam}}}</td>
</tr>
<tr>
   <th width="600" colspan="2">Tekst</th>
</tr>
<tr>
  <td width="600" colspan="2">{{{field|Issuetekst|input type=textarea}}}</td>
</tr>
</table>
{{{end template}}} 

As is the template

{{#subobject:Issue_{{PAGENAME}}_{{{Issuenaam}}} 
|Paginanaam={{PAGENAME}} 
|Issuenaam={{{Issuenaam|}}} 
|Issuetekst={{{Issuetekst|}}} 

This worked fine before we migrated to MW 1.19.6 (former version was 1.17.1). When I want to add an issue in this form, nothing happens. In the different browsers (Chrome, FF, IE10) I get the same error message.

mw.loader::execute> Exception thrown by ext.semanticforms.main:Object [object Object] has no method 'combobox' load.php:148

Does someone know the cause of this behaviour?

My guess is version incompatibility - you should upgrade SF to the latest version. Yaron Koren (talk) 12:33, 16 May 2013 (UTC)

It works fine now. But I get another problem instead. I use one and sometimes two different templates on one page. Both templates have their own form. If a form is used for one template, only the data of the template is saved which is part of the current form. The other data gets lost. --Tschijv (talk) 14:25, 28 May 2013 (UTC)

I think it relates to https://www.mediawiki.org/wiki/Extension_talk:Semantic_Forms#Partial_form_bug_in_SF_2.5.2 Because I also use a partial form. --Tschijv (talk) 14:40, 28 May 2013 (UTC)

Problem solved. I removed the partial form code.

{{{info|partial form|edit title=Cocreatie gegevens bewerken}}

Collaboration with "Proofread Page" extension

Is there any way to collaborate this extension with Proofread page extension? I need to get an image on the right side and semantic forms on the left. It is for the purpose of digitising a dictionary. Please help --Balasankarc (talk) 09:45, 16 May 2013 (UTC)

SemanticForms: Exclude special characters in #forminput

Hey,

I've got a question concerning #forminput and would be pleased, if you could help me:

I want to exclude special characters like "@" or "ä" from new form pages. Currently, I'm using #forminput (two-step-process) to enter a page name and create or edit the page. So, I avoid that an existing page will be overwrote. From the input form field ({{{field...}}}) I know that it is possible to define regular expressions inside them. This works fine. Is it possible to use regular expressions in combination with #forminput as well? Or can you recommend other solutions to exclude special characters inside #forminput?

Thank you very much in advance!

BR AArnold

I don't think you can do that in SF, unfortunately. However, you may be able to accomplish the same thing in a different way by modifying $wgLegalTitleChars. Yaron Koren (talk) 18:09, 21 May 2013 (UTC)

This seems to solve my problem. Thank you very much Yaron!

problem passing a url string to template

I recently upgraded from MW 1.16 to 1.20 with associated php and extension upgrades. Not sure what the previous version of SMW and forms were but now they are latest.

There is a form which worked fine on the previous setup but now has a problem. It involves assigning a default value to a field in the form:

{{{field|WpURL|default=http://en.wikipedia.org/wiki/{{PAGENAMEE}}|hidden}}}

I've been tweeking spaces, pipes and parameter order to try to fix so the precise string that previously worked may have been slightly different. However, when the field value is passed to its associated template, it is converted into a full html style embedded url link in the form:

[<a rel="nofollow" class="external free" href="http://en.wikipedia.org/wiki/Test1">http://en.wikipedia.org/wiki/Test1</a> Test1]

where 'test1' is the PAGENAME.

The behaviour can be seen here.

The associated template is here.

Any help/suggestions etc much appreciated. --Sabretache (talk) 19:50, 21 May 2013 (UTC)

Clarification: The form has other fields for manual completion/editing with standard url strings. These are passed to the template without conversion to the full html <a></a> format. The issue therefore seems to be connected with the 'default' parameter. --Sabretache (talk) 06:47, 22 May 2013 (UTC)

Yes, I remember looking into this issue a month or two ago. Unfortunately, I don't think there's any way around it - URLs in the "default" parameter just no longer work. Yaron Koren (talk) 13:28, 22 May 2013 (UTC)

It is clear that Mediawiki is simply converting a url string to an html link with the string as its name. This did not happen with my earlier installation. Neither does it happen when passing non-default url fields to the template. What is required is the ability to inhibit this conversion. I've tried various #NOWIKI and nowiki tags, including building the string from another template (that produces a very odd result which can be seen here), but all to no avail. Any chance this will be addressed in the near future? or is my only option to revert to an earlier release? --Sabretache (talk) 07:28, 23 May 2013 (UTC)

Actually, I think the simplest solution is to change line 828 of /includes/SF_FormPrinter.php from:

$default_value = $wgParser->recursiveTagParse( $sub_components[1] );

to:

$default_value = $sub_components[1];

As to whether this will be addressed, I don't know, but I hope so. Yaron Koren (talk) 12:08, 23 May 2013 (UTC)

Thanks Yaron. That works a treat. Your technical knowledge and willingness to help is very much appreciated. --Sabretache (talk) 19:44, 23 May 2013 (UTC)

Partial form bug in SF 2.5.2

Hi, we recently upgraded to SF 2.5.2 version and noticed that when saving partial forms, the entire page would get overwritten with just the partial form content (in our case this is only small part of the page). We did not have this problem with the previous version of SF using the same partial forms. We are use it as edit of page subtopic. Betwean main page form and subform edit areas are big free text area and after subform edit area are free text area. --Vpovilaitis (talk) 05:08, 22 May 2013 (UTC)

Partial forms in SF are barely maintained at this point, and they may be getting removed entirely in the not-too-far future. I would recommend switching to another solution, like "pseudo-partial" forms, that are standard forms, but only contain the subset of fields that you want to edit. Yaron Koren (talk) 13:31, 22 May 2013 (UTC)

But how I can change to the "pseudo-partial" forms solution, if my templates witch I wont edit is on free text and not on the begining of the article. This templates are not in the other template field. --Vpovilaitis (talk) 05:21, 24 May 2013 (UTC)

Can you explain why you have templates embedded within your free text? Are these SMW-based templates? Understanding that may help me to offer an alternate solution. Yaron Koren (talk) 16:11, 24 May 2013 (UTC)

In my site are several templates of articles. One type of article example is:

{{Auto taxobox
|ru=Синец
|fr=Abramis ballerus
|šalys=Lenkija, Rumunija, Rusija, Slovakija, Suomija, Švedija, Vengrija, Vokietija
|parent=Ballerus
|la=Ballerus ballerus
|autoriai=Linnaeus
|metai=1758
|de=Zope (Fisch)
|wormsid=279859
|alias=Ballerus ballerus
|en=Ballerus ballerus
|vaizdas=Abramis ballerus.jpg
|antraštė=''Abramis ballerus''
|išnykęs=ne
|type=rūšis
|karalystė=Animalia
}}
{{TOCright
|clear=none
}}
{{GrefTit|Ballerus ballerus}}, [[Chordiniai|chordinių]] (''[[Chordata]]'') tipo  (''[[Actinopterygii]]'') klasės (''[[Cypriniformes]]'') būrio (''[[Cyprinidae]]'') šeimos (''[[Ballerus]]'') genties rūšis.
{{Kalbos|Ballerus ballerus}}
    Free text
== Išvaizda ==
{{Gmaxilgis|Ballerus ballerus}}
    Free text
== Biologija ==
    Free text
== Mityba ==
    Free text
== Paplitimas ==
    Free text
{{Gpaplitimas|Ballerus ballerus}}
    Free text   
== Literatūra ==
    Free text
== Nuorodos ==
{{Grefs|Ballerus ballerus}}
    Free text
== Sinonimai ==
{{Sins|Ballerus ballerus}}
{{ESinonimas
|Lotyniškai=Abramis ballerus
|Pavadinimo autorius=Linnaeus
|Pavadinimo metai=1758
|WoRMS=236121
|alt=
}}
{{ESinonimas
|Lotyniškai=Cyprinus ballerus
|Pavadinimo autorius=Linnaeus
|Pavadinimo metai=1758
|WoRMS=236122
|alt=
}}
{{ESinonimas
|Lotyniškai=Cyprinus farenus
|Pavadinimo autorius=Linnaeus
|Pavadinimo metai=1758
|WoRMS=307641
|alt=
}}

== Šaltiniai ==
{{Reflist}}

In this example are is using one master form for editing complex "Auto taxobox" template. Partial form is are using for editing templates "Sins" and "ESinonimas". Template "Sins" generate special link for call this Partial form. --Vpovilaitis (talk) 05:41, 28 May 2013 (UTC)

That is a rather complex page structure. Depending on how consistent this structure is across all pages that use the "Auto taxobox" template, the planned addition of the {{{section}}} may help somewhat, in allowing an entire page structure like this to be edited by a single form. For now, though, you may be better off reverting to your previous version of SF. Yaron Koren (talk) 15:30, 28 May 2013 (UTC)

Thanks. Revert to the previous version of SF I don't can. After upgrade MW inposible was create new Semantic forms, edit it and don't work several forms. Our site are very big ad we are using many diferens SF. There are bad idea, that is not suported "Up" compobility. I think that will be needed change master form, that with this form may be edit full article text and after that change all 400000 articles, that was used it. This is very huge work, and after that vill be needed other participants teach in new how use this form. --Vpovilaitis (talk) 05:40, 30 May 2013 (UTC)

One of the drawbacks of the "pseudo-partial" forms approach is that when the form is used for the first time on a page the user gets the message Warning: This page already exists, but it does not use this form. Is there a solution to avoid this warning. The next time the form is invoked there is no message. Is you delete the data on the page managed by this form and you want to enter new data again, the message reappears. --Toine Schijvenaars (talk) 13:52, 28 June 2013 (UTC)

I just checked in a patch by Sebastian Richter that is supposed to solve the current issues with partial forms. If any of you are still reading this - please try it out, and let me know if it solves your problems. Yaron Koren (talk) 18:30, 3 July 2013 (UTC)

I tried the new version. I still get the same message. Maybe it is related tot the fact that I use this form on a seperate Tab I created by using this statement in the MediaWiki:Common.js

if ( wgCanonicalNamespace == "" || wgCanonicalNamespace == "File"  ) {
addPortletLink( 'p-namespaces', wgArticlePath.replace( '$1', 'Speciaal:FormEdit/Cocreatie/' + encodeURIComponent(wgPageName) ), 'Publicatie');}

I created two of these tabs with each one contaning a form on the same page. --Toine Schijvenaars (talk) 09:16, 11 July 2013 (UTC)

Yaron, the 2.5.3 version fixed the problem with partial forms for us. It would be a shame if the partial forms facility was removed from Semantic Forms as you indicated above. We use it extensively on http://riverwiki.restorerivers.eu. L Andy (talk) 10:40, 11 July 2013 (UTC)

Toni - who knows, that might be it... I haven't seen that problem anywhere else.

L Andy - okay, that's good to know. If/when I want to get rid of the partial forms feature, I'll definitely have a discussion about it first; evidently quite a few people like it more than I do. :) Can you point to a page on that site where it's used, by the way? Yaron Koren (talk) 12:51, 11 July 2013 (UTC)

Here's an example Yaron: http://riverwiki.restorerivers.eu/wiki/index.php?title=Case_study%3ARother_meander_reconnection . Our river case studies are very long so we split them up into sections, and in the template for each section we put an "Edit ..." link at the top right, which does a Special:FormEdit link to the form to edit that particular section.

Issue with "show on select"

Hi Yaron,
I want to use "show on select" to change the caption and the placeholder of a certain field. I tried something like <div id="foo1">|placeholder=foo1</div> but since this didn't work I just duplicated the field definition - like so:

<div id="foo1">
{|
|-
! Foo1:
| {{{field|Anker|placeholder=foo1}}}
|}
</div>

<div id="foo2">
{|
|-
! Foo2:
| {{{field|Anker|placeholder=foo2}}}
|}
</div>

This works fine when displayed in the form, but unfortunately it generates two times the field "Anker" in my page. This is somehow logical since the id only makes the div invisible, the input is still there (two times in my case).
How can I solve this issue?
Thank you so much for your support!
Stefahn (talk) 10:43, 22 May 2013 (UTC)

Unfortunately, "show on select" can't be used for that purpose, of having alternate tags for the same field. I don't think there's a good solution to this problem - other than making that placeholder text be just standard text, outside of the form input. Yaron Koren (talk) 13:39, 22 May 2013 (UTC)

Use hook to show help box

Hi Yaron,
for user guidance I show a help box next to the edit window (see an example here). For showing the box I used the hook EditPage::showEditForm:fields - this works fine in usual editing mode. Now with SF's formedit the help box doesn't appear. Can I use a different hook and if yes which one? Thank you so much! Stefahn (talk) 21:47, 28 May 2013 (UTC)

I don't know - if you look through the SF code, you can find a lot of hooks, most of them called during the printing of a form - look for "wfRunHooks()". One or more of them should work, I hope. Yaron Koren (talk) 01:23, 29 May 2013 (UTC)

#formlink broke with subtemplates after updating Semantic to 1.8

The following code worked just fine until I updated to the new version of semantic from 1.7:
{{#formlink:Announcement/Announcements/{{CURRENTTIMESTAMP}}|Go to the form|button|super_page=Announcements}}
Now it just redirects to the wiki's main page instead of the form for creating the specified page. The following code works just fine but doesn't do want I want:
{{#formlink:Announcement|...}}
Any ideas on how to fix this?

#formlink now requires names for all its parameters - my guess is that that's the issue. Yaron Koren (talk) 01:25, 29 May 2013 (UTC)

I tried switching it to

{{#formlink:form=Announcement/Announcements/{{CURRENTTIMESTAMP}}|link text=Go to the form|link type=button}}, but it still isn't working. Unixninja92 18:02, 29 May 2013 (UTC)

You need a "target=" value in there. Yaron Koren (talk) 18:50, 29 May 2013 (UTC)

That was it. Thanks for the help. Unixninja92 6:24, 30 May 2013 (UTC)

Custom buttons with WikiEditor in Forms

Same problem as "Custom buttons with WikiEditor in Forms". But I don't see generated textarea id's:

<span class="inputSpan">
<textarea tabindex="45" name="Auto taxobox[sinonimai]" id="input_53" class="wikieditor createboxInput autoGrow" rows="5" cols="90" style="width: auto"></textarea>
</span>

How I can add custom buttons to the WikiEditor, witch is are used in SF. --Vpovilaitis (talk) 06:05, 30 May 2013 (UTC)

Empty Forms after CAPTCHA

Hello, when I enter content to my SF and hit save everythings works fine and all data appears on my template-created pages. But if there is a link within these fields (in my case an e-mail-address), there appears a new page with a CAPTCHA for spam-protection after clicking "save". Unfortunately all fields are saved empty after saving again with correctly solved CAPTCHA question. Is it a bug? Does anyone know this issue? Is there a solution/workaround? I am running MediaWiki 1.19.7, PHP 5.2.17 (cgi-fcgi), MySQL 5.1.58, SF 2.5.2 -- 141.35.213.221 07:04, 6 June 2013 (UTC)

Any ideas anyone?? I discovered, that it works, when enter data without a link (and without captcha) but change the entry afterwards by adding a mailing-Address. -- 141.35.213.221 07:26, 12 June 2013 (UTC)

Sorry I didn't respond before. There are some problems with the workflow related to saving in SF 2.5.2, as a result of changes made in order to remove the now-obsolete Sajax library. Stephan Gambke is working on fixing these, and hopefully everything will be working again soon. Yaron Koren (talk) 13:06, 12 June 2013 (UTC)

Issues with multiple-instance templates

Hi Yaron,
I found two issues with multiple-instance templates:

• When using subobjects SF doesn't seem to recognize the property automatically (there is no autocompletion). I described a workaround here. Is this a bug or expected behavior?
• Within the multiple form the text entered in {{#info: text}} is not shown when hovering above the question mark (which is shown).

Thanks, Stefan Stefahn (talk) 00:11, 12 June 2013 (UTC)

The first one sounds like a bug, yes, although it happens in a variety of circumstances - my recommendation whenever SF can't figure out what the relevant property is is to use "property=" (not that different from your "values from property=" suggestion). The second one is a known bug, due to some Javascript problem. Yaron Koren (talk) 01:49, 12 June 2013 (UTC)

Found two more bugs

Hi Yaron, hope I'm not bugging you ;) I found two more issues with SF (2.5.2) :

• Added wikitext in the system message Mediawiki:Minoredit is not parsed when using "edit with form" (it seems all special characters are escaped). If one uses "edit source" the wikitext is parsed correctly.
• If I enter text into the summary field and then hit "show preview" the summary text vanishes.

Thanks for your feedback on this. Stefahn (talk) 09:06, 21 June 2013 (UTC)

Hi - thanks for the bug reports! The first one was fixed by Stephan in the latest Git code, and the fix will go into the next version. For the second one: I assume it's happening because your form definition does not contain a '<div id="wikiPreview">' tag. If that's the case, and if you add one in, the problem should hopefully go away. It's still a bug, though, and it will hopefully be fixed at some point. Yaron Koren (talk) 17:02, 26 June 2013 (UTC)

Thanks for your feedback. First point is now fixed with version 2.5.3. Second point: It's exactly like you say - I added the wikiPreview container and it works fine. Thanks :) Stefahn (talk) 10:49, 15 July 2013 (UTC)

Enclosing the "Additional query" in <div> block

I'm trying to make the "additional query" form line up the the result of the previous query. To do this I added a new <div> tag as the last line in the template displaying the query result. However, it looks like the parser closes all open tags before starting the "additional query" form.

I.e. My template ends with this line:

<div style="width:1025px; margin-left: auto; margin-right: auto;">

However, when looking at the resulting code I see the following:

<div style="width:1025px; margin-left: auto; margin-right: auto;">
</div>

<h2 style="clear: both">Additional query</h2>
	<form id="sfForm" name="createbox" action="/wiki/index.php/Special:RunQuery/IIA_query" method="post" class="createbox">
<input type="hidden" value="true" name="query" /> <div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;">

Is there any way to prevent the <div> from being closed automatically? Is a feature or a bug?

MathiasLidal (talk) 10:22, 26 June 2013 (UTC)

Whether it's a feature or a bug is a matter of opinion, I suppose. What do you mean by "line up the result"? Yaron Koren (talk) 17:04, 26 June 2013 (UTC)

I'm enclosing the query result in a <div> which is narrower than the wiki page itself. I would like the "additional query" form to have the same width, but the div is automatically closed and the form takes up the entire width of the page. Not sure if that made sense, I can probably try to set up an example (the actual page is on a company internal wiki) MathiasLidal (talk) 20:13, 26 June 2013 (UTC)

Ah, I see. Maybe it's possible to do that via CSS (placed somewhere like MediaWiki:Common.css) instead, rather than using divs? I'm not sure if it's possible, but I'd say it's worth looking into. Yaron Koren (talk)

Not sure if that will work, I'm afraid, doesn't look like the form has any css class that it is possible to utilize (and in any case, what makes things more difficult is that I would like the layout do be different in the "additional query" and the initial query form. I've been looking into the code and seems like the problem is that the result template is processed by a call to Parser->parse() which does html sanitizing (including closing open tags). Would it be possible to parse the entire page instead (both template and additional query form)?

I don't think so... the only solution I can think of is to add HTML "class" attributes in the relevant places, so that the display can be modified. Yaron Koren (talk) 18:33, 3 July 2013 (UTC)

Problem: Creating Page with Inherited Page Name via #formlink - Fatal error: Call to a member function exists() on a non-object

What I am trying to accomplish here is: generating a page that has a button which generates a page with inherited qualities that I can then query on the same page.

[{{#formlink:form=Debate|link text = edit |query string = Debate[Thing]={{PAGENAME}} }}]

And this is from the template.

{{{info|page name=Debate[Thing]<unique number;start=1>}}}
{| class="formtable"
! Argument:| {{{field|Argument|mandatory}}}
! Thing:
| {{{field|Thing|mandatory|}}}
|}

This is the error I get.

Fatal error: Call to a member function exists() on a non-object in 
/home/content/50/8262350/html/openthinklab/community/extensions/
SemanticForms/includes/SF_AutoeditAPI.php on line 674

It imputes the page name into the form no problem, but I would like to add a unique identifier or something similar that would allow me to then find and query it right away on the parent page. Anyone able to help? McDoku (talk) 11:09, 27 June 2013 (UTC)

Could you try if tis works in the last development version, please. I think I fixed this already. --F.trott (talk) 11:37, 27 June 2013 (UTC)

I just updated the extension to the lastest version from https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FSemanticForms. Same error occured.McDoku (talk) 12:07, 27 June 2013 (UTC)

Does the error occur on the same line as before? Because line 674 contains comment: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FSemanticForms/496eacae4e366ea0eaf91f02f6951ea579b1f52d/includes%2FSF_AutoeditAPI.php#L674 --F.trott (talk) 12:42, 27 June 2013 (UTC)

Apologies, my bad it is 679 now McDoku (talk) 13:23, 27 June 2013 (UTC)

Hello McDoku. We do the same thing on our Wiki. You just need to get the syntax right like this:

{{{info|page name=<Debate[Thing]><unique number;start=1>}}}

When I use your syntax I get the same Fatal error. Regards --Jongfeli (talk) 13:38, 27 June 2013 (UTC)

Perfect! Thank you very much! Sorry for the trouble McDoku (talk) 13:44, 27 June 2013 (UTC)

Ah, yes. Good that that's worked out. Still, SF should not just bail out, even if the page name is invalid. I'll fix it. Thanks for spotting this. --F.trott (talk) 14:12, 27 June 2013 (UTC)

Working with WikiDB extention

I'm using Mediawiki v1.16. I am wondering if there is a way to integrate between Semantic forms and the WikiDB extension.

I'll explain by simple example: I created a new semantic form called "Form:Books" which contain 2 fields: book number and book name. In addition, I created a related template called "Template:Books" and contain a simple <repeat> tag that based on "Books" table (WikiDB table). Can I pass the form field and use it as a parameter for the repeat tag? In other words, I want to have a form that is based on a simple tables I defined under this WikiDB.

(booknum is the field name on "Books" table. booknumber is the field name on "Books" form):

<repeat table="Books" criteria="booknum={{{booknumber}}}" />

(I don't know if the above problem is related to wikiDB or SemanticForms. I'm trying to attack this on "both sides") TNX a lot.

I don't know the answer to this (and I don't know the WikiDB syntax), but my guess is no. Yaron Koren (talk) 18:18, 27 June 2013 (UTC)

Dynamically loaded subcategories can't be selected

I'm trying to use the categories input type. As I have a rather large category hierarchy I only want to show the top-level categories initially (using the depth parameter).

However, when I expand one of the categories, the sub-categories can't be selected. I assume this is because the regex processing of the html code done in SF_CategoriesInput.php is only done for the initial load. Would it be possible to hook into the ajax function and process the new subtree before it is shown? An alternative solution is to implement a new paramenter, displaydepth, which allows you to load all categories initially, but only show a part of it (looking into this now). Any ideas on what would be the best solution? MathiasLidal (talk) 20:10, 3 July 2013 (UTC)

Unfortunately, I don't think there's a good solution at the moment - the way the "category" and "categories" inputs are structured (derived heavily from the CategoryTree extension, and basically a hack), there's no way to have categories that are hidden but can then be expanded. It could be that the only solution is to do a rewrite of those input types - which is probably a good idea anyway. Yaron Koren (talk) 18:37, 3 July 2013 (UTC)

Ok, thanks for the reply. I might look into rewriting this sometime during the summer then. MathiasLidal (talk) 20:10, 3 July 2013 (UTC)

Some extra documentation

I started learning how to use SF and wrote down what I (think) that I learned.

• http://edutechwiki.unige.ch/en/Semantic_Forms

There is nothing new, but sometimes it helps to read a second text. The reason I started my own doc, is that learn when I write.

Maybe useful to be copied here (I changed the copyright to allow a simple cut/paste).

• http://edutechwiki.unige.ch/en/Semantic_Forms#Form_input_types
• http://edutechwiki.unige.ch/en/Semantic_Form_demo_page

For now, everything is in rough draft state and I am an absolute beginner. I will work on my pages as I learn more. Today I am starting a real project :)

Finally, I had trouble getting the category inputs to work, but now they do: This is my config file for MW 1.20.6:

# Extension: Categorytree
$wgUseAjax = true;
require_once("{$IP}/extensions/CategoryTree/CategoryTree.php");
$wgCategoryTreeSidebarRoot = "Contents";
$wgCategoryTreeForceHeaders = true;
$wgCategoryTreeSidebarOptions['mode']=CT_MODE_CATEGORIES;
$wgCategoryTreeDynamicTag = false;
$wgCategoryTreeDisableCache = false;
$wgCategoryTreeMaxDepth = array(CT_MODE_PAGES => 2, CT_MODE_ALL => 2, CT_MODE_CATEGORIES => 3);

The problem was a configuration issue. Basically, if it works in the sidebar, it should work with SF - Daniel K. Schneider (talk) 12:18, 4 July 2013 (UTC)

Alright. In general, I think it's a bad idea to have more than one set of documentation for a piece of software, given that potential users can find the non-official ones with a web search, unless there's (a) some compelling difference between the different sets, or (b) some guarantee that the non-official documentation will be kept up to date. I also find the statement amusing that Wikidata/Wikibase is easier for end users to use than SF, but that's strictly a matter of opinion. Yaron Koren (talk) 22:39, 5 July 2013 (UTC)

In general, I agree. In our case there are three reasons (a) It's nice to have a ready text made oneself that one then can use to present in a class or a meeting. (b) I really don't feel confident about my understanding of SF and I do need to write things when I learn. It helps me to think. Doing that here would not be appropriate because you'd get really bad stuff at start. (c) I would NOT call our page a documentation of SF, it's more a kind of introduction with simplications, stuff missing etc. I clarified that in the beginning. Also, I have no clue about the ease of Wikidata/base (removed that bit). Finally, if we come up with something that we consider both safe and useful and missing here - e.g. a coworker is working on a diagram explaining SF - I'll copy it here:) - Daniel K. Schneider (talk) 10:00, 8 July 2013 (UTC)

Is this figure useful somewhere ? Its a simplification and again we don't feel so sure about semantic forms. Anyhow, its SVG can be edited with SVG-Edit. (talk) 17:29, 8 July 2013 (UTC)

Diagram of a simple Semantic Form

- Daniel K. Schneider

Well, I certainly wouldn't begrudge anyone trying to learn how to use the software. Still, I think it would be good to have a disclaimer at the very top of the page, saying "This is not official documentation" or some such. As to that diagram - I would probably have a few things different if I were creating it, but maybe that goes without saying. Is it helpful to people trying to learn SF? I couldn't say. Yaron Koren (talk) 03:02, 9 July 2013 (UTC)

Done the disclaimer. Indeed for the diagram I would need a comment from someone who just started. Since I never really looked at templates and parser functions before, I found that it took some time and will to create a somewhat usable model of SF in my head. The diagram should remain simple in order to be useful to beginners (e.g. teachers) but it shouldn't be wrong. Maybe I'll go for a more complex version sometimes in the future. - Daniel K. Schneider (talk) 08:55, 9 July 2013 (UTC)

link type post button adds unwanted line break

I like the idea of useing link type=post button because it has to transfer a lot of data and one field could have line breaks, etc, but it adds an unwanted line break after the formlink call. Here is an example, http://cns.dyndns.info/wiki/index.php/News and the template that has the formlink call is here http://cns.dyndns.info/wiki/index.php/Template:Title_Link_Date_Page_Description_Color_Type_Tags

thanks

Updated I really dont like looking at the extra line breaks so I took it out for now. but take my work for it if I change the link type to link type=post button it adds an extra line feed and doesnt look right

Add JavaScript calls to input fields

Hi, How can I add a call to Javascript function from to a simple SemanticForm field. For example

I want to "translate" this to a semantic form field: <input type="radio" id="test" name="test" value="Date" onClick="doSomething('divDate')">

You can't do that directly, but you can add such functionality in to MediaWiki:Common.js, using the jQuery function click(), if that makes sense. Yaron Koren (talk) 14:52, 9 July 2013 (UTC)

[RESOLVED] All properties identified in template have their input type reset to page

I've been working with SMW and SF for a week and I'm still trying to wrap my head around it.

Form:Development Comments (this error has happened with my other three forms that I've tried creating).

'''Support Comments:''' {{{field|Support Comments|input type=textarea|property=Has support comments|rows=10|autogrow}}}

Template:Development Comments
==Support Comments==
[[Has support comments::{{{Support Comments|}}}]]

This creates a page with all of the text in the field redlinked to a page in the namespace.

When I use the "Special:CreateForm" after putting in the [[Has support comments::{{{Support Comments|}}}]] even if the property page has been set up. If I remove the property info and just include {{{Support Comments}}} in my template the CreateForm, form and created page work fine. On another Property where I had defined accepted values I couldn't get them to work until I defined them directly in the Form page, filling in the "Property Name" doesn't seem to work.

When trying to use the CreateClass with the "This template can be included multiple times on the page" I get this error: Fatal error: Call to a member function getNamespace() on a non-object in /home/cowiki/public_html/includes/job/JobQueueDB.php on line 662

I have a private wiki, with some established namespaces already.

Local Settings:

$smwgNamespaceIndex = 300;
require_once( "$IP/extensions/SemanticBundle/SemanticBundleSettings.php" );
require_once( "$IP/extensions/SemanticBundle/SemanticBundle.php" );
$smwgNamespacesWithSemanticLinks[NS_SUPPORT] = true;

Version info:

MediaWiki – 1.21

PHP – 5.3.22 apache2handler

MySQL – 5.5.30-log

Semantic Bundle – 1.8.0.4

Semantic Forms – 2.5.2

Semantic MediaWiki - 1.8.05

When I tried upgrading to SF 2.5.3 suddenly the [[Has default form::Development]] in the category page no longer worked, and the "Browse Properties" link in the sidebar said that "This page has no properties."

Can I/should I be changing the namespaces of my custom namespaces so that SMW works in its default spaces?

Thanks, Jennifer – http://wiki.countingopinions.com

I went to bed and then re-installed SF. I still had the property page type error, but found that going to each of my properties, hitting edit, and save (without making changes) was enough to reset the type and eliminate all of the redlinks on the created pages.

Values from namespace doesn't work always

Hi Yaron, I use values from namespace=User for a certain field. This works fine when I do something like [[Foo::{{{field name|}}}]] in my template. But if I use [[Foo::User:{{{field name|}}}]] in my template the autocompletion in the form no longer works. Is this a bug or am I doing something wrong? Thanks. Stefahn (talk) 08:23, 17 July 2013 (UTC)

You probably just need to add "|property=Foo" to the field tag. Yaron Koren (talk) 19:49, 17 July 2013 (UTC)

Thanks a lot! This did the trick :) Stefahn (talk) 19:06, 21 July 2013 (UTC)

Multiple instance template values and 'page name' in the 'info'-Tag

Hey Yaron!

Is it possible to use a value from an multiple instance template in the 'info'-tag of the second form? I want to combine the field 'Person' of the template 'Authorship' and the field 'Title' of the template 'Article' in the page name. Do you have any idea?

An extract of the form-definition:

{{{for template|Authorship|multiple}}}
{| class="formtable"
! Author:
| {{{field|Person|mandatory|input type=text with autocomplete|values from category=Person|size=60}}}
|}
{{{end template}}}

{{{for template|Article}}}
{{{info|page name=<Article[Title]><Authorship[Person]>}}}
{| class="formtable"
! Titel:
| {{{field|Title|input type=textarea|rows=2|cols=75}}}
|}
{{{end template}}}

I also tried:

{{{info|page name=<Article[Title]><Authorship[1][Person]>}}}

and

{{{info|page name=<Article[Title]><Authorship[Person][1]>}}}

Thank you very much for an answer, Michael

My guess is no - if neither of the last two works, then it probably can't be done, unfortunately. The "info" tag is usually placed at the top of the form definition, by the way, though it will work anywhere. Yaron Koren (talk) 12:41, 18 July 2013 (UTC)

Dealing with external URLs in forms and templates

Hi, this must be a FAQ and I feel a bit daft .....

Starting with a form that asks the user to enter: 1) An external Link location (property of type URL) 2) A link text (propert of type string)

The template call looks like this:

{{Semantic Forms URL demo
|f_URL_link_text=Semantic MediaWiki
|f_URL=http://www.mediawiki.org/wiki/Extension:Semantic_Forms
}}

The template must define properties and then should display the URL using the link text. I don't know if my solution is correct or if I miss something:

[[Has URL::{{{f_URL|}}}| {{{f_URL_link_text|}}}]] <span style="display:none">[[Has URL link text::{{{f_URL_link_text|}}}]] </span>

The live example (including more variations) is here: http://edutechwiki.unige.ch/en/Semantic_Forms_URL_demo_test

- thanx and greetings ! Daniel K. Schneider (talk) 15:42, 18 July 2013 (UTC)

Hi - the best way to set semantic properties "silently" (without displaying anything to the screen) is by using #set - I would doing recommend that for both values, and then display to the link by just calling "[[{{{f_URL|}}}|{{{f_URL_link_text|}}}]]". Yaron Koren (talk) 17:20, 18 July 2013 (UTC)

Thanx a lot ! I missed that and I updated the example. (Daniel K. Schneider (talk) 19:36, 18 July 2013 (UTC)) So here is the complete example design pattern:

 {{#set:Has URL={{{f_URL|}}} }} {{#set:Has URL link text={{{f_URL_link_text|}}} }} [{{{f_URL}}} {{{f_URL_link_text}}}]

Oh yeah, oops - I gave you the wrong syntax, but you figured it out. Yaron Koren (talk) 20:19, 18 July 2013 (UTC)

Special:FormEdit/Category1/Item1 You do not have permission to edit this page

You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.

in my LocalSettings.php i have the following rule to Disable anonymous editing:
$wgGroupPermissions['*']['edit'] = false;

i don't want anonymous users to modify my pages, but i want them to be able to submit new articles for review. i have the Extension 'FlaggedRevs'.

how can i make "only " that form usable by unlogged users?

You can't have different permissions for editing and for creation. What you could do, though, is create a new namespace, maybe called "Draft", that anyone can create and edit pages in, while keeping other namespaces restricted. Or, conversely, you could just make use of FlaggedRevs... it's supposed to take the fear out of enabling unlimited editing. Yaron Koren (talk) 05:02, 22 July 2013 (UTC)

Deal with existing pages

Hi Yaron,
I'm facing the same problem like shown here and here - I want my users to be able to check whether a page already exists and at the same time edit / create the page.
I know I can use #forminput with autocomplete and I'm using this successfully on some forms.
But here comes my special case: The user should be able to input an URL and see if a page (link) for this URL was already entered. The problem is I can't save an URL as a page title (special chars), so it's saved in a property.
My question: Can I use #forminput to autocomplete on a certain property (the one storing the URL)?
Thank you so much! Stefahn (talk) 17:07, 24 July 2013 (UTC)

Hi - are you sure that you can't save a URL as a page title? (Not that I would recommend it, but I'm surprised that doesn't work.) Anyway, other than that, I can't think of any way to check whether a URL has already been entered. Yaron Koren (talk) 18:53, 24 July 2013 (UTC)

You're right. I can save the URL as the page title. But my problem was that I couldn't get it working to build links with a different anchor text like [Pagetitle_equals_URL Property_Anchor] (since Pagetitle is an URL and was always parsed directly as a link, without anchor).
So it's not possible to autocomplete on a certain property in #forminput, is it? Stefahn (talk) 11:20, 25 July 2013 (UTC)

No. Yaron Koren (talk) 12:14, 25 July 2013 (UTC)

WYSIWYG Ping

I tried out the latest WYSIWYG extension with MW 1.21.1, and it installs easily, looks great, and imports Word better than anything I've found so far. But of course it doesn't work with Semantic Forms.

I also studied the latest VisualEditor extension. It's ok, though not as polished as WYSIWYG, and it doesn't seem like it will be. I'm not sure why this is being re-invented, perhaps it's political, perhaps there's a technology advantage.

What are the current thoughts about supporting one or more of them in the free text area of a Semantic Form? Would the work needed be minimal, requiring only time, or significant?

I know of no priority to get this done, but I'm definitely an interested party, the lack of some kind of visual editor is keeping me in SF 2.4. I've played enough with SF 2.5.2 to know that my users will appreciate the new features and speed it brings.

Regards,
Salquint (talk) 19:03, 25 July 2013 (UTC)

Oh - I'm surprised to hear that WYSIWYG works again. Nevertheless, I don't have any real interest in supporting WYSIWYG/CKeditor/etc. - it was always a bit of a hack, and it messes up wikitext that's in any way complex. I definitely want SF to support VisualEditor, though - for all its faults (and it's not really ready for deployment yet, in my opinion), it's built around MediaWiki, and will be the much more error-free solution. Yaron Koren (talk) 02:26, 26 July 2013 (UTC)

Thanks for the update. I didn't know it was hack, it certainly is a nice one, but in any case it's good to know where you stand on it.

Salquint (talk) 02:56, 26 July 2013 (UTC)

example page in Semantic_Forms/Creating_query_forms#Preloading_data_in_the_query return an error

Hello, When we click on this link :

http://discoursedb.org/wiki/Special:RunQuery/Item_query?ItemQuerier%5Bauthor%5D=A&ItemQuerier%5Bsource%5D=New&wpRunQuery=true

we get the following error Message :

Fatal error: Call to a member function replace() on a non-object in /home/ngrandy/public_html/w/includes/parser/Parser.php on line 4991

See U,

Nicolas NALLET (talk) 10:13, 26 July 2013 (UTC)

Thanks for letting me know about that. Yaron Koren (talk) 11:39, 26 July 2013 (UTC)

two-step process linking to forms

Hi all!

I added the below parser function to my mainpage. I loved how it came out, BUT when I type in the name of something and pick the form I want, and click "create or edit", the resulting page is quite ugly. The left sidebar of mediawiki is overlapping the form and its hard to read anything. Has this been resolved elsewhere with some sort of modification to the sidebar settings?

{{#forminput:form=|size=|default value=|button text=|query string=|query string parameters|autocomplete on category=|autocomplete on namespace=|remote autocompletion|placeholder=|popup}}

Hi - this doesn't seem related to #forminput. My guess is that you have some sort of HTML error in either your skin or your form definition. Yaron Koren (talk) 13:53, 29 July 2013 (UTC)

Hi Yaron, Good to hear from you - I just finished your book entirely to the chapters on Semantic. It could not have been a better resource to start a wiki page. I am so excited for the way my page has turned out so far. Not ideal, but I got rid of the above problem simply by deleting the popup element of the #forminput and it looks just fine now. I am using the standard Vector skin fyi. - Matt

That's great to hear! I'm glad you liked the book. Ah, it was a popup form - there still shouldn't be any formatting errors for that, but it's more understandable that something could go wrong. Yaron Koren (talk) 17:28, 29 July 2013 (UTC)

Semantic Forms and Searching

Hi, Is it possible to make it so the below Parser function: {{#forminput:form=|size=|default value=|button text=|query string=|query string parameters|autocomplete on category=|autocomplete on namespace=|remote autocompletion|placeholder=|popup}}

Is forced when a red-link is clicked on (either through the general search bar or anywhere else in the wiki)?

I know this can be done if the item is a property and have done that where I can, but this is for items that are not in that category.

Thanks for your help

Matt

In addition to setting forms for properties, you can also set forms for namespaces - that might do the trick in this case. Yaron Koren (talk) 17:29, 29 July 2013 (UTC)

Yaron, I thought of trying that but couldn't wrap my head around it. Here is the issue I see and let me know if you think I am doing something wrong. I am creating a golf wiki. For simplicity (there are actually about 8 different ones for now), let's say there are only 2 categories: Golf Course & Professional Golf Player. I have a form for each that I want used and since it is golf and the demograph is on the older side, I need to make this as simple as it gets (why I am so excited about semantic!). Let's say the 50 year old golfer types in the standard search box (I havent gotten into semantic querying yet, but I imagine the search box will never go away) their favorite course: "Sunset Whitney" and it comes up as a red link that they click on. The way my wiki is set up now, it takes them to a clean slate white box for them to edit and I want them to go to the form for Golf Course (not professional player) or AT LEAST be queued to pick a form from the parser #forminput function after they click on the red link. I do not want them to type in Golf Course:Sunset Whitney as that is a convention I am certain my user population won't grasp easily (and I need to make it so they will add content). So knowing that, am I missing your point or do you agree? I have to beleive there is a way to edit the code to return the parser function upon clicking the red link, but I dont want to invent it :) Sorry for the long winded message.

Right, I understand. Unfortunately, I don't think there's any way to do that, other than making it obvious on the front page (and maybe on the search page as well) that there are forms to add all the content. I should note that personally, I'm not a fan of using namespaces to separate types of content (like "Golf Course:") - I just think it's unnecessary. But that's another subject. Yaron Koren (talk) 03:25, 30 July 2013 (UTC)

Changing Forms after they are created

Is it possible to modify a form in the form GUI rather than just the code? If I want to change something in my form (the page is Form:XYZ Form) after I made it and I go to the edit tab, it is just the code. I would like to go back into the form display and make changes that way. Thanks, Matt

Not directly in Semantic Forms, but the Page Schemas extension exists for that purpose. Yaron Koren (talk) 12:38, 30 July 2013 (UTC)

awesome, thanks

Contents of form

I was wondering if it is possible to suppress/remove items from the "Read" tab of a form that are not used. I believe infoboxes do this automatically. Example pasted below:

Club: Driver

Brand: Callaway

Model: Razr Fit Xtreme

Degree Loft: 9.5

Shaft Type: graphite

Shaft Flex: Extra Stiff (XS)

Shaft Brand:

Grip:

The user left Shaft Brand/Grip blank and I want it not shown on the read page, but the user can still add it at a later time in the edit forms tab)

Sorry for all the questions today, i do research for an answer before I ask but I also think creating a body of knowledge for average users like me will proliferate this amazing functionality. Thanks, Matt

You can use #if for that. That option is described in my book, by the way, speaking of my book. Yaron Koren (talk) 12:39, 30 July 2013 (UTC)

I must have missed it, thanks! - matt

included but not desired on page created by form using templates

Hello, I struggle because when I create a page with http://www.coetus.eu/wiki/Formulaire:SERIE there is a <onlyinclude></onlyinclude> that appears between the 2 templates used. As a result, when I include the page using a format {{:pagename}} , I only get what is include between <onlyinclude> and </onlyinclude>, i.e. either nothing or the free text that I would have included.

As for now, only me is including info in this wiki so I can remove the <onlyinclude></onlyinclude> by hand each time for each SERIE I input. But I want to get more users on my wiki and it needs to be simple for them so I'd need to avoid this phenomenon.

Any clue on what I did wrong that created this, or on what workaround I could use to avoid the problem ?

Many thanks for SMW, it's a fantastic tool, I love your work.

Frederic alias coetus.

Hi - yes, you should remove the "onlyinclude free text" parameter from the form's "info" tag. I'm glad you're enjoying the software! Yaron Koren (talk) 01:33, 31 July 2013 (UTC)

This worked perfectly. Many thanks Yaron, very helpful.