CMS Made Simple Forums

Hey all,

It's been awhile since we've had a release, or really any word on what is going on. So, I figured I'd just tell you all what is going on in CMS development.

Last night I merged my code for 0.8 into the subversion repository and it's coming along. While not ready for release by any means, the code is starting to stabilize. Why did it take 2-3 weeks just to get to a point where code is in subversion?

Well, 0.8 competely rewrites everything related to content. New database schema. New library. New add/edit content pages. All this is done in the interest of making content itself more flexible. We now will have the ability to add new content types with little to no work, including no changes to the database schema. We will also have the ability to make new content types via modules that will be as flexible as using the standard {cms_module module=""} syxtax that we're used to. Using News as a content type will actually have the same option set that the cms_module equivilent has.

Also in the works for 0.8 is a lot of additions into the module API to account for other shortcomings in the current system.

For example, WYSIWYGs will now become modules themselves that can be installed and uninstalled. This will also give us the ability to support more than just HTMLArea, and for the people who think that the CMS distribution is too big (like myself), remove it completely. I'd like to support fckeditor and/or tinymce as well, but that might be done after the 0.8 release.

The dhtmlmenu will also become a module. We need to get the phplayers code out of the document root and also need to have the ability to send out the link tag into the head, since putting it where it is now is technically invalid for xhtml. The upgrade script for 0.8 will take this into account and modify your template so that your site isn't broken.

Needless to say, this might be the most ambitious release since 0.1. Almost every file has been touched in this process and hopefully it'll make a more stable, more flexible product. We'll see.

Things are going good as far as development. I'd like to have an rc out before the holiday and hopefully a 0.8 release before the end of the year, but time is ticking and life is starting to get a little busy.

If you have any ideas, requests, complaints, NOW is the time! I'm in heavy development mode right now and any ideas could help shape the code before it's written instead of hacking in fixes. Let me know in IRC, here or post bugs and/or feature requests into the bug tracking system so that I can take stuff into consideration before it's coded.

Thanks for all your support. This really is a lot of fun.

Ted (wishy)

Wow! Waiting for the next version unpationately, man!

I believe, it is nessasary to define one important moment, namely - pages editing. Many CMSes are built for the users you can trust, so you just arrange that WYSIWYG editor with numerous options that allow them to do, practically speaking, everything with the site. But what if a user cannot be trusted all that well? _And I use the word trust here not to doubt somebody's good will or intentions but to underline that the design and structure of the site should stay the way I, as a professional webmaster, made it._ What will happen to the design and structure of the site if such an... erm... "amateur artist" decorates it with the huge images of different sizes and style, adds some color to what he thinks is too pale, etc.? I have already mentioned the {image} container, other visitors talked about the multiple content blocks (I personally think even two blocks would be more than enough to sutisfy the 99,9% of the customers, say - {content1} and {content2}). But it also would be great to transform the WYSIWYG into more strict editor (or into different WYSIWYG editor, and by the way, it is great to know that the WYSIWYG would become one of the plugins), where only, so to speak, "innocent options" would be available, namely: bold, italic, underline, link, email, bulletted list, numbered list, and THAT'S IT!

I definatly agree. Giving too many options to "inexperienced" users can definatly be detremental to the look and feel that a web designed spent their hard erned time developing. We should probably look into "crippling" one of the WYSIWYGs when it becomes a module. TinyMCE comes to mind right away, just because it's the least featured of the 3 I'm interested in supporting. Between this and multiple content blocks, you SHOULD(?!?) be able to throw anybody in there and let them edit pages that still conform to the admin's look and feel. Consider it on the TODO list, though probably a post 0.8 item.

Thanks for the kind words!

There are always two sides to the 'locking down' of applications and capabilities. I have one CMS Made Simple website were there will be many users adding content. I find the group permissions to be very helpful as this keeps them out of the template and css areas. I have the 'add content' 'modify any content' 'modify files' and 'modify news' only, enabled for the majority of users. The other saving feature is that all this is stored in a database that can be saved and restored in minutes.
I have been on the receiving end of locked down applications and as an experienced user I find it very frustrating to have features that I cannot use.

CMS Made Simple is the best CMS.

In the risk of getting way too far off topic, but still in the areas of security

I am recollecting another need....

One where different users are allowed to see different content. I have just recently setup egroupware at the office, and one of the features I took most advantage in their cms (sitemgr) stuff was the ability to show different content to different users.

I also want this flexibility at my home site, so family members can see content that anonymous browsers cannot. Currently I am doing this with two cmsms installations, and .htaccess (not very much fun).

Yeah, this is a good point. I'd like to come up with a good solution to this without making it a huge deal. I'm thinking that it's possible to do in a module (especially with the pre and post render hooks in 0. and now have to mess with the core, since it kind of goes above scope. I'd discuss the details with someone if they're interested in writing it.\

And how about replace from Google search in {search} to internal search script?

Hey, a fresh thought on the Tahiti version!
Wouldn't that be more visual and simple at the same time, if the checkboxes in the Group Management could not only regulate the permissions to Add..., Modify..., Remove... etc, but also control the visibility of the menu items (Show Content Management, Show Template Management, etc.) in the left? What I mean - is it possible to make the menu look like the following:

Content Management
File Management
Show Site
Logout
ModulesNews

and that's it! We are not embarassing a user with extra menu itmes, that he is not able to edit anyway. Out of sight, out of mind, so to speak.

Great idea! Been meaning to this for months now. Now is as best a time as any.

Basically, I'm going to take a shot at seeing if the user has access to any of the options on that page. For example, if they have any group related permission (add/edit/delete/change assignement, etc), then Group Management will be shown. Less work for the user, I'd say. Obviously, there is no way to handle this for modules, so they will all be shown.

Make sense?

Yes, it's even better!

What about (my favorite) {image} anyway? What I meant was wouldn't that be great if {image} could not only be like the blob but so it could be customizable, so one could choose/place/delete the image in the respective page?

I see one pretty interesting possibility here that could be archived by a couple of ways (just a notion, let me know what you think ):

1). If {content} and {image} are available in the chosen template than the text field/wysiwyg editor and the prompt dialogue of {image} choice (with the optional link to the bigger image) will appear in the Content Management in the Edit pages menu. If there is no images on the page than just {content} appears without all those additional features, just the usual interface.

2). Or: the Edit Image button/icon could appear right beside the pages that use the template with {image} in the Current Pages table.

Which way do you think is the best?

Oh, I see what you mean. That definatly goes beyond the scope of Tahiti. Hopefully multiple content blocks will be in the next release and this might be a good time to do something along these lines. {image} would probably be a good idea to do as a plugin for now and then can be moved over to more advanced functionality later on.