Extension talk:Page Forms

From MediaWiki.org
Jump to: navigation, search
An archive box Archives 

Improving doLookup() function[edit]

Sometimes the address entered by the user is one that returns ZERO_RESULTS because it contains extra information before the street address (e.g. the name of the place), but would work fine if this information were removed.

There is no simple way to let the user know exactly how the Google geocoding API works, and it would be better to have the software do the work in any event, so I wonder whether it would be possible to change the doLookup() function to do one or both of the following:

1. Use a regular expression to extract the postcode from the address (in the UK at least this is fairly easy) and perform a further search on this postcode if the original search returns ZERO_RESULTS.

2. Repeatedly/recursively remove everything up to the first comma (or perhaps also line return if textarea fields are being used) and perform a further lookup on what remains until it is successful. For example, first of all it might remove the place name, then perhaps the street name, until it is just left with the postcode.

Thanks in anticipation, and Happy New Year. Jonathan3 (talk) 01:12, 2 January 2017 (UTC)

Those both sound like they would be an improvement over the current state of things. Yaron Koren (talk) 02:12, 2 January 2017 (UTC)
Great. If I worked on this and sent you a patch, would you consider adding it to the code? (I wouldn't want to have to add it manually each time I update the extension.) Jonathan3 (talk) 20:25, 2 January 2017 (UTC) P.S. I've taken the liberty of correcting doMarker() to doLookup() in my previous comment. Jonathan3 (talk) 20:35, 2 January 2017 (UTC)
Yes, of course. Yaron Koren (talk) 21:54, 2 January 2017 (UTC)

"Edit with form" tab and "Template" namespace[edit]

I have created a Form:Template and a Project:Template page with contents: {{#default_form:Template}} but the "Edit with form" tab won't appear to "Template" namespace. PF 4.0.2 --Ioannis Protonotarios 01:42, 4 January 2017 (UTC) Happy New Year!

!P.S. The exact same thing works just fine in "Property" namespace. --Ioannis Protonotarios 01:44, 4 January 2017 (UTC)

Happy New Year! Have you defined the "Template" namespace on your wiki? Yaron Koren (talk) 05:04, 4 January 2017 (UTC)
What do you mean? It's a standard namespace. I haven't done anything myself, neither in "Property" namespace which is pre-defined too by SMW. --Ioannis Protonotarios 12:42, 4 January 2017 (UTC)
Oh, man... that's the last time I try to provide help after midnight. Disregard my last comment, of course. But I have to ask - how can you have a form to edit templates? That doesn't seem workable. Yaron Koren (talk) 16:19, 4 January 2017 (UTC)
Well, I've started building a meta-ontology to store data about the semantic structrure of my wiki, i.e. properties, concepts etc. For example, property X is subproperty of property Y, is used in template Z etc. And then I thought, why not assign properties to templates too? E.g. template A is used in template B, has template type C etc. All property definitions should obviously go inside a <noinclude> tag and the template code inside a <includeonly> tag. Then I thought, why not use forms? Since a form puts its wikitext in the begining of the page, and plain wikitext goes right after that, I figured that the workaround would be to use no <noinclude> tags and wrap the actual template code in a <onlyinclude> tag. Which I did and it worked! So now I can edit templates with forms just fine! The template code appears in the free text box. See example: Template:1080p view code view form. The only problem is what I've reported, that there is no "Edit with form" tab and that the &action=formedit doesn't work. It asks "which form to use?", even though the form is defined in Project:Template. --Ioannis Protonotarios 17:39, 4 January 2017 (UTC)
That's strange - I can't replicate this issue; it works fine for me. I don't know what's causing it on your wiki. Try resaving the "Project:Template" page, maybe? Yaron Koren (talk) 17:54, 4 January 2017 (UTC)
Yes, the infamous "null edit"! But it doesn't work. Moreover, after rebuilding semantic data after the upgrade, now it seems that all "Edit with form" tabs have disappeared! --Ioannis Protonotarios 22:10, 4 January 2017 (UTC)
P.S. Auto-creation of pages has stopped working too. --Ioannis Protonotarios 22:14, 4 January 2017 (UTC)
This I think I've found it. I use the obsolete "Creates pages with form" property but I if undestand correctly I must now use the #formredlink function instead, right? --Ioannis Protonotarios 15:29, 5 January 2017 (UTC)
Okay, now that I've looked at your wiki, I'm pretty sure what the issue is for most of your forms - you're defining the relationship of form to category via Page Schemas, and within each schema, the "semanticforms_Form" tag (both closing and opening) needs to be modified to be "pageforms_Form". Sorry that this has been poorly documented. Yaron Koren (talk) 05:49, 5 January 2017 (UTC)
I've added a side note to Page Schemas documentation. Page Schemas is a very helpful extension for newbies because it easily creates a working semantic structure but I think I will completely remove it since creating things manually gives more control and you know what you are doing. As for the template/form issue maybe it's because of my MW 1.26.2 version. I think I saw somewhere a mention of compatibility issues with latest SMW. The problem is that Media Temple, my hosting provider, is still stuck in PHP 5.3.x (MW 1.27 requires PHP 5.5.9) and they won't tell us when and if they will ever upgrade it to 7. I've filed support requests on that and they always say that they are working on it. So right now I am stuck with MW 1.26.2. --Ioannis Protonotarios 15:29, 5 January 2017 (UTC)
Not sure if this is related or not but 'Edit with Tab' based on NameSpace is not working for me anymore. MW1.28.0; SMW2.4.4.; PF4.0.2 (PF Jan. 5 download). Once I have submitted a PF and I want to edit it using 'Edit with Tab'; the only way I can get it to work is by defining the right Form in a template using {{#default_form:form-name}}.

Any idea? --Albert Ke (talk) 16:56, 12 January 2017 (UTC)

Yes - the "Has default form" special property option was removed in PF 4.0; you have to use #default_form now. Yaron Koren (talk) 18:49, 12 January 2017 (UTC)
Perfect, that solved it. Thanks! --Albert Ke (talk) 20:07, 12 January 2017 (UTC)



I am trying to improve increase validation on one of my forms with regexp but I don't seem to be getting any errors. I am competent with Page Forms but have never used regexp before. The example extract below is taken from a partial form (template)

| {{{field | HasADAccount | property=HasADAccount | input type=regexp | regexp=/^[A-Z]+$/}}}

I would have expected to get an error if I only entered a number but I get no error and the field is being passed back as though the regexp has had no effect. Can anyone advise?

MW 1.27.1, PF 4.0.2



Oops! It looks like the "regexp" input hasn't worked since at least version 4.0, i.e. the extension rename, and maybe even earlier. I just checked in some fixes, so if you get the latest code it should work. Yaron Koren (talk) 16:05, 6 January 2017 (UTC)

"UNIQ" and "Some very long page name" strings[edit]

Hi Yaron, me again. I've started replacing "Creates pages with form" property with the #formredlink function as I said two threads above and it works (almost*) fine but while in the process of creating the new pages, some weird stuff appear on page:

  1. #formredlink calls (red or blue) that are before the last #formredlink-to-be-created appear as "UNIQ--item-2--QINU?, ?UNIQ--item-3--QINU?, ?UNIQ--item-4--QINU?, ?UNIQ--item-5--QINU, etc". #formredlink calls (blue) that follow the last #formredlink-to-be-created appear OK.
  2. At the same (i.e. while there are red link pages under creation), other links, that they are property declarations of type URL, appear as "Some very long page name that will hopefully never get created ABCDEF123".

After all red link pages have been created, things go back to normal and appear as expected.

Similar past issues:

  1. Work-around for un-populated red link A very long page name error (27 October 2014)
  2. "Create pages with form" and sfEditFormPreloadText (4 November 2013)

* I say "almost" because I haven't managed to employ "query string" parameter yet but I am still looking at it and if I don't succeed I will come back to report it officially.

--Ioannis Protonotarios 09:20, 6 January 2017 (UTC)

Relocating standard inputs to a different area of the page[edit]

Hi Yaron

Some time ago I seem to remember seeing an example of using Page Forms (or Semantic Forms as it then was) to relocate the standard inputs to a different location (eg the top) of the form. Was I just imagining this or, if not, would you be able to point me in the right direction?

Many thanks

Duncan 8th Jan 2017

Ah I think I've worked this out. I created a 'sub' form (as a template) and just transcluded this before the other parts of the form. Seems to work anyway. Many thanks. Duncan
I think there is no need for a 'sub' form. You can just place any of the {{{standard input|...}}} anywhere you like in the form and multiple times if you like. For instance, in big forms I usually put the two main buttons save and preview ({{{standard input|save}}} {{{standard input|preview}}}) both at the top and at the bottom of the form, so as to be handy. --Ioannis Protonotarios 19:08, 8 January 2017 (UTC)

Have global settings changed with the move from SF to PF[edit]

Hi all, Yaron,

I'm facing some MW database issues that I'm trying to solve by cleaning my LocalSettings.php as much as possible. As such I came across $sfgNamespaceIndex which namespace I had set to 150. Is this variable still used in PF or renamed or is it save to remove this? Thanks, --Albert Ke (talk)

It was renamed - all the global variables had the "$sfg" in their name replaced with "$wgPageForms". I'm guessing you will still need to include that line in LocalSettings.php. Yaron Koren (talk) 19:40, 9 January 2017 (UTC)
Ok., so the variable becomes $wgPageFormsNamespaceIndex. I had the old SF variable directed to namespace 150 so set this new PF variable to it as well. However, when including this under the wfLoadExtension ('PageForms'), save and exit, then do a touch LocalSettings.php, even an php update.php in the maintenance folder, namespace 150 doesn't show up in the list: http://csdms.colorado.edu/mediawiki/api.php?action=query&meta=siteinfo&siprop=namespaces. Or did I miss anything? Thanks! --Albert Ke (talk)
Oh, never mind - looking through the code now, it looks like the namespace IDs are hardcoded and can't be changed, and it has been that way for a long time. I guess I had forgotten. So I think you can just remove that line. Yaron Koren (talk) 20:28, 9 January 2017 (UTC)
OK., perfect another potential database problem that is ruled out. Thanks, --Albert Ke (talk) 20:40, 9 January 2017 (UTC)

Internal Error:[edit]

Just updatet to newest MW & SMW. New PageForms causes Error, while old SemanticForms instead still works. Any ideas?

[9851f6842c7da4f513efdf25] /index.php/Hauptseite MWException from line 176 of C:\QMSSERV\htdocs\includes\Hooks.php: Invalid callback PFHooks::initProperties in hooks for smwInitProperties

#0 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyRegistry.php(420): Hooks::run(string)
#1 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyRegistry.php(79): SMW\PropertyRegistry->registerPredefinedProperties(boolean)
#2 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\includes\dataitems\SMW_DI_Property.php(86): SMW\PropertyRegistry::getInstance()
#3 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\DataItemFactory.php(42): SMW\DIProperty->__construct(string, boolean)
#4 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyAnnotator\DisplayTitlePropertyAnnotator.php(66): SMW\DataItemFactory->newDIProperty(string)
#5 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\PropertyAnnotator\PropertyAnnotatorDecorator.php(61): SMW\PropertyAnnotator\DisplayTitlePropertyAnnotator->addPropertyValues()
#6 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(117): SMW\PropertyAnnotator\PropertyAnnotatorDecorator->addAnnotation()
#7 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(87): SMW\MediaWiki\Hooks\ParserAfterTidy->updateAnnotionsForAfterParse(SMW\PropertyAnnotatorFactory, SMW\SemanticData)
#8 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ParserAfterTidy.php(53): SMW\MediaWiki\Hooks\ParserAfterTidy->performUpdate()
#9 C:\QMSSERV\htdocs\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\HookRegistry.php(126): SMW\MediaWiki\Hooks\ParserAfterTidy->process()
#10 [internal function]: SMW\MediaWiki\Hooks\HookRegistry->SMW\MediaWiki\Hooks\{closure}(Parser, string)
#11 C:\QMSSERV\htdocs\includes\Hooks.php(195): call_user_func_array(Closure, array)
#12 C:\QMSSERV\htdocs\includes\parser\Parser.php(1397): Hooks::run(string, array)
#13 C:\QMSSERV\htdocs\includes\parser\Parser.php(444): Parser->internalParseHalfParsed(string, boolean, boolean)
#14 C:\QMSSERV\htdocs\includes\content\WikitextContent.php(330): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
#15 C:\QMSSERV\htdocs\includes\content\AbstractContent.php(497): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
#16 C:\QMSSERV\htdocs\includes\poolcounter\PoolWorkArticleView.php(140): AbstractContent->getParserOutput(Title, integer, ParserOptions)
#17 C:\QMSSERV\htdocs\includes\poolcounter\PoolCounterWork.php(123): PoolWorkArticleView->doWork()
#18 C:\QMSSERV\htdocs\includes\page\Article.php(651): PoolCounterWork->execute()
#19 C:\QMSSERV\htdocs\includes\actions\ViewAction.php(71): Article->view()
#20 C:\QMSSERV\htdocs\includes\MediaWiki.php(495): ViewAction->show()
#21 C:\QMSSERV\htdocs\includes\MediaWiki.php(289): MediaWiki->performAction(Article, Title)
#22 C:\QMSSERV\htdocs\includes\MediaWiki.php(851): MediaWiki->performRequest()
#23 C:\QMSSERV\htdocs\includes\MediaWiki.php(512): MediaWiki->main()
#24 C:\QMSSERV\htdocs\index.php(43): MediaWiki->run()
#25 {main}
I'm guessing you downloaded Page Forms via the Extension Distributor. You shouldn't do that - you should always download PF (or any of my extensions) via the main download link on the page. I wish the ED link weren't there at all. Sorry about that. Yaron Koren (talk) 17:51, 10 January 2017 (UTC)
solved this Problem. Thanks --Letofred (talk) 12:31, 11 January 2017 (UTC)

File-Upload and Handling[edit]

1) Got a probleme with uploding files via PageForms (4.0.2 on MW 1.28.0 SMW 2.4.4) ending in a

Fatal error: Call to undefined method OutputPage::getHeadScripts() in *****\extensions\PageForms\specials\PF_UploadForm.php on line 327

2) I have a form like this:

{{{for template|reference|multiple|add button text=new reference}}}
<table><tr><td>ID: </td><td>{{{field|ID|input type=text|size=10}}}</td><td>Reference: </td><td>{{{field|kind|mandatory|input type=radiobutton|values=Text,Link,Page,Form,File,PDF,Pic|default=Text|show on select=Text=>Text;Link=>Link;Page=>Page;Form=>Form;File=>File;PDF=>PDF;Pic=>Pic}}}</td></tr>
<tr><td>Title: </td><td colspan=3>{{{field|Text|input type=text with autocomplete|autogrow}}}</td></tr>
<tr ID="Text"><td>{{Miniatur|info.png}} Text: </td><td colspan=3></td>
<tr ID="Link"><td>{{Miniatur|www.png}} URL: </td><td colspan=3>{{{field|URL|input type=text with autocomplete|autogrow|placeholder="http://"}}}</td></tr>
<tr ID="Page"><td>{{Miniatur|file.png}} Page: </td><td colspan=3>{{{field|Pagename|input type=text with autocomplete|autogrow|placeholder=Seitenname}}}</td></tr>
<tr ID="Form"><td>{{Miniatur|form.png}} Formular: </td><td colspan=3>{{{field|Pagename|input type=text}}}</td></tr>
<tr ID="File"><td>{{Miniatur|file-in-folder.png}} File: </td><td colspan=3>{{{field|Filename|input type=text|uploadable}}}</td></tr>
<tr ID="PDF"><td>{{Miniatur|pdf.png}} PDF-File: </td><td colspan=3>{{{field|Filename|input type=text|uploadable}}}</td></tr>
<tr ID="Pic"><td>{{Miniatur|jpg-file.png}} Pic-File: </td><td colspan=3>{{{field|Filename|input type=text|uploadable}}}</td></tr>
{{{end template}}}

Creating a Page with this Form works fine. Edit this Page with formedit causes following problem:

If I select the "Page" or "File" whitch is the first kind of

{{{field|Filename|input type=text|uploadable}}}

it works as expected.

If I select "Form" or "PDF / Pic" he wont get the "Pagename" or "Filename".

I used this way to schow a different Icon. This may helpful for users to know if its a internal (Page) or external Link (URL) or if he can view this in browser or need a different kind of program to view. I suspect, your just try to set the "pagename/filename" to the first field found. May I request to set every field found to the given "pagename/filename"?

My workaround would be to name them pagename1, pagename2 etc ... It wount satisfy me, if I upload first and later change the "kind" I forgott to set ... --Letofred (talk) 13:04, 11 January 2017 (UTC)

Hi - for #1, just delete that line - it was deleted a while ago in the main PF code, but I guess not before version 4.0.2 was released. Sorry about that. For #2, yes, you can't have more than one "field" tag for the same field name, even if only one of them is shown at a time - that's a limitation of PF. So yes, the easiest solution is to have different field names. Potentially, you could also turn those last three rows into just one row, and have "show on select" apply to just the "label" cell instead of the whole row - and then add three more "show on select" values, all applying to the same "field" cell. Does that make sense? Yaron Koren (talk) 15:10, 11 January 2017 (UTC)
#1 solved
#2 Think about your solution ... atm there seems no way to avoid a second selection. If I correctly read your suggestion, just giving the ID to the "label" / Picture will allways show the input field for the file - even if I dont select a kind of file - i.e. a page ... not the way it should look like ...
The use of classes instead of ID would be a nice solution. I could use {Class A} Pic1 {Class B} Pic2 {Class C} Pic3 {Class A B C} Form-Tag. Maybe a suggestion for a next version? Would cause problems with compatibility? --Letofred (talk) 17:32, 11 January 2017 (UTC)
No, the input field would not always be shown - but maybe it's too difficult to explain. Yes, it would have been better to go with class instead of ID, but yes, it would break compatibility at this point. Yaron Koren (talk) 17:36, 11 January 2017 (UTC)
Took some time to catch your thoughts.
show on select=[...]File=>File;PDF=>PDF;Pic=>Pic;File=>Filename;PDF=>Filename;Pic=>Filename
works fine!
Didn't know you can assign double values to one selection. --Letofred (talk) 12:31, 12 January 2017 (UTC)
Okay, great - I wasn't sure the whole thing would work. Yaron Koren (talk) 14:29, 12 January 2017 (UTC)

#forminput flag for read and not edit[edit]

A small request for improvement for the #forminput parser function - In several occasions, I have come across the need for a quick lookup form for a page with autocomplete by category or by semantic properties. The #forminput function with autocomplete would be perfect for that except it opens the form in edit mode by default. A new parameter such as 'viewmode=yes/no (no by default)' could force the action of the form to open the target page in read mode only if it exists or switch back to the form creation if it doesn't exist. --Lalquier (talk) 16:26, 13 January 2017 (UTC)

Read-only mode is controlled by MediaWiki itself. There is only one action (&action=edit) in all cases and MediaWiki decides whether a user would edit a page or view it, according to their rights. The same applies for &action=formedit. So all you have to do is play with user rights. Unless what you are asking for is that a user who does have a right to edit, to also have the ability to just view the page in read-only mode by choice. But I wonder what's the use of it? I mean, what's wrong with viewing a page in edit mode? Are you afraid that the user might alter something by mistake? Well, either you trust a user and you give them the right to edit, or you don't trust them and you don't give them this right, there is no middle ground, as I see it. --Ioannis Protonotarios 17:38, 13 January 2017 (UTC)
Lalquier - I remembered that there was already a feature request for this on Phabricator, here - but then I looked and saw that you were the one who made that request too. :) (Ioannis - I think you're misunderstanding the request; he's just talking about a way to find pages on a wiki.) It's an interesting idea; my hesitations are that (a) it's not a form-related feature, and (b) I haven't seen a lookup interface like this anywhere else, and I try to avoid having truly new UI approaches whenever possible. Yes, search inputs (like MediaWiki's own) resemble this to some extent, but they don't require an exact match, and they don't narrow the set of pages down ahead of time. Yaron Koren (talk) 20:11, 13 January 2017 (UTC)
I agree that it would be a useful feature. It might be the easiest way for a user to search - e.g. without needing to narrow down the MediaWiki search to the relevant namespace, or without needing to understand the Special:Drilldown page. In relation to your two hesitations: (a) Sometimes a user may need to see a page before knowing whether or not to edit it, so arguably it is (indirectly) form-related, and this method may encourage users to contribute. (b) It would be very similar to the search box on a dynamic table (a problem with a dynamic table, though, is that it flashes up every entry before the CSS/Javascript (or whatever) kicks in and reduces it down to the first 10). Jonathan3 (talk) 21:31, 13 January 2017 (UTC)
Thanks for the reply. My thinking for the two points you provided are a) it is not directly a Page Form related feature but adding it to Page Form would be a simple way prevent having to create a special extension just for that, with similar layout, autocompletion options and code duplication (another route could be to 'semantify' the Input Box extension but then again, why adding all that code since Page Forms already does 95% of the job) and b) as for novelty, it is no different than the standard MW mechanism of looking up a page for a 'go to' search, except for narrowing down the scope to a certain semantic property , category or namespace. Use cases I ran into for this feature are any kind of catalog, like a list of street addresses, or a dictionary. If your wiki has several types of catalogs, it is very useful to give an option for people to lookup a page and view it first in read mode before they decide to edit it or not (not a question of trust by the way, but a question of presenting the information with a display template being less intimidating for users than slapping a an edit for in front of them). In the end, you are the final judge of what to add to your extension - I just want reiterate there is a demand for this kind of option :) --Lalquier (talk) 14:36, 15 January 2017 (UTC)
Thanks to both of you for your responses. Lalquier - as I noted, there's one other difference between this and the search input, which is that this one requires an exact match. But Jonathan3's point about its similarity to the Cargo "dynamic table" format brings up an interesting option: perhaps this could be implemented instead as a result format in Cargo and/or SMW - which would give greater control over what set of pages gets displayed, and could potentially give more flexibility over display - like being able to show an image for each value. What do you all think? Yaron Koren (talk)
As long as it has the shape of a text input element with an autocomplete/auto-suggest list of elements, I would be glad to use it regardless of which extension it is from. --Lalquier (talk) 00:23, 16 January 2017 (UTC)

