WooCommerce has, at the time of writing, passed over 6 million downloads (and several million active installations) on WordPress.org. What many aren’t aware of is, WooCommerce reached the 5 million download mark with only 3 engineers officially working full time on the project (while working on several other projects as well).
Throughout this process, we took away many learnings which we can apply to all future projects. I was fortunate enough to present these findings and learnings to the group at ScaleConf 2015, a popular tech conference here in Cape Town, South Africa.
The previous time I spoke on this stage at Kirstenbosch was at WordCamp Cape Town 2012, my fist large-scale public speaking endeavour. It felt great to be back on this stage!
The WordPress author archives are a great way to create profiles for each author on your WordPress-powered website (in fact, it’s done for you by default). The author archives also make use of the “author.php” template file, if it exists in the theme, allowing for easy additions of custom information about the author, custom content from various areas of your website or links to their social media profiles. The question is, how can we leverage this and still have “/profile” as a part of the URL to each author’s archive screen?
As a developer in an industry where trends and languages grow and evolve at pace, it is virtually impossible to keep track of all the latest happenings. Thus, developers tend to specialise in certain languages or platforms which they watch. For example, while I keep tabs on developments within the PHP and WordPress communities, and I’m aware of what’s happening with CSS3 and HTML5, I may not keep a hawk-eye on CSS3 and HTML5, and certainly don’t know all the latest trends (simply because I don’t use the technology often enough). The converse would apply for a frontend designer. If this is the case, shouldn’t we constantly be striving to increase and better our knowledge in both the areas we are in touch with, as well as those which we aren’t?
I’ve been working with two websites in particular in my quest to further this goal- Code School for learning and Smarterer for testing and validating skills learned. The ways in which I’ve used them may not be obvious though.
There is regular discussion within the WordPress user community on certain common encounters developers have when creating themes and plugins. One such discussion is around post thumbnails 1 and, more specifically, how to specify a default thumbnail. After reading a few discussions around this, I thought I’d share my take on things.
There are a myriad of methods to achieve this. Some developers do conditional checks in their code to see if an entry has an image assigned to it. This is the most common method of applying a default thumbnail. If the entry doesn’t have a thumbnail, display a default image. That’s pretty straight forward. That being said, this method requires extra logic on the frontend of your website, which may not always be clean/necessary.
The Options API in WordPress is one of the many APIs we all use every day when developing with WordPress. A quick use of get_option() is not uncommon. What if you could filter those options? You can.
Adding filters in WordPress is also a common practice. Combining this with the Options API can allow for, as an example, changing an option when in preview mode without committing to the change.
In the “Magazine” template in the Canvas theme by WooThemes, for example, WooTumblog “image” and “video” posts are aware when they are present in the magazine-style grid. This is an example of filtering the Options API.
Every developer approaches their day to day development tasks from a different angle. In addition to this, each developer “designs” their code to suit their own personal preferences and approaches towards specifics in a project. When developers examine code written by other developers, we’re often critical (sometimes hyper-critical) of the code itself, mostly according to our personal preferences. While there is a place for being critical of code, and it should be encouraged, there are a few aspects of this criticism that should be left at the door… namely, the personal preferences.
While we all have our own preferences, it’s important to solidify a few areas when approaching code and to, ultimately, hone the developer’s mindset into certain guidelines. Below are a few thoughts I have running through my mind constantly while developing:
In today’s society, it seems to be a common occurrence to use the word “impossible”. For example, after climbing a mountain, one might say something like; “wow, that was impossible”. No it wasn’t… you just did it. Nowadays we seem to have a tendency to over-exaggerate (pardon the tautology there) and, in many cases, start to believe what we’re saying. Surely, this affects how we approach tasks and situations. Why should it?
Over the past few years (I’d say, since about 2008), I’ve decided to approach tasks day to day from a different angle. How can we say that a task is “impossible” if we haven’t even yet attempted it?
This is quite a common occurrence in web development… developers looking at a task, attempting to analyze it, getting “stuck” at one point and then moving on, deeming it “impossible”. Why does it have to, all of a sudden, be “impossible”, if you haven’t even attempted it yet? Why settle for the “shortcut” when you could just sit down and develop it how you envision it in the first place?
This week, Jeff and I will be presenting at our second GROW Academy Bootcamp session. We’ll be discussing “Website Design & Development” with the recruits, running through WordPress and how to setup a website using WordPress.com or WordPress.org.
The GROW Academy is an initiative to educate and empower the youth of today through technology. The Bootcamp session covers everything from social media and setting up e-mail, all the way through to search engine optimisation and an internet super-user course, for those who wish to continue on with more advanced studies. The GROW website’s “About” page (built on Canvas and Canvas BuddyPress by WooThemes) has a detailed explanation of the initiative and it’s founding partners.
The Transient API in WordPress is one of the many APIs available in the WordPress core that, once used, become invaluable and used on a daily basis. This is a quick guide to getting started with the transients API, when to use it and why.
The Transients API, while similar to the WordPress options API, has the addition of an expiry time. The API is used to store data in the database for a fix amount of time, at which point it is deleted and would need to be re-added, if one requires the data again. The WordPress Codex explains the Transients API as:
…very similar to the Options API but with the added feature of an expiration time, which simplifies the process of using the wp_options database table to store cached information.
From a technical standpoint, transients are also sped up by caching plugins, which store the data in memory, rather than in the database, making for a faster lookup.