simplecms-development Mailing List for SimpleCMS
Brought to you by:
mexi1010,
swivelgames
Menu
▾
▴
simplecms-development — Development Mailing List
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
(3) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Dmitry M. <di...@gm...> - 2005-06-27 09:56:42
|
Hi! I have just seen emails about SimpleCMS in my old mailbox. Unfortunatelly, = i=20 have not used it, because it was spammed. I have already developed SimpleCMS and asked its admin to add me in=20 developers list last year. But I could not import it into CVS. My realization was really simple :-) It does not use any database. But now, i have some ideas to make it more easy. I'll try to write them a= =20 little later. Best wishes, Dmitry P.S. Sorry for my broken english :-) |
|
From: Jonathan C. <jon...@gm...> - 2005-04-02 04:15:51
|
No, i'm not planning to make a wiki... although the way it is set up, one= =20 can easily allow everyone to edit the contents and the system to act like a= =20 wiki... I'm sorry for not laying out the design scheme clearly... The reason why I= =20 wrote the database scheme cuz I was running into road blocks as to exactly= =20 what would plug into where... I will try to explain what I have so far, but= =20 it is still very sketchy... (i'll release a full documentation when I finis= h=20 it) So far, I plan to have the content management system be a system of severa= l=20 "core" modules, and a lot of extra modules. I will explain the definition o= f=20 modules as I go on... The layout will be all virtual, using multiviews or mod_rewrite... For my= =20 example, I will be using mod_rewrite to rewrite all queries to=20 http://example.com/index.php?$QUERY... Let's say somebody goes to the page= =20 http://example.com/news/BoyEatsElephant?comments... SimpleCMS will be given= =20 http://example.com/index.php?news/BoyEatsElephant?comments. The first thing= =20 SimpleCMS will load is load the ParseURI module... This is the first of=20 SimpleCMS's "core" modules. This module (which i finished writing) reads th= e=20 URI and passes the intended URI (news/BoyEatsElephant) and the arguments=20 passed after the "?" to the rest of the system. $_GET variable will not=20 work, because it is already being used for the URI, especially if we're=20 using mod_rewrite so this ParseURI module is necessary. ParseURI also turns= =20 all variables set as foo=3Dbar seperated by "&" into into an array (ie.=20 http://example.com/test?foo=3Dbar&test=3Dtrue)...=20 The next module that is run is the uri_handler module. This module takes= =20 the uri given from the ParseURI module and determines which "page" should b= e=20 loaded. I have this crazy idea of having all the pages in a hiarchy scheme.= =20 Example: news news/foo news/bar news/test news/test/help My only problem is that this could degrade performance, but it would allow= =20 for automatic creation of navigation menus. If every page has some relation= =20 to another page, then we can just call all pages from $ParentID and get a= =20 navigation menu... In any case, if someone did not like this method, they= =20 could just replace this module. If performance is bad enough, I may just=20 write 2 different modules for this, one with the hiarchy system and one wit= h=20 just a direct URI. One of the beauties of a totally modular system. After the uri_handler is run, the core module "global module handler" (i= =20 haven't had a chance to give it a good name, if you can suggest one, i'd be= =20 very happy) is runned. The "global module handler" loads the "global"=20 modules, modules that run on every single page and could be as simple as=20 header modules (to place data before the content) or as complicated as=20 session modules to handle the user session... In this aspect, yes, my=20 definition of modules is snippets of code. But i don't want it to be just= =20 any code that gets thrown in. I would like to write a documentation=20 requiring modules to be either in OOP using standard calls, or written as= =20 several functions with standard names. In any case, the pre-content=20 functions are called, then the content is loaded. This is where I want to insert my second form of modules, "user" modules.= =20 These modules will be installed before use and will be called only on=20 individual pages by special tags <{}> or something. I'd like to see the=20 editor only have to type <{date}> and the date module be ran and replace th= e=20 <{date}> tag. I plan to use a regex search and search through the content= =20 field for all these tags and replace them with the output of the "user"=20 modules...=20 After all the tags have been replaced with modules, and the contents=20 loaded.. One last pass of "post-content" global modules are loaded... I nee= d=20 to think up of a name to call the "pre-page" and "post-page" global module= =20 functions. After this, the last "core" module is runned, the template module. Up to= =20 this time, all the content has not been displayed to the user. It has lay= =20 dormant as a $variable (probably $content). I have added another section to= =20 the Content table, "template". If set to 0, the content is displayed withou= t=20 a template, if set to a number, it uses the template of the $templateID=20 (which is another table I have added since the last email).... Of course,= =20 this module uses Smarty Templating system... I might throw in "template"=20 modules, not sure yet... haven't looked too much at this yet... I hope I have clearly layed out to you my design of the system. I'll=20 summerize once more. http://example.com/news/BoyEatsElephant?comment&page=3D2 / |-- ParseURI Reads the URI | $uri->URI =3D news/BoyEatsElephant | $uri->Args =3D comment&page=3D2 | $uri->arg =3D array... $uri->arg['comment'] =3D null; $uri->arg['page']= =3D2 |-- URI_Handler reads $uri->URI and finds it is an article under 'news';= =20 ParentID set... |-- Modules Handler/Content Handler loads "pre-page" global modules=20 functions... | *Example Global Modules:* | header module is loaded... $content .=3D date() etc. etc. | session module is loaded, sessions/cookies are loaded | |-- Content Handler/User Module Handler is loaded and searches for=20 <{usermodules}> | *Example User Modules: * | <{time}> inserts time here... | <{comment}> comment's module inserts page 2 of comments where this tag= =20 is... |=20 | After all user modules is found and replaced, $content .=3D=20 content->loadcontent()=20 | or something like that... i haven't gotten here yet. | |-- Module Handler/Content Handler loads "post-page" global module=20 functions \__Template Module is loaded, and page is spit out with or without a=20 template. So I had to write a rough draft sketch of the database design... What I= =20 have so far is 3 module models, maybe 4... "Core" modules, which the both= =20 the user and developer shouldn't need to change, the "global" modules, whic= h=20 developers can create modules for, and the "user" modules, which users can= =20 insert into the contents... I'm planning to have the admin interface as a= =20 module too.=20 Tell me what you think of the design... I tried to make this system as=20 editable as possible so there is no need to "hack". I don't think there is= =20 anywhere else that you would need to insert code that i haven't allowed cod= e=20 to be inserted... Jonathan Chan =20 > [off-topic] > I agree with the ACL. Though looking at the levels you talk about I"m > not quite sure about the overall layout of the engine you"re planning, > specially the level 100, sounds more like a wiki to me. > So, what seems to me is that when you speak of modules are you in fact > speaking of tiny snippets, and all content will be handled by a unique > component. Am I right? I thought more a phpnuke-like design so this > would change a lot of my assumptions. Please, clarify this point. >=20 > To put it with an example: > So, would http://example.com/whatever access the whatever content > page, handled by a "content" module, or would it access the whatever > module? >=20 > I believe planning first the architecture and/or classes > hierarchy/relations would be better. >=20 > [on-DB-topic] > * Anyway, the content table should have a string index if you plan to > have nice urls. If this voids the need or not of a contentID will > depend, but you most certainly want a string index whatsoever. >=20 > * Also you may want an "enabled" field on the content table too. >=20 > I would have more comments but I must first understand better the > design details. > |
|
From: Toni C. <ou...@gm...> - 2005-04-01 14:36:28
|
[off-topic] I agree with the ACL. Though looking at the levels you talk about I'm not quite sure about the overall layout of the engine you're planning, specially the level 100, sounds more like a wiki to me. So, what seems to me is that when you speak of modules are you in fact speaking of tiny snippets, and all content will be handled by a unique component. Am I right? I thought more a phpnuke-like design so this would change a lot of my assumptions. Please, clarify this point. To put it with an example: So, would http://example.com/whatever access the whatever content page, handled by a "content" module, or would it access the whatever module? I believe planning first the architecture and/or classes hierarchy/relations would be better. [on-DB-topic] * Anyway, the content table should have a string index if you plan to have nice urls. If this voids the need or not of a contentID will depend, but you most certainly want a string index whatsoever. * Also you may want an 'enabled' field on the content table too. I would have more comments but I must first understand better the design details. On Apr 1, 2005 6:34 AM, Jonathan Chan <jon...@gm...> wrote: > Hello, > > This is my plans for the database layout... Please give comments if you > think there should be other names for the tables/suggestions for improvement > that would make the data be accessed faster... > > Jonathan Chan > > ========================================== > Database Layout > > This is the document I wrote while planning the database layout for > SimpleCMS. > > > --------------------------------------- > Access Control List > The Access list is designed to provide a "single" uniform allow/deny list. > Every larger number will give the user more power. 0 is the user access > somebody not logged in would have while 255 is the highest access level > which > gives the most power to a user. Because what one would consider as more > important or more "power" is subjective, the access list can be edited. > Also, > 1 number can be used by more than one "job" (ie. The userlist admin setting > can be the same as master editor (250)). > > Access Control List > 255 - Senior Admin; "root" access; Can modify anything and everything > 254 - Userlist Admin > 253 - Admin Developer Level; Can modify "core" module settings that can > leave > SimpleCMS unusable. > 252 - Global Developer Level; Can edit "global" modules > 251 - User Developer Level; Can only edit "user" modules > 250 - Master Editor; Can edit all content pages > 100 - Insert Content into the "root" path (/); Can create new content > page > > More may be added by modules. > > Table:ACL - Hold Access Control Numbers > > moduleID - ModuleID that uses the ACL (small unsigned integer) > subID - Definition ID for the module (small unsigned integer) > summary - Short summary (1-10 words) of what the definition does. > (tinytext) > level - Access Level (0-255) (tiny unsigned integer) > > --------------------------------------- > Content Modes > > Read - Determined by Content Table > Create - Determined by access list and content list > Edit - Determined by Content Table > Delete - Owner or master editor > > > Table:Content - Will hold the actual page content. > > contentID - Internal ID for the pages. Index. (small unsigned > integer) > parentID - PageID of parent page, 0 for root (/). (smallint > unsigned) > userID - UserID of the creator of the page. (smallint unsigned) > content - actual content. (longtext) > date_created - creation date (timestamp) > date_modified - modification date (timestamp) > read_level - min security level to view the page (0-250) (tinyint 250) > edit_level - min security level to edit to this page (0-250) (tinyint > 250) > create_level - min security level to create pages under this page > (1-250) > is_index - boolean; true is index. (tinyint(1) unsigned) > recursive - boolean; false if an error should be given if child > doesn't > exist; true if the parent should handle the module > (tinyint) > > It is recommnended the read_level be between 0-10 for the most common uses. > > --------------------------------------- > Config > > Table:Config > config_name - Config Name > config_value - Config value > > Miscellaneous config options may be stored here. Modules with only a few > config options may store config settings here too. > --------------------------------------- > User > > Table:Users > userID - UserID > username - User name > first_name - First name > last_name - Last name > email - Email Adress for user > level - Access level of user > > "Single Sign On" user database. This database may be expanded by use of > joins. > (ex. we want to make a address book module, we just add a table "addr_book" > and just make joins to the userID.) The original purpose is to create a > single > sign on so that each module that needs authentication does not need to > create > their own database. This does not mean that people can not make their own > database if they want to write a module that should not use the same sign > on > info as the management system. > --------------------------------------- > Module Database > > This table will hold the module database. > > Table:Modules > moduleID - ModuleID > module_name - Module Name > summery - Short (>10 words) of what the module does > enabled - True = module enabled; false = module will not be loaded > > --------------------------------------- > > More tables may be added by modules, especially modules that provide large > services. A modules insertion documentation will be written later. > ============================================= > |
|
From: Jonathan C. <jon...@gm...> - 2005-04-01 04:34:44
|
Hello, This is my plans for the database layout... Please give comments if you=20 think there should be other names for the tables/suggestions for improvemen= t=20 that would make the data be accessed faster... Jonathan Chan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Database Layout This is the document I wrote while planning the database layout for=20 SimpleCMS. --------------------------------------- Access Control List The Access list is designed to provide a "single" uniform allow/deny list. Every larger number will give the user more power. 0 is the user access somebody not logged in would have while 255 is the highest access level=20 which gives the most power to a user. Because what one would consider as more important or more "power" is subjective, the access list can be edited.=20 Also, 1 number can be used by more than one "job" (ie. The userlist admin setting can be the same as master editor (250)). Access Control List 255 - Senior Admin; "root" access; Can modify anything and everything 254 - Userlist Admin 253 - Admin Developer Level; Can modify "core" module settings that can=20 leave SimpleCMS unusable. 252 - Global Developer Level; Can edit "global" modules 251 - User Developer Level; Can only edit "user" modules 250 - Master Editor; Can edit all content pages 100 - Insert Content into the "root" path (/); Can create new content page More may be added by modules. Table:ACL - Hold Access Control Numbers moduleID - ModuleID that uses the ACL (small unsigned integer) subID - Definition ID for the module (small unsigned integer) summary - Short summary (1-10 words) of what the definition does. (tinytext= ) level - Access Level (0-255) (tiny unsigned integer) --------------------------------------- Content Modes Read - Determined by Content Table Create - Determined by access list and content list Edit - Determined by Content Table Delete - Owner or master editor Table:Content - Will hold the actual page content. contentID - Internal ID for the pages. Index. (small unsigned integer) parentID - PageID of parent page, 0 for root (/). (smallint unsigned) userID - UserID of the creator of the page. (smallint unsigned) content - actual content. (longtext) date_created - creation date (timestamp) date_modified - modification date (timestamp) read_level - min security level to view the page (0-250) (tinyint 250) edit_level - min security level to edit to this page (0-250) (tinyint 250) create_level - min security level to create pages under this page (1-250) is_index - boolean; true is index. (tinyint(1) unsigned) recursive - boolean; false if an error should be given if child doesn't exist; true if the parent should handle the module (tinyint) It is recommnended the read_level be between 0-10 for the most common uses. --------------------------------------- Config Table:Config config_name - Config Name config_value - Config value Miscellaneous config options may be stored here. Modules with only a few config options may store config settings here too. --------------------------------------- User Table:Users userID - UserID username - User name first_name - First name last_name - Last name email - Email Adress for user level - Access level of user "Single Sign On" user database. This database may be expanded by use of=20 joins. (ex. we want to make a address book module, we just add a table "addr_book" and just make joins to the userID.) The original purpose is to create a=20 single sign on so that each module that needs authentication does not need to=20 create their own database. This does not mean that people can not make their own database if they want to write a module that should not use the same sign o= n info as the management system. --------------------------------------- Module Database This table will hold the module database. Table:Modules moduleID - ModuleID module_name - Module Name summery - Short (>10 words) of what the module does enabled - True =3D module enabled; false =3D module will not be loaded --------------------------------------- More tables may be added by modules, especially modules that provide large services. A modules insertion documentation will be written later. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Toni C. <ou...@gm...> - 2005-03-29 14:12:37
|
Ooops, forgot to send to the list! ---------- Forwarded message ---------- From: Toni Corvera <ou...@gm...> Date: Tue, 29 Mar 2005 16:11:58 +0200 Subject: Re: [Simplecms-development] Database Connection To: Jonathan Chan <jon...@gm...> The last time I looked into ADODB, PEAR::DB seemed simpler to me (certainly I can't see any complexity within PEAR::DB). Other than that if I prefer PEAR::DB is because it's in PEAR (and as such "oficial"). Anyway ADODB is a very competent alternative. On Sun, 27 Mar 2005 18:54:59 -0500, Jonathan Chan <jon...@gm...> wrote: > Hello, > > After further research and after talking to a friend. I think we > should use ADODB as our Database API. It supports many more database > types and it seems simpler to me than PEAR::DB. You may take a look at > it from http://adodb.sourceforge.net/. We may have another developer > join our team. > > Jonathan Chan > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Simplecms-development mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplecms-development > |
|
From: Jonathan C. <jon...@gm...> - 2005-03-29 09:29:51
|
Hello, I've come along this article on multiviews and i think it's pertinent to SimpleCMS. According to this, if apache is not correctly configured, google may not index sites with multiview on. I believe we should take this into consideration while we are building SimpleCMS... http://tranchant.plus.com/notes/multiviews Jonathan Chan |
|
From: Jonathan C. <jon...@gm...> - 2005-03-27 23:55:03
|
Hello, After further research and after talking to a friend. I think we should use ADODB as our Database API. It supports many more database types and it seems simpler to me than PEAR::DB. You may take a look at it from http://adodb.sourceforge.net/. We may have another developer join our team. Jonathan Chan |
|
From: Jonathan C. <jon...@gm...> - 2005-03-26 23:54:19
|
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 > > > |
