Article ID from the Write panel

gaekwad · 2017-07-03 14:24:58

I hope I’m missing something obvious…

How can I find an article’s ID from the Write panel after it has been published? I’m using Hive, because I’m curing my addiction to Classic.

I can dig it out from the end of the URL (index.php?event=article&step=edit&ID=5), but I can’t see any reference to it on the Write panel content itself.

Any advice very warmly welcomed. Thank you.

Bloke · 2017-07-03 15:54:05

You ain’t missing anything. It’s not there. I’d love to remove reliance completely on IDs in the UI and tags because they’re inherently unportable. But we’ve had them for ages so they’re not going anywhere, especially all the while article_image supports a list of ID numbers.

You can add it via a plugin such as smd_article_stats, or write your own simpler plugin if you don’t need all the other stats.

Two questions:

What do you need the ID for? If it’s for hyperlinking purposes, wet has a plugin (somewhere) that allows linking from a popup panel.
If you did argue a good case for having the ID embedded in the Write panel, where do you think would be the best place to shoehorn it? Always visible? Visible on tap of some UI element?

Now that Phil has added the publication info beneath the Title, I wonder if that’s a good place to add the ID? Or, in the interests of reducing clutter, should all that additional paraphernalia be relegated to a popup “article info”, which shows ID, pub date + author, last mod date + author, …?

gaekwad · 2017-07-03 16:22:46

Bloke wrote #306161:

I’d love to remove reliance completely on IDs in the UI and tags because they’re inherently unportable.

I can see that argument, now you mention it. Without getting too deep into semantics, you’re absolutely right that they’re not portable across Textpattern instances, but the ID is a constant within a site where the URL format of a thing might change over time. I can use permlink with the ID and it’s sufficiently vague that the URL generated will change if I switch the format, so in that respect they’re portable within the confines of URL format stuffs.

What do you need the ID for? If it’s for hyperlinking purposes, wet has a plugin (somewhere) that allows linking from a popup panel.

It’s hyperlinking purposes. I spent some time scrubbing through articles with Next and Previous earlier on, and it was the first time I’d needed to know multiple article IDs for a new article (backlinks, essentially).

