Apr
24
2019

How to exclude WordPress custom post types from Yoast’s HTML sitemap

WordPress website header - WP logo

If you have a WordPress website and have looked at improving its search engine friendliness, you will now doubt have come across the Yoast SEO plugin. One of the additional tasks you can do to improve your WordPress website’s SEO is to add a HTML sitemap to list all of the pages, posts and custom post types for search engines to find more readily.

Yoast has a handy guide to creating a HTML sitemap for WordPress already, but you may find that it needs adapting if you don’t want to list certain custom post types in your website’s sitemap.

A good example of this was a recent change for a WordPress SEO audit client of ours, who had a custom post type which recorded information from a quote system, and which was not required to be found by search engines (of course, we also hid the content another way!).

So, here’s our guide to excluding specific custom post types from the Yoast HTML sitemap:

1. Create a sitemap page template for your WordPress theme

The first step is to create a sitemap page template for your WordPress theme. Create a file called page-sitemap.php in your WordPress theme’s directory (e.g., wp-content/themes/your-theme/page-sitemap.php) and add the following:

 

<?php
/* Template name: Sitemap */
get_header();
?>

<h2 id="pages">Pages</h2>
<ul>
<?php
wp_list_pages( array( 'exclude' => '', 'title_li' => '' ) );
?>
</ul>
<?php
foreach( get_post_types( array('public' => true) ) as $post_type ) {
if ( in_array( $post_type, array('post','page','attachment') ) )
continue;
$pt = get_post_type_object( $post_type );
if ( $post_type != 'custom-post-type' ) {
echo '<h2>'.$pt->labels->name.'</h2>';
echo '<ul>';
query_posts('post_type='.$post_type.'&posts_per_page=-1');
while( have_posts() ) {
the_post();
echo '<li><a href="'.get_permalink().'"">'.get_the_title().'</a></li>';
}
echo '</ul>';
}
}
?>

<?php
get_footer();
?>

You will find that you need to adapt the HTML to ensure that the new sitemap page displays like other pages in your WordPress website. Depending on the theme you have enabled, you may not need the get_footer() and get_header() statements in this file.

2. Exclude the custom post types you don’t want appearing in search engines

For each custom post type you don’t want to appear in your HTML sitemap, you can adapt the line above:

<?php
foreach( get_post_types( array('public' => true) ) as $post_type ) {
if ( in_array( $post_type, array('post','page','attachment') ) )
continue;
$pt = get_post_type_object( $post_type );
if ( $post_type != 'custom-post-type' && $post_type != 'another-custom-post-type' ) {
echo '<h2>'.$pt->labels->name.'</h2>';
echo '<ul>';
query_posts('post_type='.$post_type.'&posts_per_page=-1');
while( have_posts() ) {
the_post();
echo '<li><a href="'.get_permalink().'"">'.get_the_title().'</a></li>';
}
echo '</ul>';
}
}
?>

This snippet would ensure that the custom post types with machine names “custom-post-type” and “another-custom-post-type” are omitted from the Yoast HTML sitemap. If you’re not sure that this value is for your post types, try using the get_post_type() function within the loop above.

3. Assign the sitemap page template to a sitemap page

Next, you will need to create a page called “Sitemap” within your WordPress website. Once that’s done, assign your new Sitemap template using the “Page template” dropdown in the Attributes block (usually displayed in the right-hand column of the screen on larger screens).

4. Link to your sitemap page

Finally, now that you’ve created your custom HTML sitemap page for your WordPress website, be sure to link it from the footer of your website. Depending on the WordPress theme you have enabled, you may be able to do this via the Appearance > Menus screen in the backend when logged in as a site administrator, or by editing your theme’s footer.php file.

If you need any help implementing this on your own website, contact us at hello@richardcarterconsultancy.com and talk to us about our WordPress consultancy services.

Nov
9
2018

Updating your WordPress site URL to HTTPS in the database

If you’re a WordPress developer, you’ve probably had the need to update an old website’s URL to use HTTPS recently.

This guide will help you to change your WordPress website’s settings to accommodate the move to HTTPS for your website, including the options in the database and all mentions of your website’s HTTP domain within your existing website’s content.

You’ll need database access to complete these tasks fully please back up your website and database before making any changes (or, even better – use a test version of your website!).

Before following these guides, you’ll need to install an SSL certificate for your domain. LetsEncrypt.org offers free SSL certificates which can renew automatically, depending on your website hosting company’s settings.

Why update your WordPress website to use HTTPs?

If you’ve been running a website for a few years, you may have your website accessible via HTTP – this is a simple protocol which means web traffic between a website visitor and your server isn’t encrypted. Potentially, this means that anyone could, with the right knowledge, intercept this traffic for malicious purposes.

