Extension talk:Page Forms/Archive October to December 2020

#formredlink inside list created by #ask?

I have a SMW with PageForms to save some structured information about historical biographies. A person's residence is stored in subobjects and displayed with #ask as a bullet list:

 {{#ask:[[-Has subobject::{{FULLPAGENAME}}]][[Kategorie:Residence]]
  |mainlabel=-
  |?homeLocation=
  |?StartDate=von
  |?EndDate=bis
  |format=ul
  |headers=plain
  |default=Es wurden noch keine Wohnsitze zu dieser Person erfasst!}}

How can red links for the homeLocation attribute automatically point to the right form (Form:Location)?

My current workaround is setting $wgPageFormsLinkAllRedLinksToForms = true; and letting the wiki user choose the right form. Any better ideas?

Maybe use the "template" format, so you can embed #formredlink around each result. Yaron Koren (talk) 17:19, 20 October 2020 (UTC)

Using autoedit on File namespace ($wgPageFormsAutoeditNamespaces global)

Hi,

Our setup: MW 1.31.1 PageForms 4.6

We are trying autoedit on the File namespace and have modified LocalSettings with "$wgPageFormsAutoeditNamespaces[] = NS_FILE;". How do we specify the namespace to target? Using "|target=File:file.png" does not work since the colon seems to cause a json format issue. We have tried putting into the query string "|query string=namespace=File&....." and that does not work. I assume there is no namespace parameter because this does not seem to work as part of the autoedit specification: "|namespace=". How do we use $wgPageFormsAutoeditNamespaces properly and how to define the autoedit link? We would like to autoedit outside the Main namespace.

Thanks,

Longphile (talk)

Is it possible to change the delimiter by default?

Hi everyone,

I would like to use semicolons (;) instead of commas (,) to separate values. Is there any variable o something else to configure this?

Thanks in advance!

Regards, Ivanhercaz (talk) 01:14, 8 October 2020 (UTC)

Yes - just add "|delimiter=;" or whatever it is to the relevant field tag(s) in the form definition. Yaron Koren (talk) 21:12, 9 October 2020 (UTC)

Links to a template using "queryformlink" from a cargo query

Hi, lets say i have Template:search that runs "queryformlink".

I have this simple cargo query:

{{#cargo_query:
table=MyTable
|where=1=1
|fields=CONCAT('{{Template:search|param1=value1...}}'))
}}

When doing that, all of the Template:search values are: 'UNIQ--item-0--QINU', Why is that? Thank you!

