So here I’ve been for a while giving shape to my first medium scale CMS and one of the things I deem very important now is to find a consistent structure for my directories as I see myself relocating files quite often.
I am using the MVC pattern so I have directories for classes, controllers, and views. I also have a directory called modules in which each module folder will have again the aforementioned folders.
In the application root directory I have three other folders called config, library and public. library has quite a few files with handy functions and another folder called resources where I keep almost all third party code.
Doing research in this matter I read that in order to enhance security all of the non-public files (application files) should reside outside of the root folder of the website (i.e. outside the public_html folder). This is what I am currently doing however this approach also makes it less practical for organization because i.e. any public files (js,css…) belonging to a particular module cannot be placed in the module folder. I have to create another folder that resides inside the public directory to host these files, which I don’t like. I have not seen any CMS yet that has its application files outside the public folder. I wonder why that is. Any thoughts on this?
So going further to my public folder I have folders named css, js ,images (for all application images), media(for all user uploaded files), and skin(for the js and css of each module).
I find myself now wanting to put all application core inside a folder called admin in the public directory just for ease of organization. What do you think about this? Well what are your thoughts generally on CMS directory structure and code organization? Know of any enlightening resources?
I use the core as essentially a gateway to functionality, rather than functionality itself.
This is good advice. Implementing now, thanks for the tip.
The problem with app design is that you never stop learning. As soon as you accomplish one hurdle, there’s a whole new world to explore.
Yes I agree, although that’s exactly what makes our job never to be boring. Always something to learn and things to improve. And yes that’s also the sin, too many ours stuck to my keyboard. Love it most of the times, specially when things come together neatly. Other times I wish I was on vacation in some remote place.
Actually, you’ve thought this out very well. My first PHP ‘application’ based on OOP was absolutely horrific.
Yes Indeed. There’s a lot of thought behind it and I’m not a complete beginner. Pulled out of my sleeve a few tricks and I am coming to see the beginning of a promising CMS, which I can use in future to build my own websites.
Been using for a while now at work other CMS like Drupal, Joomla and Magento and they have the virtue to get on my nerves most of the times be it for performance issues, complexity or non-intuitive CMS design. So why not give a go to my own? The worst it could happen is that I end up learning more.
Thanks again for your time and for sharing your knowledge.
you can easily tell I haven’t been long developing applications.
Actually, you’ve thought this out very well. My first PHP ‘application’ based on OOP was absolutely horrific.
I had a ‘glue’ class which was essentially a singleton nightmare using method chaining everywhere. It was awful. Though the support I had from the forums after completion helped me see the flaws and turn to better programming.
The problem with app design is that you never stop learning. As soon as you accomplish one hurdle, there’s a whole new world to explore. It doesn’t end - and if you find yourself doing the same approach for more than 6 months, you need to go searching for new ideas or even invent one of your own.
Well, if the second quote works out your third will have been solved
Basically with the file interaction library, just a small set of methods in the core which check if sections exist/are available, and fetch them if they do.
For example:
$Categories = $Core->getDAO('Category');
My core is the application’s access to the searching of that object (in this case a category data-access object) and the retrieving of it, returning boolean false if it doesn’t exist. The reason I have them as methods in the core, rather than straight functions, is that I use the same core for multiple functionalities of the site; administration, standard public output, XML output etc - so different controllers and DAOs are sometimes required. The core actually has an object which handles all of that, as I use the core as essentially a gateway to functionality, rather than functionality itself.
So, back to my point. If a library is in control of getting things you need, it should also be in control of judging where files are located.
Can you please explain this to me a bit further? I get the idea of what you are saying but perhaps a brief example or a resource related to this would be really helpful to me.
This is a good idea. I will give it a go thanks.
[/QUOTE] you can easily tell I haven’t been long developing applications. So does it make more sense to put it all in a folder called ‘core’? But anyway the point of this was (I don’t know if I explained myself well enough in the previous post) that currently all of my application files are one directory up from the public html folder and I cannot make a request for a CSS or JS or image file for something that is outside the root directory of the website, or can I? So me believing that I cannot was the reason that I wanted all application files and folders to be contained by the root directory. That way I can store public files inside pertinent module directories.
I often find myself doing that when building a type of application which is new to me. If you become fixated on certain structures you lose out on a part of your application’s evolution. Sometimes a change in the middle of development is a good thing - and its also a test for how well you’ve been coding. If your module files are dependent on the file-system layout (e.g. hardcoding paths), you’re going to have a bit of a nightmare to do any rearrangements - but if you’ve made a library to handle all the file interactions (includes etc) it’d take no time at all.
Of course, you don’t want to be making large changes for little/no benefit. Make informed changes based on problems you come across.
Which should take an url like styles/yourModule/main.css to …/modules/yourModule/styles/main.css - unless styles/yourModule/main.css actually exists.
My personal opinion is that this would be about as acceptable as putting all your modules inside an images folder, or a sock in your cup of coffee. It just doesn’t make sense