[RESOLVED] Is the openlayers input type still supposed to work?[edit]

I am getting a javascript error when I try to use the 'openlayers' input type in a Page Form. "Uncaught ReferenceError: OpenLayers is not defined at setupMapFormInput (...)'. The PageForms documentation suggests 'openlayers' is still one of two map related input types. Have you seen that kind of error before? I am using the PageForms 4.02, Maps 4.0.3 and Openlayers 1.0.0 extensions. --Lalquier (talk) 14:51, 15 January 2017 (UTC)

Yes, it's supposed to work, and no, I haven't seen that error before. Try disabling the OpenLayers extension, maybe? It's optional. Yaron Koren (talk) 15:17, 15 January 2017 (UTC)
Thanks. When I try to disable Open Layers, the javascript error goes away and an Open Layers map does show under the form input, but it is disconnected with the coordinates text part of the form input (changing the coordinates in the text input doesn't change the coordinates on the map and vice versa). The 'Set Marker' button doesn't do anything. The console does show more javascript errors such as 'VM1039:13 Uncaught TypeError: (intermediate value).tranpform is not a function at toOpenLayersLonLat' and 'Uncaught TypeError: realLonLat.tranpform is not a function at openLayersSetMarker' --Lalquier (talk) 18:41, 15 January 2017 (UTC)
Oh, that's funny - "transform" was incorrectly changed to "tranpform" during the big renaming of the code from Semantic Forms to Page Forms; you may be able to guess how that happened. :) I just fixed that bug, so hopefully the OpenLayers stuff works now. Yaron Koren (talk) 19:30, 15 January 2017 (UTC)
Makes a lot of sense :) Happy to report the latest version (from github master) is working with Open Layers. --Lalquier (talk) 00:27, 16 January 2017 (UTC)

