Page MenuHomePhabricator

Cargo HTML for "format=template" is escaped on-page and in Special:RunQuery with CACHE_DB cache type
Open, Needs TriagePublic

Assigned To
None
Authored By
FrozenPlum
Nov 15 2021, 11:20 PM
Referenced Files
F41519991: image.png
Nov 19 2023, 1:21 PM
F41519989: image.png
Nov 19 2023, 1:21 PM
F41519983: image.png
Nov 19 2023, 1:21 PM
F41519981: image.png
Nov 19 2023, 1:21 PM
F41519979: image.png
Nov 19 2023, 1:21 PM
F37727732: image (2).png
Sep 15 2023, 4:36 PM
Tokens
"Burninate" token, awarded by FrozenPlum."100" token, awarded by Samwilson.

Description

What happens?:
Cargo query HTML, that is created by setting display format |format=template, shows as escaped on-page when saved. The escaped HTML can be fixed by purging the page; however, the issue remains for PageForms extensions, whose queries of Cargo queries |format=template remain permanently broken (displaying always as escaped HTML) because these can't be purged. We use PageForms queries to create form-controlled inputs to cargo queries, with custom, per-row table formatting of output (which cargo |format=template and template= provides).

I found this old cargo issue report and this one, suggesting incompatibility between Cargo and the ConfirmEdit extension, packaged with MediaWiki. Update: This problem still occurs on Cargo 3.3.1, MW 1.39.1 (PHP 8.0.12, cgi-fcgi, MySQL 8.0.28-0ubuntu0.20.04.3) with //all extensions except Cargo disabled--problem is not related to ConfirmEdit extension.

What should have happened instead?:
Pages should have rendered HTML, not escaped HTML, for cargo queries on page save, and in PageForms queries.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

old version occurred on:

MediaWiki1.36.2 (d17f10c)
PHP7.3.31-1~deb10u1 (fpm-fcgi)
MariaDB10.4.21-MariaDB-1:10.4.21+maria~buster-log

Cargo: 2.8 (19b7b42)

New version still occurring on:

MediaWiki1.37.2 (75e0d3b)
PHP7.4.28 (fpm-fcgi)
MariaDB10.5.15-MariaDB-1:10.5.15+maria~bullseye-log

Cargo: 3.2 (0f06913)

I've since disabled Cargo on my Miraheze wiki, and privated my wiki. This can be reproduced on multiple versions of MediaWiki from 1.35-1.37 on the Miraheze wikis currently using Cargo.

Steps to reproduce on a site with an existing Cargo table, that already has pages populating the table:

  1. Create page entitled Cargo_Query (change "MyTable" in the code below to an existing Cargo table name, and change "type" to an existing parameter for the same table/template).
{{#cargo_query:table=MyTable
|fields=_pageTitle=Title, type
|named args=yes
|format=template
|template=FormatRow
|limit=10
|delimiter=\n
|default=No items to display
|more results text=
}}
  1. Create Template:FormatRow (making sure to change "Existing File.png" in the example below to the name of a file that exists on-wiki):
<noinclude><pre>This is a per-line cargo result formatting template</pre>

