workflow management

[galide]

Hello,

I have recently started using typolight and quite pleased by the way the application addresses common features such as user's UI custmisation, templates and plug-ins management, etc.. It is meeting 99% of my needs.

However, there is 1 thing that I think anyone can expect from a CMS: publishing workflow.

All the changes you currently make on the site go live as soon as you save the page. If you change the type of the article through the dropdown, it submit the changes automatically, and publish the page without even having to save the page.

This makes it challenging to sell to clients who need to make regular changes to the site, but would obviosuly need to preview the changes before pushing them live. And when there is more than one person responsible for the site, they would also like the ability to set up 2 types of profiles:
- the copy writer: can carry out changes to pages, but cannot publish them (only save them to make them available for preview)
- the publisher: responsible for reviewing the changes, and publish them live.

I am not sure this logic can be "plugged in" as such, and I would think that this is rather a core development.

Searching for "workflow" didn't return any result. Is any work related to this type of features has been considered yet?

Note: the change we are considering as a workaround at the moment is to use a "staging site" on which typolight is sitting. And create a plug-in which would simply copy the staging database onto the live database.
=> changes carried out in typolight only impact the staging site.

Not very clean though, as synch between staging and live needs to be carried out carefully:
1) We need to install typolight twice (staging + live)
2) We need to be careful not copying data created by users (example contact form submitted through the site and stored in the database) from staging to live
3) We need to also transfer/delete any files such as images uploaded/delete on staging..
4) etc..

So before planning starting developing the "publish" plug-in, would be interested to check that such a core feature is not likely to be release within the next weeks or so..

Emmanuel

[thyon]

There are some options. Articles are unpublished by default. You can still preview the content, by being logged into the back-end. Then the content is visible as in-place, but the client cannot see it yet (or the page is not published yet).

Try doing this:
Use TWO browsers, e.g. FireFox and Safari (or Camino and Safari, which is what I use on the Mac).

