LampCMS open source XSLT based content management
The first open source CMS that uses browser based XSLT transformation
Fri, 11 Sep 2009 21:26:14 -0400
Download the latest release here:
lampcms-0.1.1.tar.gz
or
lampcms-0.1.1.tar
Unpack, create database using the sql/db.sql mysql dump file
Read the INSTALL.txt file
Or you can check our latest development version (updated almost daily)
from the anonymous SVN:
http://www.lampcms.com/svn/
If you need help with installation just post a question as a comment to this article.
lampcms-0.1.1.tar.gz
or
lampcms-0.1.1.tar
Unpack, create database using the sql/db.sql mysql dump file
Read the INSTALL.txt file
Or you can check our latest development version (updated almost daily)
from the anonymous SVN:
http://www.lampcms.com/svn/
If you need help with installation just post a question as a comment to this article.
1
Sun, 06 Dec 2009 22:19:16 -0400
The development and rewriting of much of the core classes are going really well.
Basically I switch from using SimpleXMLElement php class to DOMDocument class
While initially I chose SimpleXMLElement for it's simplicity, I discovered it has too many limitations and cannot be used for creation of XML and especially of HTML documents. Anyway, the new classes are much better and the page rendering process is much smarter now and much much more suitable for building ajax-based apps or just adding ajax features to existing CMS.
A sample site has been built with the use of new lampcms
Check it out, it's a portal for php developers
Basically I switch from using SimpleXMLElement php class to DOMDocument class
While initially I chose SimpleXMLElement for it's simplicity, I discovered it has too many limitations and cannot be used for creation of XML and especially of HTML documents. Anyway, the new classes are much better and the page rendering process is much smarter now and much much more suitable for building ajax-based apps or just adding ajax features to existing CMS.
A sample site has been built with the use of new lampcms
Check it out, it's a portal for php developers
0
Fri, 11 Sep 2009 21:28:47 -0400
LampCMS is a system that allows you to instantly offer creation of sophisticated personal blogs and image hosting and coming soon video hosting!
It is an OPEN SOURCE software released under the GPL licence.
For example, if you have a community of people with similar interests, you can start offering them a nice place to create their own website, complete with blog, image hosting and (coming soon) their own forums.
LampCMS was designed with these goals in mind: be fast, output only valid standard-compliant HTML or XML, use memory caching to speed up processing and reduce the number of database queries to a minimum, making this CMS able to handle super heavy traffic with ease.
Be scalable an admin can very easily setup a dedicated server to server images, or can even have thumbnails to be served from one server, regular images from the other, have database on another server and the main processing will be done on yet another server. When number of images or videos grows, it is very easy to add new servers and have new images automatically be saved on the new server.
LampCMS was not designed to be a full-blown framework. For example, if you want to create something that has little to do with blogging, like a virtual store or hotel booking system, then LampCMS was not designed to be all that; however, it is fairly easy to write extra plug-in like polls, mailing list system, rss feed parser that would show nicely formatted feeds from other sites, or most anything else.
It is an OPEN SOURCE software released under the GPL licence.
For example, if you have a community of people with similar interests, you can start offering them a nice place to create their own website, complete with blog, image hosting and (coming soon) their own forums.
LampCMS was designed with these goals in mind: be fast, output only valid standard-compliant HTML or XML, use memory caching to speed up processing and reduce the number of database queries to a minimum, making this CMS able to handle super heavy traffic with ease.
Be scalable an admin can very easily setup a dedicated server to server images, or can even have thumbnails to be served from one server, regular images from the other, have database on another server and the main processing will be done on yet another server. When number of images or videos grows, it is very easy to add new servers and have new images automatically be saved on the new server.
LampCMS was not designed to be a full-blown framework. For example, if you want to create something that has little to do with blogging, like a virtual store or hotel booking system, then LampCMS was not designed to be all that; however, it is fairly easy to write extra plug-in like polls, mailing list system, rss feed parser that would show nicely formatted feeds from other sites, or most anything else.
0
Fri, 11 Sep 2009 21:29:33 -0400
Lampcms is a blogging and image hosting CMS.
In case you don't already know, LAMP is a common acronym for Linux, Apache, MySQL, and Php
That's exactly what is required to run our CMS
From one of the top php programming team comes a CMS that make use of the best of what php has to offer.
- Support for posting regular blog post or 'announcement' or 'sticky' post
- Setting the 'weight' of post. Posts with higher weight will appear higher up in the list of posts,
- even if they are made earlier than other posts.
- RTE editors for new posts and for comments.
- Upload progress bar for file uploads both for image uploads as well as uploads of 'attachments' to blog posts.
Transparent Data caching. Our cache class supports 2 types of back-end cache memcache and memcached.
We plan to add support for other types of cache like APC and a lite file-based cache system that will work without memcache and without APC extensions.
Transparent caching means that when you request the data (like the result of SQL select), it will fetch it for you, looking in cache first, then if data is not available in cache (or if cache is not available at all), it will then retrieve data from the database.
This is good news for those who don't have memcache installed because the system will still return your results, just without using the cache.
This means that memcache extension is optional if you have it, great, if not, the CMS will still work fine but will just make more calls to database.
We also store the first 'n' blog posts in the regular static .rss file, so when someone accesses your home page that rss file is being used as input, saving a call to database. The file with your profile and preferences is also stored as a static xml file, so another call to database is saved! Don't worry, these rss and xml files are automatically updated when you edit your profile or add a new post to your blog!
Switch account - a user can have more than one account on the system, then instead of logging out and then logging in with a different account, a user can login just once then use 'switch account' form to instantly being switched as a different user.
This is very helpful when user wants to have more than one blog each with a different account name.
'Email address check'. The registration form waits for bounced email right after the new user submitted his registration. If bounce comes back within 30 seconds (most bounces come back within 10 seconds), then an error message is shown to the user. This is useful if user's email server blocks emails from your server for any reason or if user's email box is full or temporarily suspended. This way a user will know right away instead of waiting for his registration email which will never come.
- Image hosting with albums
- Support for password-protected albums and X-rated albums.
- Full support for EXIF data extraction from images.
- Support for sub-domains like username.lampcms.com
- Admin can turn this feature on or off.
- Support for SEO urls' but admin can turn it on/off
- The support for SEO type of links requires mod-rewrite on your apache server.
only the links will look like this (example)
yoursite.com/index.php?a=personal&uid=1234
If SEO feature is ON but sub-domain (virtual hosting) is off, the personal pages will look like this:
www.yoursite.com/user1234/
with sub-domains on the personal pages will look like this:
user1234.yoursite.com
Configurable user options like number of items per page, pagination on top/bottom/both,
Threaded replies with option to indicate which level of replies gets expanded and which collapsed.
- Ajaxification of most forms forms will work with or without javascript.
- Users can upload avatar. Uploaded avatars are resized into 3 different sizes: regular, square and tiny square.
- Users can select the layout navigation on right of left.
- Users can edit styles visually, without touching the .css file.
- Multilingual new languages can be added.
- Attachments in blog posts images are automatically resized, other attachments are displayed as attachment and can be downloaded.
- Support for anonymous comments with use of captcha. Admin or site owner can allow/disallow anonymous comments.
- Blog owner can close post for new comments.
- Security: forms with tokens, passwords hashed (and salted), brute force detection multiple failed login attempts will cause the lockout for specified number of minutes, forcing the user to wait for awhile before trying again,
- Data filtering all input as filtered as it comes in from the form. Only the allowed datatypes go through. Only the allowed named url parameters will go in. So you can't just append any extra param to url it would not work!
GeoIP module records ip-based geo location where a new user came from, where a post or comment came from. This can later be used to generate a map application to show where messages or images were coming from.
Im sure there are more I could have said about this CMS, maybe Ill update this post later if I remember some other cool feature it can do.
1
Mon, 07 Dec 2009 21:11:51 -0400
All data, including user-submitted blog posts, comments, etc
should be stored in utf8 charset
This will make the site more multilingual-friendly.
and also this makes parsing and storing rss feeds much easier, as well as generating xml feeds.
Some important points:
Always include and execute mysql query 'SET NAMES utf8' on every new DB connection. This will assure that utf8 is used for all inserts and all selects.
All mysql tables should be in utf8 charset
All incoming data should be checked to be a valid utf8 string, whick may not be very easy to do but we must do our best.
We must have a reliable way to convert string into utf8 but ONLY IF we detected that it's not already in utf8 format.
We must use mb_string extension for all string functions, including regex, strlen, strstr, explode, substr, etc... This is actually very important!
There are 3 different ways to convert into utf8:
simpleset one is utf8_encode() but it works ONLY for ISO-8859-1 strings (default encoding on the Internet today)
iconv() not a very good option, known to have problems, different versions produce different results but it has a good option //TRANSLIT
however //TRANSLIT option may not even be the best choise when we work with UTF8 Strings, it's a good choice when converting from one encoding to another non-utf8 encoding where the charset that we convert to may not have the same character as in charset we convert from, in which case iconv will pick the closest character. So in short, this may be a decent option when converting from utf8 to ISO-8859-1 or windows-1252 (which I don't plan on doing)
Third way is to use mb_convert_encoding() It's probably the best way and produces the best results, but for it to work properly we MUST know what encoding the string is currently in. We should not really ignore this meta data. Sometimes it's included in email messages, sometimes in forms submitted via browser (somewhere in headers), it's in XML feed file and it's actuall MUST always be utf8 in all RSS feeds. If we don't know the current encoding, then we must have the best way to detect (guess) the charset encoding, which is never 100% reliable, but mb_detect_encoding is the best bet.
I will have to think about how to best implement utf8 policy. It's not very easy. Basically a valid ASCII string is already a valid utf8 string, so we don't have to run utf8_encode on such strings
Also we should use the
should be stored in utf8 charset
This will make the site more multilingual-friendly.
and also this makes parsing and storing rss feeds much easier, as well as generating xml feeds.
Some important points:
Always include and execute mysql query 'SET NAMES utf8' on every new DB connection. This will assure that utf8 is used for all inserts and all selects.
All mysql tables should be in utf8 charset
All incoming data should be checked to be a valid utf8 string, whick may not be very easy to do but we must do our best.
We must have a reliable way to convert string into utf8 but ONLY IF we detected that it's not already in utf8 format.
We must use mb_string extension for all string functions, including regex, strlen, strstr, explode, substr, etc... This is actually very important!
There are 3 different ways to convert into utf8:
simpleset one is utf8_encode() but it works ONLY for ISO-8859-1 strings (default encoding on the Internet today)
iconv() not a very good option, known to have problems, different versions produce different results but it has a good option //TRANSLIT
however //TRANSLIT option may not even be the best choise when we work with UTF8 Strings, it's a good choice when converting from one encoding to another non-utf8 encoding where the charset that we convert to may not have the same character as in charset we convert from, in which case iconv will pick the closest character. So in short, this may be a decent option when converting from utf8 to ISO-8859-1 or windows-1252 (which I don't plan on doing)
Third way is to use mb_convert_encoding() It's probably the best way and produces the best results, but for it to work properly we MUST know what encoding the string is currently in. We should not really ignore this meta data. Sometimes it's included in email messages, sometimes in forms submitted via browser (somewhere in headers), it's in XML feed file and it's actuall MUST always be utf8 in all RSS feeds. If we don't know the current encoding, then we must have the best way to detect (guess) the charset encoding, which is never 100% reliable, but mb_detect_encoding is the best bet.
I will have to think about how to best implement utf8 policy. It's not very easy. Basically a valid ASCII string is already a valid utf8 string, so we don't have to run utf8_encode on such strings
Also we should use the
mb_check_encoding
0
Sat, 15 Aug 2009 09:08:06 -0400
LampCMS makes extensive use of SPL
We use PDO class for database access, and use ONLY prepared statements for all inserts and updates of tables. This adds a tremendous amount of protection against an sql injection and also eliminates the need to use the 'old school' addslashes()
We use proven OOP programming 'good practices' and make use of the most common programming patterns like Singleton method, factory method, good sub-classing design and composite objects.
Custom exception, type hinting, interfaces, iterators you will find them all in our CMS. So if you ever wanted to learn these concepts, then developing with and for Lampcms will definitely improve your programming skills.
We use built-in php input filtering all input data goes through filters first, so only clean data reaches our scripts. This also eliminates the need to run the old-school htmlentities() on submitted data.
We use php's SimpleXML class to build the output, as well as DOM class in some cases where SimpleXML just can't handle it. This insures that the output generated by our engine is always 100% valid XML!
As a templating engine we chose to use XSLT, making use of php's libxstl extension.
After trying several templating engines like smarty and HTML_Template_Sigma
and even writing my own templating engine HTML_Template_Sigma3 (better OOP rewrite of Sigma),
I just was not satisfied with the speed and amount of functions calls a templating engine
usually has to make in order to assemble a fairly large web page with large amount of replacements.
XSTL is a surprisingly fast templating engine and the fact that it can be used for both browser based
or server based transformation makes it a clear choice for me.
Sure, there is a learning curve for someone who has never used XST templates before,
but there is a learning curve to any templating engine, be it a popular Smarty or Flexy
or any other templating engine.
At least XSL is a standard, so once you learn to use it, you can use it with any other programming language in the future.
We use PDO class for database access, and use ONLY prepared statements for all inserts and updates of tables. This adds a tremendous amount of protection against an sql injection and also eliminates the need to use the 'old school' addslashes()
We use proven OOP programming 'good practices' and make use of the most common programming patterns like Singleton method, factory method, good sub-classing design and composite objects.
Custom exception, type hinting, interfaces, iterators you will find them all in our CMS. So if you ever wanted to learn these concepts, then developing with and for Lampcms will definitely improve your programming skills.
We use built-in php input filtering all input data goes through filters first, so only clean data reaches our scripts. This also eliminates the need to run the old-school htmlentities() on submitted data.
We use php's SimpleXML class to build the output, as well as DOM class in some cases where SimpleXML just can't handle it. This insures that the output generated by our engine is always 100% valid XML!
As a templating engine we chose to use XSLT, making use of php's libxstl extension.
After trying several templating engines like smarty and HTML_Template_Sigma
and even writing my own templating engine HTML_Template_Sigma3 (better OOP rewrite of Sigma),
I just was not satisfied with the speed and amount of functions calls a templating engine
usually has to make in order to assemble a fairly large web page with large amount of replacements.
XSTL is a surprisingly fast templating engine and the fact that it can be used for both browser based
or server based transformation makes it a clear choice for me.
Sure, there is a learning curve for someone who has never used XST templates before,
but there is a learning curve to any templating engine, be it a popular Smarty or Flexy
or any other templating engine.
At least XSL is a standard, so once you learn to use it, you can use it with any other programming language in the future.
0
Sun, 12 Jul 2009 22:47:08 -0400
All classes are documented very well.
The site is event-driven. Events are fired similar to how events work in browser model. You can write up a new extension that will subscribe to any specific event and then do its thing when such event fires. For example, we have events 'onUserLogin', 'onProfileUpdate', 'onLogout', 'onNewReply', and many more... Or yes, our event system implements SplSubject Interface
and if you want to subscribe to the events all you have to do is make sure that your class implements SplObserver interface.
Good form validation with using form rules. We use HTML_QuickForm pear class, slightly modified (improved), so if you are familiar with this class it will be very easy for you to create new forms and add any form validation rules (like required fields, validate email address, validate alphanumeric only, etc.)
We use many SPL classes, like SPL fileinfo to represent a file, ArrayObject to represent many arrays and objects, many of our objects implement serializable interface. Basically if you are familiar with SPL objects, it will be easy for you to understand the design of many of our classes. If you are not familiar with SPL but always wanted to learn how to use theme, then working on our project is going to make this easy for you you will become an expert in using SPL in no time!
Some event types also bubble up, just like events in javascript.
With events it's easy to hook to the objects. For example, you can write a spam filter that listens to 'onNewReply', then examines the contents of the reply and if any spam words are found it will issue
a cancelEvent() call, so that the reply will never be added to the database.
An excellent logging system makes debugging and development very easy. You can add a simple line:
$this->log('something happened); anywhere in your script.
The logger will automatically extract the class name and line number of this line, so in your log you will see a timestamp, class, line as well as your message.
This means you don't have to add __METHOD__.' line: '.__LINE__ to every one of your log messages, this is done automatically for you.
Also admin is automatically notified by email every time the message is added to log that contains the work 'Error', so you may log some problematic events this way:
$this->log('Error: uploaded file could not be saved');
This message will be added to log and a copy of it will be sent to admin.
We even have a javascript logging console. You can use logging in any of your own javascripts. Just add
$L('got response ' + response);
This will immediately appear on logging console (small draggable panel on the page)
This javascript logging panel is only visible to developers (you must add your ip address to special file)
Lastly there is an sql query logging. All SQL queries on the site go through the Database class which logs query as well as time before and time after the query, so the time (in milliseconds) is known for every sql query. This data is then dumped to the bottom of a page. Again, this will be visible ONLY to developers and is only activated when request comes from one of the ip addresses added to developer's Ips)
All these things makes developing with Lampcms an unusually pleasant experience.
The site is event-driven. Events are fired similar to how events work in browser model. You can write up a new extension that will subscribe to any specific event and then do its thing when such event fires. For example, we have events 'onUserLogin', 'onProfileUpdate', 'onLogout', 'onNewReply', and many more... Or yes, our event system implements SplSubject Interface
and if you want to subscribe to the events all you have to do is make sure that your class implements SplObserver interface.
Good form validation with using form rules. We use HTML_QuickForm pear class, slightly modified (improved), so if you are familiar with this class it will be very easy for you to create new forms and add any form validation rules (like required fields, validate email address, validate alphanumeric only, etc.)
We use many SPL classes, like SPL fileinfo to represent a file, ArrayObject to represent many arrays and objects, many of our objects implement serializable interface. Basically if you are familiar with SPL objects, it will be easy for you to understand the design of many of our classes. If you are not familiar with SPL but always wanted to learn how to use theme, then working on our project is going to make this easy for you you will become an expert in using SPL in no time!
Some event types also bubble up, just like events in javascript.
With events it's easy to hook to the objects. For example, you can write a spam filter that listens to 'onNewReply', then examines the contents of the reply and if any spam words are found it will issue
a cancelEvent() call, so that the reply will never be added to the database.
An excellent logging system makes debugging and development very easy. You can add a simple line:
$this->log('something happened); anywhere in your script.
The logger will automatically extract the class name and line number of this line, so in your log you will see a timestamp, class, line as well as your message.
This means you don't have to add __METHOD__.' line: '.__LINE__ to every one of your log messages, this is done automatically for you.
Also admin is automatically notified by email every time the message is added to log that contains the work 'Error', so you may log some problematic events this way:
$this->log('Error: uploaded file could not be saved');
This message will be added to log and a copy of it will be sent to admin.
We even have a javascript logging console. You can use logging in any of your own javascripts. Just add
$L('got response ' + response);
This will immediately appear on logging console (small draggable panel on the page)
This javascript logging panel is only visible to developers (you must add your ip address to special file)
Lastly there is an sql query logging. All SQL queries on the site go through the Database class which logs query as well as time before and time after the query, so the time (in milliseconds) is known for every sql query. This data is then dumped to the bottom of a page. Again, this will be visible ONLY to developers and is only activated when request comes from one of the ip addresses added to developer's Ips)
All these things makes developing with Lampcms an unusually pleasant experience.
0
Mon, 13 Jul 2009 10:05:55 -0400
Coming soon:
- Support for videos;
- Support for upload in MS Word, on OpenDocument format such documents will be converted to HTML with all the formatting preserved.
- Upload by webdav just drag/drop your document or image to your own web folder and it will be published on your blog.
- A full-blown NNTP server is in the works to turn your blog into a nntp newsgroup that can be accessed with any newsreader to read/reply to blog posts.
0
Wed, 09 Dec 2009 14:37:49 -0400
Some major rewrites taking place.
Fundamentally new features:
User may have more than one email address. Only one of these can be marked as 'default', others are alternative. But these others may be used when posting to mailing lists or when joining mailing lists, etc. Email addresses must still be unique, meaning each email address can still only be used once and that means address can only belong to one user. This also means we can always find user by email address.
Another change: User can have more than one blog. This is very major change because a user will also be able to pick his own sub-domain name for his blog or even change the sub-domain of existing blog, although this is usually a bad idea for the user.
A total rewrite of how user object is instantiated, how it's used, user profile and preferences are not instantiated by default for a logged in user but will be instantiated on demand only when needed.
Options related to user's blog preferences will now be moved to BLOGS table because now the preferences are per-blog and not per-user. A rewrite of edit preferences will also be needed.
A preparation is being made for integrating Google Friend connect with the login system, as well as other authentication method like Facebook connect.
A new type of basic object is being developed and tested. It's more like a new design pattern and it will be called TableRow object. It represents array of data from one table row and will have method to save data back to table if data changes in object.
The user objects will also be called oViewer - to represend the user object of currently logged in user
another one will be oOwner to represent the owner of the blog which is being viewed by viewer.
These are just the terminology and always refer to object of tyle clsUser. Also clsUser object does not always have to be oViewer or oOwner - it can be just a regular oUser when we need to view user data about some user or if we need to edit some user.
The USER table is being modified as well as new tables EMAILS and BLOGS are being added.
There will also be changes to PROFILE and USEROPTION tables - some columns (many of them) will be removed either completely OR moved to BLOGS table.
Another table PROFILE will also be added and it will hold basic profile details like address, phone, job title, etc...
Last change: a User may have multiple avatars. Only one of them will be set a default, so user may be able to easily change them via admin panel but when someone views user details they may see all avatars.
Fundamentally new features:
User may have more than one email address. Only one of these can be marked as 'default', others are alternative. But these others may be used when posting to mailing lists or when joining mailing lists, etc. Email addresses must still be unique, meaning each email address can still only be used once and that means address can only belong to one user. This also means we can always find user by email address.
Another change: User can have more than one blog. This is very major change because a user will also be able to pick his own sub-domain name for his blog or even change the sub-domain of existing blog, although this is usually a bad idea for the user.
A total rewrite of how user object is instantiated, how it's used, user profile and preferences are not instantiated by default for a logged in user but will be instantiated on demand only when needed.
Options related to user's blog preferences will now be moved to BLOGS table because now the preferences are per-blog and not per-user. A rewrite of edit preferences will also be needed.
A preparation is being made for integrating Google Friend connect with the login system, as well as other authentication method like Facebook connect.
A new type of basic object is being developed and tested. It's more like a new design pattern and it will be called TableRow object. It represents array of data from one table row and will have method to save data back to table if data changes in object.
The user objects will also be called oViewer - to represend the user object of currently logged in user
another one will be oOwner to represent the owner of the blog which is being viewed by viewer.
These are just the terminology and always refer to object of tyle clsUser. Also clsUser object does not always have to be oViewer or oOwner - it can be just a regular oUser when we need to view user data about some user or if we need to edit some user.
The USER table is being modified as well as new tables EMAILS and BLOGS are being added.
There will also be changes to PROFILE and USEROPTION tables - some columns (many of them) will be removed either completely OR moved to BLOGS table.
Another table PROFILE will also be added and it will hold basic profile details like address, phone, job title, etc...
Last change: a User may have multiple avatars. Only one of them will be set a default, so user may be able to easily change them via admin panel but when someone views user details they may see all avatars.
0
Sun, 06 Dec 2009 22:16:59 -0400
Decouple user's blog from username
Blog is blog - it's also should be a RESOURCE and as such, have a resourceID. It can extend the RESOURCE class of cause but still, it's a basic RESOURCE.
We can still automatically create a blog for new user based on a username, but we can also ask a user to pick his own blog url - sub-domain OR full domain name.
Some users may even have more than one blog associated with one user account. This would be very helpful for developers that want to create a new blog for every one of their small software packages.
A blog can have a blog entry with download (attachment), then new items may be added as updates, user can add comments, later we may allow adding a forum to a blog, so it will be everything a developer need to maintain his software and have a community.
Some things should be worked-out like should or can we allow changing the sub-domain after the blog is already establised? If user changes sub-domain it's like a big deal because all previously indexed pages will now be unavailable - we return 404 for subdomains we don't have.
Number of blogs per user can and should be determined by the usergroup, at first every user can have just one blog.
Also should a blog that hold a software have special type of RESOURCE_TYPE or not? How can we find a list of free scripts? I guess a blog that is a home of a script must have unique RESOURCE_TYPE.id
This would require a new table to hold some blog related data and we should move BLOG OPTIONS there too, so things like per-page comments, allow comments, etc. will be defined in there.
Blog is blog - it's also should be a RESOURCE and as such, have a resourceID. It can extend the RESOURCE class of cause but still, it's a basic RESOURCE.
We can still automatically create a blog for new user based on a username, but we can also ask a user to pick his own blog url - sub-domain OR full domain name.
Some users may even have more than one blog associated with one user account. This would be very helpful for developers that want to create a new blog for every one of their small software packages.
A blog can have a blog entry with download (attachment), then new items may be added as updates, user can add comments, later we may allow adding a forum to a blog, so it will be everything a developer need to maintain his software and have a community.
Some things should be worked-out like should or can we allow changing the sub-domain after the blog is already establised? If user changes sub-domain it's like a big deal because all previously indexed pages will now be unavailable - we return 404 for subdomains we don't have.
Number of blogs per user can and should be determined by the usergroup, at first every user can have just one blog.
Also should a blog that hold a software have special type of RESOURCE_TYPE or not? How can we find a list of free scripts? I guess a blog that is a home of a script must have unique RESOURCE_TYPE.id
This would require a new table to hold some blog related data and we should move BLOG OPTIONS there too, so things like per-page comments, allow comments, etc. will be defined in there.
0
