CMSMS 2.0 (say what now?!)

[cyberman]

what is FEU?

Means existing FrontEndUsers module  ...

[Anastasis]

what is FEU?

Means existing FrontEndUsers module  ...

Aha! Should have realised - sorry. Another TLA in the bag!

[pgoneill]

Yup, totally agreed.  Users, groups, permissions (including viewing) will all work in the frontend as well as the backend.  It won't be as powerful as FEU is now, but we'll have some way to extending the users to have the same power as FEU in the future with modules.

This is great to hear.  Keep up the good work, Ted and everyone!

[Anastasis]

aozuas

Congratulations on some excellent websites. As someone who is just beginning to experiment with CMSMS and have not yet built my first site with it, these are very encouraging to me to show what CMSMS can do no matter what the style of site on the outside.

Thanks for sharing them.

[cyberman]

all the things mentioned in the 1.1 thread apply...  including being PHP5 only.

If we get a PHP5 only system why not make a real break?

PHP 5.1 has included PDO support. Via PDO we can get access to mysql, postgres and sqlite.

If we would using this we don't need a performance eating database layer like adodb anymore  ...

[Milhaus]

all the things mentioned in the 1.1 thread apply...  including being PHP5 only.

If we get a PHP5 only system why not make a real break?

PHP 5.1 has included PDO support. Via PDO we can get access to mysql, postgres and sqlite.

If we would using this we don't need a performance eating database layer like adodb anymore  ...

Agree. Most hosts who have PHP 5+ have PHP 5.1+. I think it would be great if new CMSMS will be really "future" CMS. PHP4 is becoming history. In the meantime, maybe it will be necessary to keep 1.x version secure for unfortunates.

[Pierre M.]

Hello,

PHP 5.1 has included PDO support. Via PDO we can get access to mysql, postgres and sqlite.

If we would using this we don't need a performance eating database layer like adodb anymore  ...

Database engine agnosticism ? Drop of another performance eater ?
Yeehoo! You have two strong points.
Pierre M.

[cyberman]

If we will use AdoDB (not lite) furthermore there's another solution.

AdoDB has his own cache mechanism so we can also eliminate Static HTML Generation as well.

Please read this tutorial

http://www.phpfreaks.com/tutorials/110/1.php

[Pierre M.]

Thank you for the link. I've just read one page.
This adodb caching mechanism can empower MySQL for sure. But NOT "so we can also eliminate Static HTML Generation as well" IMHO. I think full static HTML/CSS page caching is better : not only it doesn't need db access, it doesn't need PHP CPU/mem as well.
Pierre M.

[cyberman]

But NOT "so we can also eliminate Static HTML Generation as well"

Sorry, this was a quote from tutorials page  ...

[styson]

Yup, totally agreed.  Users, groups, permissions (including viewing) will all work in the frontend as well as the backend.  It won't be as powerful as FEU is now, but we'll have some way to extending the users to have the same power as FEU in the future with modules.

When you integrate the users into both front and back, I hope you design it so the Front end users can be local in CMSms OR in another system (LDAP, Acitve Directory, custom).  Obviously the bridge for authentication to the other system would be a custom module developmed by those who need it first   I say this because tomorrow I'm recommending to a client that we use CMSms and I'll be modifying the FEU module to authenticate users against another system.    How easy/hard this will be only time will tell but architecting the core so it can accept this in the future would be awesome.

What I see for the next release is great as well.   

[Foden]

About the user / group handling...

Will it be made so that you can assign ownership of a set of pages to a group? And then add editors to that group, instead of adding them to each page?

That feature could be nice

/ Thomas

[styson]

About the user / group handling...

Will it be made so that you can assign ownership of a set of pages to a group? And then add editors to that group, instead of adding them to each page?

That feature could be nice

/ Thomas

And be able to secure content based upon groups, including shopwing/hiding navigtation.

[Ted]

So the ACLs system will be based around groups to start, and then we can extend it to users later if we feel it's not flexible enough.

Permissions will work hierarchically in the case of pages.  So...  you can set permissions for all the pages by modifying the permissions for the "root" of the pages tree.  You can then go to one of the children and override those permissions.  But, the nice thing is, the children of that overridden page will now respect the overridden permissions instead of the "root" permissions.  This means that you can lock down certain sections of the hierarchy to various groups.

One of these permissions will be the "View" permission and will affect people on the front end.  So, in theory, you should be able to cut off an entire section from public view and only allow people with a login or a particular group to view them.

Again, granting those permissions will be on a group by group basis unless we decide otherwise to add the additional user specific permissions down the road.

Hope that clears up some stuff.

[styson]

So the ACLs system will be based around groups to start, and then we can extend it to users later if we feel it's not flexible enough.

Permissions will work hierarchically in the case of pages.  So...  you can set permissions for all the pages by modifying the permissions for the "root" of the pages tree.  You can then go to one of the children and override those permissions.  But, the nice thing is, the children of that overridden page will now respect the overridden permissions instead of the "root" permissions.  This means that you can lock down certain sections of the hierarchy to various groups.

One of these permissions will be the "View" permission and will affect people on the front end.  So, in theory, you should be able to cut off an entire section from public view and only allow people with a login or a particular group to view them.

Again, granting those permissions will be on a group by group basis unless we decide otherwise to add the additional user specific permissions down the road.

Hope that clears up some stuff.

Excellent Ted!!  That will work out great.  Will the security model extend to the code that generates navigation so if I cannot view  a page, it is never presented to me in the first place in the nav menus? 

Will setting the  permissions will be handled as part of the page creation process?  Allowing content creators to  set what groups have what access to that page.

Are we looking at June/July for this release?