While logged into the back-end, open the Preview link at the top of the back-end (this ALSO allows you to preview content with published/unpublished as a menu-drop down. BUT you can still just use the same browser to see content from the back-end (by clickking on the page icon in the site/article tree).

If you now open the same PAGE url (e.g. home.html) with your other browser, it will only see the client/outside information.

This is an easy way to add content, get it approved and then you can click publish to publish the content.

[planepix]

Hi Emmanuel,

unfortunately in german there exists a developer site:
http://www.typolight-forge.org/

There is discussed and first preview of a workflow manager, so may be contact the author of this extension for coordination...

[thyon]

Also, TL has a powerful userpermission system and allows access to only specific edit fields, e.g. for

Copywriter

• Create a User Group called Copywriters and prevent them from accessing the Publish, Start or Stop date, and remove any other fields they are not allowed to touch.[/*:m:2tbvu7eo]
• Then add users into this group and you will see they can modify and edit articles and CE (content elements) but they cannot publish Articles[/*:m:2tbvu7eo]

Publisher

• Create a User Group called Publishers and prevent them editing anything, but do allow them access to the Publish, start and stop fields.[/*:m:2tbvu7eo]
• Then add users into this group and you will see they can view, and then ONLY modify the publish status of an article[/*:m:2tbvu7eo]

Then you can also use the System's Task manager to create a flow between people using the site. You can for instance create a task that another BE user should do and then you can track the status of that task using the task manager.

[galide]

Hi Thion, Planepix,

Thanks for the quick head up!

Thion, the solution you describe is fine for new pages. However it doesn't apply to existing pages. Once the page is live on the site, and the person responsible for the content decides to update it - there is no way to preview changes before pushing them live. Once you save the changes they are released live.

Thanks for the link Planepix, my german is a bit rusty but I should be able to find my way around with the help of google translator.

[thyon]

Hey galide

No, you are not correct.

By adding a custom variable to config/dcaconfig.php, you can control that Content Elements must start their life as invisible, rather than visible. Then you can still preview invisible items as I've explained, and when ready, press the visibility icon on each content element to make it live.

$GLOBALS['TL_DCA']['tl_content']['fields']['invisible']['default'] = 1;

[galide]

Let's take an example:
We set up a simple page, with 1 single element: content, which we display in the main column.

The client logs in, wants to update the content of this element (let's say for the about page), and preview the changes before publishing them live.
=> I don't think this is possible, as there is no workflow supporting this type of things.

Emmanuel

[thyon]

I have installed loads of client sites and understand how to set this up, but it seems you are unwilling to believe what I'm trying to explain to you. All the best of luck to you then.

[Antipitch]

Hi Thyon,
I know that know the system more or less by heart. But it's really not possible to preview changes to a (let's say text) element, that is already online (may that be the text itself or images). Or is it? If so I'd like to know how!Only way I could think of is to copy the element, set it to invisible and preview the changes. Not very elegant...


cheers
Antipitch

[thyon]

Ok so why not take it further then. Instead of trying to get help here why not just post a Feature Request to the Trac system. Of course that's the ONLY way you're ever going to get it right. Developers can't touch the core core and the Article system is core.

I have indeed a better suggestion. Why not allow TL, which alrealy includes a versioning system, to NOT display the latest version, unless its been published. Then you can change the Article system so that if the item has NOT been approved, it displays the previous version to the outside world and if the BE is logged in, they can see the latest unapproved version. That way you CAN display, approve and track the latest changes.

This WILL require changes to the TL core, so you'd have to submit a new feature request to the Trac system.

[Antipitch]

Hi Thyon,
I wasn't asking for help, neccessarily. Nor criticizing. Just wanted to make sure I didn't miss a basic feature over the time I have been using TL (I'd be rather embarressed ). Also the topic has been discussed before and there is a ticket, already (unfortunately in German). Leo, at the time, replied that he basically likes the idea. But he also said that he sees this as a very big step, which might be a little too much to ask from Typolight. And that we shouldn't be too hopeful about it (nearer future, at least).


cheers
Antipitch

[thyon]

Hi antipitch

even though my reply post appears after yours, that doesn't mean my comment directed at you. It was directed at the original poster (galide) of course, otherwise I would have quoted you.

PS. Most of the world outside Germany doesn't speak german, but English as a common denominator. I'm Afrikaans and I speak and run my business in English, because we only have 1 common language in South Africa (12 official languages) and the world, so I think all Tickets should be translated (at least their title), so hence the reason why we can't locate or find duplicate tickets.

[Antipitch]

Hey Thyon,

that doesn't mean my comment directed at you

alrighty and no problem, at all 8-).

The language thing is a problem, I agree. Maybe the TRAC should be set to English only. But then we have that big German-speaking part of the community and apparently lots of those people don't feel too confident about their English (although everybody here has to take it at school :? ) . Not for me to decide, hope my mini-translation helps a little...


cheers
Antipitch

[thyon]

antipitch

maybe we can just get them to Google Translate the topic into english... then they can still post the content in german.

[Antipitch]

Hi Thyon,
I have no experience German-English Translator, you think that's still readable with the technical expressions etc.? And isn't Leo going to change the ticketing system again? Maybe he'll come with something languagewise...

[galide]

We have got a bit of an ego battle here.

This is a shame as this is definitely a significant feature which is currently missing from TypoLight, and it would be great to get constructive comments from developers.

Thyon, I think you just misunderstood my question, as there is actually no workflow support for publishing process in TypoLight, and the fact that a dev team is actually working on it proves this

I didn't have a chance to check the out the german project, but will definitely have a look within the next 2 weeks. I'll report back...

[thyon]

I agree with Leo. Typolight is just that Light. It's not Sharepoint Portal Server or some other corporate intranet tool, it's immediate and just works. Introducing this feature moves away from TL's core ideal. I want TL to stay lean and muscled. If I wanted Supersize and bloated, I'd look for the closest McDonalds.

I used to do corporate Intranet development and no-one used the publishing workflow, and in 3 years, I mean never! And that was for a sizable company. I'll stick with light and sexy!

[galide]

I think it is arguable, and depends on who you make responsible for managing the content of the site.

The objective of a CMS, in my view, is to allow someone responsible for marketing (regardless the size of the company) to update easily the content of the company's website.

Even in very small companies, non-technical people are always worried about doing something wrong with the technology they are using, and are always keen on being able to preview the changes they are going to make.

This becomes obviously much more critical when more than 1 person can manage the content of the site.

If the CMS is not targetting non technical people, it is definitely not targetting senior programmers either. Many hours spent on the CSS manager for instance, which is quite sexy, is in fact rather useless for someone who knows well the CSS syntax. Same applies to layout manager (header, footers, etc..), which is not really necessary.

It may target back-end programmers who are not interested (or not the time) to learn CSS, html, javascript, etc.. However a CMS will never replace a front-end designer, in a production environment.

In short, I think that it would be interesting to find out which "market" this CMS is targetting. Rather strange question for an open source project one may argue, but my point is that for such an advanced product it would be relevant to know which direction it is taking - which can only be answered by understanding which market it is targetting.

[Ben]

Galide - Have you seen this ticket? (http://dev.typolight.org/ticket/871) I know it doesn't have all that you're asking for, but it is a step in that direction.

I think a nice compromise would be adding additional states to pages, articles and CE's, so an admin / editor could set them as "in progress", "pending review", and "published". Then, the improved backend start page could list the in progress and pending review pieces.

What do you guys think?

[scare]

Well I think that "in progress", "pending review", and "published" is pretty useless unless we have two versions of the same content - one version is displayed in frontend and the second version is some kind of draft that can be freely edited without affecting frontend.

Now the question is if TL needs workflow management. As long as TL is used for small sites, like personal site or small business site etc., it is not really needed. But for anything more complicated than this, workflow management might be a deciding factor. I used to manage a website of an insurance company. There was a legal requirement to publish asset value of their mutual funds on a daily basis. There were also penalties for publishing incorrect information, so workflow management was one of the most important requirements. That is just one example where we couldn't use TL just because it lacks workflow management.

I believe the question about TL "market" is really good. It seems to me that TL is used for small sites only (maybe with few exceptions). If this is what Leo and TL team aims for, then workflow management is certainly not required. But I believe that TL's potential is much more than this.

[thyon]

Well we could do the following to start the process of suggestion:

• Add a published field to the CE[/*:m:2qtz9bai]
• Add a flag in tl_version as "preview version"[/*:m:2qtz9bai]
• Allow a new save method, so that you can [Save Preview] which will create a new version in the version database, associated with the CE.[/*:m:2qtz9bai]
• The FE will still be unchanged, as the FE will retrieve from tl_content table[/*:m:2qtz9bai]
• The preview feature will retrieve the latest "VERSION" from tl_version where "preview version" is true, deserialize it, and display that instead of the normal tl_content element.[/*:m:2qtz9bai]

That would be a way to start, without too much core changes and still make it compatible with current sites.

[galide]

I used to manage a website of an insurance company. There was a legal requirement to publish asset value of their mutual funds on a daily basis. There were also penalties for publishing incorrect information, so workflow management was one of the most important requirements. That is just one example where we couldn't use TL just because it lacks workflow management.

Yes I think you nailed it with an excellent example. More generally, you'll take the risk to receive calls at 10pm from a distressed client who has done a change to the site in the evening, made a mistake, and is now panicking about the fact that the changes are live.

Thion is already willing to start drafting requirements, we have identified a need and proved the relevance of the core feature. It may be interesting to set up an english workgroup for this, starting with drafting the specs, etc.. ? I would definitely be interested in joining the team. I am not very familiar with the process of setting up work group for open source projects though, and especially typolight. Any pointers?

[scare]

Well, no need to add this to core, I believe. Custom extension will do, after all if some 5% of sites require this feature, there is no real reason to ship it with all installations.

We'll need to duplicate DC_Table, though. That is a lot of work, but we could benefit from it also in Catalog module (and many others), so it is worth it.

Now that I think of it, there will be problem with any extension that uses save callbacks and writes directly to database. There is no way to prevent an extension from writing changes that would be immediately propagated to front-end. The only way would be some sort of abstraction, so that extension does not know where data are saved. This requires changes to all extensions, of course. Transition to 3.0 would be great opportunity for this, but we'll need to convince Leo that this concept of abstraction is good thing in the first place

[thyon]

No need for the client to panic. Just use the version manager at the top of the table screen to re-instate the previous version.

[Antipitch]

@Ben:
I'm not sure if I fully understand the ticket you mentioned. Or rather where Leo's aiming at with it (diff utility?). Else I agree with your points.

@galide:
Like Thyon, I don't think the "panic" situation is the crucial point here. Simply change the text, image whatever, again (in the end, you'd have to check and publish everything your customer does?) Diversified publishing rights and relaxed preview is what I thought about.

@Thyon

If I wanted Supersize and bloated, I'd look for the closest McDonalds

liked that one ;-). Not sure, though, if the feature would really expand the system so much.

Concerning your points:
1. CE published field
I think that's sufficient as it is (only that the switch on/ off button for CEs in the article/ list view should be accessable for user rights management). But we'd probably need two new buttons: "publish" and "save & publish" (for admins etc.) in the CE edit view, rights manageable of course.
2. Versioning:
In an older German thread (EFG-)Tom also suggested to use that for a publishing feature. I'll try to find it and post the link.


cheers
Antipitch

[galide]

It was suggested to have a look at http://dev.typolight-forge.org/projects/show/wfm

Is it worth you thin setting up an "english" version of it maybe?

Emmanuel

[Antipitch]

Hi galide,
that project seems a little stuck (don't know about that, though. You'd have to ask lindesb).

Anyway, while it would bring big improvements concerning user-rights, it won't address our "preview and publishing of changes of already published elements"(jesus!)-problem. At least, that's what I understand from the manual (I'm German ;-) ).


cheers
Antipitch

[galide]

ah, sounds like a dead end then :-(. Let's bring up a new project then, in english preferably..

[lindesbs]

Hi, i? lindesbs the developer of the alpha version of my "little beast" (my nickname for that module)

wfm is just a test, what could be done. Its just in german yet. I've missed to translate it. Sorry.
Actually i have no time to work on this app, cause i've to finishe some other modules.

My first ideas for wfm was, to remove possibility for users / groups. It is foreseen to have a sidepanel, with "jobs". Taht means, a writer creates an article. This article is ready to be reviewed from an other person. He click on the sidepanel "review" and thats all.

Than the reviewer receives an eMail : "Something happens"

And he can do his job, concerning his workflow restrictions. For example, he can go through his list of articles and so on.

I think it must be translated asap. I have three weeks of holidays. SO i can do a lot ;-)

[Ling]

Any progress on this issue?

Workflow management is indeed a missing feature but I agree with thyon that it shouldn't be a core feature.
It should be shipped as an extension. Ohterwise TL would loose its slim character and would get another TYPO3 / Drupal thing.

Btw: I would prefer if there's an english only trac...

[osindero]

Is there any update on creating a workflow management extension module?