[Simplecms-development] Re: SimpleCMS

[Jonathan C. <jon...@gm...>]

I have moved our discussion to the dev mailing list. Your ideas seem
very good. I've done some research into the PEAR::DB and it seems that
the DB API supports SQLite, which is a very small single binary SQL
server. You don't even need a dedicated server, you can just evoke the
program to run and it takes care of both server/client sql connections
(as apposed to mysql having a dedicated server and a client to
connect)...

Note: These database programs would make our data human unreadable.

If there is no objection, PEAR::DB will be the library SimpleCMS will
use for database connections. I'm thinking about even including SQLite
in the package or clear instructions on how to install SQLite into
SimpleCMS. The only problems we may face is if the user is not allowed
to run binaries on the server. Then this will not work and we should
go for a purely php solution. I still think SQLite is a good enough
compromise.


As for modules, I am talking about php code snippets that create
dynamic content like a postback menu, news page, address book pages,
dynamically generated month calendar with links to the events on that
day and events pages. I would like it so that programmers can write
modules that may somehow just be loaded into the whole system and that
a admin can write a page that just has the static content then invoke
the dynamically generated calandar to load up with just a
<<calandar>>. Somehow, maybe with a module manager system, SimpleCMS
will load the correct module to replace <<calandar>> with the
dynamically generated calandar. I am not sure will we be using Smarty
as part of this or not, but this is my goal. Please feel free to ask
questions if you don't understand.

I believe it time to define who and what we are making this for before
we continue on.

I have 4 different types of users in mind from my experience with
content management. You have basically

1.) The programmer/developer - develops php modules, works the most
with the code.
2.) The administrator - Does not necessarily know much or any php
code. He defines what template to be used, manages the user list,
takes care of global config.
3.) The Editor - many times, the editor and the administrator is the
same person. Just edits content on the site, does not have any access
to code or administrative duties.
4.) The End User - the one who browses the site and doesn't have a
clue how much work we put in to it to make it look pretty... :-P

The administrator and editor can be called the user because they will
be "using" the most features in SimpleCMS. Let us use these terms to
avoid confusion.

I think we want to make it easy for ALL four types of users to use
this system. I'm pretty new to OOP, so you will have to tell me if I'm
not implimenting it correctly.

I would like to see that we somehow have a module for everything so
that no deloper is forced to "hack" at anything to customize it. I
would like to see modules be able to be inserted on all levels. A
module management system would be nice too.

I think SimpleCMS core should handle only these things:

1. Database connection
2. "static" content (content inserted into the DB) and URI layout
3. BASIC Administrative Authorization to edit content (admin userlist)
4. Templating System
5. Module management

This is all I can think of at the moment. I want us to make sure we
stick to these things as the "core" of simplecms so we do not start
throwing in dynamic loading news pages, and other things that really
should be modules we add on. We definitely want to write news modules
(with sweet RSS feeds), calandar modules, and maybe even forum
modules, but we do not want to mix these into the "core" of SimpleCMS.

We'll just take php5 as it becomes more popular and we actually have a
user base who uses it. I'm sure upgrading from 4 to 5 will be just as
simple as changing a few lines here and there.

From what you're explaining, I have used multiviews before. I believe
apache should be our primary http server to support. I think we can
support both multiviews and mod_rewrite. We can make it an admin
option whether to use one or the other.

As for complicated rewrite rules, I was planning to have all URIs
besides URIs with media extensions (.bmp,.png, .gif, .mp3, .mpeg,
etc.) rewrite to "/index.php?" or "/index.php?page=".

I have heard of a mod_rewrite program for IIS, but it is not
opensource or freeware. I really do not care to fully support IIS, I
just believe that SimpleCMS should be able to run on it.

Having everything in lib doesn't exactly sound like the best idea to
me. I think the "core" modules should be in /lib/, but the user
created modules and user edited/created templates shouldn't go there.
Remember, our goal is to make upgrade as easy as possible. If we keep
only the "SimpleCMS core" code in /lib/, we can have users easily
upgrade by just replacing the lib folder. Modules and templates should
remain outside because the modules may be edited and the templates
too. We don't want to overwrite user edits.

I'm interested in using the "tiny_mce" javascript HTML editor so that
the editors and administrators do not have to insert content using
html codes. I agree with you that we should keep the html codes away
from the user as much as possible. I can see what you mean.

Well, to wrap this email up and to start some work, these are the
summery of what we have so far for SimpleCMS.

1. We WILL be using the PHP::DB API.
2. We WILL be using the smarty templating system.
3. We aren't going to be concerned about php5 till later.
4. We won't worry about "user" modules (news modules, calandar stuff,
etc.) until later - we're going to work on the core first.

Some new issues to think about:

1. I think we should have some coding standard (where to put white
spaces, how to comment things, etc) so that it isn't all a mess. I
suggest using PEAR's standard:

http://pear.php.net/manual/en/standards.php

