Editorial workflow... a reality?

Bloke · 2016-11-17 10:33:18

In the fix status assumptions branch I have mostly done away with our enforced notion of hierarchical status codes… at least on the admin side. The public side is “interesting” shall we say.

‘So what?’ I hear you cry. Glad you asked…

As part of this feature, there are two new core functions: status_group() and has_status_group() as a companion to the 4.6.0-introduced status_list() function. Plugins can hook into the former and alter (or extend) the core’s status fields.

In 4.6.0 the callback hook in status_list() wasn’t much use, because Txp still assumed that anything >= 4 was ‘published’ and anything less than 4 was unpublished. In this branch, while this is still the default case, you can have a say in what status fields constitute each group. Or make your own groups and use them throughout the system.

If you raise a callback on event status.types and step groups you’ll be sent an array of groups and which status codes are in each. Core will use your tinkered types when it determines what ‘published’ and ‘unpublished’ mean during things like <txp:article /> and <txp:article_custom> tags. If you want to alter the list of status codes on the Write panel — change their order, relabel or add to them — hook into the same event but supply the types step instead.

The upshot is that in this branch you can now create plugins that might introduce a ‘next status’ facility, which could allow you to push a document to the next person in the editorial chain. Or to notify people when a document reaches a nominated status.

For example, you could set up groups thus:

'published' => array (
    STATUS_LIVE => 'Published'
),
'unpublished' => array (
    STATUS_DRAFT => 'Draft',
    STATUS_PITCH => 'Pitch',
    STATUS_EDIT => 'Editor',
    STATUS_SECTION_EDIT => 'Section editor',
),
'magazine' => array (
    STATUS_PITCH => 'Pitch',
    STATUS_DRAFT => 'Draft',
    STATUS_EDIT => 'Editor',
    STATUS_SECTION_EDIT => 'Section editor',
    STATUS_LIVE => 'Published',
),

Note the ‘magazine’ workflow is in the order you want things to flow. You could set those to be the ones the Write panel uses and introduce some plugin functionality to notify people when the status changes. Entirely up to you.

Note that in this example, we’ve explicitly set the ‘unpublished’ group to a set of statuses you want to exclude from the public site; they also influence the state of the save / publish button on the Write panel. You really should set both published and unpublished sets at minimum. I’ll fix the code later to help prevent SQL errors in case they are deleted from the groups by accident. I’ve also got a whole bunch of things to do in txplib_publish.php because that has enforced the status >= 4, which brings about some interesting corner cases. Hopefully I can work them out.

Whenever anyone has time, I’d be very interested to hear people’s experiences in using these new callbacks. If there’s anything we can do to make it easier to create custom workflows, we’ll consider it.

Last edited by Bloke (2016-11-17 22:32:27)

Bloke · 2016-11-17 14:05:15

As a follow-up, to do this properly, we should also mimic this functionality in the public tags. But that opens up:

the ability to use lists of status values in article tags, which was revoked for various complex reasons a long time ago.
the question of how we deal with ‘sticky’ articles which have special meaning in article_custom tags and (under the new group-based status system) are lumped together with ‘live’. They are treated differently in searches too. so I’m not sure how to deal with them under this revised model.
potential backwards compatibility issues, depending on what we set as a default status for the tags.

I’ve got the <txp:article> tag singing with multiple status values and it works reasonably well, as far as I can test. It opens up the ability for you to display draft, pending and (potentially!) hidden articles if you use a plugin to put any of those status values in the ‘published’ group.

Semantically, allowing what Txp labels a “hidden” article to be published is counter-intuitive, but then a) it’s your funeral if you don’t rename it, or b) you can re-label and re-use ‘hidden’ as something more meaningful to your client, and allow it to be publishable. I’m inclined to think that Txp’s notion of what is and isn’t viewable — although a nice convention — could be a little more relaxed if you really want to do something outside the box. That’s what I’m aiming for: some sensible default behaviour, with the ability to rip it up if you wish.

