Extension talk:Page Forms/Archive January to March 2020

Modifying pages automatically vs Linking to forms

Hello, everybody,
I've got a little puzzle to solve and I can't figure it out...
This one works:
{{#autoedit:form=HandBook
|link text=Add this tune to your Tune Book
|link type=button
|query string=HandBook[2][f_track]=Keel_Row_(The)&HandBook[2][f_abc_section]=abc
}}


while this one doesn't:
{{#formlink:form=HandBook
|link text=Add this tune to your Tune Book
|link type=button
|query string=HandBook[2][f_track]=Keel_Row_(The)&HandBook[2][f_abc_section]=abc
|popup
}}

The HandBook form uses:
for template|HandBook|label=Tune Book|multiple

Is it the popup parameter the problem here?

What am I doing wrong?

Silkwood 19:30, 05 March 2020 (UTC)

Hi - I'm sorry for the long delay. I just tried this, and the multiple-instance template query string works for me in #formlink, even with the "popup" parameter. Could the underscores in the query string be the problem? I would try changing them all to spaces, and see if that improves things. Yaron Koren (talk) 15:58, 19 March 2020 (UTC)

Thank you, Yaron, I think I understood that the problem lies in the HandBook form with which I can't properly manage the creation of the title of an article. Let me explain: if the target page exists both #autoedit and #formlink work correctly but if I have to create the page, then only #autoedit works, and this is the problem I don't understand. The purpose of all this is to allow users to create, if it doesn't already exist, a personal Tunebook in which to collect their favorite tunes by clicking on a button next to the score. Silkwood 10:08, 26 March 2020 (UTC)

Are you sure it's not the other way around? With #formlink, you can only modify the fields through the query string if you're creating a new page - if you're editing an existing page, the query string does nothing. Yaron Koren (talk) 16:55, 26 March 2020 (UTC)

You're right! Silkwood 18:46, 3 april 2020 (UTC)

Save and Continue Bug?

I'm fixing a form for someone and the complaint is duplication of multiple-instance Template which I have tracked down to 'Save and Continue' when editing. If a user is editing and uses the 'Save and Continue' button for a change to a multiple-instance Template item, it creates a duplicate entry of the item. If a user just clicks the 'Save' button, no duplication occurs.

I don't know if this is related to this bug, Phabricator T208610 (Save-And-Continue not fully supported by Multi-Instance-Templates). The site is using the almost latest Pageforms, 4.7-Alpha, last commit from 19 Dec 2019. Has anyone tried this over a year old patch? Thanks --Hutchy68 (talk) 18:37, 8 January 2020 (UTC)

Little more information on bug. It seems to take the entire changed block of the multiple-instance template field and duplicate it. Example, if you add just one item to a blank field containing a multiple, you get the same field. Adding a link gives you this.

Link 1
Link 1

Adding two items to a multiple, you get this.

Link 1
Link 2
Link 1
Link 2

Adding additional items with items already held in multiple, Link 2 and Link 3 with Link 1 existing.

Link 1
Link 2
Link 3
Link 2
Link 3

The entire contents of the diff block to the content in a multiple-instance is duplicated in its entirety when 'Save and Continue' is used.

What kind of form is this - a regular form? A "partial form"? Yaron Koren (talk) 20:01, 8 January 2020 (UTC)

Regular form, embedded in a field. Right now I am going back to make sure they added something similar to this for all their multiple instances in the form.

{{{for template|wikipedia|multiple|label=Wikipedia articles|embed in field=Source[Wikipedia]}}}

.Form is long and really complicated. Trying to clean it up. *edit* Yes, everything looks correct. As stated, works on a regular save without issue.

Any ideas Yaron? I noticed if you delete multiples, the Save and Continue button does NOT notice the changes, nor does it activate to apply the changes. Regular fields modified, the button activates. Seems as if 'Save and Continue' is broken for multiple instances. Should I file a bug report? Or add to the existing one? --Hutchy68 (talk) 16:16, 9 January 2020 (UTC)

I don't know... as far as I remember, the Page Forms code always re-generates all of the wikitext for the page, rather than adding to or modifying the existing wikitext, so I don't know how this could happen. If you put here, or pastebin, the form definition you are using, I can try to replicate the problem. I don't think it's related to that Phabricator bug, by the way. Yaron Koren (talk) 17:19, 9 January 2020 (UTC)

Sorry for the delay, I wanted to test this further with a vanilla install. I can still reproduce the same results on different versions of MW, 1.31 and 1.32. Also tested with custom skins and Vector. Same results. Pastebin link is Hutchy68's Pastebin. Form:Test, Template:Link and Template:Test. To reproduce:

• Create a page with the form
• Edit page with form and add a link, save and continue.
• Leave page by clicking the Page or Read link, do not use the save button.
• Note the duplication, Edit with form again.
• Try to remove a multiple, note the save and continue never changes to yellow indicating a save is available even though the page is changed.

What I have noted, if you leave the page using the Page or Read Link or clicking on another link such as Recent Changes or any sidebar link, the doubling occurs. The only method of not doubling when using the save and continue is to leave the page with the save button. --Hutchy68 (talk) 16:15, 10 January 2020 (UTC)

listbox with mapping template

When using listbox input type in combination to mapping template and selecting more than one value (with Ctrl key), the form does save correct values, however, when "Edit with form" is used, the form seems not reading the previous values and erases the content when we hit save again. See the exemple below.

Example:

• Result: https://sandbox.semantic-mediawiki.org/wiki/Listbox_test
• Form: https://sandbox.semantic-mediawiki.org/wiki/Form:Listbox_test
• Template: https://sandbox.semantic-mediawiki.org/wiki/Template:Listbox_test
• Mapping template: https://sandbox.semantic-mediawiki.org/wiki/Template:Listbox_test/codes1

Jaider ^msg 16:44, 14 January 2020 (UTC)

Bypass the datepicker control (disabled days) - how to prevent?

For filling the date fields I use the datepicker control. Thereby I deactivate the already booked days by cargo queries with which I set the parameters "first date", "last date", "highlight dates" and "disable dates". My problem: The disabled dates can be bypassed simply by entering a date in the field. How can the direct input into the field be blocked, forced to input via datepicker?

Ahaemmerli (talk) 14:00, 20 January 2020 (UTC)

There's no direct way to do that. It may be possible via some custom JavaScript that you put into MediaWiki:Common.js; I'm not sure. Yaron Koren (talk) 16:53, 21 January 2020 (UTC)

Multiple templates in tabs