Well, I wouldn't really call it a "simple" query - it's a call to a parser function (#cargo_query) that produces a template call that in turn is meant to call another parser function. What you're seeing is a bug, but I'm not totally surprised that it's failing, given the chain of parsing that has to take place. Maybe there's a simpler way to do whatever you're trying to accomplish? Yaron Koren (talk) 21:07, 13 October 2020 (UTC)

Im trying to add a link (to a query form with predefined params) for each row in the result, I can ofc write the unformatted link in the CONCAT but it seems to be bad practice IMO.Do you have any idea how to solve that? (Or a workaround) Thank you! 77.125.48.193 18:45, 14 October 2020 (UTC)

Sorry, I somehow missed this entirely before. On the very small chance that you're still reading this - the "template" result format seems like the way to go here. Yaron Koren (talk) 15:45, 19 November 2020 (UTC)

Bug report: namespace prefix getting removed

I use tokens with the "values from property" parameter, which gathers values from different namespaces. However, on autocomplete, I don't see the namespace prefix (which in my case denotes a particular language so that represents essential information) and when I select a value from the dropdown menu and save the page, values are saved without their namespace prefix. Same thing with "text on autocomplete". Cavila 10:25, 15 October 2020 (UTC)

Use Math Type Elements Inside Page Form

MW 1.35 Page Form 4.9.5 Cargo 2.7: Is it possible to create a Form which will do some simple math. I would like to have a handful of fields within a form which determine a real estate term Cap Rate. In essence, one field will be the Gross Income (GI). Next, we have several fields for Taxes (T), Maintenance (M), and Insurance(I). These 3 fields equal Net Income (T+M+I=NI). We have a field called Purchase Price (PP). The final field, Cap Rate is equal to NI/PP. Technically, this is a percentage and thus the decimal answer for Cap Rate would have to convert to a percentage. Any help would be greatly appreciated! -- Foreclosurepedia (talk) 19:22, 17 October 2020 (UTC)

I'm not sure I understand what you're asking, but Special:RunQuery may help with this. Yaron Koren (talk) 15:47, 19 October 2020 (UTC)

Upgrading from Semantic Forms to Page Forms

I am attempting to upgrade my MW instance from v 1.21 to v1.35. Most everything is working correctly, but Page Forms does not recognize any of my Semantic Forms data (or it wasn't converted properly via update.php or /SemanticMediaWiki/maintenance/rebuildData.php). Basically no /wiki/Form:blah pages exist, and my links to these are dead. I'm not exactly sure what sorts of log output is needed for troubleshooting, but I don't see any historic reference to these upgrade issues for this extension, which would seem to be a common problem. I have very limited PHP knowledge outside of basic config (php-fpm v 7.4 via nginx).

It looks like Templates are OK, but Property is being interpreted as 'Form' (i.e., clicking on 'Forms' link under [Page Forms] on Special Pages brings up a list of my Properties). I see no link to 'Properties' from Special Pages.

Please assist. Thanks in advance! ~z929669 Talk 17:57, 19 October 2020 (UTC)

I'm guessing that the problem has to do with namespace IDs in the database. Do you have access to your database? If so, I would call something like "SELECT page_namespace, COUNT(*) FROM page GROUP BY page_namespace" to try to get a sense of which IDs are being used. Yaron Koren (talk) 16:05, 19 October 2020 (UTC)

Thanks for the tip, Yaron. Yes, I can access the DB ... the query returns results (namespace IDs) corresponding to most of my namespaces, but 'Form' has never been defined in my LocalSettings.php. I'm not sure how to list all of my namespaces by name, because many of these don't need to be defined in LocalSettings.php:

page_namespace	name	COUNT(*)	Before Upgrade
0	Main	1808	1808
1	Main Talk	20	20
2	User	1347	1347
3	User Talk	72	72
4	Project	48	48
5	Project Talk	6	6
6	File	1510	1510
8	Mediawiki	16	13
10	Template	252	252
11	Template Talk	3	3
12	Help	2	2
14	Category	93	93
90	Thread	33	33
102	Guide	296	296
103	Guide Talk	16	16
106	Property	122	118
110	Form	26	26
112	Concept	2	2
120	STEP	129	129
121	STEP Talk	2	2
122	Dev	19	19
124	Pack	231	231
125	Pack Talk	1	1
126	NMS	86	87

~z929669 Talk 17:57, 19 October 2020 (UTC)

Thanks, this is helpful. The relevant IDs here are 102 and 106, which are supposed to define SMW properties and PF forms, respectively. It looks like you've defined an enormous number of forms, but that's alright. I would run queries like "SELECT page_name FROM page WHERE page_namespace=102" and "SELECT page_name FROM page WHERE page_namespace=106" to make sure that these namespace IDs do in fact hold properties and forms, respectively. (No need to put the results here.) If those results seem fine, then somehow the namespace IDs are getting messed up in the code. Are you modifying them in any way in LocalSettings.php? Yaron Koren (talk) 17:48, 19 October 2020 (UTC)

I edited the info above to add names as defined by default and in my config: define("NS_GUIDE", 102); and define("NS_GUIDE_TALK", 103); as well as : $wgExtraNamespaces[NS_GUIDE] = "Guide"; and $wgExtraNamespaces[NS_GUIDE_TALK] = "Guide_talk";

Note that I do define 102 but 106 is (and has always been) undefined. I will investigate per your advice and get back. ~z929669 Talk 17:57, 19 October 2020 (UTC)

UPDATE: So it looks like 116 is something new in upgrading (values like Group:Predefined_properties), my Concepts are under 112, my Forms are under 110, and my Properties under 106 in both my old wiki (1.21; Semantic Forms v2.6) and in my upgraded wiki (1.35; Page Forms [latest version]). I have no idea or indication that the default behavior was changed for Semantic Forms, so I'm guessing that 110 used to be used for Form namespace (or perhaps juxtaposed, since 102 is custom?)? Also, 102 does not line up really with 110 (or 106), because that is a many:1 relationship. I haven't figured out how to join 102 data with that of 110/106, but that would be useful. ~z929669 Talk 18:10, 19 October 2020 (UTC)

Ah... no wonder. Well, there may be a simple fix, then: in your LocalSettings.php, you probably have some setting of SF_NS_FORM and SF_NS_FORM_TALK. You just have to change those to PF_NS_FORM and PF_NS_FORM_TALK, respectively. Yaron Koren (talk) 18:25, 19 October 2020 (UTC)

Nope, no namespace defs for *FORM*, but I have customized 102 a long time ago (see my last [edited]). This may have thrown things off in the upgrade process that may not be revealed otherwise? I can easily define the namespaces in my old config and site and upgrade likewise. It would be good to have a clear idea beforehand though ... but I think you have nailed the general issue (whew!). Any ideas? ~z929669 Talk 18:30, 19 October 2020 (UTC)

UPDATE: I went ahead and added PF_NS_FORM* namespaces to my config, and that seems to have fixed the issue :) ... but I still can't see them under Speacial:SpecialPages - Page Forms section. It also looks like my Properties may be conflated with something OOtB in SMW, so perhaps I should explicitly define Page Forms namespaces? Please confirm syntax ... I assume PF_NS_PROPERTY? That appears to be 106/7. ~z929669 Talk 18:43, 19 October 2020 (UTC)

UPDATE2: I explicitly defined Property namespace in my config as SMW_NS PROPERTY* .... this had no impact, so running php /../SemanticMediaWiki/maintenance/rebuildData.php -v, and initial se output is promising with "find and rebuild Property pages ..." ~z929669 Talk 19:18, 19 October 2020 (UTC)

UPDATE3: Rebuilding the data followed by php /../maintenance/runJobs.php has resolved all issues. Many thanks! ~z929669 Talk 19:52, 19 October 2020 (UTC)

Discourse DB examples not accessible

Hi, I'd like to be able to view the Discourse DB wiki that is frequently used to show examples (such as for Spreadsheet-style Editing) but to view such pages requires registering as a User of that wiki. When attempting to do so, there is a recaptcha that asks who the Secretary Of State of the US is, and no SOS from the last 20 years works. Or maybe the format of the name isn't right? Perhaps the question could be changed to something that shifts less often (especially with the current adminstrations high turnover) such "What is the Last Name of the SOS in the year 2013?"--GrapheneBob (talk) 22:05, 19 October 2020 (UTC)

Sorry about that - yes, the CAPTCHA answer is deliberately wrong, to prevent spammers, but it has caused a lot of frustration for real users. I just changed the permissions on Special:MultiPageEdit, i.e. the spreadsheet-style editing you're talking about, so that anyone can view the page. Hopefully I won't regret this. :) I should note that the version of this page on discoursedb.org uses different code from that in the main Page Forms code - this is a long-in-development change that may get checked in sometime this week. Yaron Koren (talk) 17:03, 20 October 2020 (UTC)

Autocapitalize off for mobile

Hi Yaron,

Could you add an "autocapitalize" parameter (keywords being "off", "characters", "words" and "sentences") to the "field" tag to be able to turn autocapitalize off for mobile ? The fix seems to be adding autocapitalize="off" to the search <input> element.

More info : https://developers.google.com/web/updates/2015/04/autocapitalize

Thank you. Best regards.

DSwissK (talk) 09:04, 20 October 2020 (UTC)

Hi! Sorry, I don't understand this. What is autocapitalize - is it the fact that, on mobile devices, the keyboard switches to capital letters before you type the first letter? Or is it something that happens to words after you have already typed them? And do you ever want it enabled, or always disabled? Yaron Koren (talk) 17:17, 20 October 2020 (UTC)

