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.


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.


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"?>

<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>



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.


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 Magento Enterprise

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 Magento Enterprise

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


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.


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.


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.



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"

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).
<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"

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


How to remove .html from your Magento store’s category URLs

Magento is a great ecommerce platform for search engines out of the box, but there are a few changes we make for most clients launching their stores on Magento Community or Magento Enterprise Editions for search engines.

One of these is quite a small change, but helps your store URLs look a lot neater (as well as being a little shorter for use on social media sites such as Twitter and Facebook!): this is removing the default .html suffix Magento adds to all product and category URLs.

Magento default category and product URL suffixes

Magento’s default setting is to add a .html suffix to the end of your product and category URLs. So, for example, your “Blue T-shirt” product page may look like:


whilst your “T-shirt” category page URL in your Magento store may be something like:


Removing the automatically-applied .html suffix from your store’s URLs would mean:

  • Product URLs look more like www.example.com/blue-tshirt
  • Category URLs look more like www.example.com/tshirts

Removing .html from your Magento store’s product and category URLs

To remove the .html suffix Magento adds to your Magento store’s product and category URLs, log in to your Magento administration panel.

Navigate to the System > Configuration screen. From there, locate the Catalog (Or Catalogue) section in the left-hand menu:

Remove HTML product and category URL suffix in Magento

Under the Search Engine Optimizations (or Search Engine Optimisations) panel here, remove the .html values for the following fields you can see in the screenshot below:

  • Category URL Suffix
  • Product URL Suffix

Once you have done this, click the Save Config button. You may now need to reindex your store to see the new URL structure.

Beware removing the suffix on live Magento stores!

A little warning: if you’re removing the suffix for your products and categories on a live Magento store, you will need to ensure that the old URLs (containing the .html at the end) are redirected properly (ideally using a HTTP 301 permanent redirect) to their new addresses, to prevent any loss in search engine rankings or traffic to your website!

There’s no real benefit for search engines to removing the .html suffix, but it certainly looks neater, and is a lot more “future proof” for your URLs – “Cool URIs don’t change” is good background reading on this!


Disabling checkout with multiple addresses in Magento

As you will no doubt know, Magento is a well built and feature-rich ecommerce platform, but there are some default settings in Magento which we frequently seem to need to alter for our ecommerce clients. One of these is disabling checkout with multiple addresses

By default, Magento Community and Magento Enterprise versions allow customers to checkout from your store with multiple delivery addresses – a useful feature, but one that most store owners do not want enabled!

Disabling checkout with multiple addresses in Magento

To disable multiple address checkout in your Magento store, follow these steps:

Log in to your Magento administration panel and navigate to the System > Configuration option. In the left-hand menu, find the Sales option, and click the Shipping Settings (or Delivery Settings, if you have the British English language pack installed):

Magento - disable checkout with multiple addresses

Expand the Options panel you can now see, and set the Allow Shipping To Multiple Addresses dropdown to No.

Disable multiple checkout addresses in Magento, part 2

Click the Save Config button to save this change (you may potentially need to refresh your caches in System > Cache Management to see the change appear on your store’s frontend).


And, of course, if you need any further help with your Magento store, our Magento consultants are available to help!