At the moment I’m trying to figure out a way of doing that without introducing a minefield of pain for upgraders. The killer problem is next/prev (i.e. getNeighbour()). That has enforced STATUS_LIVE because it needs to know what to consider as fair game for the article before/after the current one. If we swap it out for the notion of any ‘published’ content is fair game, then you’ll be able to next/prev into sticky articles. Is that what we want? I’m not sure…

Any thoughts on any of this welcome. Is Txp’s model wrong? Should we massage it into something better out of the box? And how do we handle backwards compatibility if we do?

Destry · 2018-11-08 07:45:02

Carrying this over…

Bloke wrote #315056:

Txp’s publishing statuses are rigid and their meaning cannot be changed.

There is an implied hierarchy: Draft < Hidden < Pending < Live < Sticky

There are two ‘groups’ of status: Published (Live and Sticky), Unpublished (everything else).

In numerous places in the code, the above paradigm is enforced.

This is limiting. I’m seeking to open this up so there is:

The ability to make your own status values.

No implied hierarchy.

The ability to make your own status groups and assign one or more statuses to them (Default: 2 groups, as it is today).

No enforced knowledge in the code of “status x is greater than status y”. Everything is done on the basis of a) which group it is in, and b) the order in which the statuses are configured in that group.

Game on for plugins to play and completely rip up the publishing paradigm.

I can appreciate the need and desire to make statuses more flexible.

The Hidden and Pending options have always seemed half-baked to me. However people use them, it’s because they’ve adapted to the constraints of the options or found an atypical use outside of ‘publishing workflow’ per se, not because the options were well-conceived.

For my part, one or the other, Hidden or Pending, is useful to take something offline, but it never seems like there’s a clear reason to use one or the other to do that. My brain tells me, from the labels:

Pending = Has not been published yet (nor ever was) because it needs next stage (e.g. editor, formatter, etc) review.
Hidden = Was already published at one point and then removed for some reason (e.g. time expired, was audited for ROT processing, etc)

Those make sense to me, in a real collaborative or editorial workflow, but there’s no enforcement built into Txp to use them that way. And I’m not sure ‘Hidden’ is the best label there in any case, so the ability to change labels to need is a good idea.

I’m hesitant to cheer about ‘rip up the publishing paradigm’. I’m certainly all for improving it in Txp, but I also think there should be some restraint in how much the paradigm is ripped up. I would hope that any plugin developer acting on this would base their logic on tried and true editorial workflows.

What would be ideal, and maybe this is what you had in mind, is improve the workflow in core — making it more professionally ‘editorial’ (research what publishing agencies are doing and establish a happy average in Txp), and then developers can enhance/augment that to a given house situation. So, again, I don’t like the idea ‘rip up’, but I do like the idea ‘make it better’, and ‘get it right’.

Another major thing lacking in a real editorial workflow is automatic message handling. For example, when a Freelancer is done drafting (perhaps defined as first saving a new draft) the system emails the editor — or whoever is the next stage person — to let them know it’s time to act, maybe giving a link to the draft too, whatever. Or maybe it’s not transparently automatic, per se, but done through a new ‘Workflow’ panel, where controls exist for a defined team to check off their tasks as they go, and different things happen and messages sent as needed when boxes are checked. That way everyone on the defined team can see what the project status is together rather than just something between two people.

Messaging has been discussed at least a couple of times over the years, but as I recall, it’s just not possible? If it is possible, ‘workflow messaging’ should be one of the first plugins developed, if not made core.

From there other essential editorial tools could be added, these certainly as plugins:

An editorial scheduling system that ties in with the Articles panel.
A content inventory system for when it comes time to overhaul a site.

Remember all the auditing we did for TXP Mag in the beginning? That could be immensely easier by integrating a tool that keeps a rolling spreadsheet-like inventorying/listing of content paths — both front-side URLs and back-side template components. From there the tool could allow for ‘auditing’ functions, like marking what needs edited and by who, what needs removed, what needs finished, etc. And it would be easy to see at a glance where components are missing. For example a cell shows in red if a data CF field is empty, or whatever like a critical ‘Description’.

Anyway, you see what I mean… making steps toward these kinds of processes and conventions that are essential in the real world would be fantastic direction to go. Textpattern would suddenly find a huge new market of users. I guarantee it. ;)

