Extension talk:Page Forms

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

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


 * My current workaround is setting   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:

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)

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:


 * ~z929669 Ixian_Insignia_SM.png 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:  and   as well as :   and
 * Note that I do define 102 but 106 is (and has always been) undefined. I will investigate per your advice and get back. ~z929669 Ixian_Insignia_SM.png 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 Ixian_Insignia_SM.png 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 Ixian_Insignia_SM.png 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 Ixian_Insignia_SM.png 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, and initial se output is promising with "find and rebuild Property pages ..." ~z929669 Ixian_Insignia_SM.png Talk 19:18, 19 October 2020 (UTC)
 * UPDATE3: Rebuilding the data followed by  has resolved all issues. Many thanks! ~z929669 Ixian_Insignia_SM.png 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 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,

Will show the   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)

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)

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 " " declaration, nothing apparently happens. Conversion from " " (in the wiki markup) to " " isn't taking effect as far as I've tested, and the API gives the output of ' '. (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)