Web3CMS 1.0.7.r6 (User) is released.
It is still too far from being called ‘CMS’… so, if you don’t have free time, please ignore it.
Currently only Index, Contact and Login/Logout are available.
In the next version we will add user registration and hopefully backend.
Thanks, and if you find any bugs, please post it here.
What are your long term goals with this?
To create a content management system like joomla with a set of official (built-in) components like posts, photos, videos, forum and so on.
It should by default go with a set of themes (currently done) and at least 2 languages (multilingual).
The difference with Wordpress, Joomla, Drupal and so on - we are focusing on the CMS itself while qiang and the Yii team are taking care of the MVC Framework.
We hope to add posts/tags by date of release of Yii 1.1.0.
Thanks for your interest.
I will definitely look at it. Thanks for sharing.
Please note that Yii 1.1 will not have backward compatibility, so you may end up with a lot more work if you want to put this cms into 1.0.
I also suggest you to take heavy advantage of ajax, as that is very expected in recent systems for sure. "Web3" implies that your software will also be capable of supporting facebook/twitter/delicious/linkedin/etc.
Thanks for your input.
We know about backward compatibility issue. Move this CMS from Yii 1.0 to 1.1 branch should not take more than 1 week of work (probably only 2-3 days).
We will make this CMS mostly AJAX driven with native support of jquery-ui.
Web3CMS 1.0.8.r7 (i18n) have been released.
We did it multilingual (currently only 2 languages).
Also expanded on User functionality (register, confirmEmail, show, update).
Start working on backend (admin). Next release should be 1 week earlier than usual (in 1 week after release of genius Yii).
Thanks for your interest!
Web3CMS 1.0.9.r8 (backend) have been released.
Added backend - administrator area.
Also created User updateInterface, 1 fix and multiple improvements in the code.
Thanks for your interest!
Hi, have had a look at Web3CMS, and see some nice ideas there. Maybe you could fill some of the Wiki pages with some additional stuff, would make a difference 
.
I would suggest that you move more text stuff to the params.php, especially all the default values (MParams component), languages.
I see you’re using the backend construction to create some separation between front and back, a good choice in my opinion. Maybe you can consider this to avoid redundancy in the config files (error prone):
/backend/config/main.php:
<?php
$backend=dirname(dirname(__FILE__));
$frontend=dirname($backend);
Yii::setPathOfAlias('backend', $backend);
$frontendarray = require($frontend.'/config/main.php');
// This is the main Web application backend configuration. Any writable
// CWebApplication properties can be configured here.
$backendarray = array(
'basePath' => $frontend,
'controllerPath' => $backend.'/controllers',
'viewPath' => $backend.'/views',
'runtimePath' => $backend.'/runtime',
// autoloading model and component classes
'import'=>array(
'backend.models.*',
'backend.components.*',
'application.models.*',
'application.components.*',
'application.extensions.*',
),
// alternate layoutPath
'layoutPath'=>dirname(dirname(__FILE__)).DIRECTORY_SEPARATOR.'views'.DIRECTORY_SEPARATOR.'_layouts'.DIRECTORY_SEPARATOR,
// application-level parameters that can be accessed
// using Yii::app()->params['paramName'] and MParams class
'params'=>require(dirname(__FILE__).'/params.php'),
// application components
'components'=>array(
'urlManager'=>array(
'urlFormat'=>'path',
'caseSensitive'=>false,
'showScriptName'=>true,
'urlSuffix'=>'.html',
'rules'=>require(dirname(__FILE__).'/routes.php'),
),
),
);
return (array_merge($frontendarray, $backendarray));
This way all the settings done in the frontend are available, and you can redefine what’s nessesary for the backend.
Hope you will include your user admin in the next version soon. Besides that, it might be a good idea to start a discussion in extensions too.
Hi, thanks for the reply!
I find your array_merge() idea very useful, it will be implemented in the coming release. routes.php will be implemented in the front-end as well. All is great except that array_merge() cuts off ‘db’ of ‘components’ of the front-end array, so I’ve had to modify this as follows:
<?php
$backend=dirname(dirname(__FILE__));
$frontend=dirname($backend);
Yii::setPathOfAlias('backend', $backend);
$frontendArray=require($frontend.'/config/main.php');
// This is the main Web application backend configuration. Any writable
// CWebApplication properties can be configured here.
$backendArray=array(
'basePath' => $frontend,
'controllerPath' => $backend.'/controllers',
'viewPath' => $backend.'/views',
'runtimePath' => $backend.'/runtime',
// autoloading model and component classes
'import'=>array(
'backend.models.*',
'backend.components.*',
'application.models.*',
'application.components.*',
'application.extensions.*',
),
// main is the default layout
'layout'=>'main',
// alternate layoutPath
'layoutPath'=>dirname(dirname(__FILE__)).DIRECTORY_SEPARATOR.'views'.DIRECTORY_SEPARATOR.'_layouts'.DIRECTORY_SEPARATOR,
// application-level parameters that can be accessed
// using Yii::app()->params['paramName'] and MParams class
'params'=>require(dirname(__FILE__).'/params.php'),
// application components
'components'=>array(
'urlManager'=>array(
'rules'=>require(dirname(__FILE__).'/routes.php'),
),
),
);
if(!function_exists('w3_array_union_recursive'))
{
/**
* This function does similar work to $array1+$array2,
* except that this union is applied recursively.
* @param array $array1 - more important array
* @param array $array2 - values of this array get overwritten
* @return array
*/
function w3_array_union_recursive($array1,$array2)
{
$retval=$array1+$array2;
foreach($array1 as $key=>$value)
{
if(is_array($array1[$key]) && is_array($array2[$key]))
$retval[$key]=w3_array_union_recursive($array1[$key],$array2[$key]);
}
return $retval;
}
}
return w3_array_union_recursive($backendArray,$frontendArray);
Please to all: share your ideas here, we are looking to make this app more universal to fit everyone’s needs.
I currently don’t have much free time for documentation, but hope to start Wiki in October (this year ). We hope that someone will help us with some aspects of this project, or at least with finding bugs and bringing some better ideas, like you did, thank you.
All the default values in MParams component already are in config/params.php, e.g.
const defaultLanguage='en';
in MParams is nothing more than a repeat of
'language'=>'en', //en
in params.php. The purpose of MParams default constants is to keep the app alive even if developer will do something wrong in config/params.php. Default values in MParams are fired ONLY if corresponding config in params.php is missed. The end goal is to make app working even if params.php returns an empty array (this should be finished in the next release) I will try to simplify this component.
Good idea. I like markitup as simplified editor (with different types of markup), and CKEditor as WYSIWYG editor. Also we are going to use jqGrid for grids of data. But, all pages should be 100% working with javascripts disabled.
// WORKING WITH DATES
Also, currently we are going to switch from
`createDate` DATETIME NOT NULL,
`createGmtDate` DATETIME NOT NULL,
to
`createTime` INTEGER(10) UNSIGNED NOT NULL,
The purpose of Gmt field was to convert dates from db to visitor’s timezone. With time() we can still convert it to timezones (because time() in the same moment in all timezones is the same value) and using FROM_UNIXTIME(createTime) we can work with field as if it would be datetime. So, we can use 1 field instead of 2. The cost is less human readability when you look at it in phpMyAdmin.
But this approach will be applied to fields auto-filled in by app only. Those that are filled in by human will be of type DATETIME (like startDate,endDate), so it can be any date, even before Unix Epoch (January 1 1970 00:00:00 GMT)
, see http://www.yiiframework.com/forum/index.php?/topic/3187-working-with-dates-need-your-input/ for reference
// END WORKING WITH DATES
Please, share your thoughts.
Ah yeah, didn’t look to the deeper nested arrays, this is way better.
About the docs, I know this is one of the hard parts, but perhaps adding some sample pages would do the trick.
About the params: I would personally prefer a warning when some needed param is not set in params.php, so I don’t have to go through MParams to find out what I need to change for my app (like email adresses , titles, metatags etc.). Perhaps a unified param test will save a lot of the setters/getters there.
The new dates makes sense!
I’m using an extension class for CController myself, and I understood it was better to use:
function __construct($id,$module=null)
{
parent::__construct($id,$module);
}
instead of init()
I also use the extension for common filter setup, and in these filters I also load the scipts and CSS files I use. Perhaps it is of any use for you.
Keep up the good work
Is __construct() a more safe way to initialize the app? As for right now, CController::init() does excellent work about app initialization and requires no params (like $id,$module)… Found at http://www.yiiframework.com/doc/api/CController about init():
We currently don’t have much of js and css files, but this will change soon. I thought to combine all js/css by type, e.g. all jquery plugins/scripts in css/jquery-1.3.x.plugins.css and js/jquery-1.3.x.plugins.js. Is this what you are talking about? Is there a better way than the manually merge of js & css?
In general, our current politics is to minimize use of third party applications (extensions) as our core code. Our main goal is to create an extremely secure app, so when it’s possible, we will convert extensions into components (and will test it). From the point of view of a developer, using extensions or components will be of the same ease.
Also Yii Cookbook is very very useful. Thanks to the Yii Team for their great work!!
The theme select is really nice… well done!
I am curious as to why you are doing the back end as /protected/backend/ with a backend.php entry script and second config file rather than as a module?
The answer is in the Yii Cookbook http://www.yiiframework.com/doc/cookbook/33/
We are going to release the next version very soon. Backend config in it is very optimized.
If you have a working example with backend in module, please compress it and upload here.
Is there any benefits of using module rather than in Yii Cookbook above?
I don’t know if there are benefits, since I haven’t had time to look at your backend code.
How do you go with the shell script on the backend?
Modules are very simple to create using the shell script:
module admin
exit
Then import the module in /protected/config/main.php:
// autoloading model and component classes
'import'=>array(
'application.models.*',
'application.components.*',
'application.modules.admin.*',
),
and:
'modules'=>array('admin'),
Then you can continue with creating models and crud:
model admin.models.Users
crud admin.models.Users
You can adjust user authentication in the admin DefaultController.php
admin is accessed using index.php?r=admin
You can have the admin use its own template by adjusting AdminModule.php:
public $layout = 'admin';
Then place the main layout file as /protected/modules/admin/views/layouts/admin.php
Thats about all there is to it.
PS. Talking about editors, I am currently using a modified Wymeditor (allows embedded Flash), which uses jQuery. This editor stops people from junking the pages with bad markup.
Modules is great. Yii is even better than our most expectations!
I thought to create model and crud in yiic shell the usual way (yiic shell ../index.php), then copy-paste it from protected/* to protected/backend/*
The formal release of Yii 1.1 is closer, it should have web based yiic shell, even more powerful than the current one, so I think it should be the same easy to create model&crud for "index.php", "module" and "backend.php".
Wymeditor is great (but in my opinion it would be good to have Underline and Strike Through buttons). I like it for standarts-compliant XHTML and jQuery.
Our current idea with editors is to allow for different types of markup, like wiki, markdown and so on. And if in config you allow for any type of markup, then let user decide which one to use. markItUp should be able to handle this.
The difficult part of this idea is to clean the code before save in db, and convert from selected markup to html on display. First part is hardest, especially if markup is html itself. We hope Yii will let us do this.
Why do we need a way to clean the code before save in db? Because even with Wymeditor which is cleaning the code, user can disable the javascripts and get an usual textarea, then type in any html code, even css and javascripts.
I also did my backend as a module. when you use a second entry script it’s like your backend and frontend are two separate applications.
Please vote on Best Rich Text Editor. Thank you.