Backing Up

In light of what happened last week, I decided to make coming up with a strategy for backup a priority on the Massachusetts HOSA website. After all of the work that I put into the design the first and second time around, I do not want to risk losing it again. In many regards, I am thankful that losing the data happened when it did. It has allowed me to improve my habits and develop in a more efficient and sustainable way.

The first thing that I made sure to do once I had restored the design of the website was to make an initial back up of the files and database. Although there are more efficient ways (I’ll explore some of these later), I chose what was easiest at the time and copied the files from the web server to my local hard drive through an FTP client. Through an SSH session, I dumped the contents of the database to a .sql file and transferred this file to my local computer, again through FTP. I am now far less paranoid making changes, because I know that I have this backup to fallback on should I mess anything up beyond repair. This backup contains the entire base site, with all design completed per original specifications.

After meeting to discuss the next steps, I will undoubtedly be making more changes to the site. Rather than having to initiate these backups manually each time using the process I described above, I would like to have some way of automatically backing up changes on some sort of a regular schedule. After researching plugins that could accomplish this, I found UpdraftPlus. I wanted to use a plugin rather than something server-side because we will be migrating the WordPress installation to a different server following development. By using a plugin rather than some sort of cron job or script on the server I would eliminate the need to completely reconfigure the backup service after the migration.

After initial setup, I ran a forced backup using the UpdraftPlus plugin. Despite a few files that the tool was unable to backup due to incorrect file permissions, the backup ran smoothly and stored all of the pertinent website data, including a database backup, on my Google Drive account. The only thing that has to be done at this point is to transfer the backup location to someone who will be able to access them if needed following development. I’m very happy to have found a solution to the problem of backing up, and looking forward to not worrying about breaking the website.

Recovering from Tragedy

After last week’s post I made a simple click that I’ve made probably hundreds of times before when I updated WordPress on the MassHOSA website. The difference this time, however, was that I wasn’t only updating the WordPress core but also the theme that was currently being used on the website. Depending on the update, you can sometimes get away with updating themes without losing customizations. If, however, the update includes changes to say styles.css, for example, your customizations will be obliterated.

I have nobody to blame but myself for this mistake. I was fully aware that updating a theme could wipe out customizations, and WordPress even has a handy warning on the theme update screen:

But, I was not thinking and clicked update – and lost all of the customizations that I had made to the theme, permanently. Here lies another issue: backups. I should have been making regular backups of both the WordPress filesystem and SQL databases, since at this point I have put a significant amount of effort into both the design (stored mainly on the filesystem in CSS and PHP files) and the content (stored mainly in the SQL database).

While this incident was certainly frustrating, it’s not that tragic. I was able to restore the customizations (this time in a child theme) in a matter of a few hours, and am happier with the outcome this time than I was after my original modifications. Using a child theme forced me to do things a bit differently than the first time around, but at this point I already had a pretty good idea of the changes that needed to be made. I am happy to be doing things the right way now, as my original design would not have been sustainable. Making changes directly to the themes CSS files means that you cannot apply updates as they become available. While this would be fine if updates only ever contained feature additions or style modifications that you were not interested in, this is not advisable when some updates contain security patches. Given the choice between leaving my website vulnerable to attack and losing customizations, I would rather put in a couple of hours of doing customizations the right way than face the repercussions of a breach.


Adding Content to the Skeleton, an Adapted Scrum Methodology

This week marks the beginning of adding real content to the skeleton site that I have been developing for Massachusetts HOSA. The content was provided to me in the form of a word document, with titles to differentiate between pages and sections. The first thing I did upon receiving this document was break the document down into individual user stories. I then created a Trello card for each story and placed the cards on the product backlog list. During this process, I was reading and building an understanding of the product owner’s vision for the website, as well as attempting to come up with potential acceptance criteria. I was also informally coming up with estimates for the amount of time and work that each story would take, but decided not to include these as part of the stories as it would offer minimal return on investment with me as the only developer. I looked at this process as a sort of modified Scrum Story Time meeting.

