mort Posted November 12, 2009 Share Posted November 12, 2009 Hey all Over the past few years I have built and added to my own CMS, and its getting a bit dated and has evolved far beyond the scope of its original specification. It was done very much procedurally, and has turned into a total nightmare to maintain and add extra functionality Anyways I have decided to start from scratch, and build a framework / cms from the ground up using OOP and MVC structure design. Also I have considered using other frameworks such as zend, cake, code igniter etc, but a) I wanted it to be all my own work and b) building my own I get to make it do exactly what I want, how I want, without any other bits I am not going to need / use. The main decision I have made with this is that I want to have one version to control multiple websites, as up until now if I spot a bug I have to then refix that bug in numerous other live, proofing, and development versions as well which is a massive pain. This also applies to updates and new features. Also when deploying my current system its quite a lengthy process because of the number of files, where as I could just add a new site to the existing setup which would be much more efficient. Anyways as I want a central version I wondered if it would be more efficient for the whole thing to run from a single database, or have a database for the centralised bits such as users / groups / permissions tables etc, and then a database per site for content / posts tables too. Plus with the whole MVC thing, some aspects would be unique to a particular site, where as others would be able to be shared by all. Would having an MVC layout for the main framework, and then sub layouts for the individual site be a bit overkill and inefficient? Also have a few more questions too but they hinge on the above and what peoples opinions are. Appreciate peoples comments especially if you have similar experiences with frameworks / MVC / multi site CMS's. Cheers Quote Link to comment Share on other sites More sharing options...
JonnoTheDev Posted November 12, 2009 Share Posted November 12, 2009 A framework library like zend is located in a directory on your server where all your projects can access it i.e. /usr/local/src/php/zend You web apps will include the parts of the framework they require to function i.e MVC libraries. The framework can be extended so your web apps can use the new functionality. CodeIgnitor is a deployed per site so upgrades cannot be done on a single library. A framework is not a CMS. A CMS can be built using a framework. Each web app should use its own database and should be an individual application. You would not have 1 codebase running multiple websites. Each website can be built using the functionality that the framework offers. Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted November 12, 2009 Share Posted November 12, 2009 Instead of website I'm going to use the term project, because you might be writing more than just websites. Each project should be independent of all others. This includes the database, program files, and any miscellaneous files created by the application, such as configuration files, uploaded files, etc. If you start combining project data into a centralized location, then you have issues performing certain tasks: + How will you create a backup of just "Project A?" + How will you restore a backup of just "Project A?" + What happens when you want to move just "Project A" and no other projects to another server? This doesn't mean that you can't have a centralized, single-install framework that all applications refer to. But you must keep the applications themselves separate. I might be able to pop in later with more advice. Quote Link to comment Share on other sites More sharing options...
mort Posted November 16, 2009 Author Share Posted November 16, 2009 Sorry yes I am aware that a framework isnt a CMS, just meant I will be building the framework in mind to have a CMS built on top of it. Also I would want both the framework and CMS to be a centralised architecture as explained In terms of having 1 codebase to run multiple projects, I would have the framework and CMS central, then obviously all front end bits would be done on a per project basis. roopurt18 you make some good points. I suppose I could create a script that would backup / restore sql code based on the site_id only, but that does sound like a bit of a mission. I would want to have things like the users table etc central so users could have access to more than one project, but things like content could easily go in their own database Quote Link to comment Share on other sites More sharing options...
JonnoTheDev Posted November 16, 2009 Share Posted November 16, 2009 In terms of having 1 codebase to run multiple projects, I would have the framework and CMS central, then obviously all front end bits would be done on a per project basis. I do not understand how you can have a single CMS for all projects. Yes your CMS can be built using your framework, but if I had 2 projects, one being an ecommerce application and the other a social networking app how can one CMS manage both systems? This is impossible as the feature list is completely different between the 2 projects. Write you framework and then build your CMS from it. A CMS should be per project. What if you needed to move the project to another server? Quote Link to comment Share on other sites More sharing options...
mort Posted November 16, 2009 Author Share Posted November 16, 2009 Because the CMS back end is going to be very similar for any type of project you do. All CMS will need a login form, a forgot password form, a way to present and manage data? They will all need to handle users, groups, front end stuff split into posts (blogs, news, events etc), and content pages (home, about, contact etc). Granted there will also be differences and probably bespoke work required on each project, but ultimately a lot of projects are just going to be your same basic bits with a different skin, and a few slightly different features In our current system we already have a class similar to cake's formhelper class, where you can specify the db fields, labels for the form input, and options (for select / radio / checkbox elements), and then using that business logic it will construct the back end form with very little actual work. surely this makes more sense than having individually written forms for every part of your projects CMS? Also if I want to move the project to another server then I could still have a separate copy of the framework and CMS, and it would still be easier to manage than having a copy of the CMS for each and every site I do. As for example if I spot a bug in a part of the CMS that is universal to all copies of it such as in the back end user management, I could have to fix it in up to 50 locations, instead of just 1 or 2 Quote Link to comment Share on other sites More sharing options...
JonnoTheDev Posted November 16, 2009 Share Posted November 16, 2009 In our current system we already have a class similar to cake's formhelper class, where you can specify the db fields, labels for the form input, and options (for select / radio / checkbox elements), and then using that business logic it will construct the back end form with very little actual work. surely this makes more sense than having individually written forms for every part of your projects CMS? Of course. This is part of your framework surely this makes more sense than having individually written forms for every part of your projects CMS? Not sure where this is mentioned. If you believe your approach will save you time and will be easy to manage then just go ahead and build it and see how it works out. I personally would not use a single system to manage the data acreoss multiple sites or applications, nor would I use a single database for many applications either when they have different features. I believe that this will cause more pain for you. Back to one of your original questions Plus with the whole MVC thing, some aspects would be unique to a particular site, where as others would be able to be shared by all. Would having an MVC layout for the main framework, and then sub layouts for the individual site be a bit overkill and inefficient?This doesn't make sense. MVC is a design pattern and is available for use in your app by most frameworks. I am familiar with Zend and CodeIgnitors implementation, but do not understand what you mean by main layout for the framework and sub-layouts. Quote Link to comment Share on other sites More sharing options...
mort Posted November 16, 2009 Author Share Posted November 16, 2009 Example having an MVC design for the main framework, then for any bespoke bits that needed doing on a per project basis, doing that as an MVC design within the sub project folder as both you and roopurt18 have said, a single db is probably a bad idea. so will probably go down a route with having a db per project for the content, and a central one for all universal aspects such as users + groups tbh I think your right, for say mini info sites and such where a lot of the info is going to be very samey then having one framework to fit all might work, but if you are trying to mash an ecommerce / social network into the same thing it could prove difficult. at the end of the day i just want a solution for quick deployment and maintainance for websites we do for SME's, and then anything a bit more complex and bespoke would be able to be done stand alone Quote Link to comment Share on other sites More sharing options...
JonnoTheDev Posted November 16, 2009 Share Posted November 16, 2009 Example having an MVC design for the main framework, then for any bespoke bits that needed doing on a per project basis, doing that as an MVC design within the sub project folder having one framework to fit all might work, but if you are trying to mash an ecommerce / social network into the same thing it could prove difficult. I really think that you are getting confused with the term framework. What you are describing above is a CMS or a project. Read http://framework.zend.com/docs/quickstart There is no such thing as a MVC design for a framework. As I said MVC is a 'design pattern', not design as in page layout. I think you are talking about the layout of your applications as in front end! This is not what the MVC is about. It is a pattern for separating the presentation (view) from the application logic and access to the data. Quote Link to comment Share on other sites More sharing options...
JonnoTheDev Posted November 16, 2009 Share Posted November 16, 2009 at the end of the day i just want a solution for quick deployment and maintainance for websites we do for SME's, and then anything a bit more complex and bespoke would be able to be done stand alone If most of your small projects include identical features then what I would do is create a package. Let say most clients have blogs, dynamic page content, galleries & images, etc. Create a script that you can package and install, switch features on and off. Have a selection of templates. When you have a new client you can just install a new project from the command line. When you talk about updaing these sites it is easy to create update packages that can be deployed across the board in one go, not going through 50 sets of site files. You could create a deployement script that will extract any updates and install to all site files from your server, etc. Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted November 16, 2009 Share Posted November 16, 2009 and a central one for all universal aspects such as users + groups I advise against that. Your framework or central code base should have a nifty way of handling that information so you don't have to rewrite the same old code all over again, but the data itself should still be separate! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.