Bloke · 2018-11-08 11:12:28

Destry wrote #315074:

Pending = Has not been published yet (nor ever was) because it needs next stage… review. Hidden = Was already published at one point and then removed for some reason

Yes, those are what I would expect them to represent. At the moment they both do the same thing: remove an article from the front of house if it’s published, preventing it from being shown to non-logged-in users.

Note that one of your examples (time expired) can be more elegantly handled by setting the article’s expiration date. That issues an HTTP 410: Gone result indicating it was there, but has since expired. You can then trap that in your templates (with an error_410 Page) if you wish to handle it differently.

I’m hesitant to cheer about ‘rip up the publishing paradigm’.

Well okay, you don’t need to go that far. But the point is, if we open this up successfully, a plugin could choose to completely overhaul the publishing workflow to taste, or slightly tweak it, or anything in between for any number of needs.

abc_magazine could introduce a proper editorial workflow like you suggest: hook into the article save process and honor notification rules based on status, offer user subscriptions for such notices, enforce a publishing editorial workflow such that you can’t edit work once submitted to the next step, introduce a panel (like an adi_matrix) for editorial control allowing you to see what’s missing for publishing control, yahde yahde.

abc_statuses might just relabel them to better reflect their purpose in a particular application.

abc_simplepub might remove Sticky and Pending for a simple photoblog that doesn’t need the clutter.

…

Messaging has been discussed at least a couple of times over the years, but as I recall, it’s just not possible?

Anything’s possible :) A plugin could introduce a pub-sub mechanism. Lump users into groups either based on their privileges or use something like smd_user_manager (when it works properly for 4.7) to create new privilege groups. Then create a panel that allows you to set what statuses trigger what notifications to what groups. Bonus marks for defining content templates with placeholders for each notification.

Hooking into the Save process has been available since, I dunno, 4.0.something. All a plugin has to do is look at the status of the saved article and consult the above mentioned rules table to email off an appropriate notification.

Of course there are corner cases, like what happens if an article is sent for review to an editor, then amended by the author? Does it trigger another notification? Does the author have the option to notify or not when edits are made (Atlassian Confluence has a checkbox by the Save button for this, btw)? Does the plugin even forbid changes by the author until the editor has finished with it and bounced it back?

It’s all doable now and will work fine, within the restrictions of our current hierarchical status tree. That does potentially torpedo a few niceties that the status-mods patch would neatly sidestep. But for a messaging system, it’s only sugar coating.

colak · 2018-11-08 12:10:21

I guess that the issue is not with the status of the article but with the default authors rights. Admittedly a lot of improvements have been made, transferring the authorship to another author for example.

Following the wonderful flat_files in the latest release, what I would like to see is more focus on building communities for sites. I think that this will also be a good way to spread the brand.

At the moment the only way we can do this, is using front end registration plugins. The problem however is that the articles, files, and images tabs are viewed by everyone. Since we have a filter which can list articles by author, wouldn’t it be more prudent if writers for example should view only their content by default?

If that is the case, then we would also need a collaborative content creating role, where a writer could invite other members of the site to help with a text, or the publisher might share some default images for use by everyone. This will of course also need another tag to display the authors of the text and the images, or the author tag can be expanded to allow proper credits. ie
Author(s): John Smith, Jane Smith, etc
Editor(s): John Doe, Jane Doe, etc
Copy editor(s): Donald Swain, etc
Images: Some name here

I know that my ideas might be far from what Stef is suggesting but I hope that you can see how related they are.

Destry · 2018-11-08 15:27:50

That all sounds good, Stef. Warp speed! What comes first for you, though, unlimited CFs or… ?

Colak,

I agree flexible roles/rights/governance functionality would be good. I’m not sure what you mean by ‘building communities’ (beyond what an article commenting system can do). But yeah, flexible roles and rights is good for all collaborative functionality.

wouldn’t it be more prudent if writers for example should view only their content by default?

Isn’t that how it is for Freelancers?

But, again, more easier management of roles/rights. You can never go wrong with that.

Textpattern CMS

Textpattern CMS support forum

#1 2016-11-17 10:33:18