Extension talk:Page Forms

From mediawiki.org
Jump to navigation Jump to search

#formredlink inside list created by #ask?[edit]

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::Extension talk:Page FormsKategorie: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)[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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 Ixian Insignia SM.png 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 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: 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 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 php /../SemanticMediaWiki/maintenance/rebuildData.php -v, 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 php /../maintenance/runJobs.php has resolved all issues. Many thanks! ~z929669 Ixian Insignia SM.png Talk 19:52, 19 October 2020 (UTC)

Discourse DB examples not accessible[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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)
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"[edit]

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)