Error: You need to have Semantic Forms installed in order to use Semantic Image Input.[edit]

Hi all,

I updated MW from 1.27.1 to MW 1.28.0. Old MW used Semantic Forms 3.7. I've installed Page Forms 4.0.2 via composer to new MW. If I activate Semantic Image Imput in LocalSettings, I get Error: You need to have Semantic Forms installed in order to use Semantic Image Input.

I've just tested and commented out a few lines of code in SemanticImageInput.php, where SF_Version is asked. But no effect after I requested my wiki, still getting the error message.

Is there anything I need to be aware, if I use Page Forms and Semantic Image Input? Are there any configurations, which have to be changed?

Thanks a lot! Saskia

I have bad news - Sematic Image Input simply cannot work with Page Forms until it's updated. That may not take a long time, but until someone updates the code, it will only be able to work with Semantic Forms. I hope someone does update it, and it might be worthwhile to change the name at the same time. Yaron Koren (talk) 02:37, 17 January 2017 (UTC)

"Edit with form tabs" missing in latest 4.0.2? (Jan 15)[edit]

Has anything changed in recent updates that could impact the display of the "Edit with form" tab? It was working before I updated to the latest code to fix the OpenLayers form input. I do have the configuration variables set up to enable the tab ($wgPageFormsRenameEditTabs = true; and $wgPageFormsRenameMainEditTab = true;) and assign the right permissions ($wgGroupPermissions['*']['viewedittab'] = true;). I also use the #default_form function in a category page for the forms. --Lalquier (talk) 11:57, 16 January 2017 (UTC)

