So you have just been handed the keys to a not-so-new Drupal website that another agency built, you are now the guy in charge of keeping the site running, and ensuring the success of your new client. While everything seems shiny and new on the surface you finally get your first peek under the hood only to find out that the last guy obviously lied about his experience with Drupal. Your client may even already be aware of some issues with their site and is asking you to correct them. You have now come to realize that your success relies solely on keeping this house-of-cards website from toppling over.
While telling your client that rebuilding their website from scratch is the obvious solution you risk having your integrity questioned unless you can come up with some really compelling reasons for wanting to do so. Your client may not have the budget or may just not understand the problem. After all, you probably would not let an auto mechanic tell you that the brand new Ferrari you purchased needs a new engine. Here is how not to fall into the role of “Drupal Janitor.”
Define a Process
Learn GIT or SVN and setup a development environment, and stick to it. It willsave your life! Make sure that everyone involved in the project knows exactly what to do. This should be pretty standard practice for any project, and for good reason. Mistakes can be made and corrected in your development site before pushing them out to the production site. This will ensure that your work is 100% every time, which will bode well with your client and your employer.
Identify Problem Areas
Inexperienced developers generally do not think about modularizing their work and seemingly small changes to one part of the site can potentially create more problems in other areas. It is important to fully understand any existing issues, or potential problem areas before trying to fix anything. You may have to figure out the reasoning behind why things were built a certain way and what the original intent was in order to fully understand how to fix it correctly, or if any change is needed at all.
Some things you will want to look out for are:
- Poorly written custom modules: Someone who is not familiar with Drupal probably does not know what is available to them in core or in contributed modules. Rather than doing it the Drupal way, they will often opt towards doing it their way, which can cause problems. You can implement the Coder module to look for modules that do not fit with Drupal coding standards.
- Modified contributed modules: This is a big no-no and it happens a lot. Unfortunately this can be hard to identify until it is too late. Install the Hacked module to identify any contributed modules that have been changed, and look for problems after updating modules.
- Improper website configuration: Research your options when selecting modules and make sure you are using the right tools for the job. Drupal Modules will allow you to compare modules in order to make the right choice for the job at hand.
- Bad theming and invalid HTML/CSS: These are usually the most obvious and can cause a lot of frustration while trying to test. Since a broken front-end can give the appearance of a broken back-end, they should be addressed accordingly. Firebug for FireFox is a developer must- have, and the W3C CSS and HTML validators are good for identifying bad markup.
Create a Game Plan
After identifying any issues, you will want to make sure that your client understands the depth of the issue, especially with any major changes that need to take place. They may ultimately decide that they are not very important which will help you prioritize your work. You will probably want to focus on the bugs that require the least amount of work but have the greatest impact.
Of course, once everyone is on board with what is going on you can start maintaining the site properly. You may not notice right away, but it will become very apparent to you and your team when the frantic calls from the client become less and less frequent.