The next step was Sprint Planning, in which I plucked some of the story items that I saw as most important and placed them on the Sprint Backlog list. During my modified Story Time, I had already, for the most part, broken these stories down into small enough pieces to be worked on as tasks. This was the simplest way to handle breaking down the requirements, and is allowable because I’m the only one that is working on these tasks.

Once I felt that I had taken enough stories from the backlog to keep me busy for a week, I began work. This involved adding content in the form of text and images to existing blank pages on the skeleton website, as well as creating new pages as needed. Some of the story items involved formatting things like the footer and sidebar to achieve the desired effect. Throughout development, various questions arose.

Each time that I encountered something that I needed clarification on, I added a comment to the Trello card. For this reason (and many others), I really like using Trello cards to represent user stories and tasks. Using Trello also allowed me to attach images, checklists, tags, and mentions directed at specific users. I like the idea of keeping all of the relevant information about a specific user story in a single place rather than scattering it across email, in-person meetings, and Trello. I’ve been attempting to document any information passed through other communication channels into Trello so as to have a complete log of interactions.

I’m looking forward to getting into some more specific development on the site. Next week’s post will include a review and retrospective for this sprint.


Turning Dummy Links Into Real Links

Often, when I’m designing a website, I will sketch out a diagram of what I think the relationships between different pages will be. Here’s an example of one of my early sketches:

Even if the finished product is vastly different from the original diagram, sketching out some of the pages and their relation to one another helps me to get a better idea of the overall layout of the website. Skipping this step has, in the past, led to a jumbled mess of pages with no real organization. It is much easier to change a few pages’ organization when problems arise rather than having to redesign the entire website from scratch. The design step is also great for determining parent-child relations. In the above diagram, for example, every page is a child of the HOME page, and all of the child pages link back to HOME. The first generation of children are the WHAT IS HOSA?, CONFERENCES, CHAPTERS, as well as the three callout pages HEALTHCARE PROS, STUDENTS, and TEACHERS. Under each of these pages exist multiple other pages or sections all related under a common theme. Some of these pages link to related pages that exist elsewhere, such as the Find a Chapter link under both CHAPTERS and STUDENTS.

The overall goal here is to make the site as easy to navigate as possible. When I have a basic skeleton of the site set up, I will often ask someone unfamiliar with the organization to attempt to perform a particular task. If I have done my job, they will be able to navigate the site without knowing more information than what I have given them in the description of the task. I watch closely as they move around the site, asking questions to clarify why the user makes certain choices. Things that seem obvious to me may be completely unexpected to a first time visitor to the site. This sort of testing allows me to make improvements to the flow and organization of the site.


Whoops, I Picked the Wrong Theme

After spending many hours attempting to accomplish what I thought would be a relatively simple task, I decided to change the theme of the the Massachusetts HOSA website. Although my post last week went into detail about the many reasons that I originally chose to use the Trusted theme, there was one problem that became obvious to me as I attempted to adjust the size of the image slider the displayed on the homepage of the theme. While I expected these kinds of edits to be as simple as adjusting the size of a div container, it turned out that the theme used more complex embedded functions and jQuery to make the theme responsive. This responsive nature made it difficult to edit the size of the image slider and set it to a smaller, constant size.

It was around this time that I began to question whether or not it was worth my time to continue debugging and teaching myself how the Trusted theme set up the slider. I decided to instead look for a similar theme that may be easier to edit. I found the Consulting theme and found the slider to be much easier to edit. I was able to set the maximum width for the slider at 700px while still allowing dynamic resizing for responsiveness and support for mobile devices. Unfortunately, this nullified all of the changes that I had made to the Trusted CSS files that brought the site into compliance with the HOSA style guidelines. I did, however, discover a far more efficient way to edit the Consulting theme that I kicked myself for not thinking of earlier. First, I used Chrome’s Developer Tools to find the color code that I wanted to change. I then used the “Replace All” tool in TextMate to change all occurrences of the that color code with the desired color. Overall, the second time around for customizing the theme was far smoother and more efficient than the first.

