Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2021-03-08 10:07:59

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,277
GitHub

[RFC] Wild ideas that are probably not viable

In no particular order:

  • Use curl to bulk check HTTP response codes of link URLs to scan for link rot.
  • Articles ready for publication (i.e. final draft stage) are submitted for review, assigned to 1 or more editors for sign off, automatically or from a dropdown, with said editors having an inbox or work queue with assigned work; introduced a “Signed off by” or “Approved by” attribute to the article table
  • Write panel has optional, toggle-able, distraction-free UI with maximised Title / Body / Excerpt (i.e. no sidebar furniture) akin to IA Writer.
  • Add jsonfeed as a supported article syndication format.
  • Permit an optional “All” setting for list views where server hardware is sufficiently powerful (admin will know either way) for sites with lots of content.

Last edited by gaekwad (2021-03-08 11:16:15)

Offline

#2 2021-03-08 12:02:34

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,468
Website GitHub

Re: [RFC] Wild ideas that are probably not viable

Interesting, and very good suggestions, some of which I’ve mulled over in the past.

1) Link rot: easy to do in a plugin or a jot of PHP in a <txp:linklist form="check_links" />.

2) Workflow: The unfinished status_mods branch aims to decouple our enforced status hierarchy from articles, with the aim to allow plugins to more easily step in and perform actions on status change. They can do so now, it would just be nicer if they could repurpose/augment the current status values with their own notification workflows, without the enforced baggage that Live is greater than Draft but less than Sticky.

3) Distraction-free editing should become possible when unlimited CFs land, where we’ll need to figure out how to let people tinker with the Write panel blocks. Not everyone wants title/body/excerpt front and centre. They might want Title, Body, Description, and a couple of textarea custom fields, plus a few radio buttons. But if we can tuck away the sidebar behind a togglable button, that’d be neat. Fallback: allow plugins to do so more easily.

4) jsonfeed: never heard of it, but if it’s a feed format, let’s add it. Makes sense. Atom/RSS have been the only kids on the block for a while so it’s time to give them some healthy competition.

5) ‘All’ items. That could be handy. I’d use it on the plugins panel for sure in my dev site that has over 100 plugins installed and hundreds of articles! We could also consider Adi’s full help view request as part of this.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2021-03-08 12:10:02

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,277
GitHub

Re: [RFC] Wild ideas that are probably not viable

Bloke wrote #329149:

1) Link rot: easy to do in a plugin or a jot of PHP in a <txp:linklist form="check_links" />.

Oh, of course – never thought of that – good point, well made.

2) Workflow: The unfinished status_mods branch aims to decouple our enforced status hierarchy from articles […]

3) Distraction-free editing should become possible when unlimited CFs land, where we’ll need to figure out how to let people tinker with the Write panel blocks. […]

Fantastic!

4) jsonfeed: never heard of it, but if it’s a feed format, let’s add it. Makes sense. Atom/RSS have been the only kids on the block for a while so it’s time to give them some healthy competition.

It’s not widely-deployed, sure, but if it’s straightforward to add then perhaps there’s value.

5) ‘All’ items. That could be handy. I’d use it on the plugins panel for sure in my dev site that has over 100 plugins installed and hundreds of articles! We could also consider Adi’s full help view request as part of this.

This was in response to an intranet site I was working on last year where they have colossal numbers of articles and images – literally hundreds of thousands – running on a Dell blade server with absurd compute and storage, I had to resort to database queries rather than the UI. Not a massive deal obviously, but it would also give us good optics for people wanting to run larger sites on bigger boxes.

Last edited by gaekwad (2021-03-08 12:10:15)

Offline

Board footer

Powered by FluxBB