Extension talk:Page Forms/Archive January 2017

Improving doLookup() function

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

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

• Example of not working based on Namespace: I have a form to announce meetings:
  • http://csdms.colorado.edu/wiki/Form:Submit_meeting_of_interest
• It creates a page that than cannot be edited using 'Edit with Tab':
  • http://csdms.colorado.edu/wiki/MeetingOfInterest:Meeting-207
• However, what form to use for the namespace is defined in:
  • http://csdms.colorado.edu/wiki/csdms:MeetingOfInterest

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)

regexp

Hi,

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

Regards,

Mark

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

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)

Notes:
* 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

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

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:

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
Backtrace:

#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

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>
</table>
{{{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

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?

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.

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)

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

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

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.

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?

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?

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

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

Hi,

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

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)