</noinclude>
<includeonly>
[[{{{Title}}}|{{{Title}}}]]
{{{type|}}}
[[File: Name.png|100px]]
</includeonly>
  1. Go back to the Cargo_Query you just created, edit and make a change (even just adding <!-- note --> is fine, preview to see intended results, then save the page to see resulting, escaped HTML on-page, purging will render as expected.

To see that this also causes the same (unfixable/unpurgable) issue in PageForms queries, with PageForms enabled try viewing Special:RunQuery/<form name> on any form whose corresponding template has |format=template and |template=RowTemplate set, and where "RowTemplate" has images in the output.

I don't see this listed on the known issues page for either PageForms or Cargo, and as the previous reports were significantly aged, this is to confirm the issue remains with Cargo and MediaWiki 1.36.2, 1.37.1 packaged extensions (possibly ConfirmEdit).

Event Timeline

Restricted Application added subscribers: RhinosF1, Reception123, Aklapper. · View Herald Transcript

This is still an issue, it also occurs in MediaWiki 1.35.6 and cargo 3.2 latest version downloaded today, June 24 2022 via the gitclone instructions. I noticed OPs MW version has changed, and updated it a while back, it has since changed again to 1.38.1 (the problem seems to have existed for several Cargo versions).

Also, I can confirm this is NOT a problem relating to ConfirmEdit or any other extension. It occurs when ConfirmEdit is disabled, and when all other extensions are disabled. This is a Cargo-specific bug.

I updated to confirm that this problem still exists on Cargo 3.3.1 with all extensions except Cargo disabled--i.e., I can confirm this problem is not related to the ConfirmEdit extension, it is directly related to Cargo.

Cargo3.3.1
MediaWiki1.39.1
PHP8.0.12 (cgi-fcgi)
MySQL8.0.28-0ubuntu0.20.04.3

No idea if this makes sense or not, but this issue appears to be occurring between Cargo and the MediaWiki cache, or specifically $wgMainCacheType.

On an independent 1.39.1 install, with Cargo 3.3.1, setting $wgMainCacheType = CACHE_NONE; made the issue go away and render content correctly, though this is not any kind of practical workaround for production use.

Setting the following still worked fine (without escaping):
$wgParserCacheType = CACHE_DB;
$wgMessageCacheType = CACHE_DB;
$wgSessionCacheType = CACHE_DB;
$wgLanguageConverterCacheType = CACHE_DB;

Yet with the above 4 settings on, setting $wgMainCacheType = CACHE_DB; still causes the problem to re-appear.

Edit to add: Now the only place where Cargo content is escaped is when editing a page in Visual Editor.

Sorry for the long delay on this. When I set "$wgMainCacheType = CACHE_DB;" in LocalSettings.php, I do indeed see this problem when I first save the page containing the query. But then after I purge the cache for the page (using "action=purge"), it shows up fine - and it still appears fine when I reload the page in the browser. Basically, it seems like just a temporary problem on first save. Is that the case for you also?

Yaron_Koren renamed this task from Cargo HTML created by "format=template" is escaped on-page, also affects PageForms queries. to Cargo HTML for "format=template" is escaped on-page and in Special:RunQuery with CACHE_DB cache type.Jan 11 2023, 2:45 PM

Not sure if this helps. For me, on further standalone MW 1.39/Cargo 3.3.1 install, the problem occurs in multiple places (source edit on save if no extensions installed, and in VE edit mode--if VE enabled).
On Miraheze which has different cache settings $wgMainCacheType = 'memcached-mem-2'; the problem is primarily on page save, yes--I don't know about editing with VE there, as the extension was disabled on MH and prevented from being re-enabled on most wikis due to multiple issues.

On private 1.39, I have $wgMainCacheType = CACHE_NONE; and $wgSessionCacheType = CACHE_DB; (and no other cache settings), then the problem doesn't occur on source-edit page save anymore, but then is still a problem when editing with just Visual editor enabled (during edit, escaped HTML displays in the VE edit window only). Still happens with no other extensions. On that particular VPS install, I just don't have access to use CACHE_ACCEL or CACHE_MEMCACHED and the problem also occurs with CACHE_ANYTHING (though I figured that probably defaults to CACHE_DB anyway?).

No matter what I set, the problem shifts, and seems to affect different areas/cache settings (I don't see CACHE_DB in Miraheze's settings)... Edit: Actually, strike that, I now see $wgParserCacheType = 'mysql-multiwrite'; in the MH settings, looks like it is equivalent to CACHE_DB?

I'll just add, this is not just a problem on first save, nor a temporary problem, it occurrs intermittently on subsequent saves, at a rate that can not be predicted. So, a well meaning editor will edit a page, break the cargo table, and not know to purge--we had to splash warning messages all over, to purge if tables not displaying correctly. It is also still broken on every Page Forms query. It is also is always still broken in Visual editor (always displays escaped HTML in live edit, per the above noted configuration). In short, it is persistently broken in multiple configurations.

I am just now pulling down Cargo 3.4 to test to see these problems persist in any of these areas.

Hello! I see this problem a lot, but on a private corporate wiki so I can't link to examples. It shows up when I'm using cargo queries with format=template (and a variety of templates) and is not a problem with the first save only. The only way to make it stop that I know of is to dummy edit, but sometimes this requires several dummy edits. I'm not using ConfirmEdit or VisualEditor. I'm on MW 1.35.6 with Cargo 3.1

This week I created a Special:RunQuery page (only my second one-- I don't think this happened with the first one; the first one didn't have any images, so maybe that helped?) and I get the plaintext output every time I run it. That page seems to have a worse variation, where image URLs in the plaintext get displayed as embedded images, but then somehow the code to do that becomes part of the plaintext, so that the image appears extra times and the plaintext gets longer and longer. Here's a screenshot-- my template uses that envelope icon only once.

image (2).png (252×433 px, 23 KB)

I also encountered it:

image.png (71×1 px, 11 KB)

image.png (195×369 px, 8 KB)

special:CargoQuery work fine.

image.png (405×564 px, 26 KB)

but page:

image.png (335×538 px, 19 KB)

storage data:

image.png (48×567 px, 3 KB)

query:

{{#cargo_query:
tables=patch
|fields=patch._pageName, patch.content
|where=patch.id=1243
|order by=patch._pageName DESC
|format=template
|template=GetPatch/select
|named args=yes
}}

Template:GetPatch/select

[[{{{_pageName}}}]]
{{{content}}}

The expedient is to switch to Wikitext,<b>a</b>->'''a'''