Embedding query form and show result in special page

I'm trying to embed a query form in a box in one of my portal pages. But when running the query, the results are displayed inline, instead of the box. I want to have the results displayed in the relevant Special:RunQuery page, i.e. redirect to that page. Is that feasible? 93.172.5.219 19:32, 24 May 2025 (UTC)

What do you mean by "inline"? Anyway, I don't think there's a way to have the form redirect to Special:RunQuery, unfortunately. Yaron Koren (talk) 14:04, 26 May 2025 (UTC)

By "inline" I mean that the page reloads, only with the query results instead of the original embedded form. I would have liked it to reload to a different page, so I can embed a "search" box in my portal. I believe others may find this feature useful as well 93.172.170.226 20:13, 27 May 2025 (UTC)

Embedding and preloading a query form at the same time?

Hi Yaron, first of all, thank you very much that you still maintain your powerful extensions!

I would like to embed a query form on my page that displays results automatically from the very beginning.

I can embed my form with {{Special:RunQuery/query form name}}, but for some reason it doesn't work if I use {{Special:RunQuery/query form name?template-name[item-name]=value}} or {{Special:RunQuery/query form name?template-name[item-name]=value?_run}}.

Is this supposed to work? Stefahn (talk) 15:37, 15 January 2025 (UTC)

That's a limitation of MediaWiki; I don't know if you can get around it. One option is to add those values as "default" values in the form itself, though that won't pre-run the query. You could potentially do both by adding all those values in to the query string of the page itself, maybe in links to that page. Yaron Koren (talk) 18:33, 15 January 2025 (UTC)

