I would have to agree with you that it is usually considered bad practise to have a lot of individual files that are world writable, however you can usually mitigate any risks associated with that threat by using htaccess directives in the containing directory "deny from all", which basically doesn't allow access to the directory except by Apache - though that doesn't work on a Windows server because it doesn't allow the use of .htaccess
This is a topic I have debated several times with different CMS's (including my own that I use for client sites) and there really isn't a clear winning solution because there is always a trade-off.
Some people use the approach you have described, by storing everything in the DB but this can be a problem with some shared hosting providers because they limit the number of DB query requests and/or the maximum size of the DB itself (1&1 Web host is one example).
Having a number of config/settings type files that are world writable is considered quite normal these days (I'm not agreeing that the practise is 'good') and this is usually for the benefit of ease of installation i.e. the webmaster doesn't have to manually edit those files to get the site up and running because we are all human and make mistakes or ommissions when editing files and this usually has the knock-on effect of lots of 'support' enquiries when such mistakes are made.
Personally I prefer the writable file approach; it makes installation simpler and once I'm up and running, I can CHMOD those files back down to a sensible level and forget about them. If your running PHP as suEXEC then you don't need to worry about it at all because you cannot physically CHMOD to 777.
It is definitely a good question regarding having writable files all over the place though!! I know this is simply to make life a bit easier for Code Igniter framework (because it expects specific files to be in a specfic place in relation to the public root) but that's what bootstrapping is for - to tell it where to look for specific stuff, so that is definitely something that could be improved upon.
You will always come across directories needing to be writable, especially when there is functionality that allows image uploading, file uploading, image resizing.
Sure, it is possible for a script to CHMOD a directory or file back to a 'safe' level but with the variety of different server configurations, different implementations of Apache, that doesn't always work 100% of the time.
I see where you are going with the "get data from the DB and cache it" but realistically, the only real benfit you are going to get is if the webiste is under very heavy demand, otherwise reading/writing to disc is far less resource intensive (and quicker).
- Who are you ?
I'm John, a freelance web developer, though I seem to spend most of my time working on OpenSource projects.
- Which CMS were you using before Ionize, why was it horrible or better ?
Mostly I used RavenNuke but that's because until very recently, I was on the development team for a number of years. I still use it when it fits the clients requirements because it's a great system, easy to work with and develop for BUT since I left, the release cycle is just to long for it to be able to keep up with modern technologies like HTML 5.
- Why did you switch to Ionize ?
I haven't really 'switched' - I use whatever fits the clients (or my own) requirements. Ionize is simple to install, simple to use and most importantly, easy to use for novices. It is search engine friendly and has multi-lingual support. Ionize also uses the great Code Igniter framework.
- What things made you happy in Ionize ?
Multi-lingual support - it is not enough to have multi-lingual admin area's etc, a CMS has to be able to support multi-lingual content as well - Ionize does this extremely well and even has SEO optimization for that content as well.
It is easy to install, extremely easy to use and most importantly, it is intuitive to use - you don't need to spend any time getting familiar with it.
- How would you introduce the benefits of Ionize to your client ?
I would only recommend Ionize for very simple sites at the moment or very big sites that needs lots of functionality to take advantage of the CI Framework.
- About what were you disappointed or frustrated in Ionize ?
Lack of a contact form is extremely annoying! I know no one wants to add modules etc before Ionize v 1.0 BUT for people that cannot code (end users) it prevents them from using this great CMS because it doesn't have this one basic "must have" feature.
I believe quite strongly that any website must have certain basic functionality and a contact form is one of them.
The tinyMCE editor is pretty good, though personally I prefer CKeditor because it ensures any user inputted html used is xHTML compliant - I don't think tinyMCE enforces web standards.
No disrespect but you should never give administrator rights to anyone who doesn't know what they are doing and you don't trust completely.
Sure, it is nice and sometimes useful to have really granular access permissions (though they can get complicated and be hard to understand if not done properly) but often times it is better (and quicker) to just train assistants what to do.
Not entirely sure that would be of benefit since all versions up to and including 0.9.6 are bug fixes (with some enhancements, so anyone using anything below 0.9.6 should upgrade to 0.9.6
A few are using the latest (not yet publicly released) 0.9.7 so realistically, there is only a need for specific forums for those two versions, at least until 0.9.7 is 'officially' released as a stable "for production" environment.
Having said all that, what would be REALLY useful is if people could prefix the post subject line with the version;
[0.9.6] My subject here
just to help the moderators out.
I didn't actually see any upgrade script in the Github repository for the DB to go from 0.9.6 to 0.9.7 so I'd assume, at least for now, that 0.9.7 is for clean installs only. Of course it would be easy to write a little migration script if you wanted to by comparing the schema..
OK looks like this is a local issue.
I'm using Ubnutu Linux and FireFox 5.0 to replicate the issue above.
With Ubuntu Linux and Chrome 12.0.742.91 (87961) Ubuntu 11.04 the Upload button only half greys out when I hover my mouse over the button but the button IS clickable if I am very careful with the mouse pointer - so I can at least carry on uploading images now.
Not sure if this is a cross-browser compatibility issues with Mootools (which I hate) and or the CSS but I'll try and dive into it some more.
For some reason, the media manager doesn't work.
I have recursively CHMOD all directories in /files/ to 777 just to make sure they are world writable.
If I go to Content -> Media Manager I see the list of directories I have created and it does not make a difference if I try to upload in the root media directory or any of the sub-directories, as soon as my mouse hovers over the Upload button it goes grey and doesn't do anything when I click it.
I just noticed if you use the left hand directory tree menu and add an article there, I don't see any options for adding meta data for the article.
However, if you look at the header menu under Content-> Create Page..
or use the icon New Page (centre top of the dashboard) those allow you to set the meta data when you create the article.
I wonder why those options are missing when using the menu tree links, maybe a bug or just an oversight.
I had some initial trouble installing this.
The first error was because the admin side could not find the module directory; the zip package uses the directory name modules/tcontact but the code is actually looking for modules/Tcontact (according to the error message I got) so I renamed the directory and that worked ok.
The language file names were now incorrect so I renamed those as well.
This bit in the readme has me slightly confused;
Drop the file article_tcontact.php into your theme directory inside views\articles then register as an article.
I created the file myself because it wasn't in the package but "then register as an article" ? What is that all about?
I know I can just drop
<ion:tcontact > <ion:tcontactform> </ion:tcontactform> </ion:tcontact>
into another existing view page like MySpecialPage but I don't want to do that, I want the contact form to have it's own unique view page.
I am sure in 0.9.5 you could store the meat data when creating the article but I could be wrong because it has been a long time since I used that version.
So if ion:meta_description is the same for every page, does it work if you change in the header file
<meta name="description" content="<ion:title />" /> <meta name="keywords" content="<ion:description />" />
Sorry for guessing, I have not actually tried this or tested for this on my site that uses 0.9.6
It depends on exactly what you are trying to do.
If you just need a single pre-loader page with content that will NEVER change, create your preindex.php file like you have done, making it sure it has all the code you need i.e it is a valid page with a doctype, html header, body etc tags.
Next you need to create a new a new 'folder' in the main menu and an article. When you are doing that you will see the options to set this as 'Homepage' and in your article options, select the vire type as 'preindex'. This will then load your preindex.php file as the homepage and it will also contain whatever content you wrote in the article.
I know in earlier versions of Ionize, the core system detected the browser language and loaded the site in that language by default so are you sure it is even worth the effort?
Good news thanks!
I also have a problem with that link opening a new tab and also when in admin mode when clicking the 'View Website' link.
So if you log in as admin, click 'View Website' then click the admin link again I now have three tabs open
I think it really should open the pages in the same window, otherwise if you perform any administration sometimes it doesn't work because the session is cancelled.
© 2010-2012 Partikule | Web agency Paris, France