Hi, sorry for not being clear enough. Autocapitalize is usually very useful when using mobile devices (for entering cities, names or states in a form, for example). As you said, the keyboard automatically switches to capital letters before I type de first letter. You can see it live here : https://dicoado.org/dico/Formulaire:Ajouter_un_mot

In the Dico des Ados (since it's a dictionary) it's something I'd like to disable when adding up a word with the form, since only proper nouns start with a capital letter in French. Since way more people add common nouns than proper ones, it'd be better to be disabled by default (which doesn't hinder the person to press shift on his virtual keyboard to start with a captal letter).

I hope this makes more sense now. :)

Best regards. DSwissK (talk) 07:12, 21 October 2020 (UTC)

Okay, now I understand. And that is annoying! But what you are specifically asking for here is a change to the #forminput syntax, which is different from form definitions. Do you need an "autocapitalize" parameter in both? Yaron Koren (talk) 19:37, 21 October 2020 (UTC)

Yes, we do need both. Since we also use parameters that should start with lower-case characters (like synonyms, definition...). DSwissK (talk) 10:53, 24 October 2020 (UTC)

Values from Category and Subcategories

Is it possible to get Values from Category to display subcategories as possible values as well? For my use, I have a database of Books that have a Genre and each book is in a genre category. All of those genre categories roll up to the Genre Category. So a tree is like this:

• Category:Genres
  • Category:Sci-Fi
    • Star Trek
    • Star Wars
  • Category:Fantasy
    • Sword of Shannara
    • Lord of the Rings

My form is for creating new Book pages, and would like to add one or multiple genres to each using tokens. Ideally values come from the subcategories. And if a user enters a genre that doesn't exist yet as a category, it would create a new category page (rather than article)....this part I'm not 100% sure on yet, as it's likely we'll just limit to existing values only. Thanks --GrapheneBob (talk) 15:46, 22 October 2020 (UTC)

If you're fine with limiting it to to just existing values, your best option might be to use the "tree" input type, with the "top category" parameter. Yaron Koren (talk) 15:54, 22 October 2020 (UTC)

Is it possible to store the actual Category page as the value in the cargo field? I see the documentation notes that it strips "Category:" prefix off, and the work around is to set the #arraymap up to add back in "Category:" when it is displayed in the template...But if I have a query that displays this field it will only display the non-category value in the results. Is it A) possible to add "Category:" to the stored value when it is getting stored initially, or B) possible to use #arraymap/similar method on query results to append "Category:" prefix to every value? On the latter, i have tried just using the query as the "string" parameter, but that only appends "Category:" to the sets of values in each record, rather than to each value themselves.

Thank you

Yes, it's possible - just put an #arraymap call within #cargo_store itself, so that it prepends "Category:" onto every name. Yaron Koren (talk) 13:19, 26 October 2020 (UTC)

Populating input with content from a different template

Hello,

Is there any way to populate the default field of input box with a different template content (After it was parsed)?

For example,

{{{field | test | default = {{different template}} }}

Will show the {{different template}} content to the user.

Thanks in advance. --Tufloc (talk) 16:22, 26 October 2020 (UTC)

No, and I don't know why you would want that - won't that lead to redundant content? Yaron Koren (talk) 20:15, 26 October 2020 (UTC)

Tokens only working as dropdown, no text entry

Hi, I am having an issue with token fields only functioning as dropdown menus and not allowing any text entry, rearranging of tokens, or removal of tokens once entered. I reported this as a comment on a similar topic but was advised to create a new topic for it ("Fields of type 'Page' showing as dropdown only instead of text with autocomplete")

PF v4.9.5, MW 1.34.4, Cargo 2.7, and the skin is Citizen 0.9.4. Hosted on Miraheze.

This page form is for entry into a Cargo field that holds a list of Pages. The form itself has values from namespace, and the values in the dropdown are correct. I have a few similar forms all with the same issue. Since I last posted I tried to see if I would have the same issue on another miraheze wiki and I didn't; it works fine. I also switched the Skin I am using which did not fix it. I have removed a bunch of extensions I had, to the point where I matched what that other wiki has, but no luck there either. In the previous topic it was suggested maybe an extension "importArticle" was the culprit or somehow related, but I do not have such an extension.

I looked at "common issues with Select2" that seemed related and it seems this is not an "uncommon" issue, as discussed here, here, and here. I have no idea why it would work on one wiki and not another, though... --GrapheneBob (talk) 16:18, 27 October 2020 (UTC)

It would help if you added "&debug=true" (or maybe "?debug=true"), then looked at the form page again with the JS console - you'll probably get a more helpful error message. It would be good to know which specific JS file the error is coming from. Yaron Koren (talk) 16:27, 30 October 2020 (UTC)

Long delayed response from me on this one as I got caught up in a different project, but here is what I got from debug:

Loading failed for the <script> with source “https://matomo.miraheze.org/matomo.js”. Mundry's_Sundries&debug=true:1:1

Uncaught ReferenceError: importArticles is not defined
    <anonymous> https://khouba.miraheze.org/wiki/Special:FormEdit/Shop/Mundry's_Sundries&debug=true line 11 > injectedScript:1
    jQuery 2
Mundry's_Sundries&debug=true line 11 > injectedScript:1:14

Uncaught TypeError: $.fancybox.getInstance is not a function
    jQuery 3
load.php:130:300

And when I click into the token box an additional message comes up:

JQMIGRATE: jQuery.fn.offset() requires an element connected to a document load.php:1071:746

Hopefully that helps- reading the console is not something I am very familiar with so if the above isn't what you meant, let me know. And I should say, on a second wiki I work on there is not this same issue, so I'm not sure if maybe the skin is causing the issue or something else.--GrapheneBob (talk) 17:12, 18 November 2020 (UTC)

I still think this is due to some outside JavaScript. What's the "injectedScript" that's using a different version of jQuery? Yaron Koren (talk) 18:24, 18 November 2020 (UTC)

[RESOLVED] MultiPageEdit limited to 500 entries

Hello Yaron,

We've updated MW to 1.35 and PageForms to 5.0-alpha (79ec77e) as you can see in Special:Version.

It's really great ! A lot of the bugs we mentioned have been corrected. Thank you ! Raphoraph will be more detailed about this.

I'll just talk about Special:MultiPageEdit which now works wonderfully (no more bugs, as far as I can tell) but is limited to 500 entries (for our website, it's the first 500 defined words). Would it be possible to make it unlimited ?

Thank you ! Best regards.

DSwissK (talk) 15:01, 10 November 2020 (UTC)

I'm glad that overall there is an improvement! Increasing the maximum from 500 would be tricky... I don't know how to do that at the moment, unfortunately. Yaron Koren (talk) 16:36, 13 November 2020 (UTC)

Good news! I looked into it, and was able to figure out a way to handle any number of pages, fortunately without too much trouble. I just checked this in, so if you get the latest code, you should see all the pages within that interface. Yaron Koren (talk) 19:48, 16 November 2020 (UTC)

GREAT news !! 10'933 rows editable today (because we "only" have that many definitions, yet) ! :) Thank you Yaron !! DSwissK (talk) 09:15, 17 November 2020 (UTC)

OK, it felt like Christmas a bit too soon ! :) I edited the line for to add a synonym to the word "sérénité" and the word "multiprise" got edited, as you can see here. I don't see any link between the two, they aren't even near in the Excel-like sheet.