2. How much access will we give to SimpleCMS? I know this can have its
security risks, but for the most automation, i'd like to see SimpleCMS
be able to write to the modules directory so that you can install
modules from a menu, SimpleCMS to have full access to the database so
that modules can make use of the database. Maybe we should have
SimpleCMS check for file permissions and install things automatically
only if it can write to the files?

3. Where do we want to work on the whole thing? I'm not to found of
CVS. I'd like to do the whole thing on simplecms's shell account
space... What do you think?

We're doing good... after a few more of these emails, we should have a
well laid plan so we can start writing a solid CMS system.

Jonathan Chan



On Sat, 26 Mar 2005 21:54:19 +0100, Toni Corvera <ou...@ou...> wrote:
> El dv 25 de 03 del 2005 a les 22:12 -0500, en/na Jonathan Chan va
> escriure:
> > Good ideas...
> >
> > I like the PEAR::DB idea especially... I was going to write my own
> > libraries, and I knew i was going to run into some major headaches
> > before i even started! Only question I have about PEAR::DB is does it
> > support a flat file DB? I'll have to look into that API, but we
> > definitely will want to use that or another similar API library.
> 
> Nope, it doesn't have flat file support AFAIK, although it's easy to
> extend. You could for instance create a "proxy class" to the library you
> where thinking about. By the way, if the flat files are not required to
> be human readable, maybe berkeley db <http://php.net/db4> could be
> interesting, it isn't implemented in PEAR::DB but is in PEAR::DBA.
> 
> > As for modular design, OOP definitely... I don't know exactly how we
> > would "plug" into the PEAR libraries as I haven't used them much. I
> > know I would like to have modules that would require no user
> > configuration. Maybe a module upload menu? It would be neat if all the
> > user had to do was upload the module, then add a tag like
> >
> > <<PostBack>>
> >
> > and a post back text box with a submit button and everything take the
> > place of the tag. I dunno how we will exactly do this, but I would
> > like SimpleCMS to be both easy to hack at by programmers and easy for
> > a user to configure. The modular system should allow that if we make
> > rules for modules to be designed and called in the code.
> 
> Mmmh, I'm not quite sure if I understood you.
> About plugging to PEAR, no special magic is needed.
> What's wrong with?:
>   class Sample
>   {
>       var $dbi;
> 
>       function Sample() {
>           $this->dbi = DB::connect();
>       }
>   }
> 
> > As for the templating system, I have never looked into smarty, but I
> > have heard of it. My main concern is ease of use to make a template. I
> > was hoping that templates could be made as easily as making a regular
> > html file and adding tags like <<content>> and <<navbar>> or something
> > similar. If smarty can offer this, then let us definitely use it. If
> > not, remember, our goal is ease of use and ease of installation. If
> > the user can not make his own template, it defeats our first goal.
> 
> I had avoided using smarty for this concerns, now I'm using it and
> happy :)
> The "<<content>>" and "<<navbar>>" could be declared as smarty functions
> (functions can be attached to smarty easily) and they could be called
> from the template files as you mean.
> 
> BTW, I personally suggest to avoid the dealing with HTML in the PHP
> code.
> 
> > I would love to support only XHTML, but then again, we would not be
> > providing support for the newest of html programmers. If we can have
> > an option to switch from html tags <br> <img> to xhtml tags <br />
> > <img /> easily, we can allow sites to comply to the w3 validator even
> > if they only know html. Remember, the template will hold most of the
> > code that would make it an html or an xhtml site, we should comply to
> > the users preference rather than force a standard on the user.
> > Definitely, we would want to steer users away from tables and other
> > achaic HTML practices. CSS and <div> are definitely what we want to
> > promote.
> 
> I guess you mean that apart from the template file, all the HTML code
> comes from the user.
> The problem is, there's not enough with transforming those tags to make
> the document validate. "<b><i></b></i>" doesn't validate.
> "<span><p></p></span>" doesn't validate... As I see it, if you allow the
> user to input HTML you must trust it will be valid, because correcting
> it would be quite heavy.
> 
> > Competitive meaning it can be used by large sites with millions of
> > hits per day. That would mean it would have to have a good layout,
> > easily templatable/customable and perform well in those high stress
> > environments.
> 
> OK.
> 
> > We DEFINITELY want to be big on the documentation part. I've used
> > other CMSes before, and because the documentation were not clearly
> > defined, I end up hacking it and making a huge mess. I would like to
> > make a modules directory or something like that so that this system
> > can be easily upgraded when we release new versions. I remember
> > upgrades where a pain! You got to re-hack all the changes you made
> > from the beginning.
> 
> Yuo, I've also suffered from this.
> An idea: OOP could be exploited to retain local hacks, for example:
> 
>   // SimpleCMS provides...
>   class SomeModule
>   {
>       ....
>   }
> 
>   // The user hacks it:
>   require_once('path_to_some_module');
>   class SomeModifiedModule extends SomeModule
>   {
>       ....
>   }
>   // And then uses SomeModifiedModule instead of SomeModule
> 
> Explain on the documentation this is the preferred method of extending
> the CMS and it may even work :P
> 
> > Minimum requirements:
> >
> > Definitely php4... We got to start worrying about php5 (i haven't done
> > any work in it yet...)
> 
> Well, php5's adoption is and will be slow. PHP5, afaik, doesn't breaks
> current code as long as some care was taken. In my experience the only
> important part for compatibility is, in PHP5 objects are references, so
> on current code just declare (and pass) them as such.
> References are (or at least were) a bit obscure in php, so in case you
> have no experience with them:
> 
>   // Object Construction
>   $myObject = new Object(); // normal
>   $myObject =& new Object(); // reference
> 
>   // Pass-by-reference: only on the function prototype
>   function someFunction(& $referencedObject) {
>   }
> 
> The other interesting bit is, just don't declare methods starting with
> "__" and that's it, mostly.
> 
> > I don't believe we have to worry much about client side minimal
> > requirements because individual templates would have to worry about
> > that more than us.
> 
> Yep, I was talking more about the default template(s), and, if the PHP
> code includes any HTML snippets.
> 
> > I guess we should forget about signing up to the mailing list if it is
> > just us 3, unless you want our progress to be publicly readable in the
> > mailing archives... I do have a few issues I would like to discuss...
> 
> I've subscribed anyway. Also, some interested user may sign to follow
> development, so it's a good place to discuss things.
> 
> > 1. What URI naming layout do you want to have? I am thinking about
> > having the WHOLE content management system handled from the /index.php
> > page. From there, all the other modules and pages would be loaded (ie.
> > /index.php?news, index.php?guestbook, etc). If possible, I would like
> > to see ALL the pages of this system called from the index page so we
> > could throw a mod_rewrite rule or a similar system to hide the
> > /index.php? to make it Search Engine friendly and create nice easily
> > rememberable URIs.
> > Toni: You suggested MultiViews, would you ellaborate how that would
> > work, whether we could use it in this situation?
> 
> Yes, first of all I don't know if any other server than Apache
> implements them, but they're useful to jave clean URIs without HTTP
> redirects as I said. More below.
> 
> > 1b. I have an idea to make the layout like a directory tree. Some
> > pages to be below of parent pages. IE:
> >
> > (this is with mod_rewrite or another tool already enabled)
> >
> > http://example.com/news
> > http://example.com/news/NewRelease
> > http://example.com/events
> > http://example.com/events/baseball
> > http://example.com/events/baseball/team
> > http://example.com/events/baseball/schedule
> >
> > This will be complicated to impliment, but I believe this give our CMS
> > system the most friendly URI naming scheme. Any thoughts whether this
> > would be a good idea or not? Thoughts to expand no this?
> 
> I'm using a similar this scheme on my site, and it's not that hard, at
> least with MultiViews ;)
> My version is a bit less friendly, I'd have:
> 
> http://example.com/section/news
> http://example.com/section/news/NewRelease
> http://example.com/section/events
> http://example.com/section/events/baseball
> http://example.com/section/events/baseball/team
> http://example.com/section/events/baseball/schedule
> 
> Where section is *literally* the word section. The website index page is
> called 'section.php' and the server is instructed to consider
> 'section.php' instead of 'index.php' the index page.
> 
> MultiViews is a module that "guesses" the file extension if the user
> doesn't writes it and it's not ambiguous. Also if you write, let's say
> 'file.php/whatever' the loaded file will be file.php and whatever will
> be available in $_SERVER['PATH_INFO'], as long as ther's no directory
> called 'file.php/whatever'. Same goes for 'file/whatever'.
> I hope to have explained it clearly enough.
> 
> If this method is of your liking and compatible enough, I bilieve the
> 'section/' part could be mod_rewrite'n with no need to fiddle with
> complicated rewrite rules.
> 
> > 2. How would you like the actual files to be layed out? I'm thinking
> > about maybe something like this:
> >
> > /index.php
> > /.htaccess
> > /templates/
> > /templates/$templatename
> > /img
> > /core <- not sure about this name... maybe /lib?
> > /modules <- User addable modules
> 
> My suggestion:
> 
> /index.php
> /.htaccess
> /lib/
> /lib/.htaccess <-- forbidding access
> /lib/templates
> /lib/modules
> /lib/...       <-- any other contents
> 
> > Do we want to include image management in our system? I'm not talking
> > about a image gallery, but an image management system to keep track of
> > all the images that will be used on the pages?
> 
> I'm not sure :/
> 
> > I think a major goal we should strive for is that the user does not
> > have to ever ftp or directly edit anything in the server after
> > SimpleCMS is installed. SimpleCMS should be able to take care of all
> > that.
> 
> Yes, that would be cool, although it may pose security risks.
> 
> Have fun :)
> -- Toni
> 
> 
>