Small update. Using #default_form in the page itself adds the tabs back. So it has to do with adding the form to the category page. I will do more digging tonight. --Lalquier (talk) 12:06, 16 January 2017 (UTC)
(update) It's actually weirder than that and likely an issue of config on my side. The 'Edit with form' tab only appears for some pages in the same category but not others, with no indication yet about what makes it appears or not. --Lalquier (talk) 21:28, 16 January 2017 (UTC)
That's strange. Could it be that the pages with no "edit with form" tab don't show up on the category page either? If so, the issue could be just that the necessary "updateLinks" jobs haven't finished running yet. Yaron Koren (talk) 02:41, 17 January 2017 (UTC)
The pages without the links do show in the Category. I added the #default_form to the template of the page itself and the links are still missing. I also ruled out a cache issue. Saving or refreshing the page does not bring the links back. And the job queue is currently empty. Very odd. It is happening only on one of 3 wikis so far, so I am still looking into what is different about that one. --Lalquier (talk) 13:55, 17 January 2017 (UTC)

Value dependent on other field[edit]

I have field on form called Task, I want the field person is dependent on Organisation field. If i select A on Organisation dropdown, then only persons which belong to this Organisation appear on field person. Is it possible to use value dependent on?. Or is it possible to query on value=?

Yes, you can use "value dependent on" - I think you just need to change the dropdown for "Organisation" to a combobox instead (you can use "existing values only" if you don't want new value there), and have "Person" also be a combobox. Yaron Koren (talk) 15:28, 17 January 2017 (UTC)
I still don't know how to use it correctly. I created the form on http://scratchpad.referata.com/wiki/Form:0Person. Could you please help me to fix it? to make it works. Thanks
Oops - you got me confused there. It's "values dependent on", not "value dependent on". Yaron Koren (talk) 17:15, 18 January 2017 (UTC)
Oh man, thank you very much. That was my mistake. :happy:

Same settings, different resulting fields[edit]

I am not sure if it is a PF issue, but here we are: I have these two form fields:

{{{field|Has parent page|input type=tokens|values from concept=Institution|mapping property=Display title of}}}
{{{field|Has hierarchical superior|input type=tokens|values from concept=Instituton|mapping property=Display title of}}}

the only difference between the two is the name field. But when the form loads, it looks like different. See. We can see from the URL that both of the fields is sending the same information: Institution[Has hierarchical superior]=Configuração:Institution 003 & Institution[Has parent page]=Configuração:Institution 003

It seems like a bug. I am using PF 4.0.2 (fbecc9f). Jaider msg 20:28, 18 January 2017 (UTC)

That does look like a bug, yes. Yaron Koren (talk) 20:41, 18 January 2017 (UTC)

JsInit for some pageform elements causes race condition.[edit]

Example JS Error: TypeError: Cannot read property 'wikieditor' of undefined TypeError: Cannot read property sometimes with PF_TextAreaInput

The Pageforms script can be loaded and executed sometimes quicker than the 'jquery.wikiEditor' resource and cause this error, similar with date time picker or any custom inputs using addJsInitFunctionData

instead of just giving a function name to execute to addJsInitFunctionData method maybe a resource module name should also be given so that you can check the resource module is loaded first before executing the function

   Edit: This might be resolved with a fix patch to this one  https://phabricator.wikimedia.org/rEPFMdd055d8424a36e3daef6e86d1a856f50a3a30666  though to be safe I think the initialisation functions shoudl use mw.using to be safe

Can "values dependent on" work with Cargo data?[edit]

We are trying to make a particualr query form more manageable and it sounds like "values dependent on" feature should work.

Does the query behind the scenes depend on SMW properties, or can it work with Cargo data as well?

The relevant part of the form:

{{{field|prodlong|input type=combobox|cargo table=OptionCreate|cargo field=prodlong|placeholder=Select a product }}}

{{{field|component|input type=combobox|values dependent on=OptionCreate[prodlong]}}}

These fields are both in the Cargo table for the "OptionCreate" template; however, the actual values in the table may differ a little from the values stored on the pages using the OptionCreate template (for example, we run "component" through a replace statement to change certain special characters)

Any ideas? Thank you! --Bgrenon (talk) 13:41, 20 January 2017 (UTC)

Yes, "values dependent on" can definitely work with Cargo data. Is it not working? Yaron Koren (talk) 18:52, 20 January 2017 (UTC)
Yes! It is working with Cargo. This was due to my misunderstanding - I wanted the query form to pull 'values dependent on' from a different template/cargo table than the one associated with the form. The query form is meant for readers to query data from a template that authors use a different form to maintain. By putting both functions in the same template (query for readers and data entry for authors) with a switch, it now works. Great feature. --Bgrenon (talk) 15:23, 10 February 2017 (UTC)
Great. Though the query template doesn't need to be the same a the data entry template... though maybe I'm misunderstanding what you're saying. Yaron Koren (talk) 16:09, 10 February 2017 (UTC)

Is it possible to have section edit links to open forms?[edit]

Currently there are three ways to edit a page - PageForms, VE and normal wikieditor. I would like to use only PageForms for which it is desirable to have all the best features within it :)

