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.Read more
Archive of posts with the From the workshop topic
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.Read more
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 Sass 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.Read more
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.Read more
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.Read more
As you may have read earlier, I’m currently working on the the new WordPress default theme, Twenty Twelve. One of the early Twenty Twelve discussions was about typography. I felt it was important we use a web font. Not only would a web font look great, it would also show WordPress is pushing forward to adopt new web development technologies. The font would obviously be open source, so we had 2 options:
Use the free open-source Google Web Fonts directory to load the font directly through Google’s external API.
Package it with the theme and use CSS to load the font. We would have to ensure a GPLv2 compatible license in this case (more on this later).
In the end, it was important to choose a great looking font with extensive language support. Whether we included it in the theme or not was a secondary concern.Read more
As I was working on our latest theme, I came across a situation where I needed to filter out posts that had a specific meta key that either never was set (NULL) or was false. I started down the route of using the
meta_query argument to WP_Query.
At the end of last year Matt and Lance contacted me and asked if I’d be interested in designing Twenty Twelve, the default WordPress theme for this year. I was of course honored and excited, and after some discussion about expectations and details, we started the project in relative secrecy.
After a fast start, Twenty Twelve development slowed to a crawl in February (which was my fault) and in March we decided including it in WordPress 3.4 wasn’t a good idea. Since then we’ve re-focused, moved the Twenty Twelve repository to Github, and established a regular work schedule to ensure it’s ready for WordPress 3.5.Read more