@Yaron_Koren I upgraded to Page Forms 4.9.5 and following a save action with a #formlink that uses popup + reload, the undefined message is still appears for a split second right before the page refreshes.

The issue was the $wgUrlProtocols global variable. We originally set file: without trailing slashes.

@Yaron_Koren I upgraded to 4.9.5, but I am still encountering the same issue. I call the #autoedit function from a cargo query, and assign |target=File:{{{1}}}, where {{{1}}} is the image _pageTitle. Removing File: form target does not work since it saves to a page with the same name as the file, but not in the File: namespace.

Sorry about that; I didn't mean to assign the task.

Yes, that is correct when saving a page using #formlink

Thank you for your help. Hopefully the |details fields= bug is patched at some point.

slidesOSD goes to a template that then goes to another template, which is an image viewer. If I do not use the |details fields= property, I can see the image perfectly, but once I hide the View field with |details fields= I see the UNIQ-QINU error.

Hi @Nikhil-nk, yes even with |no html I get the same error.

Just tried to directly include the query but I see the same behavior when I use the |details fields= property. If I do not use it, the query works perfectly; if I hide that field with |details fields= then I unfortunately get the UNIQ-QINU error.

It is a template call to a template that runs a cargo-query. Is there a better way to run the query within the original query, rather than using a template?

I have followed these instructions but still get the same UNIQ-QINU error:

Wonderful, the |order by= property is working now!

I now updated the .js and .php, and the patch works. Now the |oder by= property is respected when |details fields= is used. Still, unlike a regular Table query, the field used by |oder by= must actually be included in the query, which is fine but it would be better to be able to use a field for |oder by= without actually displaying it.

I modified /ext.cargo.datatables.js to include the following code, but it still did not fix the order by issue when details fields property is used.

I was able to get it to work just like your query. The issue was the |details fields=, when I removed this property the |order by= took effect. This is also what is causing my second issue, so it is a bug with the |details fields= property.

@Nikhil-nk yes, order_date=Date is my 2rd column; notice how 10, 11, and 12 were created after 3, 4, 5, 6, 7, 8, and 9 yet the order by Date is being ignored:

Just tested |order by= with |format=table vs. |format=dynamic table and it worked, so I can confirm that there is a bug with |format=dynamic table.

When I try to sort by the Date a page was create, where page 1 was created first, and page 12 was created last, this is what I get: 1, 10, 11, 12, 3, 4, 5, 6, and so on, if pages is the first column. If Date is the first column then the pages are listed in the intended order: 1, 2, 3, 4, 5, 6, and so on.