Mail Exchange tip for web developers

We recently had a couple of requests from website owners who were not receiving emails from the contact forms on their website. While there can be a number of reasons why this could happen – the majority of the cases seemed to have a similar cause. It appeared that heir website and email were hosted separately – so while the domain was registered at DomainRegistrar-A along with their emails – the DNS zone A record had been set to point to WebHost-B to serve their website.

Solution: Make sure that in such a scenario the Mail Exchange entry for your hosting account is set to “Remote Mail Exchange”. A snap of how this looks like in a cPanel based host account is shown below – to get to these settings you need to click on the MX Entry icon in the cPanel Home area.

 

WordPress vs Custom CMS

Occasionally we come across a project where we are asked to convert an existing website to use the WordPress CMS. Usually these are websites that are either built with:

  1. HTML
  2. Another well known CMS like Joomla/Drupal
  3. A completely custom CMS that was built by some web agency that uses it to build websites

While there are some scenarios where the last solution makes sense – I think in the majority of  cases this is a poor choice. Such custom solutions make the website owner completely dependent on the web agency who holds the copyright of the code. Moreover, with no oversight and independent review of the source code there is no guarantee of how secure the code is.

Building any additional functionality is again a more costly and time consuming affair. There is a complete dependency on the code owner for implementing additional functionality as there are no plugins/modules to add easily and enhance functionality.

The net result is an increase in the cost of owning/operating the website with hardly any additional benefit. Again I must point out that this is not for all cases – there are scenarios where a custom CMS solution makes more sense. However, that is only for a small minority of websites. My advice is to always check thoroughly when going through the proposals you get for building your website. Anything that locks you to a specific platform/codebase where you become dependent on just one service provider for assistance needs careful attention.

Point of View: Including jQuery in Premium WordPress themes

We usually prefer to build out WordPress themes on my own based on PSD design and accompanied by necessary documentation about the functionality that needs to be built in the website. However, every now and then my company works on a project where we use a theme that the client likes and set it up in the color scheme/settings that the client wants. One constant gripe that we have with such themes is the theme authors removing the standard WordPress jQuery and then add in a specific version of jQuery in their own theme. The poor theme designers then even make  the further mistake of including that jQuery file directly in their theme as shown below:

<script type='text/javascript' src='http://www.yourdomain.com/wp-content/themes/your-premium-theme/js/jquery_1.10.2.js'></script>

This approach is simply poor implementation. It means that you are now going to need rely on using the jQuery ‘$’ handler to write jQuery code and not write it the WP way. So any additional plugin you install that was planning to use the WP jQuery is now going to fail. Moreover, this means including the jQuery file unnecessarily because it is already there in WordPress.

The second slightly better approach is something like below:

	wp_deregister_script('jquery');
	wp_register_script('jquery',           get_bloginfo('template_url').'/js/jquery-1.9.min.js', false);
	wp_enqueue_script('jquery');

While this at least enqueues the script correctly – I fail to see any benefit from this at all. Why remove jQuery only to include your specific version again? Time and again I see this and fail to see the benefit of doing it. I seriously suggest all theme owners to accommodate this little bit of detail in their themes and spare those who bother/need to go through the theme code some anguish.

I would be happy to hear if anyone has a logical reason for doing this.

Handling post registration tasks in WordPress (using Wishlist plugin)

Wishlist is a great plugin and we have built a number of sites using it. One of the common requirements of clients is to request some additional task to be done after a new member is registered. Here is a run down of some of the scenarios and how to handle this.

Option 1: Using the post/pre HTML sections with Wishlist Registration Forms

See the image below to get an idea of where you need to go.

Wishlist - Registration Form

The great thing here is that you can use HTML+Javascript to handle stuff here. So for example if you want to show a popup every time this page is shown to a user (using javascript you can even do it so that the popup is shown AFTER the Submit button is clicked).

However, as you are only limited by HTML/Javascript therefore you can only do stuff that can be handled by the client side.

 

Option 2 – Using WordPress Hooks:

Use the “user_register”  hook to add in your thing along with whatever it is that WordPress has to do. The benefit here is that since this is executed at the server end so you can also do database stuff. For example below is a small bit of code on how you can use this to add in the user registration info to another table in your database that you can use later for other things:

There are numerous applications of this – you can even populate another database with all the info that Wishlist provides for usage in your custom CRM tool. Ofcourse, make sure you have the permission from your users to store their info and use it!

Building membership sites in WordPress

WordPress is a versatile platform that you can use to build almost any type of website. While most websites built are what one calls brochure websites I have always felt it a great platform to build membership websites as well. While there are a number of plugins to build one I think the real fight is actually between two approaches to building it.

Approach 1: Plugin does it all

This approach means finding a plugin that does it all for you. Luckily for most situations there is a plugin that provides most (if not all) of the functionality that you need for your membership site. The usual items like content protection, user management, user levels, payment gateways etc are all built in. As a matter of fact you will probably get  a lot more functionalities that you would never need actually! But since it all comes bundled with the plugin you thing will work for you so you use it and live happily.

Pros:

  • Quick way to get started
  • Cost is less

Cons:

  • Fear the day when you need to build functionality that is not built in that plugin – its going to be a lot more pain than you imagine!
  • Since more functionalities than you want come bundled in with the plugin so in some cases it may slow down your website

Approach 2: Plugin does most of the job – but provides API interface to help you extend/modify

This is a great approach for semi-complex membership sites. Its basically the approach above but allows you at least some protection against the scenario when you may need to build some functionality that is missing in the core plugin.

 Pros:

  • Basic setup cost is still less (although extending the plugin with API can cost more)
  • Quick setup
  • Offers ability to enhance functionality

Cons:

  • API change by plugin owner can cause issues if you are using that API for some functionality

At the end of the day one must choose an approach that is best suited to solving your unique problem. There is no one fit that is good for everyone and if you need to list out your requirements to find a solution that is best suited to your needs – and your budget!

Approaches to redirecting URI in WordPress

Recently we launched a big website of almost 200 pages which was basically a redesigned version of an existing site. One of the many details that we had to ensure was to make sure that old URl’s mapped correctly to the new ones. After building the usual mapping sheets of old URL -> new URL we ended up with 2 main options on how to implement it.

Use plugin
Wordpress offers numerous plugins and we could use on of them and setup all the needed redirects.

Use htaccess
Setup all our redirects using the Redirect directive in .htaccess file

Here is a short comparison of the two approach:
Speed:
Using .htaccess wins there hands down because none of the WP functions would have to be loaded to process the redirect

Ease of use:
Using plugin is definitely better here as end users are quite unlikely to be able to adjust the htaccess file on their own to add in new redirects.

After slightly more thought we decided to use the htaccess approach to implementing the redirects. We realized that:

  • there will be little to none new redirects needed after the site is launched
  • speed could not be sacrificed for ease of use because client would probably not be adding in new redirects after site launch

Having done that – I am interested in knowing how others handle similar issues. So what’s your take on this?

The Wordpress Experts