Then I tried to add a variable that was empty (attention) to the word "mot-valise" and this got created. You still have the rights, if you want to test yourself. DSwissK (talk) 10:04, 17 November 2020 (UTC)

That's too bad! Hopefully you will still get Christmas in time. :) I can't replicate either of those issues on my own wiki. Could you please make an administrator on your wiki, if you don't mind? Otherwise it doesn't work for me. Yaron Koren (talk) 19:37, 17 November 2020 (UTC)

You're admin+, enjoy. :) Thanks for your time. DSwissK (talk) 19:53, 17 November 2020 (UTC)

Okay, thanks. This was an interesting one - I think what was causing the problems was that some of those pages call the templates "Article ACGM 2" and "Article ACGM 3", and the spreadsheet was confusing those with the "Article" template. I just checked in some fixes that hopefully fix this problem. Yaron Koren (talk) 22:25, 17 November 2020 (UTC)

Thank you ! It works as it should now. I found another bug though, I'll write a new topic below. By the way, why did you need administrator rights, since I gave "multipageedit" rights to Autopatrol ? DSwissK (talk) 07:06, 18 November 2020 (UTC)

That's a reasonable question. It's because it seems like the default query limit for the API for non-admins is 50, while for admins it's 500 - and the Page Forms code gets its values 500 at a time. This part of the Page Forms JS code should probably be smarter - either check the query limit, or just get the values 50 at a time. Yaron Koren (talk) 18:13, 18 November 2020 (UTC)

Enabling subpages for "Form:" namespace

Hello once again. (To lead developer Yaron Koren: In case you're reading this, I wonder of the circumstances behind Referata's recent 503 errors/service outage [as a former admin].)

On my new ByetHost wiki (whose one-month anniversary is tomorrow), I headed to LocalSettings.php a couple of hours ago in an attempt to enable subpages for the Form namespace (and its accompanying Form talk). Only that, even when adjusting to the official "PF_NS_FORM" declaration, nothing apparently happens. Conversion from "[[/Subpage]]" (in the wiki markup) to "Form:Title/Subpage" isn't taking effect as far as I've tested, and the API gives the output of '"subpages": false,'. (Although the site-specific custom namespaces I already added don't have this problem.)

Either that's definitely a hitherto undiscovered bug, or PF already has that prevention built in. Which scenario is true?

(MW 1.35)

--Slgrandson (talk) 10:32, 12 November 2020 (UTC)

I'm guessing that it's because PF_NS_FORM is not defined yet when you're making use of it in LocalSettings.php. You may need to hardcode the ID there. Yaron Koren (talk) 16:37, 13 November 2020 (UTC)

"Text with Autocomplete" in File field clearing when loading form

Hi, I have a Text with Autocomplete field that is giving me a couple of issues. The field is to store an image in a Cargo field. The cargo database field is set to File. I can enter in a file name into the field and have it save to the database correctly, but if I go back into the form to make another change the field clears...and consequently when saving the form it removes the previously saved image from the database. The field isn't behaving the way other fields do on load, populating with their existing values. Here is my field:

{{{field|Image|input type=combobox|values from namespace=File|uploadable|class=cargo-form-image|image preview|default filename=<page name>}}}

A second issue that I'm less concerned with at least right now is that I can't seem to get "values from namespace" to work here. I have tried switching to text with autocomplete with no luck, and adding cargo table=|cargo field=| because it seems that the only values that do come up are existing values in the database (not the namespace). "Dropdown" for input type works as expected, showing me all the files in the File namespace...but then there is no option to upload, and with a long list of files it is very tedious. --GrapheneBob (talk) 20:46, 17 November 2020 (UTC)

I checked in a fix for combobox handling earlier today, which might fix at least some of these problems. Could you try it again with the latest code? Yaron Koren (talk) 22:26, 17 November 2020 (UTC)

Seems to have worked! Thank you for the help! --GrapheneBob (talk) 16:14, 18 November 2020 (UTC)

I'm surprised that fixed all the issues, but I'm glad to hear it! Yaron Koren (talk) 18:14, 18 November 2020 (UTC)

Symbol "+" gets erased when using Special:MultiPageEdit

As you can see here, the plus symbol ("+") gets automatically deleted when editing a page with MultiPageEdit. I'm not sure if it's the only sign that gets that treatment. DSwissK (talk) 07:12, 18 November 2020 (UTC)

Sorry about that! And thanks for uncovering all these issues. I just checked in what I think is a fix for this. Yaron Koren (talk) 18:22, 18 November 2020 (UTC)

Don't be sorry Yaron. I'm happy that the issues are being solved. :D See, it works !! Thank you ! So now it does look like Christmas. I'll tell my team they can try that tool and get back to you if we encounter anything odd (only admins yet, though, if I got it right ?). Kind regards. DSwissK (talk) 20:34, 18 November 2020 (UTC)

Great! For now, yes - although I really should change that part of the code to be "smarter". Yaron Koren (talk) 23:56, 18 November 2020 (UTC)

Allowing the one step process when using a default form

Hi

I love this extension :-)

