CMS Made Simple Forums

A separate admin section would be the solution, but like you said... it isn't a clean one as you don't get to see exactly which page in the hierarchy you're modifying.... but is a handy solution to allow you to quickly and easily find all the pages that are in draft mode.

NaN wrote:

calguy1000 wrote: However, you would still need to hack the listcontent page to be able to view modified pages

The module i'm developing has an own admin section that shows only content of type "ApprovableContent".
There all non-approved drafts will be shown.
The listcontent.php still just shows the actual content.
There will be no hack of the core neccessary.
Only minus is, that you need to manage two kind of content lists.
The default one and the approval stuff.

Hmmm... this starts to sound promising.
If I understand this correctly; there would be "two" pages (one listcontent.php, but different content shown) one which shows the live content and one page that is shown to the chief exclusively: the pages that are in draft.
This might be a good thing. At least it's clear which pages need approval. (Hierarchy would be clear, pages names clearify this, in my situation)
It might be different from the intuitive style from cmsms backend. But as long as the functionality meets my wishes, I would be really happy.

I feel a bit, what it's called... like standing from the sideline, supporting a team, hoping that others make a goal.
Is there anything I can do?

I need some coffee 

Still alive here...

jack4ya - have you had any luck with this? I need the same functionality and have thought of a different, iif fairly clunky, solution which is what I will probably implement as a stop-gap til version 2.1.1 is released  (as in - when version 2.0 is mature and released and doesn't behave in unexpected ways). It is a prime example of operating / programming on crack but then that's my style 

I too have control over my own server and my own domain.

In my case, the approval process can be followed by asking I.T. (as in sending me an email) asking to put such and such a piece of content "live".

I am already running dev and staging versions of the site as well as live versions.
These would be at dev.whatever.com and staging.whatever.com as well as www.whatever.com which is live. (By the way, whatever.com is not the actual domain, the actual domain is currently subject to a nondisclosure agreement)

now...

Here's what I will do:

There are a finite number of content creators / editors. They're called Bob, Joan, Mike and Sarah.
So I create subdomains with password protection in .htaccess at bob.whatever.com, joan.whatever.com, mike.whatever.com and sarah.whatever.com.

I then install CMSMS in these domains and copy the current site across to them.

Now whenever content needs to be changed on the site, these individuals make the change to their copy, then call up IT and after the approval, that change is manually copied into the staging site (for testing) then onto the live site. When content is copied to live it also gets copied to the other personal subdomains for content editors. One way to maintain multiple repositories like this might be to use SVN but I need to have a look to see whether SVN can be made to take the content (which is basically HTML) from the database and update it to static files which are held in the SVN repository. That would enable diffs for when there is concurrent editing.

This would just be a stop-gap til v2.0 comes out but bear in mind they've been promising v2.0 for the last 2 years so don't hold your breath

NaN wrote: I need some coffee 

Maybe you should provide a link for a paypal donatation so you can buy enough coffee and release your module .

uptoeleven: that's undoable as I have about 30+ editors... So no, your solution does not work for me.

NaN and me have gone behind the curtains here. 
He is still developing (when he has time) the "module". Unfortunately there are some core files that needs modification. For me it's not a big deal, just need to keep track of the modifications, hoping I can implement them again when upgrades are needed and hoping the will remain working until 2.0 is up and around.

NaN will get his coffee off course, that and a "token of apprecation"...

Now for the cmsms bunch; I paypal donation is underway, but it does not come from my pocket, so it needs some time.
And off course, I am trying to donate even more time to the forum. Trying to answer questions that are to my level, hoping that it saves time for the cmsms experts, so they can dedicate themselves to the more serious questions.

Hello all,

I'm not a programer, I haven't reviewed CMSms' code, I'm not in the (wonderfull) DevTeam, I have no money to sponsor this feature. Hence my contribution here in only loudly thinking hoping it helps the CMSms ecosystem as a whole. Of course I don't demand the DevTeam and contributors do this or that. CMSms is their product and they are free to code how they want and like.

Once upon a time I wrote somewhere in these forums : a content approval feature requires the content versioning feature. Because what is approved is one specific version and what is edited is a new, not yet approved version. Hence everything is a version. If you need the approval feature you have to sponsor the versioning feature FIRST.
As soon as strong versioning is working content approval is simple to implement : approvers review lists of content (and/or notifications) and change the approval status (the same wat they would change the caching status or the page alias) and the frontend is slightly modified to render only the latest approved version (implementation suggestion hereafter).

Today I add : the content versioning feature lessen the need of the locking feature. This is a benefit of versions : an edit produces a new version. Two concurrent edits produce two distinct versions. None trashes the other one. Both are recorded and can be copy paste from to edit a consolidated version (the one that will be approved See, "locking" is managed by exception : there is a notification to reconcile content and no more data loss.

jack4ya wrote: Isn't it possible to have (...) "content_draft" next to the "content" in the db table cms_content_props.
(...)
Is this a good idea? Can anyone help me with this
Is this is a bad idea? Why, and what would be a better solution?

My opinion is that it is a bad idea (sorry It is a data modelisation argument :
I'd rather a "version" field (unique counter) beside each "content" record. And NOT a "draft" field.
Furthermore, leveraging the strength of this versioning system :
I'd like an "approval_level" field and a "language_tag" field too. This way :
-a draft is a given version (record) whose approval level is zero.
-a reworked draft is another (bigger) version (record) whose approval level is (still) zero.
-a live content is the same version (or any later version, the latest in fact) whose approval level is at least N.
-N is a global parameter. With N>1 you get multilevel approval. (editors, section editor, editor in chief)
-BTW we have multilang in the core : just fill a version with the language tag you want and get it approved.

Yes, you have read this : content versioning, approval workflow and multilang. 3 fields away from today's implementation ?-)

NaN wrote: Storing content, draft and "approval status" as content_props won't need changes to the database.

Good news. (I don't know myself) I hope you are right.

Implementation impact : I can't measure that but I would liberaly say that
-where the "content table" is read today : the frontend would be only slightly modifed ?
-where the "content table" is read and written to : there seems to be more work in the backend. But if there is already some "content_props" thing to tag content with version, approval_level and language it may be better ?

Could this apply for Google SoC 2009 ?-)
Have fun all

Pierre

The sad truth of this is that my proposed solution doesn't work for me either. It's clunky and requires multiple subdomains, any of which could post content that clashes with another user, those suggesting version control are spot-on. It also requires a mechanism to stage content between development, staging and live servers which CMSms doesn't have. Given that my deadlines are so short I think I'm going to have to regretfully concede defeat on this and move to another CMS FOR THIS PROJECT ONLY!!!

The ones I'm testing are:
Tribiq, Automne, Ezpublish, Sitellite, Typo3 (god help me) and MySource Matrix.

I know this is not the place to talk about other CMSes and I hate it when others talk about them BUT if you have any recommendations or comments about those I have chosen please PM me. Amongst my pre-requisites were content versioning, content approval and workflow, and skinnability that enables me to make it adhere tightly to a design that will be given to me. One of the shocking things about some CMS systems that people say "oh use this one" is that they only produce sites that look like they were produced by that CMS. It was why I stopped using Mambo - I had to hack the source-code to get it to make my old site look like my design. It's why I recommend CMSms. But until CMSms v2 I won't be able to do what I need to FOR THIS PROJECT so I wait and in the meantime look elsewhere.

Caveat - I will of course continue to use the wonderful CMSms for all my other sites