Is it possible to obtain that sub-templates are written inside a tab (for instance using tabber)? I mean, suppose that I have a form "Main" like

        {{{for template|Main|label=Main}}}
	{| class="formtable"
	! Name
	| {{{field|Name|property=Has name|}}}
	|-
        {{end template}}}

	{{{for template|Position|label=Position|multiple}}}
	{| class="formtable"
	! Position
	| {{{field|Titolo|property=Has position|}}}
	|-
        {{end template}}}

and a "Position" template

<includeonly>
    '''Position''' [[Has position::{{{Position|}}}]]
</includeonly>

Following the form definition above, the "Position" templates will be added after the main template. How can I insert them into a tab, that is

<includeonly>
    <tabber>
Main =
    {| class="wikitable"
	! Name
	| [[Has name::{{{Name|}}}]]
	|-
    |}
    |-|
Positions =
    <!-- HERE -->
</tabber>
</includeonly>

Marco Falda (talk) 15:02, 21 January 2020 (UTC)

You can do that by making the "Position" template embedded - look for "embed in field" and "holds template" here. Yaron Koren (talk) 16:56, 21 January 2020 (UTC)

45

Create Form for Non-Technical Colleagues Using Subcategories as Values and Adding Appropriate Category Links?

Hi!

I'm hoping to create a form that will allow our non-technical users to enter new domains that we manage and their related information into our wiki. We have the Categories set up thusly:

• Domains (top level category)
  • IP Addresses (subcategory of Domains)
    • Actual IP Addresses of the domains (ex: 255.255.255.255) (subcategory of IP Addresses)

or

• Domains (top level category)
  • Account Managers (subcategory of Domains)
    • Jane Doe (subcategory of Account Managers)

We have them set up this way so we can see which domains have which IP (we host domains).

I've been trying to create a simple form that our sales people can use to enter new domain information into the wiki when they sign up a new client. They do not code at all. I've set up the wiki with inline category links. I can't upload screenshots because I get errors, so I'll try to describe here.

We have a page set up like this:

Domain Details

---

IP Address	DNS	Hosting Status	On Billing	TLD	Domain Owner	Auto Renew Status	Suspension Status	Domain Status	Website Status	Creation Date
172.217.1.238	ns1.google.com, ns2.google.com, ns3.google.com, ns4.google.com	Not in Hosting	Yes	.com	Unknown	Unknown	Not Suspended	Active	Active	Unknown

Account Manager	Project Manager	Notes
Jane Doe	John Doe	None

Wordpress

---

Yes

Wordpress Plugins

---

• 301 Redirects 2.45
• Advanced Custom Fields PRO 5.8.7
• Classic Editor 1.3

We have inline Category links (in red) that we use to organize our information and help the non-technical folks "search" for information they want. Is there a way to set up Page Forms to:

1. Allow subcategories to be the "values from category" source when using a dropdown in Create a form? Right now it says it's only pages. We need subcategories. Example:

• Field: IP Address

• Input Type: dropdown

• • Other parameters: values from Category: (subcategories for IP Address here?)

2. Add the appropriate Category tags to the end of the page's code? (Example: we have inline links to subcategories "Jane Doe" and "John Doe" but they don't show up there without adding them as [[Category:Jane Doe]] and [[Category:John Doe]] at the bottom of the page (as hidden categories to try and cut down on the eye-clutter). Is there a way to scrape the inline links and populate the correct categories without having to essentially double-type?

If Page Forms can't do this, can you suggest something that does? Our non-tech folks cannot be asked to code at all. Is there a better way to set up the Category Organizations?

Thanks in advance. — Preceding unsigned comment added by K894 (talk • contribs) 17:57, 12 February 2020‎ (UTC)

Let me preface by saying that I don't think it's a good idea to use categories for this kind of thing. The standard approach with Page Forms is to additionally use either the Cargo or Semantic MediaWiki extensions in order to query and display the data that is generated via forms. It might seem like a lot of overhead, but it's really worth it in the end. So, for example, instead of a "Category:Jane Doe", you would use Cargo or SMW to store the Account Manager, Project Manager information for each page - and then, on the page for every person (like "Jane Doe"), include a template that itself includes queries to show all the projects that this person is account manager for, project manager for, etc. It's a more accurate display of information, and it's a lot easier for users when they can see everything about a person (or whatever it is) on one page. And you can easily generate tables, etc. from all of that information.

That said, let me answer your questions: I believe the answer to the first question is no, unfortunately. For the second one, I would check out the #arraymap parser function - it sounds like you don't know about that one, and that may be what you are missing. Yaron Koren (talk) 19:20, 12 February 2020 (UTC)

Using #autoedit from inside a form instead of inside a page

I have written an #autoedit tag to update a page. The tag works as expected when I call it from another page. However, I would like to use the tag from a Form page instead of a page in the regular namespace. When I try to use the link from the form page, I get the error

Modifying [[]] failed. No form specified. Will try to find the default form for the target page.

No target page specified. 

The code for the autoedit tag is:

{{#autoedit:
form=Role
|target=UMG employee role
|link text=UMG
|link type=link
|query string=RoleHeldBy[1000][RoleHolder]=Testperson
|tooltip=blah
|summary=added via button from form
}}

Is it possible to use this tag from inside a form and I have the syntax wrong, or is it simply not possible to use this from inside a form?

That sounds like a bug. But why include #autoedit in a form? It seems strange to modify a page while in the middle of modifying a different page. Yaron Koren (talk) 03:48, 13 February 2020 (UTC)

Internal error with Page Forms upload

When using Page Forms 1.34 on my mediawiki 1.34 installation, the standard form uploadable field popup gives the following error response on uploading:

Internal error: Status::getWikiText called for a good result, this is incorrect

I also notice that the Destination filename field does not auto populate after selecting a source file. I've used multiple computers to log in and have experienced the same issue.

The simple uploading works fine though.

--AgentIrons (talk) 21:58, 14 February 2020 (UTC)

Is there any more to the error message, or is that it? Yaron Koren (talk) 14:11, 17 February 2020 (UTC)

That's it. Chrome console doesn't give me any other info either. Screenshot AgentIrons (talk) 18:23, 17 February 2020 (UTC)

Alright. When you said you're using "Page Forms 1.34", I assume you meant you got the version of Page Forms that goes with MW 1.34 through ExtensionDistributor. That's not recommended - if you're getting code via ExtensionDistributor, you should just get the latest code. I would try that - maybe it'll fix this issue. Yaron Koren (talk) 21:52, 18 February 2020 (UTC)

Sorry, I misspoke - I was using the PageForms 4.7 .zip download from the Download and Install page. I switched to the latest .git clone, but no change in the error. I also added the various PHP debug options to LocalSettings.php but nothing gave me any more information to go on, especially as the debug info did not appear on the Special:UploadWindow frame. AgentIrons (talk) 00:03, 19 February 2020 (UTC)

