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. Continue reading
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 the last week, Jeff and I presented a workshop at the GROW Academy’s BootCamp, discussing website design & development and focussing on using WordPress to do this. For both our introductory session on Monday and our more in-depth theory discussion on Wednesday, we needed a slideshow presentation to work through the various areas of website construction. Lets zoom back to Monday morning… I needed some slides… in a hurry.
As many of you know, I like to keep my computer as clean as possible. If I don’t use an application, it gets removed and everything that could go onto the machine is thought through before it’s loaded on. Thus, I don’t have PowerPoint, Keynote or anything of the sort… because I don’t need it. Suddenly, I did. Enter SlideRocket.
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.
A few weeks ago, I blogged about styling the tinyMCE editor in WordPress to resemble your WordPress theme’s content area. On this post, I received a comment from LA, asking if it’s possible to style the tinyMCE editor for specific posts or post templates. Folks, it’s WordPress… anything’s possible!
With my mission at hand, I set to work. I’d been thinking about this for a while after writing the initial blog post and am please to say that I have found a solution. Please be sure you’ve read through the initial blog post, as the main points are covered over there.
There are a few steps we need to go through here. They’re pretty straight forward, so bear with me. 🙂
The WordPress plugin API is vast and powerful. It allows developers to essentially hook code into almost any area of the WordPress system without modifying the core files at all. It also allows for the creation of standalone plugins that work within the WordPress system but do not hook into the core modules.
Over the last few weeks, WordPress plugin development has become one of my favourite things to do. I find it exciting to be able to create functionality, incorporate it seemlessly into the WordPress system and see it work smoothly with the other modules. While plugin development for WordPress is incredibly powerful, it also carries with it a few areas where people commonly stumble over and potentially lose interest in their code… which could be the next big thing. Here are a few guidelines I’ve picked up in order to step over the stumbling blocks.