CMS & WordPress
I've been thinking about having a go at building a bespoke content management system as a project over the Summer, but I've never tried it before. I've been using WordPress for all my CMS needs when building websites for clients. I guess I want to develop a better understanding of how they work. I understand that you need to have a basic understanding of HTML, CSS, PHP, etc in order to get started, but what other skills would you recommend that a person have in order to build a bespoke content management system? I understand that building a CMS from scratch is a daunting task for even the most experienced developers. How much experience with the programming languages and databases in order to build the most basic CMS?
Checkout Sitepoints book, Build your own database driven website with PHP and MySQL. Its not hard, the hardest part is finding a book that includes some basic security information. Would say if you are not doing comments from the public or putting sensitive info in the database, which has different security standards it is fairly easy to do.
you need to know mySql database as well.
this is a very elaborate work. unless you have something unique to offer, you are better off using existing ones.
I tend to agree with webcosmo here... Most web developers have at one time or another come up with their own CMS. It's not difficult at all to do but there are limitations to what one developer can do. I built a really great foundation for a CMS many years ago but with only me contributing to the project it would never keep up with the thousands of developers contributing to something like Drupal.
If you want to build a CMS for the thrill and learning experience of creating your own, go for it, it's well worth the effort but if you're building it as a platform to run a business on, you will provide more value and have a far more solid future by learning the ropes on an established system like Drupal or WordPress.
Many developers that I know who developed their own CMS eventually abandoned it in favor of wordpress, drupal, concrete5, expressionengine, or any of a handful of others. The problem is that with custom built CMSes, there's only one--maybe two--people working on it. With these larger CMSes, there are entire communities. And then if you need something customized, there are usually options for creating your own plugins, widgets and themes.
In the end, by using an existing CMS, it means less development time spent on the nuts and bolts of the CMS and more time actually doing work for clients.
While building your own CMS can be a good experience, there are so many options available that it's not really necessary to do so any more.
It's actually not that unusual to have your own sort of "in-house" CMS that you might use for certain clients in certain situations.
I work with a few different web development frameworks, and it's not unusual, when building out a custom job for a client ... to include a protected interface where the client can go to do basic things like update images, or text on a certain page. Just basic CRUD stuff, and when you really break it down, that's all a CMS really is and that's the function it serves.
For the clients whom I've gone the custom route with ... they have an interface for their site that is 100% tailored to their site's needs ... and absolutely ZERO bloat and no added "crap" that they won't ever use or need. They log in and see maybe two or three options -- only the stuff that they need to do.
In the end, it works well, but I have no reason to think it would be practical to do this for every client. As a more "general purpose" CMS, one of the many fine open-source offerings are more than adequate for the job, and no need to reinvent the wheel.
Thanks for the input, guys. Much appreciated.
I've bought the SitePoint book about building CMS and am going to have a read through it and try things out for myself. Even if I don't end up using the CMS I make, it'll give me a better understanding of how they work, and I'll be able to give more support to my students if they wish to go down this route.
Just a word of warning to throw in the mix.
I agree with the comments above, great to know the inner workings of a CMS but there's a need to be able to advise clients on picking a good CMS too. I'd advise against opting for a custom built one after my experiences working for a large company who went this route. They ended up trapped and tied to a couple of guys who did the development of the CMS which inevitably grew and grew. They tried to offer limited functionality to staff for changes - but as the company grew so did the companies needs. The task and investment in a proprietary system has meant a lack of CMS development as staff changes. What once may have offered great investment and tailoring is now an expensive noose around their neck. They have a messy database, out-dated website, and no easy way of breaking free.
This isn't to say that custom CMS can't be useful or necessary. Just that it is important that the clients know what their choices are. Will a custom solution be easy to change a few years down the track? The advantage in some of the Open Source and well-supported commercial options is that they have a large user base and if your head tech gets run over by a bus, someone else can come along and pretty quickly establish how things are working and carry on.
Unless of course there are a lot of custom modules and templates that may / may not follow the standard way of doing things with that CMS.
But yea, you make a good point.
These are reasons #1 and #2 for my switch about 5 years ago from our brilliant in-house CMS to Drupal, a brilliant community driven CMS:
1) I realized single-handedly I couldn't keep up with the demand for features that a community driven project can accomplish effortlessly and I noted several prospective clients who had stories about being stuck on proprietary or custom CMS systems without a modular method of expansion or upgrade path.
2) What if I decided I didn't want to support the project for personal or health reasons. I had met several clients who had great tech support but then one day the tech either checked out for personal reasons or health reasons and they were stuck spinning their wheels until they found someone to maintain their custom solutions or provide a plan to move forward with something Open Source.
Now we typically take on at least one new client a year and move them off some limited custom CMS and onto an open ended community driven CMS where they aren't locked into any person or corporation for maintenance and feature upgrades.
I personally am giving both methods a try (coding my own and using a combo is MediaWiki, phpBB and Wordpress), both methods will have to interact with a game which is being coded seperate and an seperate irc server (I've got to look into one that i can tie in so that irc bans, etc get logged in the main app and so I can set it that only registered users can use the irc). A few things that I'm keeping in mind when using either way:
- Sessions: I want to have (if I go for the use of the combo) one app handling all session management and storage.
- User Groups: I want to have a central point with one app handling all bans and management of users
- File Management & Avatars: Again one app handling it all
A few points to consider:
- If you go for a combination, try to avoid hacking about the core coding of whatever app you use as it will make upgrading to newer versions of whatever the app is harder, use apis and plugins
- Unless you expect your site to have enough traffic, don't bother with any paid-for solution, you will need to decide if you can justify to yourself the costs of any paid-for solution (initial purchase price, licences, support costs, etc)
- If you do go for a paid-for solution, look into what open source solutions you could migrate to the easiest if you ever decide to drop a paid for solution
- Research the apps you plan to use to make sure that they will work together well.
- If you go for the custom route, make sure that everything is well documented
mid sized growing companies are very skeptical on custom no-name CMS. they rather prefer something proven, been around for a while.
they have good reason for this view. they look down the road; when they need to change something on the system they have the option not to depend on a single person/company.
but then again thats not always the case. when you are to build a big complete custom software, its lot easier to do that with a custom CMS.
which basically boils down to the target market.
Not necessarily... Anyone who has been coding enough to connect to a database, text file or xml can create a CMS and there's no harm in messing about with that. In fact I think it's a very good exercise to learn the ins and outs of CMS design. I still run our company site on a CMS we developed at least 10 years ago.
The difference comes into play when you are developing for a client. If you're developing professionally, you have to think about your client's immediate and future needs. What do they need now, what will they need in 6 months. What happens if you drop off the edge of the world and are no longer around to maintain the custom code you wrote. For that reason I usually recommend a community driven CMS with a strong following.
Case in point...
I'm doing some custom code for someone right now (I mean right this minute I'm working on it) and they're a big wholesaler with big clients of their own but they have a custom CMS for their B2B portal and even their database is custom code and data files. They've been looking for a developer to help them add features for a couple of months now and after some review I took on the job. It's going to rock once I'm done and I've assured them that it will be alright but I know they've been sweating it out for a little while now trying to figure out how they were going to keep it going. In the long run, I'm going to suggest we do a rewrite with Drupal but for now I'm just adding features. I have no idea what happened to the original coder. Whoever it was, they had a unique way of doing things... It's not terrible, just very unique and reminiscent of what guys used to do with desktop apps in the Windows 3.x days.
Have a good night (or morning) and Happy Friday!
Let the development be for anything that should fulfill the requirements of the customer needs now and should be flexible enough to add the new features at any future. If you are good enough in designing the database, you can do a lot better based on your requirements than what a community driven CMS software can do on your specific needs. What I think is relying on the CMS software is based on the requirements. For developing medium or larger scale application going for CMS is good idea because it took much time to develop on our own. The CMS software is also developed in that way to handle that much level applications. Imagine for small applications development the CMS is not necessarily required. It is enough to have handy coding
To grow your own CMS you need to be proficient in HTML/CSS, PHP and SQL, and it's not just about the programming, it's the layout and design as well.
If you were to create a Bulletin Board / Forum type system, you probably don't have to worry a lot about features/plugins and templates, but for a system to become popular, it needs to cater for the needs of those who use it.
That's why I would recommend using either Bulletin Board software, or Wordpress, Joomla or something similar, because these have been designed with all of this in mind.
If you create your own system, you will need to ideally do some detailed design to know what you want to add into it, or do this as you go along, which results in lots of program (script) changes, and a lot of messy code.
It's nice to do as a project, but if you consider the thousands of hours of development time that have gone into Wordpress, you would be better off building plugins/themes for Wordpress that made it do what you want.
Definitely good points Andrew. Having worked in IT for 30 years (more than I care to remember) I have seen many cases where a developer leaves and it's almost impossible to maintain a system. The people who requested it have also usually left the company too, and the documentation (if any) is woefully lacking.
If you opt for a standard software package, then there is usually never a shortage of people who understand it and can help to maintain it.
Thanks poddys, I know exactly what you mean. For me, it's very important that the client has something tangible that they can hold onto, maintain and extend, rather than a teardown the next time they decide to do a redesign or if the developer wins the lottery and goes out of business.
About 5 - 6 years ago I had the same opinion as varul. We had developed an in-house CMS that was optimized for speed, had a theming engine and a number of modular add-ons for blog, news, search, etc... The problem was that we were the only ones who knew how to maintain and extend it so if we weren't around, it was dead in the water. With hundreds of CMS choices available, who would want to learn our system and keep it alive if it landed in their lap without documentation? It was definitely a shift in thinking when I finally got an idea of the potential of a community driven CMS.
I wouldn't tell someone not to attempt their own CMS. It's a good exercise and makes you think about the tricky concepts behind managing content, navigation, search, creating an API, users/roles, etc... In fact if you dig in and try to build the next WordPress, Joomla or Drupal, you might decide to contribute your big ideas to the core of such a project and improve what others are doing or come up with the next big thing.
Funny because I think Drupal and Drupal modules have some of worst documentation. Writing code then relying on others to write the documentation for you is a poor mentality. Though that seems to be what is promoted throughout the community…
I can't even count the number of modules without any documentation and/or core topic docs that have little to none. Even those that provide documentation whether online or with help integration almost always seem to contain useless information as if it was an after thought and just thrown together.
Funny, because I find the opposite to be true. Isn't that strange how depending on how you look at things you'll get a differing perspective :lol:
I chose Drupal as my main CMS and application development tool which caused me to delve a little deeper and realize that the documentation is there. As a matter of fact 99.99% of all of the modules I've used have a very good readme.txt, install.txt that describes the modules in great detail and if I look at the module code itself, it's actually self documented via the API. Furthermore there are a great deal of modules documented in Drupal's Community Docs.
To be honest, I can't say I'm 100% happy with every bug-request or help issues I've made made through Drupal's module issue queues but I have been impressed with the infrastructure and standardization that surrounds the way modules are vetted and accepted and the majority of issues and areas of interest I've been involved with on Drupal.org have been positive & successful.
Do you have any specifics? It's easy to throw around rhetoric about this sucks and that sucks but how about some specific module you had trouble with. Did you fill in a request issue? Did you Google it?
next page →