Frankly it was no great shakes to look at the URL, but something in the UI itself would have been prettier. I remember having a hard time with browsers a few years ago when they mostly went to ‘clean’ URLS (just the domain rather than the whole flingin’-flangin’ address with ? and &s and =s and the like. I’ve mostly come to terms with clean URLs, and picking through them is an occasional task when I’m in web consumer mode.

If you did argue a good case for having the ID embedded in the Write panel, where do you think would be the best place to shoehorn it? Always visible? Visible on tap of some UI element?

Now that Phil has added the publication info beneath the Title, I wonder if that’s a good place to add the ID?

This was exactly my first thought. The action of publishing or drafting an article generates an article with a timestamp, and it’s listed beneath the meat and potatoes of the article. An inline article ID appended to the article would be the most straightforward way to resolve it, but I think this is another edge case.

(I suspect I have earned the much-coveted Official Textpattern Make a Thing Out of an Edge Case certificate. I must be due one of those, soon!)

philwareham · 2017-07-03 21:10:55

We could certainly put it in the footnote text under the title field (where posted and modified info is). All it needs to say is ‘ID: xxx’ or something. I can see value in that.

gomedia · 2017-07-03 23:11:39

philwareham wrote #306166:

We could certainly put it in the footnote text under the title field (where posted and modified info is). All it needs to say is ‘ID: xxx’ or something. I can see value in that.

Yes indeed. That would be greatly appreciated.

Alternatives: adi_article_tab or adi_recent_tab

And just to have a moan – this is basic information that we’ve been asking for for years (for example) but for some reason there’s been resistance – in one case, and I can’t find the post now, but one past developer told a new user, in no uncertain terms, that they should never ever reference an article directly by ID. Utter rubbish.

IDs are shown in the article list screen, used in some clean url schemes, referenced by TXP tag attributes etc etc. So please make life easier for us mortals and provide us with easy access to the information. The same argument goes for image, file and link IDs.

phiw13 · 2017-07-03 23:31:21

gomedia wrote #306167:

The same argument goes for image, file and link IDs.

Images and Files already show their ID on their respective Edit panels. Links not, though. No objections from me for adding it on the Write panel, I use smd_article_stats for that purpose (OK, and the word count thing).

gaekwad · 2017-07-04 07:58:19

Welcome aboard, issue 911: github.com/textpattern/textpattern/issues/911

Last edited by gaekwad (2017-07-04 07:58:29)

Bloke · 2017-07-04 08:57:11

gomedia wrote #306167:

should never ever reference an article directly by ID.

I wouldn’t go that far at the moment (I hope it wasn’t me that said that!) but I’d prefer the term discourage referencing an article by its ID. Or any asset, for that matter.

Unfortunately, Txp’s design history has made the ID ubiquitous. It should have been hidden from day one, imo, like all auto-increment fields. It’s for the DB to assist indexing, not for us. While exposing indexes to the masses is handy, it’s lazy, and troublesome at best.

Instead, a true “uniqe” identifier should be assigned to each record that is not auto-increment. Some simple hash (like Github uses) or, better, UUIDs where you can refer to the article by some part of that instead. It increases storage slightly (UUIDs are 128-bit values with convenient hex-representation for human consumption), but there are advantages.

Think of all the times you’ve used <txp:article_custom id="NN" /> or <txp:permlink id="NN" /> in a design. It’s fine as long as the data is in one database and nothing goes wrong. But in exceptional circumstances or when performing database operations, an auto-increment ID that is also exposed in the API can become a burden.

With a separate unique field, migrating or merging content from one DB to another (consolidation) becomes a breeze. Export a bunch of articles, import them somewhere else, they might get different (auto-increment) IDs but would retain their unique value. Nothing breaks. Recovering from partial data failure is simpler becasue you can load a backup and not worry about IDs having to match up. You can grab page templates from one database, along with some records and just shove them in another DB without worrying about changing the template to match up the new IDs. A few minutes job instead of what currently takes faaaar longer.

Sure, these are extraneous circumstances. If you dump a DB and import it lock-stock into an empty database, your IDs stay the same: no problem. But there are other real-world benefits to using randomly-generated keys:

It obfuscates the number of records in a table and their insertion order, improving security. Trial and error guessing of content goes away. I know right now that article ID 42 was written after article 11. Does it matter? Maybe not. But it might.
Inserting linked data is easier because it can be done in one query and prepared outside the database. More efficient. No more insert primary record, grab last-inserted-ID value, then set other records to point to it and insert them nonsense. Just create the UUID up-front and use it, then fire one query at the DB. The algorithms for constructing UUIDs are well-known. The performance and storage costs in a CMS are negligible compared to the benefits.

The txp_users table does it right… sort of. We enforce uniqueness of the account via application logic but don’t expose the ID (login name or auto-increment value) to the public. Only the User Name. The <txp:authors /> and <txp:author /> tags don’t have a sniff of ID anywhere. On the admin side we use ID for the Edit step in the URL, which is poor, but otherwise it’s pretty decent. The other tables could learn a thing or three from this one.

For now, and back on topic, I don’t mind exposing the article ID in the interface because of its ubiquity and we’re stuck with it for the time being. But longer-term I would love to find a way to design out our reliance on internal auto-increment IDs.

philwareham · 2017-07-04 09:10:42

OK, Stef, that all makes perfect sense. I agree that the auto-increment IDs are not great and a permanent hash would be better. I’d welcome that.

However, in the short-term I find the best way to create link permanence in articles between local and live versions of a site is to use <txp:permlink id="xx">a link</txp:permlink> so the ID value is handy to see.

I’ve put in the mockups for approval.

Bloke · 2017-07-04 09:13:11

Yep, looks good. I’ll do that now.

philwareham · 2017-07-04 09:17:15

Great! Thanks Stef. Maybe open an issue to track the discussion of replacing ID reliance with hashes?

Bloke · 2017-07-04 09:42:00

Done.

Will think about adding an issue to track the UUID/hashes. Big job. Lots of backwards-compatibility issues to solve.

Textpattern CMS

Textpattern CMS support forum

#1 2017-07-03 14:24:58