I presented at WordCamp Cape Town 2012 yesterday on the topic of “Shifting the WordPress Mindset”. The objective of the presentation was to take a retrospective look at WordPress’ history and evolution, helping everyone (both new and seasoned users) to understand where we as the WordPress community has evolved from, where we are currently within WordPress’ growth and, thus, to enable us to more accurately forecast and understand where WordPress is heading as a platform and to help us, as a community, understand the role that we play and how we can help to evolve WordPress.
In the comments of my post on custom rewrite rules in WordPress, I received a query regarding creating author profile URLs using a rewrite convention of “/profile“.
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?
So… you think you know WordPress, huh? 😉 Well, why not test your skills and see where you rank on the world’s stage? Presenting… the WordPress test!
I blogged the other day about using Smarterer and Code School for online education. As a starting point, take the test below and see how you stack up. You never know… the results may just surprise you. 🙂
Once you’ve done taking the test, sign up over at Smarterer and take a few other tests to verify and enhance your skills set.
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.
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?
At the GROW Academy 2012, Jeff and I have been discussing and showcasing WordPress and what it can do. We’ve been working with the recruits, setting up WordPress.com websites and learning the system.
We thought it’d be a cool idea to showcase what the recruits of 2012 have compiled.
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.