||[Sep. 24th, 2010|11:00 am]
Got everything with a consistent look via the magic of CSS.
My main navigation menu is an included PHP file. I like this bit. On a CMS of any sort, you'll often want different types of users. An admin to make structural changes, add users, and the like, a writer to make posts, a commenter account is good too. To this I've added an "inactive" access level, and an "any" as a default. I've added the access level to the session variable array, the access level pulled from the user table when someone logs in. This lets me run a simple switch statement to decide what links are on my navigation menu. One file, gives me up to 5 different menu setups. Currently I only have menus for the default, the writer, and admin... but the structure allows for expansion as I scale this thing up to a production ready app.
I'd like to have a database table that stores every page in the app along with it's access level, so I can simply query the database. Keep the PHP code simpler. This would be especially useful with a feature I want to add in the future- Allow admin users to change the security setting of various parts of the app. With it in the database, it would be easy. With this tracked inside the PHP file, it would be difficult and introduce a potential security issue of an important include file being writable from the web. I tried a couple brief attempts at this, but it's a bit complicated for my level of SQL knowledge.
Still need to write the admin page. Initial features will be a user manager- add CMS users, set their access levels, delete users. I'll also be adding a post delete feature. At present, this stuff I have to do through the MySQL command line client. That's unacceptable for a release version. While I'm ok with it lagging behind in featureset when I release, it needs to have a minimum of features to be useable. It's not to that point yet, though what it does allow it does do reasonably well.
I also need to write a registration page so people could sign up, and a user profile page so people could manage their own posts. Comments and a permanent link feature need to go in, I need to add post time to the post database for sorting. Then pagination, and I think I'll be ready to release it.
Long term I'd like to look into localization. Perhaps put all the displayed strings into a database table, one table per supported language. Include the users selected language in a cookie and/or the session. I think I'll implement this as soon as the basic featureset is up- if I wait too long, the number of strings involved would make the job really, really annoying.
Will it have any real advantage over existing CMS's? Probably not. As a platform to fuel my studies in SQL and PHP, it should work well, but that's about all I expect. It might also be useful if I apply to jobs where I work with web technolgies or databases. Even if it's not specifically in the job domain, or is but isn't up to their standards, showing that I've been able to build a functional app with this stuff would be a good boost to my chances. Since it's done on my own they probably wouldn't expect something of the quality I could build with the support of the companies dev team.