What does the field tag for that uploadable field look like, in the form definition? Yaron Koren (talk) 00:34, 19 February 2020 (UTC)

The following:

! Front Panel Image:
| {{{field|frontimagefile|input type=text|uploadable|image preview|default filename=<page name>_frontpanel.jpg}}}
|-

AgentIrons (talk) 07:54, 19 February 2020 (UTC)

Okay, thanks. I finally tried this out myself - which I probably should have done right at the beginning, because I got that same error message right away. This turned out to be a bug I accidentally inserted into the code about a month ago. I just checked in a fix for this, so if you get the latest code the problem should hopefully go away. I should probably release a new version of Page Forms soon, because it could be that uploading in version 4.7 is broken completely... Yaron Koren (talk) 03:14, 20 February 2020 (UTC)

Confirmed working with latest code! Thanks Yaron. AgentIrons (talk) 23:55, 20 February 2020 (UTC)

Great. And sorry about the problem! Yaron Koren (talk) 00:04, 21 February 2020 (UTC)

Which tables does Special:MultiPageEdit work for? [RESOLVED]

This page only displays a minority of my tables. I wonder what I could do to get more added. The extension page states: "It currently supports text, text area, checkbox, date, combobox and tokens input types."

Looking at one of them, it has Wikitext (size=2000), String and Date input types. Would changing the first two to Text work?

Also is it relevant that the template has a #cargo_attach statement in it?

Thanks Jonathan3 (talk) 22:51, 17 February 2020 (UTC)

This should probably be explained somewhere. Page Forms' selection actually has nothing to do with Cargo data, if I remember correctly. Rather, I believe it only picks form/template pairs where there is a direct, 1:1 connection between the form and the template. So if two or more forms include the same template (presumably as a multiple-instance template in both cases) then I believe Special:MultiPageEdit doesn't include either form. Could that be case on your wiki? If not, there may be some other rules too. Yaron Koren (talk) 21:50, 18 February 2020 (UTC)

I don't have any multiple-instance templates (that I am aware of!). I deleted a couple of test forms which made one extra form show up in Special:MultiPageEdit, so the 1:1 relationship must be part of it. I would be interested to hear the other rules. Jonathan3 (talk) 23:19, 20 February 2020 (UTC)

I think it's basically "any form that contains a template that's in more than one form is excluded". Yaron Koren (talk) 00:06, 21 February 2020 (UTC)

I'm not positive but I think I'm experiencing a related bug. My Special:MultiPage says "Showing below up to 6 results in range #1 to #6." but nothing is visible. The top/bottom view per page options are there but nothing in between them. I used the Special Pages 'Create Form' and 'Create Template' on a brand new pair just to test but no change. AgentIrons (talk) 03:11, 22 February 2020 (UTC)

I hadn't thought anything of it until your comment, but mine says "Showing below up to 50 results in range #1 to #50" then lists templates for four of my 13 forms. Jonathan3 (talk) 09:40, 22 February 2020 (UTC)

The code is correctly saving the the 1:1 template:form relationships in an array.

But when it comes to displaying the templates, it takes the limit (default 50) and runs through the first 50 templates in the wiki, which means that it misses any relevant templates beyond that. A workaround for now is to change the limit to a number which is higher than the number of templates in the wiki, e.g. title=Special:MultiPageEdit&limit=500&offset=0 Jonathan3 (talk) 10:48, 22 February 2020 (UTC)

This seems to fix it. Change function getQueryInfo() in PF_MultiPageEdit.php so that the 'conds' line also restricts results to those templates identified as being linked to by one form.

'conds' => array( 'page_namespace' => NS_TEMPLATE , 'page_title IN ("' . implode( '", "', array_keys( $this->templateInForm ) ). '") ' )

I have spent all morning working through the code, so really hope you haven't fixed this already :-) Jonathan3 (talk) 12:18, 22 February 2020 (UTC)

Thank you for that patch! I just checked it in - it does indeed seem to fix that problem. Yaron Koren (talk) 20:22, 24 February 2020 (UTC)

Yes it works fine - thank you. Jonathan3 (talk) 21:04, 25 February 2020 (UTC)

show on select not working

I tried following the example provided for a query form, but for some reason all fields are shown in the form regardless of selection. Is it possible that show on select doesn't work for form queries? I even tried using the actual code from the example (Source) but it isn't working either.

autocomplete isn't working as well in my fields, but I dont know if that's related. My version is MW 1.30.1, PHP 5.5.9, MySQL 5.7.25 .217.132.232.233 22:25, 21 February 2020 (UTC)

I'm guessing it's all related. If you look in your browser's JavaScript console, do you see any error messages there when viewing the form? Yaron Koren (talk) 23:13, 21 February 2020 (UTC)

just some error in PushServiceWebSocket.jsm calling _beginWSSetup() in a state other than STATE_SHUT_DOWN. Doesn't sounds related to the form really. I can't post a link to my test wiki unfortunately. 217.132.232.233 06:57, 22 February 2020 (UTC)

One more update - I tried to narrow down to a simple field with autocomplete on regular values. Doesn't work either. The problem seems to be related to using Hebrew values. When using English values autocomplete works. I saw a post from 2016 mentioning this issue. Is this still a known an existing bug? 217.132.232.233 03:51, 24 February 2020 (UTC)

Does "show on select" work for you with English also? Or are these two separate issues? And what is the 2016 post? Yaron Koren (talk) 04:35, 24 February 2020 (UTC)

Nope. Alas, "show on select" doesnt work for english, nor Hebrew. So it's probably two separate issues. The post I saw mentioning issues with Hebrew is with the title 'Fix autocomplete filter function for no \w chars'. 217.132.232.233 09:16, 24 February 2020 (UTC)

I'm guessing you're talking about this, from 2019. I don't know if it was fixed. But it would be good to solve the "show on select" problem first - maybe it leads to the other one. Does this problem happen for you in browsers other than Firefox (which is what I assume you're using)? Yaron Koren (talk) 19:13, 24 February 2020 (UTC)

Besides Firefox I also tried Edge, doesn't work there either. 217.132.232.233 04:05, 25 February 2020 (UTC)

Is there a JavaScript error message there? Yaron Koren (talk) 16:27, 25 February 2020 (UTC)

Probably not related but, strangely, it shows "'mwCustomEditButtons' is not defined". 217.132.232.233 19:06, 25 February 2020 (UTC)

It might be related. Maybe this error comes from some custom code, in MediaWiki:Common.css or elsewhere, that needs to be updated? And by the way, what version of Page Forms are you running? Yaron Koren (talk) 19:40, 25 February 2020 (UTC)

Deleted everything from Mediawiki:Common.css, cleared cached, reloaded. Same problem. PF version is 4.1.2. 217.132.232.233 20:06, 25 February 2020 (UTC)

