Archive of posts with the From the workshop topic
Last week we moved to a new SSL everywhere setup for this website. We were really excited to implement SSL across the board, but nervous about the impact on site performance. Therefore, we made it priority to focus on performance during the transition. Using a CDN (content delivery network) for the new site was a forgone conclusion, as we assumed it would help us speed things up. But, after testing with a few different CDNs, we uncovered some surprising results.
‘Tis the season for a WordPress checklist. Here’s three ideas for optimizing your WordPress website as the year comes to a close.
Imagine you’re looking to build a brand new car from scratch. Sounds pretty intimidating right? Now imagine that one of the best car companies in the world is giving you a free “starter” car. They’ve built the car using years of practice and experience. It’s a fully functioning car, it just doesn’t have any design or colors applied to it. You need to paint it and make some configuration choices.
A WordPress starter theme is exactly like that car. It’s a fully functional WordPress theme that just needs to be styled and configured. When I began designing our first WordPress templates way back in 2008 there wasn’t much to help in the early stages of the process. You usually just started from scratch or converted some HTML to WordPress. That’s all changed with the advent of WordPress starter themes.
Ensuring plugin compatibility within the Single Page Application in Collections was a major challenge. In this post, I will discuss some of the measures we took to increase the probability of plugin compatibility in Collections.
The biggest challenge with building a Backbone.js powered theme for WordPress was handling routing. This post will explore those struggles and outline the solution used in Collections.
As you may have heard, WordPress will be adopting Sass in core with the upcoming WordPress 3.8 release. Aptly dubbed “CSS with superpowers”, Sass brings your CSS to a whole new level. We’re big fans of using Sass in our WordPress templates here at The Theme Foundry, so this is really exciting news for us. Here’s three little known facts about The Theme Foundry and Sass:
If you look at the best practices expounded by most WordPress professionals, you’ll find one related to plugins that goes something like this: when a plugin is deleted, it should remove all traces of itself. No meta data, no extra tables, nothing.
This approach sounds great and it feels downright refreshing to any seasoned WordPress developer. It’s clean, and it respects the existing plugin system, which follows this two-step logic:
- When you deactivate a plugin, nothing is removed, but the plugin is disabled.
- When you delete a plugin, you get a confirmation screen, and then everything is removed.
Easy right? If you’re thinking about maybe using a plugin again later, you should just deactivate it. If you never plan to use it again, you should just delete it.
The big problem: Most WordPress users have no idea about these subtleties, nor are they 100% sure if they’re going to use a plugin again. The even bigger problem: Removing certain plugin data can have disastrous consequences. If someone has used a plugin extensively to set up their site, deletes it for any multitude of reasons, and then re-installs it, everything is gone.
Earlier this summer, we launched Collections, the first WordPress theme that we know of that leverages Backbone.js to add single page application (SPA) experiences (e.g., load new content without a full page refresh) in the theme. Now that the theme is in the wild, I would like to share some of our experiences building the theme through a series of posts about Collections. These posts will specifically emphasize the integration of Backbone.js into the theme.
At the outset, we decided that the SPA features would follow the progressive enhancement philosophy. First and foremost, we wanted to build a solid WordPress theme. Then, we wanted to make it special by adding SPA features on top of it (e.g., fast page loading, transition animations). Fortunately, this approach paid off as we were able to create a WordPress theme that did not need to compromise WordPress standards in order to implement SPA features.
I’ve been on the soapbox over here at The Theme Foundry lately discouraging too much “process” while we’re designing and building a new WordPress theme. What do I mean by process? I’m defining process as the steps you take to get from point A to point B. In a traditional agency environment this might take the form of: client meeting, client pitch, wireframes, Photoshop mock-ups, site delivery.
Working on the new default WordPress theme, Twenty Twelve, has been a very special, exciting, and humbling experience. We got off to a slow start earlier this year, but the pace has picked up significantly since then, and we’re now preparing to move the codebase back into WordPress core.
We have a live demo of Twenty Twelve hosted over on WordPress.com!
Twenty Twelve isn’t finished yet, but all the major styling is complete. The goal was to design a clean, minimal, and responsive theme, with a focus on typography and readability. I think we met that goal and I’m really happy with where we are right now. Take it for a spin and let us know what you think.