Grit and Oyster Limited

Video: Hosting and Building a WordPress Website

This is a series of videos that take you through the basic steps of hosting and building a website using WordPress. It is a useful guide to choosing a hosting solution and describes what you need to do to get a WordPress website set up using ‘one-click-install’ on a shared host (the most common approach for those switching to WordPress for the first time).

The videos are provided by WPMU DEV.

Moving Jetpack’s sharing buttons

This is how to change the default display behaviour of the Jetpack plugin’s sharing buttons feature.

I’ve been using Jetpack to provide sharing buttons to Twitter, Facebook and the like on my personal site and was having an issue with where they were being positioned in a post. Because Jetpack adds the button code onto the end of the post content using a filter, they weren’t playing nicely with the elements in my theme that came after the post content. This was particularly noticeable when display the quote post format as the buttons were getting all wrapped up in a blockquote tag.

So I searched for a solution and eventually ended up with some code that strips out the buttons from the post content and then adds them back into the theme in the place where you want them displayed. Although I’ve not been using it, this code also does the same for Jetpack’s ‘like’ feature.

In your theme’s functions.php file add the following:

function jptweak_remove_share() {
if ( function_exists( 'sharing_display' ) ) remove_filter( 'the_content', 'sharing_display',19 );
if ( function_exists( 'sharing_display' ) ) remove_filter( 'the_excerpt', 'sharing_display',19 );
if ( class_exists( 'Jetpack_Likes' ) ) {
remove_filter( 'the_content', array( Jetpack_Likes::init(), 'post_likes' ), 30, 1 );
}
add_action( 'loop_start', 'jptweak_remove_share' );

Then where you want the sharing and like buttons to be displayed in your template files add this:

if ( function_exists( 'sharing_display' ) ) {
sharing_display( '', true );
}

if ( class_exists( 'Jetpack_Likes' ) ) {
$custom_likes = new Jetpack_Likes;
echo $custom_likes->post_likes( '' );
}

I actually wrapped the last bit of code in its own function and called that in the template for neatness sake.

The various if statements should ensure that everything works smoothly whether or not you have the particular Jetpack feature switched on or not.

The sources for this code are:

 

Welcome to Grit & Oyster

I’m Andy Strange and I build websites with WordPress. Grit & Oyster is my company through which I provide web development services to meet the needs of a range of different individuals and organisations. Grit & Oyster is also where I write about digital media, technology and WordPress.

Coding Email Newsletters

I’ve been having a look at the current best practice for the design and coding standards of HTML email newsletters. I thought I’d turn my key findings into a brief check list to act as a prompt and link to some very useful resources.

The key thing to understand when designing email newsletters is that most email clients take a rather archaic approach to rendering modern web standards. This means that the best advice is to keep it simple and tend towards the lowest common denominator in coding standards.

Use tables for layout

Using DIV tags and CSS for layout in an email is unlikely to work consistently so the best approach is to “code like it’s 1999” and use tables for layout. So nest multiple tables inside each other and set padding and margins using empty table cells.

One tip is to set the width in each table cell and not to rely on setting the width in the table tag.

I like the suggestion of using one container table to set the width and background colour of the newsletter and then nesting within it separate tables for the header, body and footer.

Set a maximum width of 600px

Emails are usually shown in environments where the screen space is limited, often they are displayed in the preview pane of an email program, so the width of the newsletter should be limited. Most of the advice seems to be that 600px works best as a maximum size.

There is the issue of taking account the display in mobile being less than this, and the transfer of some responsive web design techniques into email newsletters to cope with this, but I reckon that if you keep the design simple mobile devices should cope reasonably well.

Even so a good tip is to ensure that your important content is placed on the left side of the email towards the top.

Use pixel units to define your sizes

Widths and font sizes should be defined in pixels. Support for percentages and other units is patchy.

Use inline CSS

Except for layout, as discussed above, do use CSS for styling but again it is best to aim for the lowest common denominator. It may be useful to check the support for the CSS properties your are using.

Always move your CSS inline. Once you’ve completed your design, you will need to go through and add inline styles to your elements – although some email services help you with this.

Also avoid using shorthand for fonts and hex notation. Hex colors such as #ccc should be written in full as #cccccc.

With paragraph alignment you should set the margin inline via CSS for every paragraph in your email. Do not use the float property in CSS instead use the align tag in the HTML.

Take care with the design of links

It seems that some email clients will overwrite your link colours with their defaults. To avoid this you should set a default colour for each link inline then also again set the colour using a redundant span tag inside the a tag.

Users will expect your links to open in a new tab or window so include the target="_blank" attribute in each link.

Be careful with images

Don’t assume that images will be viewed. In many of the major email clients, your images will not be shown by default.

So always include good alt text for every image. Specify height and width for images to ensure that the blank placeholders don’t throw your design off.

Also don’t rely on background images – use blocks of colour instead.

Finally, avoid using PNGs, they don’t get displayed in Lotus Notes, so stick to using use GIF and JPEG.

Alternatives

Include a plain text version of your email and/or a prominent text-based link to a Web version of your newsletter.

Use templates

I think my biggest conclusion from all this is to do yourself a favour and use a pre-existing template. If you are using a third party service to send your newsletters, such as MailChimp and the like, then they will have a range of existing templates for you to use and adapt.

Resources

Sources

Backup Plugins for WordPress

As part of making sure the various installations of WordPress that I look after are working as they should I have been trying out various backup plugins. Everyone knows that taking regular backups is important, but almost everyone either forgets to do it from time to time or doesn’t do it regularly enough. So I was looking for plugins that would automate and simplify the process as much as possible.

The two I’ve chosen to use are:

BackUpWordPress

This is a really simple solution. It requires very little configuration to get up and running and is ideal for the beginner who wants a straightforward method for ensuring that their site is backed up regularly.

I’m using this on single site installations and will include it as the default backup plugin when I set up sites for clients.

BackWPup

For my multi-site installations I needed something a bit more sophisticated with a greater level of configuration. This plugin supports multi-site although in this situation it restricts access to the plugin to the network admin — but this is the kind of set up I was looking for. It has an annoying habit when first installed of adding a button to the WP admin bar, although this can be removed by selecting an option in the settings.

 

Video: Luke Wroblewski – Mobile To The Future

This video is of an excellent presentation by Luke Wroblewski, author of ‘Mobile First’, from An Event Apart.

AEA Video: Luke Wroblewski (author, Mobile First) – Mobile To The Future

His key points are;

  • Mobile is the next form of mass media
  • We are currently in a process of transition from ‘the desktop web’ to ‘the mobile web’
  • So the process web designers and developers should engage in is;
    1. Taking what we know from the desktop web
    2. Adapting and optimising it for mobile
    3. Then finding new ways to do things that only mobile makes possible
  • He looks at how to do this through the examples of making a better login form and improving the online checkout process.
  • He concludes that the shift to mobile forces us to look again at what we are doing and find ways to do it better.