Tag: WordPress (Page 173 of 220)

Articles, tips, and resources for WordPress-based development.

Adding Post Pagination Attributes in WordPress

January 14, 2014 / Tom / 0 Comments

Be sure to checkout this comment to see why adding title attributes may not be a good idea.

When it comes to working with pagination in WordPress, it’s relatively easy to manage:

There is pagination for index and archive pages.
There is pagination at the single post level.

Each of which usually consists of doing the following:

If you’re on an index or an archive page then you’ll use `get_next_posts_link`, `next_posts_link`, `get_previous_posts_link`, `previous_posts_link`.
If you’re on a single post page, then you’ll use `get_previous_post_link`, `previous_post_link`, `get_next_post_link`, and `next_post_link`.

Enough enough, right?

But there are times in which you may want to add or enhance some of the attributes that are on each of these anchors.

Officially Partnering with Envato and WordPress

January 13, 2014 / Tom / 0 Comments

For the past several years, I’ve contributed a number of articles and premium tutorials to Envato specifically around WordPress.

The content has ranged from topics such as Strategies For Supporting WordPress Plugins up through my current series on Using WordPress For Web Application Development.

To say that I enjoy contributing code and content to WordPress is an understatement.

To that end, I’m proud to announce that I – or, more specifically, Pressware – is officially partnering with Envato and WPTuts+ in 2014.

WordPress Theme Development: Know Your Customer – The Blogger

January 9, 2014 / Tom / 0 Comments

When it comes to WordPress theme development, one or the areas that developers often find themselves wrestling with is just how verbose they should make their code.

For example, we’re often taught and strive from principles such as DRY and KISS, but it’s hard to maintain both of these when building WordPress themes from the ground up.

For example (and as according to the Codex):

At the very minimum, a WordPress Theme consists of two files:

– style.css

– index.php

And for anyone who has done extensive work in WordPress development knows this to be true; however, if you’re getting into theme development – that is, specifically for bloggers, or digital publishers – then you know there’s a wide variety of templates that are also supposed by the WordPress Template Hierarchy.

To name a few:

style.css
rtl.css
editor-style.css
archives.php
author.php
category.php
comments.php
date.php
index.php
single.php
tag.php
…and so many more

But here’s the deal: it’s nearly impossible to embrace DRY while simultaneously trying to implement each of these templates.

Instead, we’re left with having to repeat a variety of code all the while doing so when much of the code could be produced though template parts and conditional logic.

Though I’m sure we all fall somewhere in between on this issue, he’s where I’ve landed with respect to the various themes that I’ve developed over the last couples of years.

WordPress Settings API Wrapper? No Thanks.

January 8, 2014 / Tom / 0 Comments

From time to time, I end up having conversations with other developers about the state of the WordPress Settings API, whether or not there should be wrappers for it, and/or how the current API can be improved.

Each time the conversation begins, it generally stems from the fact that the Settings API is confusing, can be very intimidating to work with the first time, and it’s not as intuitive as some of the other WordPress APIs.

As with anyone who’s worked with WordPress long enough, I have my own opinions about this – and this is certainly not a “patches welcome” post – because this has been already been discussed at great length on Trac.

Instead, this is nothing more than my general stance on the WordPress Settings API, and how I see wrappers fitting into the scope of overall WordPress Development.

How To Add Google Fonts To The WordPress Editor

January 7, 2014 / Tom / 0 Comments

When it comes to building themes in WordPress, one of the nicest things that you can do for your users is to implement a stylesheet specifically for the editor so that they get a true WYSIWYG experience.

To be more specific, that is you can (and should!) add a stylesheet specifically for the WYSIWYG editor in the WordPress Dashboard. This stylesheet is normally called `editor-style.css`, but can actually be called whatever it is that you’d like permitting that you enqueue it properly.

With the popularity of web fonts rising – such as those from Google – you have to take a slightly different approach when implementing them in the context of the editor rather than the typical way of doing so with server side hooks.