Re: CMSMS 2.0 (say what now?!)
Posted: Thu Apr 05, 2007 7:38 am
Means existing FrontEndUsers moduleAnastasis wrote: what is FEU?
... ...CMS Made Simple Forums
Content management as it is meant to be
https://forum.cmsmadesimple.org/
CMSMS 2.0 (say what now?!)
Page 7 of 18
...Re: CMSMS 2.0 (say what now?!)
Posted: Thu Apr 05, 2007 10:54 am
Aha! Should have realised - sorry. Another TLA in the bag!cyberman wrote:Means existing FrontEndUsers moduleAnastasis wrote: what is FEU?
Re: CMSMS 2.0 (say what now?!)
Posted: Thu Apr 05, 2007 3:31 pm
This is great to hear. Keep up the good work, Ted and everyone!Ted wrote: 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.
Re: CMSMS 2.0 (say what now?!)
Posted: Fri Apr 06, 2007 11:14 pm
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.
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.
Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 11, 2007 9:56 am
If we get a PHP5 only system why not make a real break?Ted wrote: all the things mentioned in the 1.1 thread apply... including being PHP5 only.
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
...Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 11, 2007 10:15 am
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.cyberman wrote:If we get a PHP5 only system why not make a real break?Ted wrote: all the things mentioned in the 1.1 thread apply... including being PHP5 only.
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
Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 11, 2007 1:22 pm
Hello,
Yeehoo! You have two strong points.
Pierre M.
Database engine agnosticism ? Drop of another performance eater ?cyberman wrote: 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
Yeehoo! You have two strong points.
Pierre M.
Re: CMSMS 2.0 (say what now?!)
Posted: Fri Apr 13, 2007 10:11 am
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
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
Re: CMSMS 2.0 (say what now?!)
Posted: Fri Apr 13, 2007 12:23 pm
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.
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.
Re: CMSMS 2.0 (say what now?!)
Posted: Sun Apr 15, 2007 9:58 am
Sorry, this was a quote from tutorials pagePierre M. wrote: But NOT "so we can also eliminate Static HTML Generation as well"
...Re: CMSMS 2.0 (say what now?!)
Posted: Tue Apr 17, 2007 6:28 pm
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 firstTed wrote: 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.
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.
Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 18, 2007 7:52 am
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
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
Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 18, 2007 4:50 pm
And be able to secure content based upon groups, including shopwing/hiding navigtation.Foden wrote: 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
Re: CMSMS 2.0 (say what now?!)
Posted: Wed Apr 18, 2007 5:54 pm
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.
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.
Re: CMSMS 2.0 (say what now?!)
Posted: Thu Apr 19, 2007 8:25 pm
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?Ted wrote: 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.
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?