Just noticed that when description is not set in the query, it defaults to the HTML (not wikitext) of the page.

Yes, it seems to work all right now! Thanks.

It would be nice if the description could even include a fully-parsed Cargo query. Maybe that comes free when you sort out parsing links and wikitext in general.

@Samwilson - mentioning you here in case you've not spotted this one. Thanks.

Yes, maybe I'm trying to shoehorn my old ways into Cargo where they don't fit... I've used the Bulletfeed extension for ages. It was a tag extension that converted a bullet list into an RSS feed (with an optional extra tag per bullet for description). It took the link from the description (parsing the HTML so treating internal and external links alike) as there wasn't a separate tag for url. When Cargo came along I just used Cargo to create the same bullet list. But since I can now cut out the middle man there's no reason I couldn't specify the url in the query. I'll give that a go anyway.

Yes, it might be! It would be useful when you're using Cargo as a back end for an RSS feed but never want the Cargo wiki page to be visited. I can't remember whether I use the first or last link as usually there is only one, e.g. "A new Between the Brackets podcast has been released: see [link]." Hypothetical example :-)

It would be fairly simple and if you had a link from description parameter it shouldn't lead to unintended consequences. If I were to submit a patch here would you consider it?

@Samwilson I've added you as a subscriber but don't know whether you get notified automatically by the system...

I've added some notes to the docs about what field names are possible. Feel free to edit.

The url field could be used for that but I'd need to add a separate URL field to my Cargo table, manually add the URL for each item, and include that field in the Cargo query. That's likely what I will do.

but are you saying that sometimes you're providing that and it isn't an existing page

This makes it work for my Drilldown pages, including one with Date fields. The "timeline" tabs on Special:Drilldown/_pageData and Special:Drilldown/_fileData don't like it (popup says "Caught exception: SyntaxError: Unexpected number"). It's a bad first draft but I hope is a step in the right direction.

"but it also sometimes causes the query to not work"

The following seems to fix the problem:

Is this the code to be looking at?

This seems to be the source of the problem:

• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Cargo/+/2755b36edca99f9de340427a4b03557b87eab879%5E%21/
• T331066: Cargo strips link when using Special:RunQuery with a template mode cargo query

git checkout 3.4.1 - template displays properly.
git checkout 3.4.2 - broken again.

I think the query used on Special:Drilldown is (paraphrasing):

Sorry for resurrecting this. I was reading https://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory which advises against short URLs like example.com/pagename and which mentions this Phabricator task.

Did you make any headway on adding RSS as an export format for Cargo?

If it helps to narrow things down, I've got stacks of page names and, separately, field names with apostrophes within them, and never have had this problem with CargoRecreateData.php, and currently I'm using Cargo 3.0 (55f3f72) 22:04, 18 October 2021 (and MW 1.34 - forgive me).

As a Cargo user, I agree that it would be a good idea.

In T171314#3473374, @Jonathan3 wrote:

I would like the same thing, if possible - to present existing categories as options but allow creation of new categories.

Or maybe whenever the MediaWiki categories table gets updated in the job queue, we could use a hook to add to Cargo's _pageData table at the same time.

I don't want to derail this Phabricator page, but I've asked what I think may be a related question on the Cargo talk page: https://www.mediawiki.org/wiki/Extension_talk:Cargo#Text-file_output_display_format

@Tombolano Thanks for this and for your other recent contribution (about HOLDS). I had worked round this one using CSS as I wrongly thought it was a Foreground skin problem. I'm "watching" this project now in the hope that you continue your interest :-)

"The drill-down interface provided by Amazon.com offers some interesting options: there, the filters and all their values appear in a sidebar, instead of at the top of the page - perhaps that should be the case for Special:Drilldown too?"

I have just removed mapOptions['fullscreenControl'] = true; from my code and the fullscreen control remains.

in other words, if page A gets added to category B, it's only for purposes of tagging and querying; no one is expected to go to the page Category:B to check out what pages are there, and traverse through the tree. (Let me know if I'm wrong about that.)

... obviating the need to patch the extension at all ...

I would like the same thing, if possible - to present existing categories as options but allow creation of new categories.

I've not perfected it, but here it is, in Template:Add drilldown links.

Yes, and annoyingly in answering your question I worked out how to use it within a Cargo query too, obviating the need to patch the extension at all... however, I do think it's a good feature, and having a parameter to control it would be easier.

I use Chrome on Windows and don't mind it! Though I concede it doesn't look as classy as on most of the other browsers...

Brilliant, thanks. One final change to fix the add drilldown link= thing:

Pleased you like it!

The ⟱ didn't show up on the iPhone (email or Phabricator website) so there must be something funny about it.

Yesterday I said...

I like the Unicode character :-) I think it maybe looks better on Chrome so it must be a matter of taste.

From Wikipedia: "The magnifying glass (i.e. Magnifying glass icon.svg, or U+1F50D in Unicode: 🔍) is commonly used as a symbolic representation for the ability to search or zoom, especially in computer software and websites.[4][5]".

In the code below, if you add |add drilldown links (with no equals sign and no parameters) it displays the magnifying glass for all possible fields.

I've changed "feeds-to-map" to "data-feeds-to-map".

Sorry for the delay. I'll try to finalise this over the next few days.

Pleased you like it :-)

Here's what I have so far. It's the magnifying glass that is the link. Not tested yet with Integer or Page. Feel free to let me know what you think!

Earlier you said...

Sorry, I forgot to add that the CSS did load from Cargo.css for format=table but not for format=dynamic table. I needed it to work for dynamic tables, which is why I ended up adding Cargo.css to the styles of ext.cargo.datatables. I hope it makes sense now!

That didn't work for the CSS, for me anyway. The CSS isn't needed in Special:Drilldown, but in a normal page's Cargo query.

I'm pleased you like it :-)

Ok, here we go:

Why can't this be done if "feeds to map" gets the standard "TemplateName[FieldName]" format, though?

Cheers. In relation to your two points:

Sorry, I should add that currently I just have the CSS in Common.css:

I don't understand - how is that different from the current patch?

Here is a way of automatically detecting map feeding with jQuery. The relevant lines in the big diff below are:

P.S. I wonder whether it would be possible to add a hook to Cargo to allow someone to create their own mini extension to modify the output of Special:Drilldown without having to amend the code of the extension. This could be a short-term solution for me.

I *am* sure that none of my users will have a need for "set marker" :-)

A table may make sense if there are a lot of display fields... maybe if there are more than, say, three display fields, it should just show up as a table instead of a category?

It seems to me that the only really customizable thing is which extra fields to display, though.

I'm pleased you like it so far :-)

For a table which has coordinates I'd like to include a query like this:

Apologies. I have belatedly noticed that the namespace, when needed, is already included in $valuesTable's 'title'. See amended patch below.

As an afterthought, I made a small change so that if "hidesetmarker" is set (i.e. the user is not expected to type in coordinate values) then the Coordinates input box is set to "readonly". See the first four green lines below.

I wonder whether it would be possible to avoid the need for the "hideaddressinput" parameter.

Sorry for the delay. I've changed it now so as not to use id and class parameters.

Here is a further attempt, based on your suggestion on the extension discussion page:

Thanks. I'd be happy to have a go at this, though if I try to spend time on it before Christmas I might not survive to tell the tale.