My default form, defined on a namespace, uses the 'one step' process to generate a name for the page. It then uses a field in the form and Display Title to define the text that the User sees as the page title and refers to the page by in links.

This works great if I have a item on the sidebar to create new pages. However, when there is a red link referring to a missing page, the name given in the link is used as the name for the page in the form rather than the generated name. This makes perfect sense for many cases, but I wonder if there is, or could be, an option on the #default_form parser function similar to #formredlink that would tell the default form to generate the page name and put the supplied text into a field in the form?

Many thanks

DuncanCrane (talk) 10:39, 23 November 2020 (UTC)

Thanks! That's an interesting idea - I don't think it's possible now. But is there an actual problem with the current behavior? Do you want the name of the page created to sometimes be different from the text of the red link? Yaron Koren (talk) 14:21, 23 November 2020 (UTC)

Hi Yaron, yes I am hoping to get the name to be different from the text of the red link. I use the 'one step' process in Page Forms so that each page created with a form has a name which has a format 'aaaxxxxxxxx' where 'aaa' is an alha prefix which is unique to the form (and the table associated with it) and the 'xxxxxxxx' is a unique number identifying each table entry. I then use Cindy's DisplayTitle extension so that the content of another field on the form can be set to be the Display Title of the page.

This works really well as it allows users to edit the displayed title of the page without having to use redirects, which is something my users are really keen on!

However, users will often insert links in the page where the page doesn't exist already. They are using the TinyMCE editor, of course, so aren't really aware of the underlying wiki markup. The redlink that mediawiki will create for these will point to the correct form, but it doesn't use the generated key when the user clicks on the link. Apart from making the keys a bit of a mess, this could ultimately lead to page naming conflicts which would be difficult to manage neatly.

The current way of working for #default_form is fine for many cases, but it would be really neat if the syntax could be extended to allow it to also have additional parameters, similar to #formredlink. That way it would only be necessary to code it once in the #default_form call on the namespace or category page.

I was thinking something like:

