Extension talk:Page Forms/Archive January to February 2018

Hi, I'm having a

"It appears that your browser does not support Unicode. It is required to edit pages, so your edit was not saved. " 

error when trying to use autoedit and formredlink. Specific correction for MW 1.30 in PF_FormPrinter.php only solved gui form editing error. Standard page edition with text including formredlink with "create page" option doesn't even save content. Please help! Steph.

Possible Solution

I too was seeing that error message with an autoedit, but it had nothing to do with what the actual problem was. The problem for me was that the target page did not already exist. If I make certain that the target page exists before clicking the autoedit, I do not get the error. Sounds like a bug to me.

hi, Same for me, but it is new behaviour: autoedit used to create page on the fly, which was very effective. And since the disappearance of "create pages with form", and exception raised by formredlink+create page, it leaves me with no automatic page creation capability. Steph.
Downgrading to 1.29 solved all problems. Steph.

Multi Instance fields - parser functions only parse once.

Mediawiki 1.29
I have an uploadable field in a multiple template which I would like to auto-generate filenames to ensure they are unique.
I thought using the page name with a timestamp would be simple enough, but the timestamp doesn't update when you "Add Another".

{{{field|StepImage|uploadable|image preview|fancybox|default filename={{#titleparts: {{FULLPAGENAME}} | 1 | 1 }}-{{#titleparts: {{FULLPAGENAME}} | 1 | 2 }}-PackStep-{{#time: U | now }}.jpg }}}

I have also tried:

{{{field|StepImage|uploadable|image preview|fancybox|default filename={{#titleparts: {{FULLPAGENAME}} | 1 | 1 }}-{{#titleparts: {{FULLPAGENAME}} | 1 | 2 }}-PackStep-{{#vardefine: pvCounter | {{#expr: {{#var: pvCounter}} + 1 }} }}{{#var: pvCounter}}.jpg }}}

Similar results except that it does increment once. First filename gets a 1. When I "Add Another" the filename there gets a 2, and all added after that remain 2.
Is there a way to ensure each uploaded file is unique regardless of the incoming filename. I thought this approach should work, but clearly I'm missing something.
Thanks. Paul

I'm aware of the issues resulting from multiple-instance templates only being parsed once, and I don't know of a solution for them, unfortunately. Yaron Koren (talk) 03:02, 3 January 2018 (UTC)Reply

Is there another way to do what I'm trying to do? A way to generate unique filenames in a multiple-instance template?
Any workaround suggestions are welcome. Thx.

(SOLVED) Upload file field gives blank page

Hi Yaron, I'm running MW 1.30 (http://csdms.colorado.edu/wiki/Special:Version) using your PageForms (latest version). It operates great with Cargo and Sementic Mediawiki except for the 'Upload file' function. It was working well running MW1.29 with an older PageForms version but after updating I get a blank page as soon as I try to upload a file, see screenshot.

 

.

Any idea what might cause that? Happy new year, --Albert Ke (talk) 17:34, 3 January 2018 (UTC)Reply
Ps.1 File upload function MediaWiki provides standard works fine.
Ps.2 Same result when using chrome or Safari

Please see this page for how to get error messages, instead of blank pages, to be displayed. Yaron Koren (talk) 02:25, 4 January 2018 (UTC)Reply
Thank you Yaron, and good point, but I have the 'get error messages print to screen' always on using last lines in LocalSetting.php:
error_reporting( E_ALL );
ini_set( 'display_errors', 1 );
And I wish there where but no error message shows up, also not in the web log files. Any idea / hint more than welcome!

--Albert Ke (talk) 19:37, 4 January 2018 (UTC)Reply

Oh, okay. Does the JavaScript console in the browser show any errors? Yaron Koren (talk) 22:39, 4 January 2018 (UTC)Reply
Never mind - I was able to reproduce this problem. It's a JS bug due to the jump in the jQuery version, to 3.0, in MW 1.30. I just checked in a fix for this, so if you get the very latest code, the problem should go away. Yaron Koren (talk) 04:08, 5 January 2018 (UTC)Reply
Awesome, thank you for the quick fix Yaron! Problem solved with the latest fix. Much appreciated! --Albert Ke (talk) 14:46, 5 January 2018 (UTC)Reply

Multi Instance Forms Within Form Not Working

I had updated PageForms the other day via git and didn't notice any issues, but I was reported that the buttons to create a multi instance form do not bring up the form. If an instance already exists it shows up but can't add. I updated to mediawiki 1.30 just in case it was a version mismatch issue and the problem persists. Page with the Form, the Form --Cody3647 (talk) 22:42, 12 January 2018 (UTC)Reply

The fact that this is a public wiki makes debugging a lot easier. Clearly this is a JavaScript problem. Your form appears to have two JS errors, either of which may be blocking the "Add another" button from working:
I would try removing "editor=wikieditor" from the form, and if that doesn't fix the problem, simplifying MediaWiki:Common.js. If neither of those fixes the problem, let me know. Yaron Koren (talk) 23:29, 12 January 2018 (UTC)Reply
Removing the wikieditor worked, though I do like having it. And I fixed the other error as well. --Cody3647 (talk) 01:10, 13 January 2018 (UTC)Reply

input type "tokens" no longer working

After the update to 4.2.1 the input type tokens is no longer working on a MW 1.27.4. After rolling back to 4.2.0 things a fine again. --[[kgh]] (talk) 20:51, 24 January 2018 (UTC)Reply

I'm guessing that this is actually an unrelated JavaScript error. If you look in the browser console, do you see any error messages? Yaron Koren (talk) 22:03, 24 January 2018 (UTC)Reply
Just had a look at console:
Exception in module-execute in module ext.pageforms.main:
load.php:178:411
TypeError: func is undefined 
TypeError: func is undefined
Stack trace
getFunctionFromName@https://example.org/w/load.php?debug=false&lang=en&modules=ext.Lingo.Scripts%7Cext.echo.api%2Cinit%7Cext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2CUri%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cskins.foreground.js%2Cmodernizr%7Cuser.defaults&skin=foreground&version=f6f4492ae581:128:439
@https://example.org/w/load.php?debug=false&lang=en&modules=ext.Lingo.Scripts%7Cext.echo.api%2Cinit%7Cext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2CUri%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cskins.foreground.js%2Cmodernizr%7Cuser.defaults&skin=foreground&version=f6f4492ae581:128:765
fire@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:45:104
add@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:45:656
jQuery.fn.ready@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:49:40
@https://example.org/w/load.php?debug=false&lang=en&modules=ext.Lingo.Scripts%7Cext.echo.api%2Cinit%7Cext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2CUri%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cskins.foreground.js%2Cmodernizr%7Cuser.defaults&skin=foreground&version=f6f4492ae581:128:238
@https://example.org/w/load.php?debug=false&lang=en&modules=ext.Lingo.Scripts%7Cext.echo.api%2Cinit%7Cext.headertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2CUri%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cskins.foreground.js%2Cmodernizr%7Cuser.defaults&skin=foreground&version=f6f4492ae581:100:104
runScript/<@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:163:74
fire@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:45:104
add@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:45:656
always@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:46:865
runScript@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:162:944
checkCssHandles@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:163:774
cssHandle/<@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:163:904
fire@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:45:104
fireWith@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:46:431
fire@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:46:474
fireCallbacks@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:157:607
addEmbeddedCSS@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:158:681
addEmbeddedCSS/cssBufferTimer<@https://example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=foreground&version=HCxTBC9n:157:832
load.php:178:449

I hope this helps debugging. Cheers --[[kgh]] (talk) 22:21, 24 January 2018 (UTC)Reply

Hm, somewhat. Does the problem with "tokens" go away if you disable the Lingo extension, or if you switch from the Foreground skin to Vector? If neither of those fixes the problem, could you add "?debug=true" to the page and let me know what the error message is? Yaron Koren (talk) 22:29, 24 January 2018 (UTC)Reply
Disabling Lingo and Semantic Glossary does not change a thing, neither does using Vector. When adding "&debug=true" I am getting
https://example.org/w/vendor/onoi/shared-resources/res/jquery.qtip/extended/jquery.qtip.js?18428".
--[[kgh]] (talk) 22:47, 24 January 2018 (UTC)Reply
Alright. What's the full error message? Yaron Koren (talk) 23:17, 24 January 2018 (UTC)Reply
That's all I get in error console. :( --[[kgh]] (talk) 23:21, 24 January 2018 (UTC)Reply
Adding "debug=true" to the URL made the error message go from 10 lines to a single URL? Yaron Koren (talk) 23:38, 24 January 2018 (UTC)Reply
Affirmative and as stupid it may sound. --[[kgh]] (talk) 09:58, 25 January 2018 (UTC) PS That's how I constructed the call to the page: https://example.org/w/index.php?title=PageName&action=formedit&debug=true Turning error reporting on in "LocalSettings.php" does not help either.Reply
Alright. I probably should have asked this before, but: with "debug=true" in the URL, does the original problem still happen? My guess is no, given that there's no actual error message any more. Yaron Koren (talk) 15:04, 25 January 2018 (UTC)Reply
The issue is still there. No tokens. I have no idea why console remains silent. --[[kgh]] (talk) 23:49, 25 January 2018 (UTC)Reply

That's strange, okay. If you temporarily disable all the extensions except for Page Forms, is the problem still there? Yaron Koren (talk) 23:59, 25 January 2018 (UTC)Reply

I did not see your post till yesterday since I was busy with other stuff. If I just use PageForm it works so I disabled possible candidats and pinned down the WikiEditor extension as the one causing input type tokens to fail. Cheers --[[kgh]] (talk) 17:28, 8 February 2018 (UTC) PS I have been told that input type "datepicker" is affected, too. On the respective wikis I rolled back to 4.1.2 to restore these features.Reply
Ah, WikiEditor - great find. So it's the same issue as the question above this, more or less. I'll have to look into why WikiEditor handling broke. Yaron Koren (talk) 19:03, 8 February 2018 (UTC)Reply
Indeed, my first suspect was MobileFrontend, the second one was HeaderTabs and the third one WikiEditor was it in the end. The error console was completely empty. :| --[[kgh]] (talk) 20:14, 8 February 2018 (UTC)Reply
I have seen tokens not displayed because of the extension Extension:FancyBoxThumbs Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk)

This is on and off creating issues even with earlier versions, too. I migrated away from tokens. Hopefully it will be a stable feature at some point. --[[kgh]] (talk) 12:13, 3 March 2018 (UTC)Reply

I'm not aware of any issues with tokens - other than a Firefox-only problem that was fixed about a month ago. So I assume again that this is some unrelated JS issue. Yaron Koren (talk) 19:59, 6 March 2018 (UTC)Reply
I get mails about tokens not working pretty frequently. However if I test it always works. I suspect some clients failing to interact with tokens. Probably I should start asking for acesss information. Moreover it does no longer work in the recent version which killed this input type completely. :( Keeping fingers crossed for a fix. --[[kgh]] (talk) 21:01, 7 March 2018 (UTC)Reply
Well, I can't fix a problem I'm not aware of, and I don't know what this problem you're talking about is. But maybe someone else will fix it, whatever it is. Yaron Koren (talk) 22:58, 7 March 2018 (UTC)Reply
That's true. With fixing stuff I meant the real big issue in conjunction with WikiEditor. The rest is currently not a big concern I guess. --[[kgh]] (talk) 23:14, 7 March 2018 (UTC)Reply
Oh, okay. Yaron Koren (talk) 02:48, 8 March 2018 (UTC)Reply

Sorry for jumping in like that but I get the same exact error message. I can not reproduce the error with debug=true. For me it looks like a timing issue. I would appreciate if anybody could help figuring this out. --Mojoaxel (talk) 14:48, 16 March 2018 (UTC)Reply

Are you using the latest version, 4.3? If not, I would recommend upgrading - this issue might have been fixed. Yaron Koren (talk) 14:50, 16 March 2018 (UTC)Reply

About "formredlink"_parser_function

This is still happening in 4.2.0 and 4.2.1 which is a pretty big issue since I have to remove superflous content from many pages. I am using the following syntax to create the page:

{{#arraymap: {{{keyword|}}} |; |@@@@ |{{#formredlink:target=Glossary:@@@@ |form=GlossaryPage |create page }} }}

On the glossary page created not only the {{GlossaryPage}} template gets added but also the whole content of the originating page. Sometimes I have up to 6 edits creating the missing page. In the following example I got 3 edits:

Jobs executed
2018-01-24 22:07:55 SMW\FulltextSearchTableUpdateJob Glossary:Plexus slot:id=dermosco_mw378-mwyv_:smw:diff:284fb9a5c27f200720efe2f46f36980f requestId=WmkDpCU87d0AALiveukAAAAP (id=32921,timestamp=20180124220737) STARTING
2018-01-24 22:07:55 SMW\FulltextSearchTableUpdateJob Glossary:Plexus slot:id=dermosco_mw378-mwyv_:smw:diff:284fb9a5c27f200720efe2f46f36980f requestId=WmkDpCU87d0AALiveukAAAAP (id=32921,timestamp=20180124220737) t=84 good
2018-01-24 22:07:55 htmlCacheUpdate Philosopy_of_Dermoscopedia table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=72a4525c6a67e807fa435b7a9c51613d02bdf118 rootJobTimestamp=20180124220734 requestId=WmkDpCU87d0AALiveukAAAAP (id=32914,timestamp=20180124220734) STARTING
2018-01-24 22:07:55 htmlCacheUpdate Philosopy_of_Dermoscopedia table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=72a4525c6a67e807fa435b7a9c51613d02bdf118 rootJobTimestamp=20180124220734 requestId=WmkDpCU87d0AALiveukAAAAP (id=32914,timestamp=20180124220734) t=2 good
2018-01-24 22:07:55 SMW\ParserCachePurgeJob Glossary:Plexus idlist=[70348,31] requestId=WmkDpCU87d0AALiveukAAAAP (id=32923,timestamp=20180124220737) STARTING
2018-01-24 22:07:55 SMW\ParserCachePurgeJob Glossary:Plexus idlist=[70348,31] requestId=WmkDpCU87d0AALiveukAAAAP (id=32923,timestamp=20180124220737) t=18 good
2018-01-24 22:07:55 htmlCacheUpdate Glossary:Plexus table=pagelinks recursive=1 rootJobIsSelf=1 rootJobSignature=6412e9bfe867c39e9721b6311cb5fbfef0f4f4cd rootJobTimestamp=20180124220737 requestId=WmkDpCU87d0AALiveukAAAAP (id=32922,timestamp=20180124220737) STARTING
2018-01-24 22:07:55 htmlCacheUpdate Glossary:Plexus table=pagelinks recursive=1 rootJobIsSelf=1 rootJobSignature=6412e9bfe867c39e9721b6311cb5fbfef0f4f4cd rootJobTimestamp=20180124220737 requestId=WmkDpCU87d0AALiveukAAAAP (id=32922,timestamp=20180124220737) t=1 good
2018-01-24 22:07:55 SMW\ParserCachePurgeJob Glossary:Plexus idlist=array(32) requestId=WmkDpCU87d0AALiveukAAAAP (id=32920,timestamp=20180124220737) STARTING
2018-01-24 22:07:55 SMW\ParserCachePurgeJob Glossary:Plexus idlist=array(32) requestId=WmkDpCU87d0AALiveukAAAAP (id=32920,timestamp=20180124220737) t=375 good
2018-01-24 22:07:55 createPage Glossary:Plexus user_id=8 page_text={{GlossaryPage}}
 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32916,timestamp=20180124220736) STARTING
2018-01-24 22:07:56 createPage Glossary:Plexus user_id=8 page_text={{GlossaryPage}}
 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32916,timestamp=20180124220736) t=403 good
2018-01-24 22:07:56 createPage Glossary:Plexus user_id=8 page_text=string(2063) requestId=WmkDpCU87d0AALiveukAAAAP (id=32915,timestamp=20180124220735) STARTING
2018-01-24 22:07:56 createPage Glossary:Plexus user_id=8 page_text=string(2063) requestId=WmkDpCU87d0AALiveukAAAAP (id=32915,timestamp=20180124220735) t=349 good
2018-01-24 22:07:56 EchoNotificationDeleteJob Glossary:Main_Page userIds={"4":4} requestId=WmkDpCU87d0AALiveukAAAAP (id=32918,timestamp=20180124220737) STARTING
2018-01-24 22:07:56 EchoNotificationDeleteJob Glossary:Main_Page userIds={"4":4} requestId=WmkDpCU87d0AALiveukAAAAP (id=32918,timestamp=20180124220737) t=4 good
2018-01-24 22:07:56 EchoNotificationDeleteJob Main_Page userIds={"1":1} requestId=WmkDpCU87d0AALiveukAAAAP (id=32917,timestamp=20180124220737) STARTING
2018-01-24 22:07:56 EchoNotificationDeleteJob Main_Page userIds={"1":1} requestId=WmkDpCU87d0AALiveukAAAAP (id=32917,timestamp=20180124220737) t=3 good
2018-01-24 22:07:56 recentChangesUpdate Special:RecentChanges type=cacheUpdate requestId=WmkDpCU87d0AALiveukAAAAP (id=32912,timestamp=20180124220734) STARTING
2018-01-24 22:07:56 recentChangesUpdate Special:RecentChanges type=cacheUpdate requestId=WmkDpCU87d0AALiveukAAAAP (id=32912,timestamp=20180124220734) t=8 good
2018-01-24 22:07:56 htmlCacheUpdate Glossary:Plexus table=templatelinks recursive=1 rootJobIsSelf=1 rootJobSignature=aa9f6358d1b69664c494107ce0e4e37378d32811 rootJobTimestamp=20180124220756 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32924,timestamp=20180124220756) STARTING
2018-01-24 22:07:56 htmlCacheUpdate Glossary:Plexus table=templatelinks recursive=1 rootJobIsSelf=1 rootJobSignature=aa9f6358d1b69664c494107ce0e4e37378d32811 rootJobTimestamp=20180124220756 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32924,timestamp=20180124220756) t=0 good
2018-01-24 22:07:56 EchoNotificationDeleteJob Glossary:Index userIds={"4":4} requestId=WmkDpCU87d0AALiveukAAAAP (id=32919,timestamp=20180124220737) STARTING
2018-01-24 22:07:56 EchoNotificationDeleteJob Glossary:Index userIds={"4":4} requestId=WmkDpCU87d0AALiveukAAAAP (id=32919,timestamp=20180124220737) t=0 good
2018-01-24 22:07:56 htmlCacheUpdate Glossary:Plexus table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=e2993cc4660e5b3ca1a28d4af54b235b5ea28e56 rootJobTimestamp=20180124220756 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32925,timestamp=20180124220756) STARTING
2018-01-24 22:07:56 htmlCacheUpdate Glossary:Plexus table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=e2993cc4660e5b3ca1a28d4af54b235b5ea28e56 rootJobTimestamp=20180124220756 requestId=WmkDpyU87d0AABPX2-wAAAAA (id=32925,timestamp=20180124220756) t=1 good
Respective revision history
	N b  00:07  	Plexus‎‎ (3 changes | history) . . (+2,040)‎ . . [AutoCreateBot‎ (3×)]
	  b   	00:07 (cur | prev) . . (+2,024)‎ . . AutoCreateBot (talk | contribs | block)
	  b   	00:07 (cur | prev) . . (-2,024)‎ . . AutoCreateBot (talk | contribs | block)
	N b   	00:07 (cur | prev) . . (+2,040)‎ . . AutoCreateBot (talk | contribs | block)

Cheers --[[kgh]] (talk) 22:16, 24 January 2018 (UTC)Reply

This is an extremly nasty bug. I apprechiate any effort to fix this parser function. Thumbs up and a big cheer up! Cheers --[[kgh]] (talk) 17:30, 8 February 2018 (UTC)Reply
I think the reason is that the form that adds the template contains a field of input type textarea which probably leads it to believe that someing must automatically be added. The superfluous text however is not added within the template but below it where one usually places the free text field. In this case there is however not free text field. The field within the form looks like
{{{field|description|input type=textarea|editor=wikieditor|rows=3|autogrow|placeholder=Try to use a maximum of 160 characters to describe this glossary term.}}}
This is a pretty bad situation, so a fix will be appreciated a lot. Thanks and cheers --[[kgh]] (talk) 10:00, 28 February 2018 (UTC)Reply
Could this be another WikiEditor-related issue? Yaron Koren (talk) 16:58, 28 February 2018 (UTC)Reply
Perhaps though this issue is there for over a year. Also I would expect the superfluous text to appear in the respective field and not below the inserted template. I will have to test this. --[[kgh]] (talk) 12:11, 3 March 2018 (UTC)Reply

Page Forms input type=tree

MediaWiki	1.30.0
PHP	7.1.8 (apache2handler)
Semantic MediaWiki	2.5.6
Page Forms	4.2.1 (624f2a9) 18:20, 16 January 2018
I'm having issues with input type=tree instead of a pick list I'm getting bullet list.
Tokens are not working either
Thanks, Phil
Page Forms	4.1.2 (624f2a9) 18:20, 16 January 2018 : Works fine
I think you're seeing the same problem kgh reported, above. Yaron Koren (talk) 15:05, 25 January 2018 (UTC)Reply
I think so as well but the debug does not show anything.
Phil
Is there going to be a fix for this issue?
Thanks, Phil.
I'm guessing that this is a WikiEditor issue - and if you uninstall that extension, the error goes away. Is that true? Yaron Koren (talk) 21:29, 26 February 2018 (UTC)Reply


Yes that is true. If we will no longer be able to use WikiEditor, How can I add a custom toolbar to the PageForm?
-- Legaulph (talk) 12:53, 27 February 2018 (UTC)Reply
Good to know, and I don't know. But I hope to get WikiEditor working again soon. Yaron Koren (talk) 17:00, 27 February 2018 (UTC)Reply
Thank you
-- Legaulph (talk) 19:43, 27 February 2018 (UTC)Reply

#forminput: Restrict list of forms

Hi,


I'm using #forminput for providing a form to create new pages. I want the user to choose from a list of available forms. However, I have a number of query forms in my wiki that I don't want to show up in the list of available forms for content creation. AFAIU, the current syntax neither allows for defining a fixed list of available forms nor restricting the kind of form to be shown to the user:


form= - the name of the PF form to be used; if it is left empty, a dropdown will appear, letting the user choose among all existing forms

Is there a workaround for this problem? I'd like to have something similar as "autocomplete on category=".

Best regards, Frank

Nakohdo (talk) 12:38, 30 January 2018 (UTC)Reply

I'm hoping to add in a feature soon that would allow "form=" to take in a list of values, which would manually populate a dropdown - would that be good enough for you? Yaron Koren (talk) 14:11, 30 January 2018 (UTC)Reply
Hi Yaron, Thanks for the quick reply. And yes, allowing to pass a list to the "form=" parameter would be perfect. Nakohdo (talk) 08:29, 2 February 2018 (UTC)Reply
This is now done, in the latest code. Yaron Koren (talk) 20:56, 20 February 2018 (UTC)Reply

(SOLVED) Issue with combobox, using Firefox browser

Hi Yaron, all,

It looks like there might be an issue, using input type "combobox" in a PageForm in combination with the browser 'Firefox' (chrome, safari work fine). The combobox comes with suggestions when start typing but when selecting a suggestion, it doesn't close the drop list. It does populate the field but then the drop list stays open, blocking the fields below and the rest of the form becomes unresponsive and you have to close the browser to get out of it.

This behavior occurs on forms that have been around for years, and was indicated by users of our website and I was able to recreate the problem (see image) using the latest firefox version. Seems to start occurring after MW & extensions update.

Any idea how to solve this? Thanks, --Albert Ke (talk) 16:26, 31 January 2018 (UTC)Reply

 

Site configuration:

Hi Albert - yes, I see the problem too. It's been a long time since I last did any MediaWiki testing with Firefox. Do you know what versions of MediaWiki and Page Forms you were doing before the upgrade? And could the issue be recent changes to Firefox browser? I know they just had a big release (version 58, about a week ago) that included a lot of changes. Or is it definitely due to the MW upgrade? Yaron Koren (talk) 19:34, 31 January 2018 (UTC)Reply
Yep, Firefox isn't my favorite browser either. Looks like older Firefox versions have the same problem, I still have version 22 on an old mac and that gives the same problem (see figure). For earlier versions of MW, PF, etc: MW 1.29.latest release (not sure what that was); SMW: 2.5.4; PF, 2.4.0 (installed late December).
 
PF 2.4.0? Are you sure about that? That's from 2012. Yaron Koren (talk) 21:55, 31 January 2018 (UTC)Reply
Ooops, numbers switched around, PF 4.2.0. Thanks, --128.138.65.73 15:40, 1 February 2018 (UTC)Reply
Great, that helped a lot in narrowing it down. The problem turned out to be a code change I made in November. I just checked in a fix for this, which you can see here. Yaron Koren (talk) 17:31, 1 February 2018 (UTC)Reply
Thank you Yaron!; I checked out the new version and the combobox issue is solved for firefox. Thank you so much for the prompt fix! --Albert Ke (talk) 20:36, 1 February 2018 (UTC)Reply

#default_form not working properly

This topic is a continuation of one from December. When creating a new page that has a default_form, I would expect edit-with-form to know, which form it is right away. But it isn't. When clicking I get the "menu" of all available forms in my wiki. The root cause lies in the created jobs that are not yet executed. After creating the page showJobs shows this;

htmlCacheUpdate: 1 queued; 0 claimed (0 active, 0 abandoned); 0 delayed
recentChangesUpdate: 1 queued; 0 claimed (0 active, 0 abandoned); 0 delayed
refreshLinksPrioritized: 1 queued; 0 claimed (0 active, 0 abandoned); 0 delayed

After running the "refreshLinksPrioritized" job and clicking on the edit-with-form link the right form will open.

Unfortunately it does not matter whether the default-form is defined

  • in the page itself
  • in a template called by the page
  • for the page's category

This issues started to happen after we moved from MW 1.23 to MW.1.27.

@Yaron, do you think it is possible to fix this in PageForms at all or are we stuck with this (due to MW's jobs design).

Thanks Emwiemaikel (talk) 09:18, 2 February 2018 (UTC)Reply

I'm rather surprised that putting #default_form in a page and in a category page (your 1st and 3rd options) now require a job in order to work. But given that, I don't know if anything can be done in the Page Forms code to change the situation. Yaron Koren (talk) 00:06, 5 February 2018 (UTC)Reply

Forms to create spreadsheet like pages

I don't know if this is possible, but I would like to create a form to generate pages similar to spreadsheet. E.g. I want to describe the workflow of a digitization of a book; the page generated by the form will be the name of the book; this page should contain a table in which each column header is a property and all the values listed in the columns are property values. Each row should be generated by a form. E.g. the book Alice in wonderland is composed by 10 pages; I want to add information such as 'Name' (property type: Page), 'Digitization' (property type: Boolean (this is a yes/no field), Uploaded (property type: Boolean (this is a yes/no field), Metadata (property type: Boolean (this is a yes/no field) for all the pages, that is something like the following:

Name Digitization Uploaded Metadata
1
 
 
 
2
 
 
 
3
 
 
 

I read something about a Spreadsheet-style_editing but it is not very clear how it works. I could do this using wikitable (like in the example) but it is too difficult and not 'semantic' at all. Any ideas? Thanks!

Yes, you should use spreadsheet-style editing. The first step is to create two templates, one for "Book" and one for "Page" (unless you have them already). Given that you are using SMW, within the "Page" template you need to call #subobject for all the properties, instead of just using regular property tags. Then, to create the form, you need to make "Page" a multiple-instance template, and add "|display=spreadsheet" to the "for template" tag. Getting all the data to look nice on the resulting page is another story, but first things first. Yaron Koren (talk) 14:32, 8 February 2018 (UTC)Reply
Hi Yaron, thanks for your answer. I guess I am almost there, but there is problem with the subojects call. In the "Page" template should I have as many subobjects as properties or a unique subobject call? E.g. something like this
{{#subobject:PageWorkflow

|Name={{{Name|}}} |Leaf={{{Leaf|}}} |Digitization={{{Digitization|}}}

}}

or something like this

{{#subobject:Name
|Name={{{Name|}}}}}
{{#subobject:Leaf 
|Leaf={{{Leaf|}}}}}
{{#subobject:Digitization
|Digitization={{{Digitization|}}}}}

Or any of those?

Thanks, Loman87 (talk) 17:45, 9 February 2018 (UTC)Reply

The former - one #subobject call. Yaron Koren (talk) 19:29, 9 February 2018 (UTC)Reply
Sorry to bother you, but I have still an issue. The form seems ok and the spreadsheet is perfect for my need. Anyway after I have filled the 'Book' form and the 'Page' spreadsheet form, the data of latter is not saved (nor displayed on the page, nor using the browse properties tool). So, I guess, there is still something wrong with the template containing the subobject call. Other than the subobject call, does the template have to host something else? Thanks for your patience...Loman87 (talk) 15:31, 10 February 2018 (UTC)Reply
I think the issue is that #subobject is being called with a name - personally, I'm not even really sure why they made that an option. Instead, you should make it nameless, by having the call look like "{{#subobject:-|Name=...|Leaf=...". Yaron Koren (talk) 02:31, 12 February 2018 (UTC)Reply
Still not working, I guess I am giving up :( Thanks for your help Yaron. One last question: is it possible to do the same stuff using Cargo? -- Loman87 (talk) 10:12, 12 February 2018 (UTC)Reply
Adding an unnamed subobject will be {{#subobject:| and not {{#subobject:-| --[[kgh]] (talk) 12:22, 12 February 2018 (UTC)Reply
Sorry, my mistake. Kghbln - thanks for the correction. But yes, this can be done with Cargo too. Yaron Koren (talk) 14:39, 12 February 2018 (UTC)Reply
Thank you both for your help! Anyway I guess there is an issue with the spreadsheet format, since if I do not use it everything works fine. If used, data added to the spreadsheet are not saved. --Loman87 (talk) 13:48, 16 February 2018 (UTC)Reply

Oh... you meant that, when you use a spreadsheet display, the templates themselves are not saved on the page? Yaron Koren (talk) 16:52, 16 February 2018 (UTC)Reply

Yes, I meant that. Loman87 (talk) 07:51, 19 February 2018 (UTC)Reply
Oh - from your previous description, I thought the problem was with data storage, not wikitext creation. If possible, could you pastebin the form definition with "display=spreadsheet" (that's all that's needed), and link to it here? Also, what version of Page Forms are you using? Yaron Koren (talk) 23:44, 19 February 2018 (UTC)Reply
Sorry Yaron, I am not a specialist so, since I didn't see neither anything saved in a wiki-table nor in the SMW properties, I thought the problem was related to data creation. Anyway, you can look at the form definition here and at the templates called here and here. In my last attempt to suceed, I finally used Cargo for the template creation (but also this doesn't work: from here my guess that something goes wrong with the spreadsheet format). My MW version is 1.27.4 and PageForms 4.2.1. Thanks for your help! Loman87 (talk) 08:06, 20 February 2018 (UTC)Reply
Oh, I didn't know this was a public wiki. Would it be possible to get a user account on this wiki? That would make debugging a lot easier. If you make yaron57@gmail.com the account email address, I can set the password, etc. Yaron Koren (talk) 16:20, 20 February 2018 (UTC)Reply
Just did it. Thanks again for your help! Loman87 (talk) 17:00, 20 February 2018 (UTC)Reply
Yes, thank you. For me, the form seems to work fine - I didn't save any pages, but I can see what the output would be with the page preview. Could it be that you're just not pressing "+" after filling out a row? The spreadsheet interface is a little confusing, in that the top row is just an "adder", that's used to add actual rows below. Yaron Koren (talk) 17:49, 20 February 2018 (UTC)Reply
Ok, I am feeling dumb...I guess the 'issue' was exactly that one. Sorry for bothering you for so long and thanks for your patience! Loman87 (talk) 15:30, 21 February 2018 (UTC)Reply

Okay, cool. It's not really your fault - there's some less-than-ideal interface design in the jsGrid library, which is what's being used. I should look into this at some point - it could be that just changing around some of the colors, or adding more text, could make things clearer. Yaron Koren (talk) 19:07, 21 February 2018 (UTC)Reply

Datepicker regression

In the past I was able to use datepicker unmodified. We either enter dates in iso-date format e.g. 2018-02-10 or in german format e.g. 10.02.2018. Now datepicker creates us format 10/02/2018 and what is worse the results do not show up in the properties any more so we lose all information for date fields if we use datepicker. So it looks like we are forced to do according to: https://www.mediawiki.org/wiki/Extension:Page_Forms/Input_types/Datepicker#Customization

# https://www.mediawiki.org/wiki/Extension_talk:Page_Forms#Datepicker_regression
$wgPageFormsDatePickerSettings['DateFormat'] = 'yy-mm-dd';

I'd prefer if ISO Dates would work out of the box at least when typed in. also

yyyy-mm-dd

did not work as expected - the 4 digit year would show twice! --WolfgangFahl (talk) 08:50, 10 February 2018 (UTC)Reply

Unable to save page using form

MediaWiki 1.30.0
PHP 7.1.8 (apache2handler)
Semantic MediaWiki 2.5.5
Page Forms 4.1.2
Try to save page using the form does not close out of edit nor does it save the page.
Using 4.2.1 has other issues.
I enabled debugging and there where no errors
I would try upgrading to the latest version. Yaron Koren (talk) 18:50, 12 February 2018 (UTC)Reply
I did use 4.2.1 had a typo above. I ran into issues with tokens. I'm testing again. (Phil)
I tested 4.2.1 and disabled WikiEditor 0.5.1
input type=tree and tokens work as well as saving the page. (Phil)

PF - Mandatory fields - HeaderTabs - issue: Empty field error gets hidden in tabs

Hi Yaron, all,

Not really a bug or anything but hoping to get some advise. When using mandatory fields in a form that uses the HeaderTabs extension and people forget to fill out a mandatory field on a previous tab, the form cannot be saved but the user doesn't see the error message in red next to the field "cannot be blank" either, as it is on a different tab than the save button.
Is there any work around for that? For example, is it possible to get that error message next to the save button so the user knows he/she has to go back some tabs to find the empty field. Or would something like the "save and continue" option specified at the end of each tab be an option?

Thanks, --Albert Ke (talk) 18:07, 14 February 2018 (UTC)Reply

I've seen that problem too - I don't know what a good solution is. Making the relevant tab(s) red, maybe? I don't know if adding "save and continue" buttons everywhere would be a good solution - it's worth a try. Yaron Koren (talk) 03:11, 15 February 2018 (UTC)Reply
I'll try the "save and continue" button in the coming days, see if that works. Other webforms sometimes have their 'save/submit' button grayed out as long as not all required fields are filled out. I'm not sure if that is easy to add to the code. When constructing a form, I can add text next to it, saying something like: 'make sure to fill out all required fields'. Probably that would mean that the 'save' button needs to check continuously if all requirements (mandatory fields) are met. Not sure if that is possible with the current structure of your code. Thanks, --Albert Ke (talk) 15:53, 15 February 2018 (UTC)Reply
Return to "Page Forms/Archive January to February 2018" page.