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
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?
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.
As WordPress users soon come to realise after setting up their website, a few defaults are loaded in. These defaults include a test “Hello World” post with a comment from Mr. WordPress, a “Sample Page’ with some text and instructions and the “Uncategorized” category, amongst the various default “Links” data and “Blogroll” category.
Having given this some thought, the “Uncategorized” category doesn’t really seem correct in that the term is a category in itself. It’s almost a full paradox to say that a post is “uncategorized”, meanwhile it is in fact in a category.
Today’s question, folks, is; “What does a blog redesign mean to you?”. Lets dive right in, shall we?
For me, a blog redesign means quite a lot. It means the opportunity to hone my skills, experiment with new ideas and techniques and put a fresh coat of paint and a new engine behind my blog. Let me elaborate on the paint and engine for a moment.