Is it possible to have section edit links to open forms for editing? --Nischayn22 (talk) 05:44, 24 January 2017 (UTC)

I don't know if there's any easy way to do that, but what I can recommend instead is just getting rid of those section edit links, by adding "__NOEDITSECTION__" to any template associated with a form. Yaron Koren (talk) 15:16, 24 January 2017 (UTC)

Is #default_form available on Properties[edit]

I previously used Has default form: extensively on my Properties with the Type:Page, to automate the form selection on the creation of red-linked pages. Does the #default_form parser work on Property pages to assign Forms for red-linked pages? In my testing it does not appear to. I am also going to assume the former Has alternative form: Special property has no replacement as well. thanks --Jcantroot (talk) 17:20, 25 January 2017 (UTC)

The replacement for "Has default/alternate form" for properties is the #formredlink parser function. Yaron Koren (talk) 18:38, 25 January 2017 (UTC)
Can you point to an example? I have used the #formredlink on property of type page and get an error stating the value can not be used as page name and the supplied value is not understood.. However if clicking on the red-linked page, the page is created with the desired form.
This is what I have in my Template:abbreviation for property Meaning to call up form Definition to create a page titled with the value of Meaning:
! Meaning | [[Meaning::{{#formredlink:target={{{Meaning|}}}|form=Definition}} ]] PeterBodifee (talk) 17:17, 29 January 2017 (UTC)
You need to instead have something like "{{#formredlink:target={{{Meaning|}}}|form=Definition}} {{#set:Meaning={{{Meaning|}}}}}". Yaron Koren (talk) 02:55, 30 January 2017 (UTC)
Thanks, the error is gone! PeterBodifee (talk) 11:34, 30 January 2017 (UTC)

Free Text positioning[edit]


I'd like to know how to position Free Text first, before the forms. Is there something I can add to the template page to forst Free Text to come first? Thank you!

Someone asked about this above - you just need to put the "free text" input at the top of the form. Yaron Koren (talk) 16:16, 30 January 2017 (UTC)
Didn't work. Changed the position on the form but, on the page, Free text still showing on the bottom. I think my template should have something related to free text to. But it doesnt. Maybe that's the problem? Thanks
Sorry for the delay. I just tried this out, and it worked for me. No, the template doesn't have to have anything related to the free text. Are you using a recent version of Page Forms? Yaron Koren (talk) 18:33, 3 February 2017 (UTC)

Do not overwrite existing page text[edit]

I have a formlink where the target is defined by one of the form fields. The target may or may not have existing text on the page. How do I make it so that the existing text is not overwritten by the form?

I tried "partial forms," but that did not seem to work since the target is not pre-defined. Also, I tried pre-loading the free text field, but that does not work either.

Thanks for the help.

--Dgennaro 19:41, 30 January 2017 (UTC)

I don't understand how the text would get overwritten. If you go with #formlink to a form for a page that already exists, you should see the existing values in that form - either as form field values, or in the "free text", depending on whether or not it's the right form. But in no case should text just get removed without the user knowing about it. What exactly is happening? Yaron Koren (talk) 20:56, 30 January 2017 (UTC)
Ok, so I have a form that is used to upload files to a "folder" (assign a "Is in Folder" property). During the actual upload process the the file is indexed and its content is added to the File's page. So when the upload screen is minimized and the form is saved it overwrites the file content that was added to File page. I'm sorry if this is confusing. What I might have to do is instead of saving the file's content to the page directly I will have to create a new table and add the content there and use External Data to pull it in.

--Dgennaro 21:34, 30 January 2017 (UTC)

Mandatory and input type=tree[edit]

From my testing looks like mandatory doesn't work in conjunction with input type=tree. Is there a way to force the user to select a value (or in case of list at least one)? PeterBodifee (talk) 10:25, 1 February 2017 (UTC)

I don't think so... if that doesn't work, it sounds like a bug. Yaron Koren (talk) 03:50, 2 February 2017 (UTC)
This is my construct in the form {{{field|Context|input type=tree|structure={{ComponentContextValues}}|mandatory }}} : it allows me to save the page without selecting a value for Context. Should I report the bug (and where)? We use Semantic Forms 3.6-alpha (77c4a3b) 17 apr 2016 22:18 PeterBodifee (talk) 08:00, 2 February 2017 (UTC)
That's a pretty old version. I'd recommend upgrading to the latest version, i.e. switching to Page Forms - it's possible that this bug has been fixed already, and I think it's a good idea anyway. Yaron Koren (talk) 14:37, 2 February 2017 (UTC)

Query using only some of the fields[edit]

Hi. My problem is this: I have a semantic form with 3 fields, but, if want to use the query I have to write the values for all the 3 fields. Is there a way to query using only some of the values and leaving the rest in blank? Thanks.

I don't know whether you're doing the query with SMW or Cargo, but whichever it is, this sounds like a question for that extension, not for Page Forms. Yaron Koren (talk) 03:00, 9 February 2017 (UTC)

using a form to edit a template call and leave rest of page alone[edit]

We have an established wiki that has used templates and SMW ad-hoc for some time. I am trying to add forms to edit where templates are used. What I am finding is that the template is yanked to the top of the page, and any surrounding text is put around it. What I had hoped is that it would stay in place. Have I set up my form incorrectly, or is this the nature of the beast and I can't use it this way? Thanks! Tenbergen (talk) 03:52, 10 February 2017 (UTC)

I assume you meant "put below it". You might be able to avoid this by using partial forms, though personally I would recommend making your pages more structured and less ad hoc. Yaron Koren (talk) 16:06, 10 February 2017 (UTC)
Your point is taken, Yaron: if I were to re-design the wiki or add new concepts I would use forms more comprehensively. I am trying to introduce them slowly into a live environment for now. If I can show the benefits of having them for my template that involves dates then I think people will come on board for bigger changes. The template I am working with is usually used in the middle of a page; within its own section, but still in the middle of a page. I think the "partial form" tag is just what I need.
When I add the "partial form" tag, my preview stops working. The example given in partial forms is this. However, that uses cargo, so I can't simply steal from there. Should the preview work using just SMW?
Also, when I save from the form with the partial form tag, I end up with an empty page. Works without the partial form tag.
The latter sounds like a major bug - sorry about that. Partial forms are a very under-used and under-tested feature, so it's not surprising (though disappointing) that it might have a bug like this. Hopefully it'll get fixed. (I assume you're using a recent version of Page Forms.) Yaron Koren (talk) 15:34, 15 February 2017 (UTC)
I am using Page Forms version 4.0.2 (fbecc9f) 2016-12-19T15:47:40 . I have created a task in Phabricator. Tenbergen (talk) 17:37, 15 February 2017 (UTC)

Namespace collision with Scribuntu extension for Italian language[edit]

Can you please check if you can replicate/confirm this?

PageForms extension defines the following namespaces:

SemanticForms/includes/SF_Hooks.php: defines( 'SF_NS_FORM', 106 );
SemanticForms/includes/SF_Hooks.php: defines( 'SF_NS_FORM_TALK', 107 );

The namespace translation in Italian is:

SemanticForms/languages/SF_Namespaces.php:   SF_NS_FORM           => 'Modulo',

Hence, a form named Test would correspond in italian to the article Modulo:Test rather than Form:Test.

Scribuntu extension defines the following namespaces:

Scribunto/Scribunto.php: define( 'NS_MODULE', 828 );
Scribunto/Scribunto.php: define( 'NS_MODULE_TALK', 829 );

The same extension defines the following in the Scribunto.namespaces.php configuration file:

$namespaceNames['it'] = array(
        828 => 'Modulo',
        829 => 'Discussioni_modulo',

The id of the two namespaces is different (106 vs 828) but having the same "label" for the namespace (Modulo) does not allow to create Forms (they will be parsed according to Scribuntu and expect some lua scripting code in it..).

I will eventually try to change the Scribuntu configuration using a different "label", and see if this can work around the issue.. ..can you please check this? Eventually other languages might be impacted.

thanks Mik

Ooh, that's a problem - "modulo" indeed seems to be the Italian word for both "form" and "module". I don't know if there's such a problem in any other language. I looked it up, and it seems like "formulario" is an alternate word in Italian for "form". Maybe that could just be used instead for the Page Forms namespace? Is it a common word? Yaron Koren (talk) 14:43, 16 February 2017 (UTC)

input types[edit]

Extension:Page_Forms/Input_types lists a bunch of options. Not a lot of info is given on how to use them. For example, how do I even put options into a dropdown? Can I populate them from categories or queries? I have looked at some of the wikis listed in Extension:Page Forms/Sites that use Page Forms, but what I have found is pretty generic, looks like most came from the automatic generator. Is there more documentation elsewhere? Is there a wiki that has actually made some more advanced use of these input types? Tenbergen (talk) 23:09, 16 February 2017 (UTC)

The answer to that specific question is here. Yaron Koren (talk) 03:15, 17 February 2017 (UTC)
Thanks Yaron, yes, I did find that. I was wondering about some more elaborate examples. For example, can I use a query to populate a listbox, that sort of thing. I think I just understand code better by looking at some examples. Tenbergen (talk) 17:55, 18 February 2017 (UTC)
If you're using SMW, you can basically do that with "values from concept", or, I believe, with the Semantic Forms Select extension, though I haven't tried it. I agree that more examples would be helpful. Yes, there are wikis that make advanced use of these input types. Yaron Koren (talk) 03:05, 19 February 2017 (UTC)

requirements for #rating[edit]

I'm testing the new rating input:

   | ?Rating
   | mainlabel=-
   | format=average

just prints


No stars. Am I missing any requirements? Using Page Forms 4.1 (39557fb) and Semantic MediaWiki 2.4.6 on MediaWiki 1.28.0

C Wagner (talk) 09:57, 17 February 2017 (UTC)

The #rating function isn't defined by Page Forms - that's from the Semantic Rating extension; you'll have to install that. Yaron Koren (talk) 15:50, 17 February 2017 (UTC)

Autocomplete with characters limit?[edit]

I am using Page Forms 4.1 and I have a problem with an input like this:

{{{field|review|input type=text with autocomplete|values from property:Review}}}

The values are "cut" at the end of the strings, see. I realized it is happening not only with "text with autocomplete" input type, but also with "textarea with autocomplete", "tokens" and "combobox" (I did not test with other input types).

The values are coming from here, which are all fine. So, is this a bug, or did I forget to set some configuration for character limit in autocomplete? Jaider msg 12:39, 18 February 2017 (UTC)

It should be "values from property=Review". Maybe that's the issue? I'm surprised that it works for you at all... Yaron Koren (talk) 03:06, 19 February 2017 (UTC)
Ops, true. I corrected to "values from property=Review" but the same behaviour happens. Jaider msg 12:16, 19 February 2017 (UTC)
Yes, indeed - I don't know how it worked with "values from property:", but that's another story. You can see the underlying problem here. I have no idea why this is happening, and I've never seen this kind of problem before. I'm guessing that it's some kind of database encoding issue. I don't remember if you have a coding background, but if so, you could try adding some debugging calls to getSMWPropertyValues() in /includes/PF_ValuesUtils.php, to see if you can find out where the problem is coming from. Yaron Koren (talk) 13:37, 19 February 2017 (UTC)
Unfortunately, I don't have a coding background... But, I can confirm this exactly form worked fine about one year ago. However, for testing purpose, I just have downgraded to SF 2.6 (in a MW 1.28.0 instance) and the problem still happens. So, maybe MW or SMW have something to do with that. Jaider msg 15:21, 19 February 2017 (UTC)
Ah. I wouldn't be surprised if this is an issue in SMW, one that got added in a somewhat recent version. Yaron Koren (talk) 16:54, 19 February 2017 (UTC)
I'm not of much help here, but I was wondering about that myself when seeing the same kind of hashed string in another situation sometime last year (perhaps it's the number of characters per string, or the number of separate strings that the autocomplete feature tries to load or a coding issue to do with specific characters). Cavila 13:47, 19 February 2017 (UTC)
Did it also happen with "values from property"? Yaron Koren (talk) 14:40, 19 February 2017 (UTC)
It did yeah. Cavila 21:57, 19 February 2017 (UTC)

input list links[edit]

I am trying to use a listbox to let a user chose several pages in a category. Since these are pages, it would be nice to show them as links. However, instead of

page1, page2

it saves

page1, page2

which of course just shows as a redlink. Is there a way to get it to show the choices as links? Thanks! Tenbergen (talk) 06:22, 20 February 2017 (UTC)

Yes - call #arraymap in the template; see here. Yaron Koren (talk) 14:11, 20 February 2017 (UTC)
That did it. Had seen the arraymap info on that help page before but could not make any sense of it then. Thanks again!Tenbergen (talk) 23:32, 20 February 2017 (UTC)

Associating a From Based on namespace does not work[edit]

I followed the instructions and created a page with the Name of the target namespace in the namespace number 4, which is the "Project" namespace in english default installs. But it didn't work. We are using a german install and have our own name for namespace number 4 (MW 1.27.1, 4.1 (0cce6dc), 1.3 (7f66a6f), but not using Page Schema). Any hints how to make this work?

What exactly did you do? Yaron Koren (talk) 14:02, 21 February 2017 (UTC)
I followed the instructions on the main page Extension:Page_Forms/The_"edit_with_form"_tab#Based on namespace: I installed Page Forms and Cargo, set up the namespace X: in LocalSettings.php, created a Form 'X' and created a Page 'X' in the 'Project' namespace, which is identified by namespace id 4. On this page I added
That does sound like it should work... so for pages with a name like "X:pagename", no "Edit with form" tab shows up? And have you gotten "Edit with form" to show up in any other way? Yaron Koren (talk) 14:17, 21 February 2017 (UTC)
I found out: It now works on our real install where we acces the Pages with /wiki/PAGENAME but it does not work on the test install, where we access the Pages with /mediawiki/index.php?title=PAGENAME. There we did not set $wgArticlePath in LocalSettings.php. Maybe this gives a hint what went wrong.
I can't think of why that would cause the problem... is there any other difference between the two wikis? Yaron Koren (talk) 14:36, 22 February 2017 (UTC)