Customizing a WordPress Theme

With literally thousands of themes in existence, there is sure to be a WordPress theme out there that fits the needs of you or your business. Why spend your own time designing a theme when some generous person has already done the work for you – and posted it  online for you to access completely free of charge? While some themes may no longer be updated or maintained, many receive regular security patches and feature enhancements to ensure your site is not at risk.

The main considerations when choosing a theme for the Massachusetts HOSA website were a banner image and feature area to mirror the appearance of Georgia’s HOSA website ( The theme I found that most closely matched this desired appearance was the Trusted theme by uxl ( The theme was highly rated, installed and active on more than 5,000 WordPress installations, and recently updated to ensure compatibility and security.

No theme is perfect, however. The first changes I needed to make were to the color scheme of the theme. I’ve work with CSS before, but found that Google Chrome’s Developer Tools ( made it much easier to isolate a specific CSS attribute or tag rather than digging through the more than 5000 lines of code. I used the HOSA Style Guide to make sure that the colors and images that I was using in development matched the requirements of the organization. This was a new concept for me, but I found it extremely helpful that the organization published all of the approved brand colors, fonts, and logo requirements in a single resource.

The website is now up and running on a development server, and the theme has been modified to match the appearance of the HOSA brand. The next task that I will be working on is implementing a slider in place of the banner image on the homepage that displays conference information with links to register for a conference.

Choosing a CMS

When choosing a content management system (CMS) to begin developing a website for myself or someone else, there are a few important considerations that must be made:

1. Who will be maintaining the website after development is finished?

I think that possibly the most important consideration that needs to be made when choosing a CMS for website development is who will be the one responsible for maintaining and updating the website once development is complete. Nothing is more frustrating than going on a beautifully designed website only to be faced with outdated and/or broken content. It does not matter how beautiful or complex the original design is if there is a need for dynamically updated content and nobody around who possesses the skill set required to make the changes or update the content.

2. What type of website is being built?

Another important consideration is the type of content that the website will serve. While many CMSs have support for multiple types of websites such as blogs, ecommerce stores, and static content sites, one may be better suited to a particular task than another. Choosing the right CMS for the job can make both the developer’s life easier and also create a more efficient, polished finished product.

3. How is the website being deployed?

In addition to considering how the website will be hosted and deployed, it is important to consider what the expected volume of traffic will be when choosing a CMS. If the expected volume is extremely high, then perhaps a cloud-based SaaS CMS is the best option. A cloud-based solution would allow for much easier load distribution and balancing and may be automatically handled by the platform itself. If volume is expected to be relatively light or the site is to be hosted locally, considerations must be made for the hardware/software support of the systems on which the site will be running.

4. Does the website need to integrate with existing infrastructure?

In addition to hardware/software considerations for deployment, another factor to think about is what types of IT infrastructure is already in place that will need to be integrated into the website. If there are already databases in existence, ensuring that the website will be able to integrate with them will save significant time and cost over having to migrate data between systems.

5. What kind of support is available for the CMS?

Whether it is for the developer, or for the client after development has been completed, what types of support and how easily accessible it is can be an important factor in deciding on a CMS. Are security patches regularly released so that the site will not be vulnerable? Is there a community that releases plugins, themes or other types of time-saving customizations for the CMS?

In deciding on which CMS to use for the development of the Massachusetts HOSA website, I considered these five points and decided on WordPress. My experience with WordPress as a CMS has been very positive, and I feel that choosing such a user-friendly CMS will allow for straightforward updating and maintaining of the website for many years to come. WordPress is flexible, powerful, and will be easy to scale should the needs of the organization change in the future.