Alright. I would definitely try upgrading Page Forms - that's a very old version, so maybe this is a problem that has been fixed already. Yaron Koren (talk) 20:54, 25 February 2020 (UTC)

That's the version for MW 1.30 (downloaded from github), it's three years old, not THAT old... anyway upgraded to 4.5. Problem persists 217.132.232.233 04:57, 26 February 2020 (UTC)

Okay, maybe three years is not very old. :) Could you try it with the actual latest version, 4.7, though? There's no reason not to use the latest version. Yaron Koren (talk) 14:24, 26 February 2020 (UTC)

Same problem :/ 217.132.232.233 18:45, 26 February 2020 (UTC)

Alright. I would add "&debug=true" (or "?debug=true") to the URL, then look in the JavaScript console again, to see exactly where the JS error is coming from - my guess is, some other extension. I have a strong feeling that some unrelated JavaScript is messing up Page Forms' JavaScript. Yaron Koren (talk) 20:40, 2 March 2020 (UTC)

I'm afraid that error is gone now. The problem persists though. I tried disabling every extension, no effect. 93.172.112.247 19:56, 3 March 2020 (UTC)

Well, if there's no JavaScript error in the console, then I'm guessing the problem is with the form definition syntax. Is this a public wiki? If not, could you pastebin the form definition? Yaron Koren (talk) 20:05, 3 March 2020 (UTC)

Can't put links for some reason <noinclude> {{#queryformlink:form=Temp}} </noinclude> <includeonly> {{{info|query form at top}}} {{{for template|Temp|display=table}}} {| !section | {{{field|section|values=משהו,סתם|input type=text with autocomplete}}} |} {{{end template}}}

One more thing worth mentioning - even when I use English values the autocomplete box isn't handled very well. The box is very long, much longer than the value, actually stepping over the sidebar. And the value is on the right of the box as if it is a Right-to-left value.

Where's the "show on select" part? Yaron Koren (talk) 03:35, 6 March 2020 (UTC)

Select columns to display in Special:MultiPageEdit

Is it possible to do this? It would help for tables with many fields.

Thanks. Jonathan3 (talk) 19:02, 23 February 2020 (UTC)

No, but you can "X" out the columns you don't want, if there are a lot of them. Yaron Koren (talk) 04:36, 24 February 2020 (UTC)

I hadn't noticed those! Thanks. Jonathan3 (talk) 21:06, 25 February 2020 (UTC)

Computed value in values from namespace=?

Hi Yaron,