{{#default_form:form-name|display title=form-name[field-name]}}

When a red link in the namespace or category is clicked, the relevant form would be displayed with the generated name and the field 'field-name' would be pre-populated with the page name text in the link. If there was no generated name then the text from the link would be used. If the field didn't exist in the form then the text from the link would be ignored. If the parameter was omitted, it would operate exactly as now.

Because of the way DisplayTitle works, the original link would automatically be directed to the new page that was created.

This would meet my needs, but there are other features of #formredlink that may also be useful?

DuncanCrane (talk) 15:56, 23 November 2020 (UTC)

It sounds like you should be using #formlink, then, not #formredlink. I don't know how exactly you're generating the #formredlink calls, but I'm guessing there's a way to change it to use a combination of regular links and #formlink. Yaron Koren (talk) 19:04, 23 November 2020 (UTC)

Hi Yaron, I'm not sure I really explained myself well (which is not unusual:) ). I'm not using either #formlink or #formredlink, I'm using #default_form.

Of course, you are right, if I use a #formlink as follows:

{{#formlink:form=Article|link text='No Page'|query string=Article[Title]='No Page'}}

This will generate the following link in the wiki page:

https://www.mywebsite.farm/index.php?title=Special:FormEdit/Article%5BTitle%5D=No_Page

Clicking this in the wiki page will open the Article form with 'No Page' in the Title field and a generated name, in this case ARTxxxxxx, where the xxxxxx is a generated integer. That is exactly the behaviour I want.

Now suppose I have {{#default_form:Article}} defining the #default_form for the Main namespace. In the wiki page I have a link to a non existent page, [[No Page]]. This will create the following link in the wiki page:

https://mywebsite/index.php?title=No_Page&action=formedit&redlink=1

Clicking this in the wiki page will open the Article form with nothing in the Title field. The page name will not be generated but be set to 'No Page'. No problem there, that is the way it works. What I have in mind though is a new feature that extends the #deafult_form parser function to allow the following:

{{#default_form:Article|display title=Article[Title]}}

Then if the user put [[No Page]] in a page this would generate a link that was equivalent to them putting {{#formlink:form=Article|link text='No Page'|query string=Article[Title]='No Page'}} instead eg:

https://www.mywebsite.farm/index.php?title=Special:FormEdit/Article%5BTitle%5D=No_Page

The rationale for this is that it is a lot easier for the user to write [[No Page]] as they don't need to know anything about the form or fields. Also it gives the developer the freedom to change the #deafult_form without needing to change any of the links. If the 'display title' modifier was omitted from the #default_form parser function call, then it should behave exactly as it does now.

DuncanCrane (talk) 10:33, 24 November 2020 (UTC)

The problem with that approach is that you have a red link to a page called "No Page" - and then a user clicks on it, gets to a form for creating a page, submits it - and then when they go back to the first page, there's still a red link to "No Page", since the page they created has a different name. That can be quite confusing, no? Yaron Koren (talk) 14:11, 24 November 2020 (UTC)

Yes, I can see that would be a problem. I believe that the DisplayTitle extension should cater for this situation, ie if the DISPLAYTITLE is set on a page and the DisplayTitle extension installed then the DISPLAYTITLE could be used in links in [[]] to that page. I've just tried that and, as you said, the link remains a red link. I wonder if @Cindy.cicalese can help here? DuncanCrane (talk) 09:28, 25 November 2020 (UTC)

This doesn't seem like something that could be solved by using the display title - you can map from a real page name to its display title, but I don't think you can go the other way around (especially because multiple pages can have the same display title). Yaron Koren (talk) 17:06, 25 November 2020 (UTC)

Right, there is no current solution for mapping a display title to a page name with DisplayTitle. There is a bit of discussion about this at Topic:Uzg42yi6wfrercty. Cindy.cicalese (talk) 21:33, 25 November 2020 (UTC)

Thanks Cindy, seeing the discussion is v. helpful. When I have a little time I may investigate/experiment a little further and revert to you and Yaron if I have any fresh ideas. :-) DuncanCrane (talk) 07:49, 26 November 2020 (UTC)

Error on "Special:CreateProperty" & "Special:CreateClass"

Using either of these yields the following trace:

[ad35007d9c4a0e552d49f40a] /wikidev/Special:CreateProperty Error from line 99 of /srv/sites/_wikidev/extensions/PageForms/specials/PF_CreateProperty.php: Call to a member function getDatatypeLabels() on null

Backtrace:

#0 /srv/sites/_wikidev/extensions/PageForms/specials/PF_CreateProperty.php(22): PFCreateProperty->printCreatePropertyForm()
#1 /srv/sites/_wikidev/includes/specialpage/SpecialPage.php(600): PFCreateProperty->execute()
#2 /srv/sites/_wikidev/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run()
#3 /srv/sites/_wikidev/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#4 /srv/sites/_wikidev/includes/MediaWiki.php(940): MediaWiki->performRequest()
#5 /srv/sites/_wikidev/includes/MediaWiki.php(543): MediaWiki->main()
#6 /srv/sites/_wikidev/index.php(53): MediaWiki->run()
#7 /srv/sites/_wikidev/index.php(46): wfIndexMain()
#8 {main}

Problem with SMW integrations?

Sorry about that - this was a bug that was fixed about two months ago. I hope to release the next version of Page Forms soon. Yaron Koren (talk) 17:07, 25 November 2020 (UTC)

Pre-Populate Form Field

I'd like to pass a value from the initial Form:* start into the Form itself if possible. Here's the scenario:

• The Form entry page requests the user to choose a namespace from values predefined in the Form: {{#forminput: form=Mod|default value=Mod/|namespace selector=SkyrimLE,SkyrimSE,NMS}}

Side note: I also have the same values defined in Property:Game using [[allows value::*]], so that may also be leveraged here.

• The form itself has a field for holding this same value: {{{field|game|size=30|property=Game}}}

I've figured out how to populate the info on page creation (when saving the Form) but not within the Form itself. The problem with this method is that the user will select the Property value from the dropdown menu, which is redundant, since the namespace name is identical to the Property value (and users can make mistakes, causing an inconsistency). I could hide this field to avoid the potential problem, but then it would not be available on form-edit after the page has been created (probably a rare need, but possibly useful nonetheless).

Is there a way for me to pre-populate the field using the namespace value chosen at Form start?

---

Follow-up Qs:

1. Note that my #forminput above specifies: default value=Mod/. I can't find any way to prevent users from overwriting this when they input a subpage name. The intention is to 'persuade' them into adding the subpage string.
2. Once the page is created, both the basepagename and the subpagename appear in the Category page names when viewing the respective Category. I tried using #titleparts to strip off only the subpage for the Category listing via the associated Template (CategoryModList), but it's not working. This is not a Page Forms issue, but maybe you have an idea. Category page listing:

{{#ask: [[Category:Mods]] [[Section::SE-D]]
|format=template
|template=CategoryModList
|?IsCore
|limit=300
}}

Thanks in advance! ~z929669 Talk 17:54, 1 December 2020 (UTC)

Do you know about #formlink and the "one-step process"? Using that may solve some or all of your problems. Yaron Koren (talk) 21:20, 1 December 2020 (UTC)

I looked at that and tried some things with no luck. Specifically passing the "namespace selector" value chosen in #forminput doesn't appear to be possible using #formlink ... at least not in a way that I can see. Same goes for the other Qs I posed. I've played with #formlink and "query string" in #forminput with no useable results. ~z929669 Talk 21:40, 1 December 2020 (UTC)

Right - with #formlink you would select the namespace in the form itself. Which is what you wanted to do anyway, no? Yaron Koren (talk) 21:50, 1 December 2020 (UTC)

So, link to my form using #formlink and get the namespace there ... unsure what parameter to use in the #formlink. If only the namespace would resolve in the Form itself, I would be golden, but it doesn't parse: {{{field|game|size=30|default={{NAMESPACE}}}}} ~z929669 Talk 22:12, 1 December 2020 (UTC)

Finally figured out what you are saying. I swapped the #forminput method and used #formlink: {{#formlink:form=Mod2|link text=Create a mod page|link type=button}}. Created new Form:Mod2 page with {{{info|create title=Create new Mod page|edit title=Edit Mod page|page name=<Mod[game]>:<Mod[fullname]>}}}. That got me what I wanted. Thanks! ... I will look into my other problems using this method and will get back if I need a nudge. ~z929669 Talk 23:02, 1 December 2020 (UTC)

Great! Yaron Koren (talk) 15:48, 2 December 2020 (UTC)

Mixing mandatory, optional and arbitrary sections

Hello! I've had great success in using page forms, but this use case is baffling me. Basically, here is the page layout I'm trying to get support for in PF:

{{Some template}}

Some introductory text

== Mandatory section 1 ==
Some text ...

== Optional section 1 ==
Some text ...

== Arbitrary section ==
Some text ...

== Mandatory section 2 ==
Some text ...

== Mandatory section 3 ==
Some text ...

== Arbitrary section ==
Some text ...

Some sections are defined in the form, they are either optional or mandatory. However, the editor can add arbitrary sections wherever in the text. Here are some links to the actual pages in my wiki:

• A page
• the form
• the page being edited in the form

Putting free text fields between my sections does not seem to work. Is this use case supported by PF? Thanks! Tinss (talk) 23:40, 3 December 2020 (UTC)

I had to look up "facultative". :) I guess it means "optional". Yes, what you're trying to do is too complex for Page Forms - and you can't have more than one "free text" input in a single form. You might be better off just having inputs in the form for the template fields, and having one big free text input for everything else. Yaron Koren (talk) 01:28, 4 December 2020 (UTC)

Thanks Yaron, haven't been using English for a while :) I've updated the title of the section to make it easier to find should someone come up with a similar question. Tinss (talk) 04:30, 8 December 2020 (UTC)

Does input type=tree work with Page Forms 5.0 and MediaWiki 1.35.0?

input type=tree appears to hang indefinitely on my wiki. Is anybody experiencing the same, or experiencing the opposite? The browser's console reports: Uncaught SyntaxError: JSON.parse: unterminated string at line 1 column 22627 of the JSON data - setOptions jQuery --Choralia (talk) 21:00, 6 December 2020 (UTC)

It works fine for me. How are you setting the values for that tree - manually, or from a category? And if it's manually, could there be a syntax error in your list of values? Yaron Koren (talk) 13:48, 7 December 2020 (UTC)

Values are set from a category. It seems that the problem shows up when the selected category contains sub-categories, and at least one of the subcategories includes an apostrophe in its name. I guess that the apostrophe character has to be escaped somewhere in the code. --Choralia (talk) 07:50, 8 December 2020 (UTC)

I can't reproduce this problem - I'm using the same versions of the software, and a subcategory with an apostrophe in its name, and everything works fine. Are you sure it's the apostrophe, in your case? Yaron Koren (talk) 16:17, 10 December 2020 (UTC)

This is the test form that I've created to easily reproduce the problem:

{{{for template|Test template}}} {| class="formtable" | {{{field|test|input type=tree|top category=Test category 1| }}} |} {{{end template}}}

Test category 1 then includes Test category 2 as a sub-category, and the query page correctly displays the tree. If I rename Test category 2 as Tes't category 2, the query page hangs. Is there anything wrong with the form code? --Choralia (talk) 07:37, 11 December 2020 (UTC)

I don't know - I tried out that form, and it works fine for me with both variations on the category name. And I'm using roughly the same versions of MW and Page Forms. This might be a browser issue - does it happen for you with multiple browsers? It might also be an issue with PHP or MySQL settings, but I don't know what. Yaron Koren (talk) 20:29, 14 December 2020 (UTC)

It's the same with all browsers. I've also made a fresh MediaWiki installation on the same server, and results are the same. Then I've made a fresh installation on another server, and results are the same again. You can check it here. I noticed that the variable data that is passed to JSON.parse() at line 23 of PF_tree.js is trunkated at the apostrophe position. --Choralia (talk) 19:32, 19 December 2020 (UTC)

Where are you seeing it get truncated? Yaron Koren (talk) 02:29, 21 December 2020 (UTC)

I've now added an alert(data); instruction just before line 23 of PF_tree.js so that you can see the content of the variable data. It reports [{"text":"Test category 1","level":1,"state":{"opened":true},"children":[{"text":"Tes, so it is trunkated where the apostrophe of Tes't category 2 occurs --Choralia (talk) 06:47, 21 December 2020 (UTC)

Okay, it's very helpful to see the HTML on the site. Now I see what's going wrong - this is a bug that was actually fixed about two weeks ago. I'm planning to release a new version of Page Forms in the next few days, so if you only want to use released versions, the fix will be available soon. Yaron Koren (talk) 15:35, 21 December 2020 (UTC)

I've cloned the extension via git, and it's OK, thank you very much. For the actual wiki I think I'll wait that the new version is published as I still have several MediaWiki 1.35 compatibility problems with other extensions to address (we make use of DPL 3.3.3 on many pages, which is not compatible with MW 1.35). Thank you very much for fixing this, at least one problem is solved now. --Choralia (talk) 06:41, 22 December 2020 (UTC)

Token input problem in foreign language (Korean)

Hello, I am experiencing a problem when I use the token input type in a foreign language (Korean) - English works fine. I set $wgPageFormsCacheAutocompleteValues = true; but I am still having errors. For example, when I try to type anything, each letter is input multiple times (for example, "apple" becomes something like "apaplappaplee"). Strangely, the backspace button ends up adding even more letters to the end rather than deleting them (for the first two presses, from the third press or so it begins deleting them.). Any thoughts on what the problem could be? --Lyndsey022 (talk) 07:48, 8 December 2020 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 20:05, 8 December 2020 (UTC)

Issue with External Data

Hi Yaron, I tried the External Data option but it didn't work for me. The use case I set up for testing retrieves data from the MW API for user edits and is working like a charm when used on a regular page. When used within a form, however, with values from external data rather than #for_external_table, the form hangs indefinitely, and I'm getting an wgPageFormsEDSettings[name] is undefined error in the console. I later noticed that I cannot print any data with #for_external_table within a form either. Apparently then, #get_web_data cannot be used to retrieve data when used within a form. Cavila 10:35, 8 December 2020 (UTC)

Yes, indeed! It turns out that "values from external data" has not worked for the last eight months or so, due to code changes in both Page Forms and External Data. I think no one pointed it out until you, which maybe means that it's not that popular of a feature. I just checked in some changes to both PF and ED to get this working - so if you get the latest code for both extensions, it should hopefully start working again. Yaron Koren (talk) 15:16, 10 December 2020 (UTC)

Thanks once again. Not everyone is immediately vocal or keeps up to date with the latest version of the extension but it's more of an advanced feature anyway. Cavila 14:34, 19 December 2020 (UTC)

Problem with autocomplete and 'value from category'

Hi, I am having a problem with using a textfield and the 'value form category' parameter. When I enter a value without an existing page in the category, the value gets saved. But when I open the form again, the input field clears. Furthermore, it works when I use a textarea and allow multiple values, as long as I am not using the #formredlink template. In that case it also doesn't work and the textarea appears as an empty textfield.

{{#arraymap:{{{employer|}}}|,|x|{{#formredlink:target=x|form=Institutiton}}{{#set:has_employer=x}}}} doesn't work,

{{#arraymap:{{{employer|}}}|,|x|[[has_employer=x>]]}} works.

I am using Mediawiki 1.34.2, Semantic Mediawiki 3.2.0 and PageForms 5.0. I am new so I don't know if it's a bug or if I am using it wrong. If someone can point me in the right direction, that would be awesome :) Pmuehleder (talk) 11:34, 11 December 2020 (UTC)

It seems very strange that the form would work differently depending on what's in the template - at least, given that you're using "values from category" and thus there is no parsing of the template involved. What does the exact field tag look like in the form? Yaron Koren (talk) 14:01, 11 December 2020 (UTC)

Thanks for the quick reply! The form looks like this: {{{field|employer|input type=textarea with autocomplete|values from category=Institutions}}} . Pmuehleder (talk) 14:22, 11 December 2020 (UTC)

Oh, now I get it - "values from category" works for you if the input type is "tokens", but not when it's "combobox". (In Page Forms 5.0, "textarea with autocomplete" is just an alias for either "combobox" or "tokens", depending on whether the field holds a list of values.) I was able to replicate this problem - it happens when the autocompletion is done "locally", meaning the values are stored in the page itself. Sorry about that! I just checked in what I think is a fix for this problem. Yaron Koren (talk) 20:34, 11 December 2020 (UTC)

Thank you so much for the fix! I get it now :) It works fine now when I specify "tokens" in the form field. When I use "textarea with autocomplete", it still uses "combobox" even if there is a list of values, with all values in one string ("University A,University B"). But all values are present now. Pmuehleder (talk) 07:47, 13 December 2020 (UTC)

That's great! To clarify, the code sets whether to use "tokens" or "combobox" based only on what's in the template, not what's on the page. Though you'd be safer specifying "combobox" or "tokens" directly. Yaron Koren (talk) 00:29, 14 December 2020 (UTC)

Deselect Last Tokens Selection

This is an echo of a previous question.

I'd like to be able to deselect the last entry in an input type=tokens form element. But, when I try to do that, the first item in the droplist is selected and then, when I blur, that selected item is readded into the form element.

Is there a way to modify the tokens type to allow an empty selection -- in other words, to be able to deselect the last element -- after a value has been selected?

I thought all issues with "tokens" had been fixed already. What version of Page Forms are you using? Yaron Koren (talk) 17:18, 20 December 2020 (UTC)

Passing Parameter Values Into Field Definition

I have a form for creating pages based upon namespaces using |namespace selector=| in my #forminput parser. I am trying to create a single Form for not only creating pages across various namespaces using this method, but some of the field definitions also require that these namespace names be passed into the parameter definitions to work. Example (on the Form itself):

{{#forminput:form=GuideVersion|namespace selector=namespace1,namespace2, ... namespaceN}}
...
{{{field|name|input type=dropdown|values from concept=namespaceN_commonConceptName}}}

Is it possible to re-apply the chosen 'namespaceN' to the "values from concept" definition? If not, then I will need to create a separate form for each namespace. Additionally, I need to use this same variable elsewhere in the form definition. The only source for the single correct value for namespaceN is provided by the User upon selecting a namespace. Similarly, I would have the same problem using #formlink, where I can set page creation using a selected namespaceN per user input into a field on the form itself. I still have the problem of using namespaceN elsewhere in the form/field definition(s)

I suppose a similar question would be, is it possible to define an entire Form using a Template? That would also allow me to pass variables as a replacer for pretty much any string anywhere in the Form ... but that seems like overkill and problematic for any number of reasons. ~z929669 Talk 20:06, 21 December 2020 (UTC)

Well, duh .... it seems to have been as easy as using {{NAMESPACE}}. I thought that was too simple and simply failed to try it. Will post back if further issues. Thanks! ~z929669 Talk 01:43, 22 December 2020 (UTC)

I'm surprised that that worked - I would have thought, given that the URL probably looks like "Special:FormEdit/...", that NAMESPACE would display NS_SPECIAL (or its numerical equivalent). But I guess not. Yaron Koren (talk) 15:03, 22 December 2020 (UTC)

Well, preliminary testing shows the correct result ... but I have yet to really implement in all applicable instances and test it for true. I'm still skeptical and will post back after I get that far. ~z929669 Talk 16:23, 22 December 2020 (UTC)

Wikieditor for free text standard input not loading

I was attempting to add |editor=wikieditor to my free text standard input in a form. I'm using MW 1.35 and the composer install of PageForms (composer.lock states it is PF5.0 at de93c72f). Not sure if there's something else I need to do in places other than the form to get this to work, I do not have any custom wikieditor toolbars at the moment so I didn't have anything to add in the Common.js to my knowledge. Anyone have clues how to get this to work? It would be really nice for the users of this form I'm building. -Rina

Yes, I see the problem too. It looks like the culprit is this big change to the WikiEditor code in July 2019, right after the release of MW 1.33. So until someone fixes the Page Forms WikiEditor integration code, I fear "editor=wikieditor" will not be usable. Yaron Koren (talk) 15:44, 22 December 2020 (UTC)

Darn! Maybe I can get TinyMCE to work too, I was having issues with it too but I was assuming that I was failing at configuration with that one rather than something else bigger going on like what is happening with wikieditor. Thanks for the reply!! -Rina

Is it possible to nest multiple-instance templates?

I have a functioning MIT that I'd like to nest inside of another MIT if possible. The Embedded Templates section of the documentation indicates that this cannot be done with embedded templates, but such a note does not exist under Multiple-Instance Templates section of the doc, so I am just confirming before continuing in my failed attempts to do this. Thanks! ~z929669 Talk 20:51, 22 December 2020 (UTC)

No, it's not possible - you can't store a three-dimensional array of data. Yaron Koren (talk) 21:25, 22 December 2020 (UTC)

Drat ... I figured. Thanks for sparing me the wild goose chase. ~z929669 Talk 22:39, 22 December 2020 (UTC)

Share a link of result of a query form

HI, I'm using a query form, the problem is that the query form is using post to send the params, means I cant share the full link to a specific search. There is any other way to share a link to a specific share, I'm talking about a dynamic option (and not using predefine #queryformlink:form). Like, when a user is searching something he will be able to share it.

Thank you!

It sounds like you're using a rather old version of Page Forms - Special:RunQuery changed from POST to GET about two years ago. I would upgrade Page Forms, if possible. Yaron Koren (talk) 15:20, 29 December 2020 (UTC)

My bad, tyvm! Koshob (talk) 11:31, 1 January 2021 (UTC)