I grew up when tape decks were still a thing. When I was even younger than that, I have memories of using our old turntable in the lounge and putting on whatever record my parents we’re listening to at the time (most often Sgt. Pepper’s Lonely Heart’s Club Band by The Beatles… what an awesome album).
With a tape deck, one had to fast-forward or rewind through all the other songs to arrive at the song of choice. While there were some tape decks that were intelligent enough to know when a song was finished, I don’t remember these catching on too well.
Much like a cassette tape or a record being played through from the start, a Git tree is, at its essence, the same; a record of commits, controlled by a playhead. These commits are “played” onto the tree in a specified order.
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?
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:
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.
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. 🙂
With WordPress’ easy to use nature and user interface, content management of websites is accessible to a vast range of users, from the Bill Gates’ of the world right through to users who discovered this “internet thing” just yesterday. Once the concepts of “what is a content management system?” and “Okay, so this is the ‘backend’ and the website is the ‘frontend'” have been grasped, the usual question arises: “So, why does the backend content look different to the frontend content?”. To this question, we are about to say one thing: “Question… be gone!”
With the introduction of the wp_list_comments() function, WordPress enabled users to easily list comments on the websites without having to manually run a series of loops and queries to get the comments into neat XHTML. This function outputs default code with a selection of options for how this code is structured. Today we’ll be customising how comments are displayed in our WordPress theme, and adding a few extra enhancements to our comments while we’re at it (one of them being the Twitter username we added before). Lets start with the callback, shall we?
We’ve all seen this before when commenting on a blog post we’ve just read. The standard comment form on a WordPress-driven website asks for a user’s name, email address (not published), website address and their comment. What if we could get some other information from the user*, and later integrate that into their comment? Why not get their Twitter username and link back to their Twitter profile as well as to their website? This tutorial will explain how to do just that.
* While this tutorial uses a Twitter username as an example, virtually any additional information supplied by the user can be stored along with their comment (a rating, a selection of their social media profiles, etc).
Wow, part 4 already? This is where the real fun comes in, folks. Today we’ll be opening up some *.phtml and *.xml files, looking at what’s going on under the hood and finding out how the theme files all tie together. Lets get started, shall we?
Before we get to those files…
Folks, before we dive into the files, lets get some concepts down that are crucial to understanding how the Magento theme files play together.
The *.xml files define blocks and regions, which template files get used for which blocks & regions as well as various attributes and parameters for each if these definitions, where applicable.
While the *.xml files tell everything where to be and what to look like, the *.phtml files contain the actual XHTML code required for each block and region.
At the time of writing this tutorial, I have upgraded my Magento installation to Community Edition 1.4. All further tutorials, as well as this one, will be referencing Magento Community Edition 1.4 unless otherwise stated. Please be sure you have the latest version.