Thanks for your quick reply. I found a way to work around this. If anybody is interested: I installed the extension UrlGetParameter and implemented this wikitext: {{#ifeq:{{#urlget:pfRunQueryFormName}}||{{#ask:MyQuery}}}}

This way my initial query is only shown if the URL parameter pfRunQueryFormName does not exist, i.e. the user didn't hit the search button yet. If the user hits the search button, the dynamic search is shown, but the initial query is no longer shown :)

Still need to find a way to add #My-Search-Section to the URL if the user hits the search button, in order to prevent that the user is taken to the very top after he hit the search button... Stefahn (talk) 18:51, 17 January 2025 (UTC)

How to I Edit a Form

I want to change the order of a couple templates I used in a form. I haven't been able to find a way to edit an already created form. I can edit pages using a form, but that's not what I'm looking for. How do I edit the form itself? Irish brigid (talk) 17:14, 22 January 2025 (UTC)

Just go to the page for that form, at Form:form-name. The form definition is just wikitext, so it can be edited like any other page. Yaron Koren (talk) 23:10, 22 January 2025 (UTC)

Ah. Thanks. Might make more complex edits a little difficult, but at least it can be done. Irish brigid (talk) 03:39, 23 January 2025 (UTC)

"Values dependent on=" does not work

This is described at: https://www.mediawiki.org/wiki/Extension:Page_Forms/Values%2C_mappings_and_autocompletion#Dependent_autocompletion

I've created what I think what should recreate the example given, but it just does not do anything: no matter which value is selected for "Country", all previous values of "City" are suggested for auto-completion.

Template:Restaurant

<noinclude>
{{#template_params:Country|City}}
{{#cargo_declare:_table=Restaurants|Country=String|City=String}}
</noinclude><includeonly>{{#cargo_store:_table=Restaurants}}
{{#template_display:_format=infobox}}</includeonly>

Form:Restaurant

<noinclude>
This is the "Restaurant" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Restaurant}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Restaurant}}}
{| class="formtable"
! Country: 
| {{{field|Country|input type=combobox}}}
|-
! City: 
| {{{field|City|input type=combobox|values dependent on=Restaurant[Country]}}}
|}
{{{end template}}}

'''Free text:'''

{{{standard input|free text|rows=10}}}
</includeonly>

Thanks Jonathan3 (talk) 12:47, 3 February 2025 (UTC)

I just tried this, and it works for me. Are there any errors in the JavaScript console? Yaron Koren (talk) 15:15, 3 February 2025 (UTC)

I don't think so. I've tried it on two completely separate wikis and it doesn't work for me. Both are on MW 1.39 and Page Forms master branch. Jonathan3 (talk) 14:59, 7 February 2025 (UTC)

Should "values dependent on=" work with list fields?

Can either of the two fields (e.g. the main "Country" field or the dependent "City" field) be a list field?

Also, what input types are allowed? Thanks. Jonathan3 (talk) 12:48, 3 February 2025 (UTC)

No - only comobobox and (I think) tokens. Yaron Koren (talk) 15:15, 3 February 2025 (UTC)

"displayed fields when minimized=" does not seem to work

When I use this parameter with any field names, it just says "No results". When I don't use the parameter, only the value of the first field is shown.

Previously (based on hazy memory, and the topic at https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_May_to_December_2024#%22displayed_fields_when_minimized%22_not_working) it (wrongly) used to show every field.

What should I do? Thanks. Jonathan3 (talk) 14:34, 3 February 2025 (UTC)

I just tried this, and it works fine for me, both when the parameter is used and not used. Do you see any errors in the JavaScript console? Yaron Koren (talk) 15:21, 3 February 2025 (UTC)

autoedit removes all subobjects

We just upgraded Page Forms from 5.4 to 5.9.1 and noticed that 'autoedit' functionality which we were using for a very long time to add subobjects to the page is now broken (it was one of the most appreciated and useful feature we used to implement page workflows and used it to record and track workflow transitions: who, when, what).

autoedit link still adds a new subobject (record of workflow transition in our case) to the page (as expected and as defined in the autoedit element) but at the same time removes all 'old' subobjects (records of past transitions).

Any suggestions / recommendations how to make it work again? Were there any changes in the api/functionality we didn't notice/should be aware of?

Page modified via autoedit

{{Specification Requirement
|status=Review
|statement=System shall ....

|transitions={{Workflow Status Change
|workflow=Status
|user=XXX
|endstate=Draft
|timestamp=2024-12-09T16:01:00Z
}}{{Workflow Status Change
|workflow=Status
|user=XXX
|endstate=Review
|timestamp=2024-12-11T13:45:00Z
}}{{Workflow Status Change
|workflow=Status
|user=XXXX
|endstate=Draft
|timestamp=2024-12-13T12:59:00Z
}}

..

}}

autoedit element

• History is a subobject property holding 'transitions'
• @WORKFLOWCOUNT properly evaluates to 'number of Workflow subobjects' + 1

{{#vardefine:@WORKFLOWCOUNT|{{#expr:{{#ask:[[History::{{PAGENAME}}]]|format=count}}+1}}}}

{{#autoedit:form=Specification Requirement
|target={{PAGENAME}}
|link text=[[Image:Back arrow.png|link=|20px]] Back to Draft
|query string=Specification Requirement[status]=Draft&Workflow Status Change[{{#var:@WORKFLOWCOUNT}}][uuid]={{UUID}}&Workflow Status Change[{{#var:@WORKFLOWCOUNT}}][workflow]=Status&Workflow Status Change[{{#var:@WORKFLOWCOUNT}}][user]={{CURRENTUSER}}&Workflow Status Change[{{#var:@WORKFLOWCOUNT}}][endstate]=Draft&Workflow Status Change[{{#var:@WORKFLOWCOUNT}}][timestamp]={{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY2}}T{{CURRENTTIME}}Z
|summary=Changing state to "Draft"
|reload }}

Form_Specification Requirement

{{{for template|Specification Requirement}}}

<div style="display:none">
{{{field|transitions|holds template}}}
</div>

{{{field|status|input type=text|mandatory|size=50|default=Draft|hidden}}}
..display status ..

{{{field|statement|input type=textarea|mandatory|rows=5|autogrow}}}

{{{end template}}}

{{{for template|Workflow Status Change|multiple|embed in field=Specification Requirement[transitions]}}}
{{{field|uuid|default=uuid|hidden}}}
{{{field|workflow|input type=text|size=50|cols=50}}}
{{{field|user|input type=text|size=50|cols=50}}}
{{{field|endstate|input type=text|size=50|cols=50}}}
{{{field|timestamp|input type=datetimepicker}}}
{{{end template}}}

After executing above autoedit all 'old' 'Workflow Status Change' elements which existed on the page are removed and 'transitions' attribute holds only the one 'Workflow Status Change' element for the transition defined in autoedit element.

Previously it was added to the existing list. Mourawi (talk) 23:25, 3 February 2025 (UTC)

What does the #autoedit call look like? Yaron Koren (talk) 06:40, 4 February 2025 (UTC)

I added code snippets above. We use that pattern on many concepts and in many Wiki instances.

It was working with Page Forms 5.4 and MW 1.35, now seems to be broken with Page Forms 5.9.1 and MW 1.39.

Mourawi (talk) 13:44, 4 February 2025 (UTC)

Improvements to "uploadable" inputs - default filename, categorisation

It would be good if the default filename parameter could allow the file extension to be set automatically according to the actual file's extension. This would be useful for images, which could be .jpg, .png etc.

It would also be good if there were a category parameter to categorise the related "File:" page. Jonathan3 (talk) 03:01, 5 February 2025 (UTC)

Special:ask whitelist

Hi,

I'm kind of stuck on how to allow anonymous users to use/access the Special:ask query function, and hope someone here can advice.

I have a Mediawiki 1.39.7 with Semantic Mediawiki extension. The 'special:' pages are locked down so anonymous users can't access them.

The problem is that there is tables that anonymous users should be able download. This is prevented by the fact that the 'special:ask' pages are locked down.

Ex:

https://exwiki.org/wiki/Special:ask/-5B-5BBok::530-5D-5D-20-5B-5BStatus::Gjeldende-5D-5D/-3FBok/-3FKapittel%3DKap./-3FVedlegg%3DVedl./-3FKravtekst/-3FKravtype/-3FKravhensikt/-3FMerknader/mainlabel%3D/limit%3D10000/offset%3D0/format%3Dcsv/sep%3D-3B/filename%3D530.csv

Is there a way to make an exception for the 'special:ask' query so anonymous users can download the complete list?

Toreolav (talk) 14:17, 26 February 2025 (UTC)

This sounds like a Semantic MediaWiki question, no? Yaron Koren (talk) 17:47, 26 February 2025 (UTC)

Access Uploadable Field Filename When Editing

I have a mandatory uploadable field on my page form.

When users edits an existing page that uses that template it shows a 100px width image, an upload option, and a remove option.

I don't want users to be able to replace or remove the image, but I do want them to be able to see a larger thumbnail size of the image.

I can use CSS to hide the uploadable field on the editing page, but is there a way to access the filename for me to populate some [[File:Filename|thumb]] wikitext? 70.160.223.43 00:07, 6 March 2025 (UTC)

Check out the "image preview" parameter here - could this be essentially what you're looking for? Yaron Koren (talk) 04:30, 6 March 2025 (UTC)

form input type tokens and values from concept are not showing all results

Hello,

I have defined the following in a form, for example: forTest

If not many pages are found for the Concept:Test, it works. As soon as the concept has 250 or more pages (approximately, in my current example I have 400 pages), not all pages are found during input. Can I increase a limit here? How do I manage to get all pages offered for selection?

Kind regards 212.77.172.210 16:27, 6 March 2025 (UTC)

Do you mean, even as you keep typing, there are certain pages that never show up? Yaron Koren (talk) 17:51, 6 March 2025 (UTC)

Yes, thats exactly what I mean. Some pages do not show up even if I start typing the name (until the whole pagename has been entered) 212.77.172.210 10:28, 14 March 2025 (UTC)

I have this same issue with cargo table and cargo field, where the it will only find the first 109 existing values for that field, and will not suggest any remaining ones even if they're typed out. This combined with using existing values only makes it so that certaing existing values cannot be typed even though they already exist. AhiruRat (talk) 18:36, 22 May 2025 (UTC)

That's more unexpected. What versions of MediaWiki, Page Forms and Cargo are you running? Yaron Koren (talk) 13:50, 23 May 2025 (UTC)

/index.php?title=Special:FormEdit/Vacation/<pagename> Error: Class "SMWDIProperty" not found

I tried to use a form today and am getting an error. This might be relate to a recent update to SMW 5.0.0-beta. I tried to downgrade back from that SMW version but got an error from update.php, the update might be a one-way street.

ChatGPT tells me "I reviewed the Semantic MediaWiki (SMW) GitHub repository and found that the SMWDIProperty class has undergone changes in recent commits. Notably, the class was renamed to SMW\DIProperty as part of the transition to namespace usage. This change is part of ongoing development efforts to modernize the codebase. For detailed information, you can examine the commit history related to this class in the repository."

/home/<mywiki>/extensions/PageForms/includes/PF_TemplateField.php(164)

#0 /home/<mywiki>/extensions/PageForms/includes/PF_TemplateField.php(196): PFTemplateField->setTypeAndPossibleValues()

#1 /home/<mywiki>/extensions/PageForms/includes/PF_FormField.php(424): PFTemplateField->setSemanticProperty(string)

#2 /home/<mywiki>/extensions/PageForms/includes/PF_FormPrinter.php(1167): PFFormField::newFromFormFieldTag(array, PFTemplate, PFTemplateInForm, bool, MediaWiki\User\User)

#3 [internal function]: PFFormPrinter->formHTML(string, bool, bool, int, string, string, null, int, array, MediaWiki\User\User)

#4 /home/<mywiki>/includes/StubObject/StubObject.php(125): call_user_func_array(array, array)

#5 /home/<mywiki>/includes/StubObject/StubObject.php(155): MediaWiki\StubObject\StubObject->_call(string, array)

#6 /home/<mywiki>/extensions/PageForms/includes/PF_AutoeditAPI.php(953): MediaWiki\StubObject\StubObject->__call(string, array)

#7 /home/<mywiki>/extensions/PageForms/includes/PF_AutoeditAPI.php(130): PFAutoeditAPI->doAction()

#8 /home/<mywiki>/extensions/PageForms/specials/PF_FormEdit.php(113): PFAutoeditAPI->execute()

#9 /home/<mywiki>/extensions/PageForms/specials/PF_FormEdit.php(54): PFFormEdit->printForm(string, string, null)

#10 /home/<mywiki>/includes/specialpage/SpecialPage.php(728): PFFormEdit->execute(string)

#11 /home/<mywiki>/includes/specialpage/SpecialPageFactory.php(1724): MediaWiki\SpecialPage\SpecialPage->run(string)

#12 /home/<mywiki>/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)

#13 /home/<mywiki>/includes/actions/ActionEntryPoint.php(146): MediaWiki\Actions\ActionEntryPoint->performRequest()

#14 /home/<mywiki>/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute()

#15 /home/<mywiki>/index.php(58): MediaWiki\MediaWikiEntryPoint->run()

#16 {main} Tenbergen (talk) 00:43, 7 March 2025 (UTC)

ChatGPT is right about this one - though this bug was actually fixed (as far as I know) a few weeks ago. That reminds me that I need to release a new version, though. Yaron Koren (talk) 04:01, 7 March 2025 (UTC)

Ah! I was using git branch 1.43; changed it to master and that fixed the problem. Sorry about that. Tenbergen (talk) 04:36, 8 March 2025 (UTC)

Just to say thank you. I was doing the same thing and using the REL1_43 git branch. Switching to "master" has solved this for me too Dogsbody (talk) 16:09, 17 April 2025 (UTC)

Multiple editor=wikieditor in one form

The manual says "Unfortunately, only one input within the form can have WikiEditor associated with it, due to a limitation in the WikiEditor extension."

This no longer seems to be the case. Jonathan3 (talk) 21:54, 7 April 2025 (UTC)

That's great to hear! Thanks for letting me know. I just removed that line from the documentation. Yaron Koren (talk) 14:19, 8 April 2025 (UTC)

Feature request: Allowing "{{#default_form:form-name}}" on property pages

Earlier this week, I experimented with {{#default_form:form-name}} on a form-based template for property descriptions on my Miraheze site. At this writing, PF's "default_form" feature works on regular pages, categories, and namespaces, but not SMW property pages for some reason. (Pre-2017 [and therefore during Referata's heyday], this was implemented by way of the "Has default form" special property, whose function some of my site's properties still make reference to. Said property has since been localised there for matters of convenience.)

Perhaps in a future version, maybe you could try reintroducing semantic support with that in mind? Or do wiki webmasters like me already have a workaround they can use instead? --Slgrandson (talk) 19:26, 11 April 2025 (UTC)

The new standard approach is to use #formredlink instead - do you know about it? Yaron Koren (talk) 18:33, 14 April 2025 (UTC)

All right, so after several weeks' delay (as usual), I removed the default-form experiment from the template this morning.

However, I have now encountered a residual side effect on the property pages affected: Although they should now resume pointing to the Property form (as they did before), they are instead defined by what is indicated by the "df" (default form) parameter. (For instance, the site's "National capital" property [used on sovereign-country profiles] uses the Place form for input when it really shouldn't anymore. Even a dummy refresh, which normally clears things up, hasn't helped.)

At least what I aimed for seemed like a good idea. Maybe I'll bring up the issue to MH's Issue Tracker (formerly Phabricator) by Monday and find out if they can resolve this bug?

P.S. As I've just found out minutes before press time, the parameter menu in the form-creation tool (in its current build) won't budge when a different input type is selected, thus remaining in place. (At least on the laptop I'm using; Android Chrome gives us no such issue, so I may as well proceed from there.) Most likely a revisit of an earlier bug from several years ago?

P.P.S. Yes, #formredlink is alive and well where I am--albeit used in only two templates on my site to date. --Slgrandson (talk) 03:30, 7 June 2025 (UTC)

By the way, Mr. Koren, the CreateForm issue indeed is a revisit of this October 2023 filing. (Just in case you need your memory refreshed.) --Slgrandson (talk) 01:42, 10 June 2025 (UTC)

Sorry for the delay. I don't know what's going wrong on your site with the default form thing, sorry. As for the Special:CreateForm problem: what browser(s) does this happen with? Yaron Koren (talk) 13:11, 10 June 2025 (UTC)

1) Already filed on the Miraheze Issue Tracker last night.

2) Edge 135.0.3179.73, against MW 1.43.1 on Miraheze.

--Slgrandson (talk) 13:50, 10 June 2025 (UTC)

Input type tokens with delimiter && will place wrong delimiter into the template

I have a template with a field where it is a list of strings with delimiter &&.

Using a form editor for the template with this: {{{field|<my field>|input type=tokens|cargo table=<my cargo table>|cargo field=<my cargo field>|delimiter=&&}}} will result in the strings being placed into the template with the delimiter &​amp;&​amp; instead of &&. How do I fix this? AhiruRat (talk) 19:04, 26 April 2025 (UTC)