Using HTTPS for access to your website enhances its security by encrypting the traffic between the website’s server and your visitors.

Search engines, such as Google, have recommended for some time now that all websites use HTTPS to provide content to visitorsChrome browser even flags your site with an error message if it doesn’t use HTTPS now.

How to change your WordPress site’s siteurl and homeurl settings in the database

  1. Back up your WordPress website and database before attempting these changes!
  2. To change your WordPress website’s basic URL settings to use HTTPS rather than HTTP, the first step after installing your SSL certificate is to log in to your database management tool (such as phpMyAdmin, used in this tutorial).
  3. Navigate to the options database table. This may be called just options, or something like wp_options, or something_options (if you’re really stuck, look in your WordPress website’s wp-config.php file and see if the database prefix setting is set here using the $table_prefix.
  4. Updating the siteurl setting in your WordPress website database
    Locate the siteurl and homeurl settings
    in this database table. You’ll see they are set to something like http://www.yourwebsite.com – see image above.
  5. Change the values of these settings to https://www.yourwebsite.com. Don’t forget to update the table with your changes.

How to change your WordPress website URL in content

If you’ve done that in WordPress’ wp_options database table for the siteurl and homeurl settings, that won’t be enough to tie off your change to HTTPS entirely – as your existing WordPress pages and posts will still link to other pages and images using your HTTP domain. Follow these steps to update your website URLs in WordPress’ content as well, via the database:

  1. Back up your WordPress website and database before attempting these changes!
  2. Log in to the database tool you use (this guide uses the popular phpMyAdmin application).
  3. Navigate to the wp_posts table (the name of this table may vary depending on your database prefix – please see notes above).
  4. Click the SQL tab to run SQL queries on the database.
  5. Run this SQL query, replacing www.yourwebsite.com with your own website’s domain name. Be sure that wp_posts is the name of your WordPress posts table:
    update wp_posts set post_content = replace(post_content,'http://www.yourwebsite.com','https://www.yourwebsite.com');
    Change your website domain to HTTPS in WordPress content database

Of course, if you’re stuck and would like our help to install your SSL certificate to your WordPress website’s domain and do all of the tidy up we suggest above, get in touch with our WordPress development experts.

Jul
24
2017

Bulk deleting WordPress spam in Contact Form 7 Flamingo plugin

WordPress UK

Have you had problems in your WordPress website with a lot of spam submissions through your Contact Form 7 plugin?

Spam emails aren’t uncommon, but if you use Contact Form 7 out of the box and simply set it to forward the submitted message to you by email, your email program – Gmail, Outlook, etc – will probably do a reasonable job of filtering the spam out for you.

Many WordPress websites rely on Contact Form 7 to add a contact form feature to their website, and the plugin provides a nice interface for building simple (and even more complex) contact forms. We also add the Flamingo plugin for sites using the Contact Form 7 plugin, as this provides a safety net if the website doesn’t send you a message. Flamingo creates an archive of all messages submitted through contact forms on your website, as well as maintaining an “address book” of contacts who have contacted you.

However, Flamingo’s spam filtering isn’t particularly strong, and it’s possible to end up with a few thousand spam messages archived in your website in Flamingo. You can safely ignore these, but you may find that the sheer quantity of the messages means it’s easier to miss genuine enquiries. This is something we’ve looked in to for our own your WordPress website clients, and have provided these notes to help other WordPress users in a similar situation.

How to bulk delete spam from Flamingo / Contact Form 7 forms on your WordPress website

On sites we were asked to look at for clients, many submissions were sent from the (fake) email address “sample@email.tst”, which made it easier to filter the messages, and then delete them.

Flamingo stores the submitted contact form messages in WordPress’ post_content table in the posts table. To select all submitted contact form submissions containing this, you can use the following SQL query:

SELECT * FROM posts WHERE post_content LIKE '%sample@email.tst%';

  1. Note: this will also select other content types (blog posts) that contain the email address. If you’re not familiar with databases, it’s wise not to play around with this, and get your web developer involved – you could potentially delete your entire site’s data!
  2. ‘posts’ is the database table name; if you have used a database table prefix for your WordPress installation, this is likely to be something more list wp_posts

If that selects the content you want to delete, you can now DELETE the posts:

DELETE FROM posts WHERE post_content LIKE '%sample@email.tst%';

Note: this permanently deletes the content from your WordPress website’s database, so it’s wise to back your database up before running this!

If you would like to discuss our WordPress training courses, or WordPress consultancy project with us, please get in touch.

Jun
19
2017

Disabling redirect to checkout in Magento after adding a product

Here’s another Magento guide for quite a common query: how to disable the redirect to the checkout after adding a product to the cart in Magento.

Whilst this is a handy feature – enabled by default – for stores where customers aren’t likely to browse, it can be frustrating for customers who want to continue shopping after adding an item to your store’s cart. Luckily, there’s a setting to disable this feature in Magento’s administration panel!

Disabling cart redirect after add to cart in Magento

  1. Log in to your Magento administration account
  2. Navigate to the System > Configuration screen, with Default Config, or the desired store view in Magento you want to change this setting for, set as the Current Configuration Scope (top-left of the screen)
  3. From the left-hand column, find the “Sales” heading, and click the “Checkout” option
    Magento - disable add to cart redirect to checkout
  4. Under the Shopping Cart options that now appear, find the After Adding a Product Redirect to Shopping Cart option (this should currently be set to “Yes”):
    Change setting to disable add to cart redirect in Magento 1.9
  5. Change this option to “No”, and click the Save Config button at the top-right of your screen.

That’s it – adding a product to your cart in Magento should no longer redirect you to the cart. 

Troubleshooting add to cart redirect

If you’re still being redirected to Magento’s cart after changing the setting, take a look at these troubleshooting tips:

  1. Hard-refresh your browser (Ctrl + F5 on Windows; Cmd + Shift + R on Mac)
  2. Clear your Magento store’s caches (System > Cache Management in the Magento admin panel)
  3. Check that you’ve changed the setting at the right configuration scope (the dropdown at the top-left of the configuration screen – if you’ve changed the setting in the Default Config scope, but the setting is overwritten at a lower scope (e.g., for an individual store view), it won’t take effect:
    Changing configuration scope in Magento 1

If you’d like any further help with your Magento store, you can talk to us about Magento consultancy services – we’re based in the UK and love Magento! We also offer comprehensive Magento training courses for clients across the UK.

Mar
11
2017

Adding a Google Font to your Magento theme using local.xml layout file

A fairly common task for building custom Magento themes these days is to use a web font. Whilst there are plenty of services which offer hosted web fonts for use on Magento and other website platforms, Google Fonts has a reasonable library of fonts available for us on the web.

This guide will show you how to add your own Google Font to your Magento 1.9 theme the proper way – using your theme’s local.xml file to add the request to load the font to your Magento store’s <head> element.

Add your Google Font as a block in local.xml

Your first step is to open your theme’s local.xml file; this should be present in the app/design/frontend/[package]/[theme]/layout directory, where [package] and [theme] represent the package your theme belongs to, and its name, respectively. The local.xml file is there to overwrite anything you want to change from your parent Magento theme (typically, your parent Magento theme would be rwd, Magento’s default responsive theme).

Once there, locate the <reference name=”head”> line within the <default> handle (this means it applies to all pages in your Magento store); this contains all of the things we want to do in your Magento theme’s <head> element. The highlighted code below (in bold) shows the <block> element which is added to add a link to an external CSS file in Magento 1.9 – which is essentially what all you need to embed a Google Font in to your own store:

<?xml version="1.0"?>
<layout>

<default>
<reference name="head">
<block type="core/text" name="google.fonts.opensans">
<action method="setText">
<text><![CDATA[<link href="https://fonts.googleapis.com/css?family=Open+Sans" type="text/css" rel="stylesheet" />]]></text>
</action>

</block>

</reference>

It’s worth being wary of page load times with fonts, so it pays to be careful in how many Google web fonts you add to your Magento store, as well as the weights (see Google Fonts itself for information on that).

And if you need more pointers for Magento’s local.xml layout file, take a look at the boilerplate local.xml on Maksold’s Github account, or you can contact us about our Magento consultancy services.

Dec
7
2016

An overview of Magento 1.x security patches

Magento is a great ecommerce platform, and like any open source platform, it requires a degree of maintenance to keep it running smoothly and securely.

Magento themselves publish a list of the patches on their website; this article explores what a Magento security patch is, and a brief overview of what issue each patch resolves.

What is a Magento security patch?

A Magento security patch addresses one or more known security issues with Magento. Sometimes, these are exploits which have made their way on the real-life, production Magento websites. Other patches are precautionary, fixing a potential loophole which could be exploited in the future, but which isn’t known to have been used on a production Magento store.

After their initial release, Magento security patches are packaged with the next update to Magento software.

A brief overview of all Magento 1.x security patches

Below is a list of all current Magento 1.x security patches (as of December 2016; in progress).

Patch name
(Date released)
Description Comments
SUPEE-8788 (October 2016) Addresses issues with Zend framework (which Magento is based on), payment vulnerabilities. 8788 also addresses a potential issue with user sessions, ensuring they are invalidated after a user logs out.

This patch is included in Magento Community Edition 1.9.3 Magento Enterprise 1.14.3.

SUPEE-7405 (February 2016) SUPEE-7405 addresses issues with XSS (cross-site scripting) vulnerabilities in customer registration, customer order comments, and removes the ability to upload executable code via the Magento administration panel media browser tool, as well as other security issues.

This patch is included in Magento Community Edition 1.9.2.4 Magento Enterprise 1.14.2.4.

The first version of the patch introduced issues with Magento’s SOAP API and was not backwards compatible with PHP 5.3 due to short array syntax use. Version 1.1 of the patch addresses these and other issues in SUPEE-7405 v1.0.
SUPEE-6788 (October 2015) The SUPEE-6788 Magento patch addresses issues with the routing of Magento modules in the administration panel, as well as SQL injection, and introducing a whitelist for CMS static blocks to prevent unauthorised access to private information. It also addresses a potential exploit with the “custom option” file type, and secures password resets (which may require you to update your theme’s forms for password reset and account registration). Finally, it addresses an XSS issue.

This patch is included in Magento Community Edition 1.9.2.2 Magento Enterprise 1.14.2.2.

SUPEE-6788 can break backwards compatibility with customisations to your Magento store; see Magento’s tech docs for more information.

Need help with Magento patches?

If you’re struggling with applying Magento security patches, our experienced Magento consultants can help you on an ad-hoc or retained monthly Magento support package

Sep
26
2016

Best practice tips for Magento theme development

seasoned Magento consultants, one of the things we see often is poorly implemented Magento themes.

After running a Magento training course for web developers recently, a discussion with them lead to creating a list of best practices for Magento 1.x theme development.

So, here are a list of tips for newcomers to Magento and Magento theming:

1. Keep your text translatable

One of the many features of Magento is support for multilingual store fronts to cater for different languages your customers may speak. Badly built Magento themes can break this functionality, but it’s easy to maintain it in your own themes.

To ensure text used within your Magento templates can be translated, simply wrap it within the translate function:

<button><?php echo __('Click me'); ?></button>

Product descriptions and page contents are still controlled via the Magento administration panel.

2. Let Magento help you!

Magento’s templates are pretty extensive, and it can be hard to know which template you need to edit to change a specific block within Magento. Luckily, Magento has tools available for this! Log in to your store’s administration panel and navigate to:

System > Configuration > Developer > Template Path Hints

You will then need to change your Configuration Scope from the default scope to see the options to enable this tool. Once enabled, you should see your Magento theme is highlighted by red borders and boxes telling you which directories each template is being pulled from – knowing this makes them much easier to overwrite!

Magento theme development - Template path hints example

You can restrict this via IP address, so that only you are able to see these (though you shouldn’t use them on a production Magento website!).

3. Use Magento’s local.xml

When overwriting layout XML from a parent theme in your child Magento theme (Magento 1.9+), don’t overwrite an entire file: make the changes in your Magento theme’s local.xml file – e.g. /app/design/­frontend/your-custom-theme/­default/layout/­local.xml.

This means future updates to the parent theme are less likely to break your Magento theme, and that you’re only overwriting what you need to overwrite (see #5).

4. Never edit core Magento themes

If you want to make the use of a core Magento theme as your parent theme, that’s fine (many themes on Magento 1.9 are based on the rwd theme) – but never edit core Magento themes!

An update will likely overwrite core Magento themes in the future, and you’ll lose customisations you’ve made; make the changes in your custom child theme, and you will avoid this problem.

Plus, it upsets Ben Marks.

5. Only overwrite what you need

A very common mistake we see in Magento themes is that all of the base theme’s files are copied in to the child theme. This negates the benefits of using child themes, as when updates occur to the parent theme, unchanged templates are still being overwritten at the child theme level, potentially leaving a security hole behind or breaking functionality, and definitely creating more work for the Magento developer!

It’s best practice for your Magento theme to copy only the template and other files you specifically want to overwrite in to the child theme. For more information on parent/child themes in Magento 1, see this article by the brilliant Alan Storm.

Another great resource for other Magento tips is magentotherightway.com.

Sep
2
2016

Changing the default uploads directory in WordPress

By default, all media – images, files, etc – uploaded in to a WordPress website in the wp-content/uploads directory.

There are times that this isn’t particularly helpful – for example, if you want to maintain legacy URLs for images from an old website you have migrated to WordPress, you’ll need to change the value.  This is our brief guide for changing the default uploads directory in WordPress.

WordPress 3.4 and under allowed you to change the file uploads path in the WordPress administration screen under the Settings panel, but this feature was removed in WordPress 3.5 and above.

WordPress’ default media uploads directory

By default, files uploaded via WordPress’ “insert media” tool (see screenshot below, as it appears in WordPress 4.6.x onwards) are saved on the server in the wp-content/uploads directory, sorted in to sub-directories ordered by year and month.

For example, if you upload a file called image.jpg to WordPress in September 2016, by default this file would be written to the wp-content/uploads/2016/09 directory on the server.

WordPress' default file upload in 4.6

As mentioned above, this may not be ideal for your WordPress website, and this default can be changed.

Changing WordPress default uploads directory

Thankfully, changing WordPress’ default file uploads directory is relatively simple, once you know how.

Open your WordPress installation’s wp-config.php file, found in the root directory of your website. Find the following declaration (if it exists in your wp-config.php file), or add this line to the bottom of your file if it doesn’t exist:

define('UPLOADS', 'wp-content/media');

The above change would save uploaded files in WordPress’ wp-content/media directory. If you want to move the file uploads to the root directory of the website (e.g., so your files are accessible via http://www.example.com/uploads/), use the following snippet in your wp-config.php file:

define('UPLOADS', 'uploads');

Note! You will need to ensure this directory has the correct permissions for WordPress to be able to use the new file uploads path you have just set. It’s also worth ensuring that final semi-colon – ; – is present at the end of the line, as missing this will likely cause you some issues!

Disabling WordPress from storing uploaded files by year and date

Of course, you can also disable WordPress’ default behaviour of organising file uploads in to year/month directories in the Settings > Media page.

We hope this post is helpful for WordPress users and developers alike! If you need further help with your website, please do consider our WordPress consultancy services.

Aug
18
2016

Great resources for Magento developers

There are many great resources for Magento developers online, as well as a lot of places to get “bad” information on Magento development. This is a list of everything we’ve found helpful in our many years as Magento developers.

Over the years, we’ve made use of many Magento resources for developers, and thought it’d be useful to share our favourites with other Magento developers! The list contains useful articles and resources for Magento frontend and backend developers, split in to Magento 1 and Magento 2.

Brilliant Magento developer resources

Great Magento 2 developer resources

So, that’s it – our work-in-progress list of Magento development resources which we’ve found useful over the previous years.

 

May
27
2016

Showing Magento’s search engine below Google’s sitelinks

This is a guide to implementing the necessary markup to tell Google about your own Magento store’s search engine, which can then be used in some listings when users are searching for terms related to your website.

Keep reading to learn how to show your Magento website’s search engine in the Google Search Engine Results Page (SERP). For more information about Google Sitelinks, see this documentation.

When search appears in Google sitelinks

Even when implemented correctly, the Google sitelinks search box will not appear for all search terms. Typically, the sitelinks and search form will only appear when a user searches Google for a term related to your business or organisation.

For example, if your company is called Widgets Ltd, and a user searches for “Widgets Ltd”, the sitelinks search form may appear. If a user searches for the more generic term “widgets”, it’s unlikely to appear.

See the example below – Mothercare.ie, a Magento Enterprise store, shows sitelinks for key product categories below the store’s main listing. You can also see that Google adds another search field below the primary listing, labelled “results from mothercare.ie”:

Show Magento's search in Google Sitelinks

The code snippet is fairly simple:

<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "WebSite",
"url": "https://www.example.com/",
"potentialAction": {
"@type": "SearchAction",
"target": "https://www.example.com/catalogsearch/result/?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}
</script>

This tells Google that your website, www.example.com, allows searches to be performed by passing a key word or key phrase to https://www.example.com/catalogsearch/result/?q=.

How to get Google to show your Magento store’s search field in results pages

Showing Magento’s search engine below Google’s sitelinks involves adding a small snippet to the <head> element of your Magento store. This only needs to be on the homepage, so whilst you could amend your theme’s layout files to add the snippet, this guide will add it using Magento’s CMS tools.

  1. Log in to your Magento administration panel
  2. Navigate to CMS > Pages
  3. Edit your store’s homepage
  4. Open the Design tab in the left-hand column
  5. In the Layout Update XML field, enter the code snippet below
  6. Click the Save Page button
  7. (You may need to clear your store’s caches via System > Cache Management).
<![CDATA[
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "WebSite",
"url": "https://www.example.com/",
"potentialAction": {
"@type": "SearchAction",
"target": "https://www.example.com/catalogsearch/result/?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}
</script>
]]>

Don’t forget to swap out www.example.com for your own website’s domain name!