I have a form editing pages in different namespaces, and would like to autocomplete from a current namespace. For instance NS1:page1 should autocomplete from NS1. I have a variable containing the current namespace {{#var:namespace|}} using the variable module. However when use the example code block

{{!}} {{{field|replaces|input type=tokens|values from namespace={{#var:namespace}}|delimiter=、|optional}}}

it returns Could not find namespace: {{#var:namespace}}

I can see from debugging and other usage that the variable works. Is there another way to retrieve values on a 'current' namespace?

Thank you! Øyvind

I can't think of a way to always get that to work, no. Let me note that a form that applies to pages in multiple namespaces is rare, and may indicate an overuse of namespaces - although I don't know your data structure, so maybe it's fine. Yaron Koren (talk) 16:33, 25 February 2020 (UTC)

Thanks. Is this something I could try to implement? I'm thinking of adding a case looking for `current` or maybe `page`, but some thought should probably go into thinking about reserving a keyword. Øyvind.

Adding handling just for this particular use case seems like a bad idea, because it's a very rare use case. There are a few potential other solutions, though:

1. Add parsing for "values from namespace=". This will work for you when editing existing pages. However, I think it will fail when the page name of the form starts with "Special:FormEdit", i.e. when creating a new page.
2. Change your data structure so that the same form does not handle multiple namespaces. I don't know what your data structure is, but I'm guessing that it can be "improved"/simplified in some way.
3. Add a hook to Page Forms to allow for admins to create custom PHP code to set the values for an input. This is the most general solution, and it could help solve a number of different issues.

Maybe #3 is the best solution; I'm curious what you think about #2, though. Yaron Koren (talk) 14:32, 26 February 2020 (UTC)

Regarding #2, I think I am partially overusing namespaces, but I do like the model, which is basically Collection -> Concept (memberOf Collection, for now, one namespace per collection). One or more collections belongs to a group of editors, so I use namespace to set edit rights. I also query the member collection for language tokens, to define which tabs are shown in the Concept form (Concept in Collection 1, Concept in Collection 2 with less languages defined I think I may want to move the individual Collections to the group namespaces (which are now in the main namespace, example: https://termwiki.oyvindg.no/index.php?title=MRT -> https://termwiki.oyvindg.no/index.php?title=MRT:MRT). I think I then could use the special variable NAMESPACE to set the variable for forminput, so one namespace could also contain multiple Collections. This would reduce the namespace usage to the number of groups, instead of individual Collections.

Creation and editing of new Concepts are available (and works) from the individal Collections view using forminput {{#forminput:button text=Legg til nytt Begrep|form=Begrep|link type=button|query string=Begrep[medlem]={{PAGENAMEE}}|namespace={{#var:ns_from_identifier}}|autocomplete on namespace={{#var:ns_from_identifier}}|reload|new window|no autofocus

Could #1 be an option, since parsing also works on #forminput - autocomplete on namespace?

Thanks! Øyvind

Did you understand what I meant about #1 only working some of the time? Yaron Koren (talk) 18:27, 27 February 2020 (UTC)

Would the use case be similar to how I use #forminput and autocomplete on namespace=? Then I can set a param containing the namespace in query string, and use UrlGetParameters to retrieve it on Special:FormEdit page.

Sorry for the long delay. That's a good point, and last week a change was made to Page Forms so that "values from namespace=", plus the equivalents for category and concept, all parse their own value. So what you wanted should now be possible. Yaron Koren (talk) 01:16, 25 March 2020 (UTC)

Thank you Yaron and AmrElabsy, I look forward to trying it out :)

Øyvind

Format of Special:MultiPageEdit

Here are some suggestions:

1. It would be good if the space to edit the text were bigger. I have some long-ish String fields (e.g. lists of authors) and there isn't room to view all the text in the narrow one-row text field.
2. Maybe, linked with this, it would be good if it were possible to 'X' out columns even after the screen space limit has been reached (i.e. even if the screen can hold 6 columns, it should be possible to reduce it to fewer than 6).
3. Instead of having an extra frame with its own toolbar would it be possible to just display the spreadsheet in the normal (larger) page?
4. On an empty field of type Page, the dropdown autocomplete suggestions aren't wide enough to display even one letter.
5. On my laptop screen the light/dark/light row colouring is invisible unless I push the screen right back and lift up the keyboard. The lack of a row border makes it difficult, especially as the rows change size when you go to edit them.

Other than these suggestions, it's a great idea and seems to work well :-) Jonathan3 (talk) 21:16, 25 February 2020 (UTC)

There's a planned project for this summer that will, among other things, replace the JavaScript library currently used for Special:MultiPageEdit, jsGrid, with a different one. This may fix some of these problems, or it may make them worse - we'll see. Yaron Koren (talk) 21:25, 3 March 2020 (UTC)

Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

I'm seeing the following error whenever I click "Save page" while creating a Property/Category/Template/etc with one of the Page Forms extension special pages:

Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

I'm running MW locally using XAMPP, with the following versions:

MediaWiki: 1.34.0

PHP: 7.3.14 (apache2handler)

MariaDB: 10.4.11-MariaDB

Semantic MediaWiki: 3.1.4

Page Forms: 4.7

I can save a normal page just fine with no errors, so I think I have everything installed and set up properly. I'd love some suggestions/workarounds. I noticed in a previous discussion page for this extensions someone had a similar problem, but I didn't see a resolution. Please let me know if there's any more info I can provide that would be helpful, thank you.

I hadn't heard of that before. I did a web search on that error message, and saw this, among other things - there they suggest that the problem might be due to too-low value for post_max_size in php.ini. Could that be the issue? Yaron Koren (talk) 14:03, 4 March 2020 (UTC)

Thank you for the suggestion, unfortunately that does not seem to be the problem. A simple property that is 1 line of text will not save immediately, but I can post several paragraphs to a normal page with no issue. I did try increasing the value from the default it was set to (40M) to 200M, and this did not alleviate the problem.

Today I updated to Page Forms version 4.8, and I now see the following text below the original error message: "Error: No form found with name "".". Perhaps this will better indicate what problem is occurring? Thank you again for any help.

Which helper form do you see that message on? Or is it all of them? Yaron Koren (talk) 13:51, 9 March 2020 (UTC)

"Create a category" is the only helper form where I see both the original "Some parts of the edit form did not reach the server" message as well as the "Error: No form" message. When using the helper forms for creating a form, a property, or a template, I see only the original "Some parts of the edit form did not reach the server" message.

Alright, good to know. I'm guessing that those two problems are related, but I don't know what's causing them - I can't replicate this problem. Yaron Koren (talk) 01:53, 11 March 2020 (UTC)

Problems using Page Forms in conjunction with Cargo

My goal is to have a single form with different sections that I can style using html for example. The form should hold several fields that describe object properties. Finally everything is stored in a single cargo table which should look like this:

object id	property1	property2
1	green	solid

Assume there is some kind of "master template" which holds all the Cargo table delcarations I want and which "calls" several subtemplates to perfom the actual cargo store operations. Now I'd like to create a form for the master template in a way which enables me to add some style to around the form inputs, for example to color some sections green and others blue. I'll give an example.

    <!-- MASTER FORM -->
    ...
    <!-- define property1 input field -->
    {{{for template|MASTER_TEMPLATE_test|label=property1}}}
        {{{field|test_property1|mandatory|default={{PAGENAME}}}}}
    {{{end template}}}

    <!-- define property2 input field -->
    {{{for template|MASTER_TEMPLATE_test|label=property2}}}
        {{{field|test_property2|mandatory|default={{PAGENAME}}}}}
    {{{end template}}}
    ...

    <!-- MASTER_TEMPLATE_test -->
    ...
    {{#if:{{{test_property1}}}
        |{{TEMPLATE_test_property1|{{property1}}}}
        |
    }}

    {{#if:{{{test_property2}}}
        |{{TEMPLATE_test_property2|{{property2}}}}
        |
    }}
    ...

But then my resulting page (in code) looks like this. Notice the empty {{MASTER_TEMPLATE_test}} at the end.

{{MASTER_TEMPLATE_test
|property1=green
|property2=solid
}}
{{MASTER_TEMPLATE_test}}

How do I get rid of the unnecessary template call at the end? Or how to do all this properly in the first place? The reason I tried this specific way was 3-fold.

1. I wanted to be able to "style" different form sections (which I can't when I include all fields in a single {{{for template....}}}
2. I wanted to abandon my previous approach, which was to have a single table for every property instead of one big table for every object. I used to join all the property tables in my queries when needed but that didn't feel quite right.
3. I wanted to avoid a Cargo(?) issue where I'd get duplicated and incomplete entries when trying to write into the same table from different templates (hence the master template). I'd then get something like

object id	property1	property2
1	green
1		solid

Sorry for this somewhat convoluted post. Any advice is welcome. Thanks in advance. Mwarge (talk) 14:34, 2 March 2020 (UTC)mwarge

I’m pretty certain you can apply CSS styles to form elements. Press F12 and find out the class/id names, and put the CSS in Common.css. Or I bet putting them inside spans/divs would work. I could be wrong - what have you tried? Jonathan3 (talk) 16:18, 2 March 2020 (UTC)

You are right, that seems to be a way but somewhat limits the possibilities and feels a bit hacky. I imagine you'd have to bend over backwards to achieve some kind of tabular form layout for example. But then again, I'm not well versed in these matters. For now I tend to stick to the approach which yields the empty and unnecessary template-calls at the end of my pages and then hide extra <p></p> with something like .mw-parser-output p:nth-last-child(-n+5){display:none} for example. That feels very wrong but at least gives me the desired results for now. If there is any other advice on

1. getting the cargo structure right, so writing to the same table from different templates doesn't yield duplicated and incomplete entries and forces me to use a "master template" or
2. using a master template, but avoiding the issues I described above,

I'd be happy to hear about it.

Edit: Apparently my "master template approach" is useless. As stated here this cannot be done with Cargo. I'll try to figure out a way that's not extremely ugly and keep you posted if anyone is interested. Cheers Mwarge (talk) 08:26, 3 March 2020 (UTC)

You should just have one template - it works, and there's nothing hacky about it. Yaron Koren (talk) 18:35, 3 March 2020 (UTC)

I cannot create graphically clearly structured forms with just one single template. And if I have a lot of templates, I get a lot of individual PostgreSQL tables. Though, I can summarize them afterwards via JOINS and I can design more clearly arranged tables via VIEWS in the SQL-Layer.
However it would be really good, if I could BEGIN transactions in an earlier template and send a COMMIT in a template behind.Barpfotenbaer (talk) 09:01, 4 March 2020 (UTC)

What do you mean by "graphically clearly structured forms"? Yaron Koren (talk) 13:58, 4 March 2020 (UTC)

<table><tr><td>

===Section 0===

</td></tr><tr valign="top"><td>

====Subsection A====

<table width="100%"><tr valign="top"><td><div class="abc">
{{{for template|FieldTypeA|label=A}}}
{| class="def"
! Line A one:
| {{{field|1|input type=text with autocomplete}}}
|-
! Line A two:
| {{{field|2|input type=text with autocomplete}}}
|-
! Line A three:
| {{{field|3|input type=text with autocomplete}}}
|}
{{{end template}}}
</div></td></tr></table>

====Subsection B====

<table width="100%"><tr valign="top"><td><div class="abc">
{{{for template|FieldTypeB|label=B}}}
{| class="def"
! Line B one:
| {{{field|1|input type=text with autocomplete}}}
|-
! Line B two:
| {{{field|2|input type=text with autocomplete}}}
|-
! Line B three:
| {{{field|3|input type=text with autocomplete}}}
|}
{{{end template}}}
</div></td></tr></table>
</td></tr></table>

Barpfotenbaer (talk) 14:38, 4 March 2020 (UTC)

Okay.... can't you do that with just one template? Yaron Koren (talk) 14:51, 4 March 2020 (UTC)

Not possible, if my record uses multiple fields combined with standard fields Barpfotenbaer (talk) 15:21, 4 March 2020 (UTC)

<table><tr><td>

===Section 0===

</td></tr><tr valign="top"><td>

====Subsection A====

<table width="100%"><tr valign="top"><td><div class="abc">
{{{for template|FieldTypeA|label=A}}}
{| class="def"
! Line A one:
| {{{field|1|input type=text with autocomplete}}}
|-
! Line A two:
| {{{field|2|input type=text with autocomplete}}}
|-
! Line A three:
| {{{field|3|input type=text with autocomplete}}}
|}
{{{end template}}}
</div></td></tr></table>

====Subsection B====

<table width="100%"><tr valign="top"><td><div class="abc">
{{{for template|FieldTypeB|multiple|label=B}}}
{| class="def"
! Line B one:
| {{{field|1|input type=text with autocomplete}}}
|-
! Line B two:
| {{{field|2|input type=text with autocomplete}}}
|-
! Line B three:
| {{{field|3|input type=text with autocomplete}}}
|}
{{{end template}}}
</div></td></tr></table>
</td></tr></table>

Well, if one template is a multiple-instance template, then it has to be a separate template, unrelated to the graphic display or anything else. A "master template" wouldn't work for that situation either. It sounds like two templates is the way to go, then. Yaron Koren (talk) 15:56, 4 March 2020 (UTC)

"Searching..." message on text with autocomplete

For a long time I didn't realise that "text with autocomplete" was working, so used tokens instead, which didn't suit as well for other reasons... but it was just the speed of the connection/server causing a delay. Both types were working all along. It would be good if the text with autocomplete input type had a "Searching..." message in the same way as the "tokens" type does! Jonathan3 (talk) 10:31, 5 March 2020 (UTC)

I'm actually planning to get rid of "text with autocomplete" and "textarea with autocomplete" sometime this year, because I don't think they're good as "combobox" and "tokens" - so you can consider them semi-deprecated already. If you think they should be kept, though, let me know why. Yaron Koren (talk) 16:57, 6 March 2020 (UTC)

Definitely keep, please - text is more intuitive for less computer literate people. It’s not obvious that double clicking on a token lets you edit it. It’s easy to cut and paste with text with autocomplete (is it possible with tokens?). If the connection is slow people can end up not entering anything unless they know to cut the autocomplete lookup short by typing the delimiter. People are used to text boxes and less so with tokens (though Hotmail etc does use them for recipients). What happens to tokens if JavaScript is off (I don’t know, just asking)? I’m sure I could think of more reasons :-) Jonathan3 (talk) 20:03, 6 March 2020 (UTC)

Pasting in values is possible in tokens - you can't cut/copy, though. (I don't know how important that is.) Tokens can't work without JavaScript, but then again I'm pretty sure forms in general won't work without JavaScript enabled. So that basically leaves that "tokens" is less obvious to use than "text(area) with autocomplete". That sounds like an argument for getting rid of the "tokens" option, no? Or are there some forms, or wikis, where the users are guaranteed to be more computer-savvy than others? Yaron Koren (talk) 17:21, 8 March 2020 (UTC)

I’d prefer both to be available. I haven’t thought it through in detail! I seem to remember having trouble with the width of tokens fields on the iPhone (now I don’t use HTML tables in the forms so I can’t remember the details). I have a form where copying and pasting between fields is useful (though I guess I could add JavaScript to do that). Tokens are nice though so it would be a shame to get rid of them either. Text with autocomplete is easier if you need to edit a suggested value. Tokens are good if you will probably use a suggestion as is. Tokens ensure you get a list delimiter right. Both have pros and cons and I can imagine swapping between them in future... Jonathan3 (talk) 18:12, 8 March 2020 (UTC)

I don't understand - won't most people use suggestions as-is, in any autocompletion input? Yaron Koren (talk) 18:14, 8 March 2020 (UTC)

I don’t know what most people do :-) Certainly on the first form box (page name selection) I’m sure it would be common to change the suggestion to something similar but slightly different. I imagine most of the time a suggestion in the form would be used as is (eg name of existing wiki page). If I were to choose one to keep I would agree with your original suggestion of keeping tokens and getting rid of text with autocomplete. Jonathan3 (talk) 18:52, 8 March 2020 (UTC)

Yes, the #forminput input is a special case. Alright, that's good to know. Let me know if you change your mind... Yaron Koren (talk) 20:36, 8 March 2020 (UTC)

Reduce minimum text field size? [SOLVED]

We're putting together a couple of forms [PF 4.6] that have ~200 defined fields (industrial process lab test results). My 'size=4' parameter in the form definition seems to be getting over-ridden by some minimum value or something as they are all coming out ~7 chars wide. It would really help real estate-wise if we could shrink this. I see you can set class= to something that might help with this, but I'm really weak with css and am having trouble identifying what class statement needs to be made.

I see class="createboxInput" is called out in the page source for the input. I've used Extension:CSS successfully for this kind of thing, but am normally able to find the class names in the PF css files such that I can hack together a statement that has the desired effect. In this case, I think something like {{#css: createboxInput { width:50px; } }} should work, but I don't think I'm referencing it right. A little help? Thanks! - Lbillett (talk) 13:23, 6 March 2020 (UTC)

My bad. I was close, just clearly weak with CSS. I had be more specific and cover any parents.

This worked perfect: {{#css: *.createboxInput { width:25px; } }} - Lbillett (talk) 15:01, 6 March 2020 (UTC)

Special:RunQuery returning me to the main page without any results

MediaWiki 1.31.6
PHP 7.3.15 (cgi-fcgi)
MySQL 5.6.41-log
Semantic MediaWiki 3.1.5
PageForms 4.8 (d60a82c) 17:10, 30 August 2018

I'm trying to upgrade my site and I'm having issue with Special:RunQuery/, I'm using linkedwiki with #sparql. this was working in my old version, and I've gone through and fixed all the changes upgrading to Semantic MediaWiki 3.1.5. I have linked wiki sparql query working on other pages. Now when I try with Special:RunQuery it just returns me to the main page.

Are you sure you're using Page Forms 4.8? It came out in 2020, not 2018. Yaron Koren (talk) 17:22, 9 March 2020 (UTC)

Yes I just downloaded it from git Legaulph (talk) 17:31, 9 March 2020 (UTC)

Did you use a branch or something? I don't know why it's giving that date. Yaron Koren (talk) 17:47, 9 March 2020 (UTC)

Actually the version you see I pulled from the MW 1.31 selection. I have downloaded directly from git and know it shows PageForms 4.8. I also just tested ask query and it does it with that as well. Legaulph (talk) 17:54, 9 March 2020 (UTC)

I'm also using PluggableAuth 5.7 with simplesaml, not sure that would cause this.Legaulph (talk) 17:57, 9 March 2020 (UTC)

Alright, it's good that you're using the true latest version. I'm guessing that your wiki has the default URL structure (index.php?title=...). There were some similar problems with the handling of the default URL structure; I thought they were all fixed, but I guess not. I doubt it's related to anything auth-related. Yaron Koren (talk) 18:10, 9 March 2020 (UTC)

Yes using the default structure. Legaulph (talk) 18:18, 9 March 2020 (UTC)

OK I was able to get the short url's working and it fixed this issue.Thanks Legaulph (talk) 20:17, 12 March 2020 (UTC)

That's good to hear - though I still want to fix the actual bug. Yaron Koren (talk) 02:01, 13 March 2020 (UTC)

Tree display not collapsing

We have a form with some fields accepting multiple values selected from a category tree within a formtable. The tree is displayed, and checking several boxes causes the correct output. But the tree is displayed to all levels, in spite of depth=1, and branches of the tree are not collapsible – clicking on the arrow has no effect. (MW 1.34.0, PageForms 4.6) A typical line in the form is:

{{{field|genre|input type=tree|top category=Musical genres|depth=1|hideroot|list}}}

and the line in the template is:

|category={{#if:{{{genre|}}}|{{#arraymap:{{{genre|}}}|,|x|x|{{!}}}}|_none_}}

Bcjohnston (talk) 17:15, 10 March 2020 (UTC)

Could there be a JavaScript error there? What do you see if you look in the browser's JavaScript console? Yaron Koren (talk) 17:49, 10 March 2020 (UTC)

Console on the RunQuery page:

This page is using the deprecated ResourceLoader module "jquery.ui".Please use OOUI instead. load.php:1014:243

JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:890:792

This page is using the deprecated ResourceLoader module "jquery.ui.autocomplete". Please use the main `jquery.ui` module, not this alias. load.php:1302:97

This page is using the deprecated ResourceLoader module "jquery.ui.position". Please use the main `jquery.ui` module, not this alias. load.php:1302:337

This page is using the deprecated ResourceLoader module "jquery.ui.sortable". Please use the main `jquery.ui` module, not this alias. load.php:1302:573

This page is using the deprecated ResourceLoader module "jquery.ui.widget". Please use the main `jquery.ui` module, not this alias. load.php:1302:807

JQMIGRATE: jQuery.unique is deprecated; use jQuery.uniqueSort load.php:890:792

(Firefox updated and PageForms to 4.8 before this) Bcjohnston (talk) 19:25, 10 March 2020 (UTC)

Okay, I should have tried this out myself - I'm seeing the same problem. I don't know why it's happening - it's not because of any of those warning messages, but it might be due to some JavaScript compatibility issues. I should note that there is a planned project for this summer that would replace the current JS library used for the tree input, Fancytree, with a different one - most likely jsTree. That would probably fix these problems. Can this issue wait another five months or so, or is it fairly pressing? Yaron Koren (talk) 20:47, 10 March 2020 (UTC)

I've got the same problem (I'd lived with it so long I'd forgotten it was meant to be any different... so, for me, it can wait) :-) Jonathan3 (talk) 21:02, 10 March 2020 (UTC)

We are testing MW 1.34 with PageForms to prepare an upgrade to the next Long Term Support version of MediaWiki (1.35), planned for release in June 2020. Can you synchronize the tree replacement with MW 1.35? Several of the trees in our form are very long because of this issue, therefore difficult for users to deal with. So we don't feel we can put this on the public server as it is. Bcjohnston (talk) 15:43, 11 March 2020 (UTC)

Well, the changeover is planned to happen this summer, so unless this problem gets fixed separately, it probably won't be before the 1.35 release. Yaron Koren (talk) 15:59, 11 March 2020 (UTC)

Thanks for your help! Bcjohnston (talk) 19:43, 11 March 2020 (UTC)

For the records: I'm working on the same project of Bcjohnston, and I'vee been able to fix this problem with a rollback, using Semantic Forms 3.4.1 in lieu of Page Forms. However, some patches were required to make Semantic Forms 3.4.1 working with MW 1.34: replace some instances of wfGetDB( DB_SLAVE ) with wfGetDB( DB_REPLICA ); and replace some instances of $this->getTitle with $this->getPageTitle. We will survive with this until the issue is fixed on Page Forms. Choralia (talk) 10:23, 15 March 2020 (UTC)

Special:RunQuery returning wrong page links

MediaWiki 1.31.6
PHP 7.3.15 (cgi-fcgi)
MySQL 5.6.41-log
Semantic MediaWiki 3.1.5
PageForms 4.8 (d60a82c) 17:10, 30 August 2018
LinkedWiki 3.3.7

I'm using SPARQL query with LinkedWiki

trying to resolve issue with the run query. https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4653.

I needed to update enableSemantics( 'example.org/wiki/', true ); fixed most of the issues.

why do the links with "-" changed to "-2D"? ex.(https://example.org/wiki/Special:RunQuery/example.org/wiki/Adobe_Illustrator/TS-2DRoadmap).

The pages that have "-2D" The Link does not work..

Legaulph (talk) 11:29, 22 March 2020 (UTC)

The links are the same with:

MediaWiki 1.31.1
PHP 7.1.30 (apache2handler)
MySQL 5.6.10
Semantic MediaWiki 2.5.8
LinkedWiki 3.1.1 (73067e5) 14:39, 13 January 2018

The links that had -2D worked with this setup

Legaulph (talk) 12:44, 22 March 2020 (UTC)

I don't understand that URL. Do you really have "example.org/wiki" (or whatever the actual thing is) twice in the URL? Yaron Koren (talk) 13:44, 22 March 2020 (UTC)

I'm using Linkedwiki for the query, and changed enableSemantics( 'example.org/wiki/', true) to enableSemantics( 'https://example.org/wiki/', true) and now the link shows up like (https://example.org/wiki/AMEGAVIEW_CENTRAL_MONITORING_SYSTEM/Manufacturer-2DRoadmap.

In the old version it shows up like (http://example.org/index.php/Special:URIResolver/Aris_Mashzone/TS-2DRoadmap).

I deleted the graph and started again, rebuildData.php - If I used the -f it fails for some reason, so I deleted it from the endpoint. Not sure why it was coming out twice before, i copied the url from the result and that's what it was.

However still (https://example.org/wiki/AMEGAVIEW_CENTRAL_MONITORING_SYSTEM/Manufacturer-2DRoadmap) does not work. If I remove the 2D it works. In the old version it works fine. Legaulph (talk) 11:29, 23 March 2020 (UTC)

What is generating this URL? Yaron Koren (talk) 13:58, 23 March 2020 (UTC)

At the link

when I run this on a wiki page I get the result with the -2D on the link column, I do see it is fine on other columns where there is a link

{{#sparql:</nowiki>
 PREFIX property:<https://server.com/wiki/Property-3A>
 PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
 PREFIX swivt:<http://semantic-mediawiki.org/swivt/1.0#>
 SELECT ?supported_by ?Subcategory ?name ?version ?technology_name ?owner ?contact ?publication_date ?publication_status ?support_status ?Link
 WHERE 
 {
             ?Link property:Has_parent_page ?parent.
             ?parent property:PublicationStatus ?Publication_Status .
             ?Link property:Has_subobject ?Subobject .
             ?Subobject property:Technology_Name ?Name .
             ?Subobject property:Has_Start_Date ?Start_Date .
             OPTIONAL {
             ?Subobject property:Has_End_Date ?End_Date .
             }
             ?Subobject property:Has_Support_Status ?Status .
             OPTIONAL {
              ?parent ?p ?sub .
              ?cat rdfs:label ?Category .
              FILTER(CONTAINS(STR(?cat), "Category")) .
              ?sub rdfs:subClassOf ?cat .
              ?sub rdfs:label ?Subcategory .
             }
   ?subobject property:Has_Version ?version .
   ?subobject property:Technology_Name ?technology_name .
   ?subobject property:Has_Support_Status ?support_status .
   ?subobject property:Supported_By ?supported_by .
   ?subobject property:Has_Start_Date ?start_date .
 OPTIONAL {
   ?subobject property:Has_End_Date ?end_date .
 }
 OPTIONAL {
   ?parent property:OwnedBy ?owner.
 }
 OPTIONAL {
   ?parent property:PublicationDate ?publication_date .
   ?parent property:PublicationStatus ?publication_status .
 }
 OPTIONAL {
  ?parent ?p ?sub .
  ?cat rdfs:label ?Category .
  FILTER(CONTAINS(STR(?cat), "Category")) .
  ?sub rdfs:subClassOf ?cat .
  ?sub rdfs:label ?Subcategory .
 }
 OPTIONAL {
  ?parent property:ManufacturedBy ?manufacturer.
 }
 OPTIONAL {
  ?parent property:Contact ?contact.
 }
 }
 LIMIT 10
 |endpoint=http://server.com/sparql}}

That sounds like it could be a problem with the LinkedWiki extension, no? Yaron Koren (talk) 14:26, 23 March 2020 (UTC)

I'm checking there as well. However I get this directly from the endpoint. Could it be Semantic MediaWiki?Legaulph (talk) 14:42, 23 March 2020 (UTC)

Sure - whatever is generating that URL. It doesn't sound like it's Page Forms... Yaron Koren (talk) 14:59, 23 March 2020 (UTC)

Thanks, Karima pointed me to the Doc : https://www.semantic-mediawiki.org/wiki/Help:Pretty_URIs,

Allowing pipe character in form text input?

I'm tying to get the settings right to allow users to fill out a form with a large text box with some code, that often contains pipes |, so that they can submit a form with code examples that auto creates pages in my wiki. However entering a | results in the form not allowing them to save. Escaping the pipe by various means won't be intuitive enough for the end user.

Is there a way to do this? I see that on Wikipedia I can save text when editing pages with pipes in it without any escaping. Do I need to pursue another editor for the field? Or a better way of allowing code to be pasted into a field?

Input type=code didn't help. Editor=wiki editor also didn't allow the pipe character to be saved.

Thanks! AndyRPH (talk) 16:31, 24 March 2020 (UTC)

Can this field be made a page section, or the "free text" field, instead of a template field? That would be the easiest solution. Those both allow any use of pipes. Yaron Koren (talk) 01:06, 25 March 2020 (UTC)

Page sections worked perfectly! Thank you! AndyRPH (talk) 01:37, 26 March 2020 (UTC)

Linking properties to forms

If I understand correctly #default_form doesn't work for properties? Is there any way other than using #formredlink to have a property redlink link to a form? Thanks,

--Dan Bolser (talk) 11:42, 27 March 2020 (UTC)

Unfortunately, no. Though if anyone creates a patch to support #default_form within property pages, I'd be happy to add it in. Yaron Koren (talk) 13:01, 27 March 2020 (UTC)

Mobile editing

Does PageForms support mobile editing? At first glance I don’t see the Edit with form button on mobile.

I'm pretty sure it doesn't work with MobileFrontend, AKA the Minerva Neue skin, if that's what you're asking about. Yaron Koren (talk) 01:54, 30 March 2020 (UTC)

Hmm, ok. So it looks like Special:FormEdit works as it should on mobile (with some css tweaks), so I was thinking about adding a button with some javascript. Do you know a reliable way to check if a page is editable with Javascript? (this is for mobile, on desktop I can just see if the Edit with Form button exists). JakePotrebic (talk) 02:35, 30 March 2020 (UTC)

I don't know. But are you sure that editing works? I thought the Page Forms JavaScript that needs to be loaded does not get loaded with MobileFrontend, which means that saving doesn't work, plus all the JS-based input types. Yaron Koren (talk) 14:47, 30 March 2020 (UTC)

Output for token input type

When I use the values prop to set a list of values for the "tokens" input type, it outputs with a space followed by a comma between each selected option. When I use the "values from category" I don't get the space inbetween the options. Any solution? JakePotrebic (talk) 18:23, 30 March 2020 (UTC)

Sorry for the long delay. If there's no space, that's a bug - though I can't reproduce that error. What version of Page Forms are you running? Yaron Koren (talk) 01:47, 20 April 2020 (UTC)