Extension talk:Cargo
Add topicDrilldown Field Join Issue
[edit]I have a _parentTables
statement that looks similar to:
|_parentTables=Location (_remoteField=locationCustomerID, _localField=_pageID, _alias=Locations)
I get the following error: Error: Invalid field name "_pageID" specified for _localField.
This is also true for _pageTitle, _pageNamespace, and _ID. Same results if I try the _remoteField param instead of _localField. _pageName works fine, as well as any other fields declared in the table. Is this a bug? Am I missing something?Yahoobecause (talk) 13:27, 9 July 2024 (UTC)
Cargo Compound Query PHP Depreciation Warning Issue
[edit]Here's my Cargo query:
{{#cargo_compound_query: tables=Site1;fields=site1Name,site1Date; |tables=Site2;fields=site2Name,site2Date; |format=calendar}}
When the query runs, I get a series of the following messages (seems like 2-3 per row retrieved):
Deprecated: urlencode(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/includes/GlobalFunctions.php on line 361
This issue has been persistent since I created a clean install of MediaWiki with minimal extensions enabled. Here's my config:
Product | Version |
---|---|
MediaWiki | 1.41.1 |
PHP | 8.1.28 (apache2handler) |
ICU | 72.1 |
MariaDB | 11.3.2-MariaDB-1:11.3.2+maria~ubu2204 |
Lua | 5.1.5 |
Pygments | 2.16.1 |
Page Forms | 5.7.2 |
Cargo | 3.5.1 (c6c8867) 07:28, April 23, 2024 |
I can reproduce this error on any page the query is executed on by adding ?action=purge to the end of the URL. The error isn't generated if I remove the second query/lookup. Is there a way to suppress this error or fix it? Yahoobecause (talk) 18:14, 21 June 2024 (UTC)
- Could you print out the full error message, not just the first line of it (assuming there's more to it than that)? Yaron Koren (talk) 18:32, 21 June 2024 (UTC)
- That's the entire message. It repeats itself several times, depending on how many rows are returned in the query. Yahoobecause (talk) 18:39, 21 June 2024 (UTC)
- That's unfortunate... that error message is coming from the global function wfArrayToCgi(),but Cargo doesn't call that function directly; so there must be at least one intermediate MediaWiki function in there. Which may make it hard to isolate the problem. Yaron Koren (talk) 20:26, 21 June 2024 (UTC)
- Thanks for checking this out, Yaron. And thanks for all the tools you've made for the community. Yahoobecause (talk) 20:23, 26 June 2024 (UTC)
- That's unfortunate... that error message is coming from the global function wfArrayToCgi(),but Cargo doesn't call that function directly; so there must be at least one intermediate MediaWiki function in there. Which may make it hard to isolate the problem. Yaron Koren (talk) 20:26, 21 June 2024 (UTC)
- That's the entire message. It repeats itself several times, depending on how many rows are returned in the query. Yahoobecause (talk) 18:39, 21 June 2024 (UTC)
- If anyone is looking for an immediate solution, adding this to
LocalSettings.php
worked for me: error_reporting(0);
- Use at your own risk. Yahoobecause (talk) 20:22, 26 June 2024 (UTC)
What's the Best Option for Field/column Labels
[edit]Here's an example of what I'm trying to track:
Site | Wash Windows | Vacuum Carpet | Empty Garbage |
---|---|---|---|
12 Main St | June 4, 2024 | June 8, 2024 | June 15, 2024 |
34 Second St | March 23, 2024 | March 4, 2024 | May 12, 2024 |
... | ... | ... | ... |
89 South Blvd | May 5, 2024 | June 23, 2024 | April 15, 2024 |
The issue I'm running into is how to store the field label in addition to the field ID. Cargo doesn't allow me to store a field ID of "Wash Windows" because it has a space in it, so I would have to name it something like "Wash_Windows", which doesn't present well to the end user. I could use a #switch function to do a find/replace, but if I need to update dozens of pages, or if I use the field in multiple queries on the same page, it turns into a lot of work and chances to miss something if I ever need to change the field ID or label. If I create a table with field IDs like "Wash_Windows_label" and "Wash_Windows_date", then I'm storing the label of "Wash Windows" for every row (waste of DB space), and still having to figure out how to dynamically update all of the rows if I ever need to change the label. Another option is to create a lookup table and query the label name for each row ID when I need it. This just seems a bit clunky and inefficient. Is this my best option? Yahoobecause (talk) 17:54, 21 June 2024 (UTC)
- I solved this by using an intermediate lookup table with a
#switch
statement. Here's a lookup table example: {{#switch: {{{1}}}|Wash_Windows = Wash Windows|Vacuum_Carpet = Vacuum Carpet|...|#default = {{{1}}}
- When I need to reference the value, I use
{{{Wash_Windows}}}
and when I need to reference the human-friendly label, I can use{{Lookup Table Template|Wash_Windows}}
. Yahoobecause (talk) 20:46, 26 June 2024 (UTC)- Just to clarify, if you query a field called "Wash_Windows", the underscores will automatically be turned into spaces in the display, so it will appear by default as "Wash Windows". I don't know if that affects what you're talking about here. Yaron Koren (talk) 23:30, 26 June 2024 (UTC)
- Bad choice on my part. Almost any other example would have been better (ex: WindowsWashed). Yahoobecause (talk) 13:30, 9 July 2024 (UTC)
- Just to clarify, if you query a field called "Wash_Windows", the underscores will automatically be turned into spaces in the display, so it will appear by default as "Wash Windows". I don't know if that affects what you're talking about here. Yaron Koren (talk) 23:30, 26 June 2024 (UTC)
Adding part of page name as default value
[edit]In my wiki, to create a new page, you call the template for a new page with subst: first, so a basic page structure is inserted into the new page. I am now including a call to a cargo template with this basic structure template. Since all page names are structured the same way (street name street number (town), e.g. Main street 234 (Footown)), I would like to use the page name to prepopulate the fields street name, street number, and town. Since we are creating new pages not by form, but by red links or searches, the default parameter does not work. So, I am trying to set these values in the structure template. I can include the magic word {{PAGENAME}}, but once I use parser functions like #sub and #pos to select just the street name, the street number, and the town name, I get an error. Within the structure template my call looks like this:
{{cargotemplate |street=''combination of #sub, #pos, and {{PAGENAME}}'' |street number=''combination of #sub, #pos, and {{PAGENAME}}'' |town=''combination of #sub, #pos, and {{PAGENAME}}''}}
Is a "prepopulation" like this possible? How would I do it? Sorry if this has been asked before. Dumpstar (talk) 15:58, 2 April 2024 (UTC)
- Is this a Cargo question? It sounds like just a core MediaWiki question. Yaron Koren (talk) 17:33, 2 April 2024 (UTC)
- Should string parser functions like #sub and #pos work as value inputs for a field in a Cargo template? Dumpstar (talk) 17:42, 2 April 2024 (UTC)
- I personally wouldn't use the term "Cargo template", but yes, I think so. Presumably the fact that you're using subst: complicates things, but that's not a Cargo issue. Yaron Koren (talk) 17:46, 2 April 2024 (UTC)
- Should string parser functions like #sub and #pos work as value inputs for a field in a Cargo template? Dumpstar (talk) 17:42, 2 April 2024 (UTC)
CEIL function adding commas to number, bug?
[edit]I have a cargo query that does some math on the returned column value. When using the CEIL function, it appears that the returned number is formatted as a string and suddenly has commas in it. for example:
{{#cargo_query: table=Prices |fields=IF(Price<0,0,Price)*1000 |where=Item='apples' |format=list |more results text= |no html |default=0 }}
A query like this will return a value like 1234.56
But, if I want to round this up to the nearest whole number and change the fields
parameter to:
fields=CEIL(IF(Price<0,0,Price)*1000)
Now, I get a number back like 1,235
I need that comma to not be there. Any clues why this is happening and how to stop it? I have tested this with MySQL database and the number returned from a CEIL operation does not have a comma, so I am thinking Cargo may be adding it somehow.
My current work around is to use the #expr: ceil()
parser function, but this complicates the code and makes it harder to maintain.
Why is the comma a problem? because this gets sent to another template that does more math on the value. AllenKll (talk) 19:17, 10 April 2024 (UTC)
- Right, Cargo views CEIL() as returning an integer, and then formats it accordingly. I think you can get around that by putting CONCAT( ) around the whole thing. Yaron Koren (talk) 19:30, 10 April 2024 (UTC)
- That worked. Seems hacky, but it's better than nothing. Thanks. AllenKll (talk) 19:55, 10 April 2024 (UTC)
- Great! I agree. Yaron Koren (talk) 20:41, 10 April 2024 (UTC)
- That worked. Seems hacky, but it's better than nothing. Thanks. AllenKll (talk) 19:55, 10 April 2024 (UTC)
Query within a query?
[edit]Is it possible to use the result of one cargo query as an input to another query? In my mind, it would look something like this:
{{#cargo_query: table = Books |fields = _pageName |where = Author = '{{#cargo_query: tables = Books|fields = Author|where = _pageName='{{PAGENAME}}'}}' }}
but using that format produces Error in "where" parameter: the string "--" cannot be used within #cargo_query.
Perhaps there is a better way of doing this that I'm just not thinking of. Penguinaut 22 (talk) 19:26, 14 April 2024 (UTC)
- I'm not surprised that that doesn't work, although I don't why it's giving that specific error message. Anyway, depending on what exact query you're trying to do, it might be possible to just do it via a "join". The second best option, I would say, is to move this query into a Lua module (if you have the Scribunto extension), and then store the first query's result in a variable, which you pass to the second query. Another option is to use the "template" format for the inner/first query, and then put the outer/second query into that "formatting" template. Yaron Koren (talk) 13:05, 15 April 2024 (UTC)
- Hmmm yes I didn't think of using the template format. That worked like a charm, thanks! Penguinaut 22 (talk) 02:03, 16 April 2024 (UTC)
Output format = Wikitext
[edit]Is there any way to get Cargo to output a result in wikitext format? DPL3 can, for example using debug=5
.
Use cases:
- One-time (or expensive) query output whose result can be converted instead to wikitext.
- Data that changes very infrequently, not warranting live query to repeatedly cache.
- Swapping to wikitext, so data is still displayed while moving, renaming, or changing tables or columns, or especially migrating wiki locations, say if Cargo is not supported on a different wiki platform. Or converting key items (like main page queries) to wikitext if Cargo needs to be temporarily disabled.
- For instant troubleshooting of Cargo interaction with template format, particularly when templates are used for formatting within templates, and queries within queries.
We largely use template format, with table headers in intro/outro, and <pre></pre>
in |intro=
and |outro=
doesn't work, for obvious reasons. Next I'll try doing these tags in header, footer, and formatting template...-- that didn't work ofc (the values never got carried to the rows). Though setting |template = <pre>Template-CargoRow</pre>
got us part of the way, thankfully carrying the values to the rows and outputting that as wikitext.
It just feels like Cargo, which works with wikitext input, should ideally be able to output to (pre-tag escaped) wikitext, on MediaWiki. A wikitext output format would be hugely appreciated, and solve several issues for us and perhaps for other users. Thanks!
FrozenPlum (talk) 00:05, 18 April 2024 (UTC)
- I agree with this. Sometimes I create content using a Cargo query and would like to be able to cut and paste it for posterity into a wiki page. This would help with that.
- I vaguely remember being able to achieve this using templates, at least to a limited extent, but it would be easier if Cargo could just output wikitext as a standard output format. Jonathan3 (talk) 09:56, 4 October 2024 (UTC)
Cannot change the label of the field
[edit]I changed a couple of fields' labels in a template, but one of them cannot be processed and still shows the past title. What might cause this issue? Saving the template again and recreating the table doesn't help. 83.27.55.123 13:01, 24 April 2024 (UTC)
- A number of things could cause this... is your MediaWiki job queue empty, or how many jobs are in the queue? Your question may be impossible to answer without more information, or a link to your wiki's relevant pages. Normally provided/expected information:
- MediaWiki, Cargo, and php versions, which you can get from your wiki's Special:Version page.
- The template wikitext.
- The page wikitext.
Any idea to implement PivotTable in Cargo?
[edit]Hello. Any idea to implement PivotTable in Cargo?
Pivot table would be a very useful tools to calculate, summarize, and analyze data, by convert row data to column.
Since MySQL has no PIVOT keyword, I tried other solutions using customs SQL function, but still no successful.
The nearest solution for Pivot Table in Mediawiki is I found is Semantic OLAP, which is for Sematic extension, and also unmaintained. This extension also use orbs Javascript library, which has no update since 2015.
Duyhungwiki (talk) 11:44, 3 June 2024 (UTC)
- Can't you get a lot of this functionality just via Special:Drilldown? If not, what specifically do you want to be able to do? Yaron Koren (talk) 14:38, 3 June 2024 (UTC)
- Thanks for your reply. Special:Drilldown is only for browser the data. While I'm trying to query the data and display on page. My usage case is like below:
- 1/ My Cargo table is have data like this:
Name Food Emotion Anna Banana Love Anna Cream Like Anna Egg Hate Bob Cream Like Charlie Cream Hate Charlie Milk Hate Diana Egg Like
- 2/ Then I will Query the data to have another table like this:
Banana | Cream | Milk | Egg | |
Anna | Love | Like | Hate | |
Bob | Like | |||
Chalie | Hate | Hate | ||
Diana | Like |
- |} Duyhungwiki (talk) 11:50, 14 June 2024 (UTC)
- Okay, thanks for the very helpful explanation. I knew about this concept, but didn't realize that this was called a "pivot table". I remember having a conversation a long time ago about creating such a result format - actually, back then it was in the context of Semantic MediaWiki. It would be great to have, but I personally don't have plans to add such a thing. For the moment, I think the only way this could be done is via a Lua module. Yaron Koren (talk) 18:46, 14 June 2024 (UTC)
- Hello @Yaron Koren .Just want to update that I did query successful, with no need for Lua module. May not be optimal, but get the job done for me.
- This usage case, I already know the list of foods, so it's possible to hard code it into the query.
- Okay, thanks for the very helpful explanation. I knew about this concept, but didn't realize that this was called a "pivot table". I remember having a conversation a long time ago about creating such a result format - actually, back then it was in the context of Semantic MediaWiki. It would be great to have, but I personally don't have plans to add such a thing. For the moment, I think the only way this could be done is via a Lua module. Yaron Koren (talk) 18:46, 14 June 2024 (UTC)
- |} Duyhungwiki (talk) 11:50, 14 June 2024 (UTC)
{{#cargo_query: tables=Emotion |fields=CONCAT('[[', Emotion.People, ']]') = People, GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Banana' THEN Emotion.EmotionName END) = Banana, GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Cream' THEN Emotion1.EmotionName END) = Cream, GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Milk' THEN Emotion.EmotionName END) = Milk, GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Egg' THEN Emotion.EmotionName END) = Egg |group by=Emotion.People |format=table}}
- Duyhungwiki (talk) 16:10, 19 June 2024 (UTC)
- Nice! Impressive use of SQL. Yaron Koren (talk) 19:04, 19 June 2024 (UTC)
- Duyhungwiki (talk) 16:10, 19 June 2024 (UTC)
htmlspecialchars_decode
[edit]One of my wikis recently started to throw the following error when running its crontabbed runJobs.php:
PHP Deprecated: htmlspecialchars_decode(): Passing null to parameter #1 ($string) of type string is deprecated in /**blanked**/extensions/Cargo/includes/CargoUtils.php on line 529 Deprecated: htmlspecialchars_decode(): Passing null to parameter #1 ($string) of type string is deprecated in /**blanked**/extensions/Cargo/includes/CargoUtils.php on line 529
It doesn't do it every time, and I don't know which jobs are causing it.
- Thanks for pointing out that problem - it's another in the endless series of PHP 8-related bugs. I just checked in what I think is a fix for it, here. Yaron Koren (talk) 14:22, 12 June 2024 (UTC)
- Thank you for your answer. Now running 3.6 (f6baf05) 00:21, 2024 June 19 and the problem is fixed. (Edit to remove mistake on my part that it was still broken) Tenbergen (talk) 14:20, 23 June 2024 (UTC)
_parentTables
[edit]For parent tables, if I have templates in which multiple fields share the same name (e.g. Building.years_built and Church.years_built, Building.image and Church.image, etc.), am I able to put multiple fields into the #cargo_declare or should I just leave the cargo declare as the page name and then do multiple 'join on' in my queries? Also I'm assuming I wouldn't need do join on for queries where I display them using templates and do named args. Rothwell4217 (talk) 09:54, 29 June 2024 (UTC)
- Sorry, what do you mean by "leave the cargo declare as the page name"? Yaron Koren (talk) 15:36, 1 July 2024 (UTC)
- Sorry, I didn't explain that too well. I have two templates that are essentially the same (sharing about 90% of fields) but one has specific fields related to Churches. I'm trying to figure out which is the best option for linking the two so that queries are easier. Essentially I want to have this diagram showing arrows going to Building for all fields that are the same.
- I think there's 3 possibilities, though some may not work:
- If this is possible, adding more than one field when I set the parent table.
|_parentTables= tableName1(_localField=localFieldName, _remoteField=remoteFieldName, [... more fields])
- Just doing lots of 'join on' for all the fields that are the same when I do my queries. What I meant by "leave the cargo declare as the page name" was that I saw in the documentation that the default for the fields in the parent table above is the page name. So if I do multiple join on, should I still do the parent table and just leave the fields as the default.
- Using
cargo_attach
to attach the Church template to the Building template. Although I'm not certain how this works. Would it allow me to link fields of the same name in both tables, while still allowing for different fields? And do I have to declare the fields that are the same?
- If this is possible, adding more than one field when I set the parent table.
- Rothwell4217 (talk) 20:44, 3 July 2024 (UTC)
- Okay, I understand better, but I'm still somewhat confused. As far as I can tell, you have two options: (1) have the "Building" and "Church" DB tables look more or less the same as each another (which is how you have it now), or (2) have the "Building" table store info for both regular buildings and churches, and then have a separate DB table, maybe called "ChurchInfo", that just holds that handful of additional fields for churches, like "parish". Under option #1, there's no need to join at all, since the same page will never be in both tables. Under option #2, you would need to join them in queries - on _pageName or _pageID; and each page about a church would have to call, either directly or indirectly, both the "Building" and "ChurchInfo" templates. There are valid reasons to go with either option, but you should pick one; it seems like you might have a mix of both in mind. Yaron Koren (talk) 00:56, 4 July 2024 (UTC)
- I think there's 3 possibilities, though some may not work:
Unable to query date__precision values
[edit]Hi there, I have a date value in a table, and when displaying it I'd like to use different formats based on the precision of the input. I'm led to understand that the {name}__precision
field is the way to go, however whenever I try to query on this I receive the following error: Error: No field named "date__precision" found for the database table "events".
Having looked in my database, I can see that date and date__precision columns are both present and being populated with correct-looking values. Is there something I'm missing for using this column in queries? Thanks in advance for any assistance.
{{#cargo_declare:_table=events |title=String (mandatory) |class=String (mandatory;allowed values=xxx,xxx,xxx) |city=Page (mandatory) |area=Page (mandatory) |date=date (mandatory) |blurb=Wikitext string |link=URL }} {{#cargo_query: tables=events |fields=events.title, events.class, events.date, events.blurb, events.date__precision |where=events.date >= '1980' and events.date < '1990' |order by=events.date ASC |format=template |template=event timeline/format }}
MisfitMaid (talk) 17:12, 30 July 2024 (UTC)
- That's a bug - but I believe you can get around it by just changing
events.date__precision
toCONCAT(events.date__precision)
in the query - which is a hack, I admit. Yaron Koren (talk) 18:36, 30 July 2024 (UTC)- Ah, nifty workaround, thank you! I'll just go with that then :) MisfitMaid (talk) 00:17, 31 July 2024 (UTC)
turning result into link breaks grouping
[edit]I have a query where I group rooms by a field "floor" concatted to other text. It still groups fine when I add a square bracket, but it I add matched square brackets to turn it into a link, the grouping goes away and the floor is displayed for each row. See example.
- this works as expected: |fields=concat("[", floor, " floor]]")=Floor,_pageName=Room
- this breaks the merge: |fields=concat("[[", floor, " floor]]")=Floor,_pageName=Room
Tenbergen (talk) 03:47, 11 August 2024 (UTC)
- I see the problem on your wiki, but I can't reproduce it on my wiki - for me, a similar query with links and "merge similar cells" displays fine. I have no idea why it's failing for you, since the relevant code just does pretty simple string matching. It might be due to your wiki's use of PHP 8, though I can't think of why that would make a difference here. Yaron Koren (talk) 17:06, 14 August 2024 (UTC)
- What version of PHP should I try instead? Tenbergen (talk) 02:24, 16 August 2024 (UTC)
- PHP 8 is fine to use (it's the future, after all); I'm just saying that that might be the reason why we are seeing different behavior. I'm still using PHP 7.4. Yaron Koren (talk) 14:28, 16 August 2024 (UTC)
- What version of PHP should I try instead? Tenbergen (talk) 02:24, 16 August 2024 (UTC)
getting error "Identifier must not contain quote, dot or null characters" when trying to use Concatenate
[edit]I have enabled the Concatenate function on a wiki, and it works fine in general, but when I try to concatenate a string into the result it gives error "Identifier must not contain quote, dot or null characters". For example:
- works: no added string:
...cargo_query: table=tool |fields = CONCAT(image_map_coordinates__full,room)...
- gives error:
...cargo_query: table=tool |fields = CONCAT(image_map_coordinates__full,'~',room )...
(error is not just for ~ but any string)
See example on wiki. Tenbergen (talk) 02:24, 16 August 2024 (UTC)
- I just did a different search for that error in google, and it seems to mostly be on wikis. It actually affects another wiki of mine as well, in a spot that I know worked before. So this may have been broken by some recent update to something. Tenbergen (talk) 02:26, 16 August 2024 (UTC)
- I don't know what the exact cause of that error is, but there's the possibility that adding an alias would fix the problem, i.e.
CONCAT(...)=Field name
. Yaron Koren (talk) 04:47, 16 August 2024 (UTC)- That does indeed fix the problem. I didn't think field names were required. And I still think this used to work before. However, happy to have a solution, thanks! Tenbergen (talk) 04:30, 18 August 2024 (UTC)
- Great! I looked into this a little more - it looks like this was validation added to core MediaWiki in MW 1.42. So maybe handling for this needs to be improved in Cargo - though I'm not sure how. Yaron Koren (talk) 13:47, 19 August 2024 (UTC)
- That does indeed fix the problem. I didn't think field names were required. And I still think this used to work before. However, happy to have a solution, thanks! Tenbergen (talk) 04:30, 18 August 2024 (UTC)
- I don't know what the exact cause of that error is, but there's the possibility that adding an alias would fix the problem, i.e.
Join on a field with multiple values
[edit]{{#cargo_query: tables=bookings=b, persons=p
|join on=b.person__full=p._pageName |fields=p._pageName, CONCAT(MIN(b.year)) |group by=p._pageName |where=p._pageName IS NOT NULL}}
works fine, but only for the first Value in bookings.person(__full). Is there a way to have the second and third value too? Ernst Rosser again (talk) 09:54, 30 August 2024 (UTC)
- That line should ideally instead be
join on=b.person HOLDS p._pageName
. Hopefully that will work. Yaron Koren (talk) 14:45, 30 August 2024 (UTC)
Expandable maps?
[edit]This is a fantastic extension that has added many useful timesaving features and interesting maps to the wiki. Are there any plans to add expandable maps like in the Karographer extension? Where one can click a button and the map fills the screen. Garuda3 (talk) 21:08, 12 September 2024 (UTC)
- Thank you! No, but it's an interesting idea. Yaron Koren (talk) 17:35, 13 September 2024 (UTC)
$wgCargoDBtype defaults to $wgDBtype
[edit]@Yaron Koren: Regarding your change here, are you sure $wgCargoDBtype
is actually required? I'm using a separate DB and do not set it, and everything's fine. The source has:
$type = $dbr->getType();
if ( $wgCargoDBtype === null ) {
$wgCargoDBtype = $type;
}
Sam Wilson 22:39, 18 September 2024 (UTC)
- Ah, I thought I might be doing something incorrect. I just fixed that section, and generally improved the layout. Hopefully it makes more sense now (and is correct). Yaron Koren (talk) 00:52, 19 September 2024 (UTC)
- @Yaron Koren: Looks good! Thanks. Sam Wilson 02:28, 19 September 2024 (UTC)
Dynamic tables (DataTables): filtering with SearchPanes extension
[edit]Is there any way to add the functionality of DataTables‘ SearchPanes extension to Cargo? Gnarfoo (talk) 10:40, 20 September 2024 (UTC)
- Oh, very interesting! I didn't know about SearchPanes, so I just looked it up - here is a basic demo of it. This obviously is similar functionality to Cargo's Special:Drilldown, although it's all client-side (JavaScript) so it moves a lot faster. It's also similar in concept to the exhibit format, although not many people use that. It certainly would make sense to add this as an option. (Though I don't know why they called it SearchPanes - "FilterPanes" would have made more sense.) Yaron Koren (talk) 14:30, 20 September 2024 (UTC)
- Thank you for pointing to the exhibit format – actually, I didn‘t realize, this would be the better choice for filtering. I will, for sure, look into it (and would appreciate it, if SearchPanes could be an option in Cargo, one day). Gnarfoo (talk) 17:31, 20 September 2024 (UTC)
- @GnarfooI found that Extension:ContainerFilter is easy to implement, and suitable for Search options. Can give it a try. Duyhungwiki (talk) 16:29, 26 October 2024 (UTC)
- Thank you for pointing to the exhibit format – actually, I didn‘t realize, this would be the better choice for filtering. I will, for sure, look into it (and would appreciate it, if SearchPanes could be an option in Cargo, one day). Gnarfoo (talk) 17:31, 20 September 2024 (UTC)
[SOLVED] Events on Sunday 1st of any month do not appear on that month's calendar
[edit]Create any event which is both a Sunday and the 1st of the month and display it using the calendar (month) output format.
Using the example of Sunday 1 December 2024 - the event will be displayed at the end of the November 2024 page, but will not be displayed at the start of the December 2024 page.
Can we fix this within Cargo? Or is it a problem with https://fullcalendar.io/ ? Jonathan3 (talk) 09:51, 4 October 2024 (UTC)
- That is curious. Does it appear properly in week or day format?
- I would have to guess it’s more how data is translated into fullcalendar.io coding. You have tried creating a test entry in other dates than Dec 1, 2024, and multiple entries on the Dec 1? Geoff3ds (talk) 22:07, 4 October 2024 (UTC)
- Other dates show fine.
- Multiple events on 1 Dec 24 - none display properly. Jonathan3 (talk) 22:10, 4 October 2024 (UTC)
- Sorry, I meant other dates on the first of a month which is a Sunday. Beyond Dec 1. Geoff3ds (talk) 22:18, 4 October 2024 (UTC)
- Other dates that are a Sunday and are the 1st of the month are the same. I just used 1 Dec 24 as an example. Jonathan3 (talk) 13:43, 5 October 2024 (UTC)
- Which version of Cargo extension are you running? Geoff3ds (talk) 14:31, 5 October 2024 (UTC)
- I am using MW 1.39.6 and the latest version of Cargo. Jonathan3 (talk) 12:36, 7 October 2024 (UTC)
- Which version of Cargo extension are you running? Geoff3ds (talk) 14:31, 5 October 2024 (UTC)
- Other dates that are a Sunday and are the 1st of the month are the same. I just used 1 Dec 24 as an example. Jonathan3 (talk) 13:43, 5 October 2024 (UTC)
- Sorry, I meant other dates on the first of a month which is a Sunday. Beyond Dec 1. Geoff3ds (talk) 22:18, 4 October 2024 (UTC)
- @Yaron Koren Any ideas on this? Thanks. Jonathan3 (talk) 15:01, 11 October 2024 (UTC)
- Sorry about that - this was actually a problem with the first day shown on any calendar (which is always a Sunday), regardless of whether it's the first of the month. I just checked in a fix for it. Yaron Koren (talk) 18:17, 11 October 2024 (UTC)
- This works! Thanks. Jonathan3 (talk) 22:15, 11 October 2024 (UTC)
- Sorry about that - this was actually a problem with the first day shown on any calendar (which is always a Sunday), regardless of whether it's the first of the month. I just checked in a fix for it. Yaron Koren (talk) 18:17, 11 October 2024 (UTC)
Unable to get any events to appear in a calendar (solved)
[edit]I have created a table, using {{#cargo_declare:_table=Tests|Type=String|Date=Date|Start=Date|End=Date|description=Text}} and populated it with a few rows of data. It displays well in lists and table formats, but trying to call it for a calendar, {{#cargo_query:tables=Tests|fields=_pageName,Date,Type|format=calendar|width=100%}}
I get a calendar that is empty. The items in there have dates in format 2024-10-10 , 2024-10-01 , etc.
Is there any obvious mistake in what I’ve done that the calendar format needs? I have a table Events that I started with and got nowhere, trying to call it as {{#cargo_query:table=Events|fields=Eventname=name,Date|format=calendar|width=100%}}
I’ve tried studying the examples in the documentation, but I’ve gotten no idea how calendars might work or how I can troubleshoot what is going wrong. Geoff3ds (talk) 21:59, 4 October 2024 (UTC)
- Maybe you can't call a field Date? Jonathan3 (talk) 22:06, 4 October 2024 (UTC)
- Checked, the first example showed it using Author, Date, Source, etc. I tested without Date, maybe that was removed as option in later versions. I wish I had more examples to review (and more documentation). Do you know any source of examples or documentation relating to calendar beyond the extension page on this site?
Also, if you might provide table structure of what you might use that’s working? Geoff3ds (talk) 22:16, 4 October 2024 (UTC)
- Maybe start from scratch with the bare minimum, e.g. a table Events_test with only fields Event_name (String) and Event_date (Date), and see whether that works. Jonathan3 (talk) 12:39, 7 October 2024 (UTC)
- Calling Start and End fields but not Date hasn’t solved getting a single item to display. Geoff3ds (talk) 22:22, 4 October 2024 (UTC)
- The "calendar" format works for me. Could you look in the browser console to see if there are any JS errors? If you don't see any errors, try looking in the "Network" tab (if you see such a thing) and click to different months - each one should have its own URL, and going to any such URL may show something relevant. Yaron Koren (talk) 21:18, 6 October 2024 (UTC)
- Looking into the console did help alert me to the problem, which if you ever want to include on a FAQ may save someone from the unlikely problem I created for myself:
- I installed the wiki on my site, and then later added a secure certificate. Because the site address in LocalSettings.php had the $wgServer of my site without the s in https, any web browser was throwing errors when trying to call javascript to run the table.
- https site calling http address because the $wgServer needed to be corrected. Geoff3ds (talk) 20:59, 9 October 2024 (UTC)
- Good news! I've heard of that problem happening before, although I don't remember if it was in the context of Cargo or some other extension (or core MediaWiki). Maybe it makes sense to add something about this to the "Common problems" page. Yaron Koren (talk) 15:43, 10 October 2024 (UTC)
Deprecated: Linker::tocIndent
[edit]Hello! I am getting the following deprecation notice with MediaWiki 1.42.3 and Cargo 3.5.1 (903d10b):
Deprecated: Use of MediaWiki\Linker\Linker::tocIndent was deprecated in MediaWiki 1.42. [Called from CargoPageValues::execute in /var/www/html/extensions/Cargo/includes/specials/CargoPageValues.php at line 56] in /var/www/html/includes/debug/MWDebug.php on line 379
I wanted to raise this as I'm already on REL1_42 which should be the compatible version for my MediaWiki install. Please let me know if there is anything that I can fix on my end here. Mpvlewis (talk) 18:08, 8 October 2024 (UTC)
- I think this has already been fixed - you should switch to the master branch. More generally, you shouldn't use any of the REL... branches for Cargo. Yaron Koren (talk) 19:16, 8 October 2024 (UTC)
Deleting table using CargoTables page doesn't always work properly
[edit]I deleted a table but its template page says 'Edit the page to see the template text. This template defines the table "tablename". View table.'
When I click "view table" it says "Error: Table tablename not found." Jonathan3 (talk) 09:52, 11 October 2024 (UTC)
- I deleted the various helper tables that had not been deleted by Cargo automatically, and purged the cache of the Template page, and it works now, so as usual I don't know what fixed the problem. Probably just purging the cache. Jonathan3 (talk) 10:00, 11 October 2024 (UTC)
- The fact that some helper tables were not deleted is a problem. Which types of helper tables were not deleted, do you remember? Yaron Koren (talk) 13:33, 11 October 2024 (UTC)
- Unfortunately I can't remember them all. Most related to list fields, though. Jonathan3 (talk) 14:30, 11 October 2024 (UTC)
- The fact that some helper tables were not deleted is a problem. Which types of helper tables were not deleted, do you remember? Yaron Koren (talk) 13:33, 11 October 2024 (UTC)
Have custom formatting within #cargo_query instead of needing separate template
[edit]I can't remember whether I've asked for this before. But it would be great to be able to do this, especially for what now are fairly simple templates. It would sometimes save having to create a template at all. Jonathan3 (talk) 22:39, 11 October 2024 (UTC)
- If the formatting is simple enough, you might be able to do it directly in the query, using CONCAT(). Yaron Koren (talk) 23:04, 11 October 2024 (UTC)
[SOLVED] Problem with "intro=" introduced between REL1_42 and master
[edit]The effect of a change between REL1_42 and master means the intro=
parameter isn't creating a table properly.
This:
|intro=
{{{!}} class="wikitable sortable"
Turns into <table class="wikitable sortable">
on REL1_42. But on master it turns into:
<table class=""wikitable">
Jonathan3 (talk) 23:47, 12 October 2024 (UTC)
- I just checked in a patch that I think fixes this, among other issues. Yaron Koren (talk) 18:33, 14 October 2024 (UTC)
- This works. Thank you. Jonathan3 (talk) 20:58, 14 October 2024 (UTC)
API: Field names starting with an underscore (_pageName, _pageID, ...) only work if a display name is set (e.g. fields=_pageName=pageName)
[edit]The title above is a quotation from a previous topic here: Extension_talk:Cargo/Archive_January_to_February_2018#API_improvements.
I'm glad the topic is still there as it's still necessary to do this, but I couldn't find it documented anywhere. Jonathan3 (talk) 18:59, 13 October 2024 (UTC)
- It's there in "Common problems". Yaron Koren (talk) 18:14, 14 October 2024 (UTC)
- So it is. Thanks. It would be good to have it also (or instead) here: Extension:Cargo/Exporting_data#API. Jonathan3 (talk) 21:00, 14 October 2024 (UTC)
Problem when field value contains one of the "List" field names
[edit]Cargo query:
{{#cargo_query:tables=A
|where=Field1="qwertyuiop Field2 asdfghjkl"
}}
Error: Error: operator for the virtual field 'A.Field1' must be 'HOLDS', 'HOLDS NOT', 'HOLDS LIKE' or 'HOLDS NOT LIKE'.
- Where Field1 appears above - it happens for any field.
- Where Field2 appears above - it happens for "List (,) of String" and "List (,) of Page" fields but not for normal Text or String fields. It only happens when the field name has space characters on both sides.
Jonathan3 (talk) 20:45, 13 October 2024 (UTC)
- This is quite an annoying problem. It means, for instance, if you have Author as a field in your Books table, you can't have a book called "Advice to the Author", or if you have a field called Price then you can't have a book called "The Price is Right", because every Cargo query using that title in a string within the WHERE clause will cause an error.
- @Yaron Koren Would you like any more information? Thank you in anticipation. Jonathan3 (talk) 21:43, 24 October 2024 (UTC)
- I agree that it's annoying, but you could always use the "PAGEID" magic word instead of "PAGENAME", no? Yaron Koren (talk) 15:20, 25 October 2024 (UTC)
- I'm afraid not. The problem arises no matter which field is field1 above. The error occurs when the name of a list field name is used within thr query. Jonathan3 (talk) 16:21, 25 October 2024 (UTC)
- I agree that it's annoying, but you could always use the "PAGEID" magic word instead of "PAGENAME", no? Yaron Koren (talk) 15:20, 25 October 2024 (UTC)
[SOLVED] Best way of displaying individual values only once from list field
[edit]Let's say we have an Editions table (for books), and a List (,) of String
Author field. Edition 1 has authors A, B while Edition 2 has Authors B and C. For all the book's authors, how can I return "A, B, C" rather than "A, B, B, C"? I'm having a mental block and no doubt it will seem easy when I see it! Jonathan3 (talk) 22:32, 15 October 2024 (UTC)
- You might have to query the list helper table (e.g., Editions__Author), with "group by=". Yaron Koren (talk) 15:02, 16 October 2024 (UTC)
- That worked! Thank you. Jonathan3 (talk) 22:22, 16 October 2024 (UTC)
Lua and embedded multi-instance templates, and dealing with list fields
[edit]I'm able to get data from a Cargo table all right, using the example provided - but to save me reinventing the wheel, do you have an example of using Lua to get (and use) all of the data from a Cargo table including data from another table used by the PF embedded multi-instance template?
Also, I found a short function to "explode" a Cargo list field into an array of its constituent parts, but I imagine there's a better way of dealing with Cargo list fields.
Thanks in advance!
@RheingoldRiver, I hope you don't mind me pinging you, but I remember you talking about Cargo and Lua on the Between the Brackets podcast. Jonathan3 (talk) 23:45, 19 October 2024 (UTC)
- I have a couple blog posts that might help, on list fields and on representing one-to-many functions. Specifically in Lua, yes, you will need to use
mw.text.split
. Looking at my Cargo wrapper on Leaguepedia might help although it hasn't been maintained by me for a while, and it has a bunch of complex and unnecessary operations if you haveGROUP_CONCAT
available to you (which you should). --RheingoldRiver (talk) 04:51, 20 October 2024 (UTC)- Thanks for the swift response. I'll read that now. In the meantime I've asked a question about mw.text.split on Extension_talk:Scribunto at Topic:Yelw4qke5vomdp5y. Jonathan3 (talk) 20:01, 20 October 2024 (UTC)
[SOLVED] Max display character for format=template (Show/Hide feature for long Wikitext)
[edit]Hello. I tried to implement the "max display char" feature for query results (Show/Hide for long Wikitext, similar to Special:CargoTable/View Table), however haven't successful.
Searching on Archive, it seems that the issue is because "max display char" is not applicable for format=template.
I also tried to manual implement it, but was still not successful.
- Load Cargo.js https://github.com/wikimedia/mediawiki-extensions-Cargo/blob/3d972d59d6bddf3f3b5a15d90aee7a87e78b0841/libs/Cargo.js
- Assign <td><span class="cargoMinimizedText" style="display: none;"><p>Long Wikitext here</p></span></td>
Can you please help where I did wrong? Thank you.
Duyhungwiki (talk) 10:32, 26 October 2024 (UTC)
- Is there a way to do this within the template, using parser functions and/or a custom widget (i.e., via the Widgets extension)? Yaron Koren (talk) 22:27, 30 October 2024 (UTC)
- @Yaron Koren I managed to do it successfully, by exact Cargo code to Gadget and Template.
- My step is below for anyone needed:
- Gadgets:
var showText = '[Show]'; var showPseudoLink = $( '<a>' ).addClass( 'cargoToggle' ).text( showText ); var hideText = '[Hide]'; $('span.cargoMinimizedText') .hide() .parent().prepend( showPseudoLink ); $('a.cargoToggle').click( function() { if ( $(this).text() == showText ) { $(this).siblings('.cargoMinimizedText').show(100).css('display', 'inline'); $(this).text(hideText); } else { $(this).siblings('.cargoMinimizedText').hide(100); $(this).text(showText); } });
- Template to add outside "Show more" text and inside <td> </td> of the table
{{#ifexpr: {{#invoke:String|len|{{{1|}}}}} >= 300 |<span class="cargoMinimizedText"> {{{1|}}}</span></td>|{{{1|}}}}}
- Duyhungwiki (talk) 15:29, 6 November 2024 (UTC)
- That's great! I think you meant "by copying". I'm glad you were able to do it with a combination of JavaScript, Lua and ParserFunctions. Yaron Koren (talk) 16:22, 6 November 2024 (UTC)
- Duyhungwiki (talk) 15:29, 6 November 2024 (UTC)
Error for cargoRecreateData.php
[edit]Hello, I hope you can help me figure out why cargoRecreateData.php stopped working. It was working fine, but without any changes that I can think of other than users entering data into forms, it started throwing the error below.
From the terminal, or at least what my website management API tells me:
"Recreating data for Cargo table Hausstätte in 5 seconds... hit [Ctrl]-C to escape.
Deleting and recreating table...
Handling template that adds to this table: Hausstätte info
Saving data for pages 1 to 500 that call this template...
Saving data for pages 501 to 1000 t..."
Note: there are more than 1000 pages that call Hausstätte_info
The more detailed backtrace:
[6e8fbaa2730a68080cf9692f] [no req] Error: Call to a member function exists() on null Backtrace: from /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/PageForms/includes/parserfunctions/PF_TemplateDisplay.php(205)
- 0 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/PageForms/includes/parserfunctions/PF_TemplateDisplay.php(123): PFTemplateDisplay::pageText()
- 1 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3371): PFTemplateDisplay::run()
- 2 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3056): Parser->callParserFunction()
- 3 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/PPFrame_Hash.php(274): Parser->braceSubstitution()
- 4 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3247): PPFrame_Hash->expand()
- 5 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/PPFrame_Hash.php(274): Parser->braceSubstitution()
- 6 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(2888): PPFrame_Hash->expand()
- 7 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(1544): Parser->replaceVariables()
- 8 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(651): Parser->internalParse()
- 9 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/includes/CargoUtils.php(605): Parser->parse()
- 10 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(171): CargoUtils::parsePageForStorage()
- 11 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(72): CargoRecreateData->recreateAllDataForTable()
- 12 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/maintenance/includes/MaintenanceRunner.php(703): CargoRecreateData->execute()
- 13 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/maintenance/doMaintenance.php(100): MediaWiki\Maintenance\MaintenanceRunner->run()
- 14 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(180): require_once(string)
- 15 {main}
In effect, it does recreate the table and I can see that complete table in the wiki with more than 1000 rows. Dumpstar (talk) 18:36, 30 October 2024 (UTC)
- What versions of MediaWiki, Cargo and Page Forms are you running? Yaron Koren (talk) 20:14, 30 October 2024 (UTC)
- MediaWiki 1.41.0
- Cargo 3.5
- Page Forms 5.7 Dumpstar (talk) 20:36, 30 October 2024 (UTC)
- Okay - those versions of Cargo and Page Forms are not that old, but they're somewhat old. Could you try switching to the latest version of both, and see if it works better? At the very least, the line numbers will be different. Yaron Koren (talk) 22:30, 30 October 2024 (UTC)
- I did try. I updated to Mediawiki 1.42 and installed the versions for 1.42 for Cargo and PageForms. I received this message when executing cargoRecreateData.php:
- PHP Deprecated: Use of wfGetDB was deprecated in MediaWiki 1.39. [Called from PageAuthors::getPageAuthors in /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/PageAuthors/PageAuthors.php at line 67] in /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/debug/MWDebug.php on line 379
- [35df5d9d2064831551a463ac] [no req] Error: Call to a member function exists() on null
- Backtrace:
- from /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/PageForms/includes/parserfunctions/PF_TemplateDisplay.php(219)
- 0 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/PageForms/includes/parserfunctions/PF_TemplateDisplay.php(137): PFTemplateDisplay::pageText()
- 1 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3451): PFTemplateDisplay::run()
- 2 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3136): MediaWiki\Parser\Parser->callParserFunction()
- 3 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/PPFrame_Hash.php(275): MediaWiki\Parser\Parser->braceSubstitution()
- 4 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(3327): PPFrame_Hash->expand()
- 5 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/PPFrame_Hash.php(275): MediaWiki\Parser\Parser->braceSubstitution()
- 6 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(2970): PPFrame_Hash->expand()
- 7 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(1620): MediaWiki\Parser\Parser->replaceVariables()
- 8 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/includes/parser/Parser.php(722): MediaWiki\Parser\Parser->internalParse()
- 9 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/includes/CargoUtils.php(608): MediaWiki\Parser\Parser->parse()
- 10 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(171): CargoUtils::parsePageForStorage()
- 11 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(72): CargoRecreateData->recreateAllDataForTable()
- 12 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/maintenance/includes/MaintenanceRunner.php(698): CargoRecreateData->execute()
- 13 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/maintenance/doMaintenance.php(100): MediaWiki\Maintenance\MaintenanceRunner->run()
- 14 /var/www/vhosts/lippe-haeuser-wiki.de/httpdocs/extensions/Cargo/maintenance/cargoRecreateData.php(180): require_once(string)
- 15 {main}
- However, there also seem to be other issues with my wiki, or the 1.42.3 upgrade, because several functions would not work anymore. May be a PHP issue. I rolled it back for now. Have to figure that out. Dumpstar (talk) 01:14, 3 November 2024 (UTC)
- Sorry I wasn't clear before - please use the latest version of these two extensions, not the version/branch that corresponds to whatever MediaWiki version you're using. (Those are generally worthless.) Yaron Koren (talk) 15:53, 3 November 2024 (UTC)
- Okay - those versions of Cargo and Page Forms are not that old, but they're somewhat old. Could you try switching to the latest version of both, and see if it works better? At the very least, the line numbers will be different. Yaron Koren (talk) 22:30, 30 October 2024 (UTC)
Autocomplete with aliases in page forms
[edit]I'm just learning about Cargo, and have watched your Youtube video on Ben Fletcher's channel. I really like the token suggestion feature.
One concern I have is what I see with a similar feature on a forum I use. People make different tags for synonyms or different spellings of the same word (e.g. "CBT", "cognitive behavioral therapy", "cognitive-behavioral therapy", and "cognitive behavioural therapy"). Different people put different tags for the same thing.
I wonder if it'd be possible to have "aliases" for tokens. Where I might store "CBT" as an alias for "cognitive behavioral therapy", so that if I start typing the former, the latter appears in suggestions. And maybe if I submit the former as is, it is equivalent to submitting the latter. (Though maybe not in this case since CBT can be an acronym for many things.) Dimpizzy (talk) 13:39, 1 November 2024 (UTC)
- This is a valid question, but it's for the Page Forms extension - please ask it on that extension's talk page. Yaron Koren (talk) 15:21, 1 November 2024 (UTC)