Customise WordPress RSS Feeds

Here are the steps to modify or create your own WordPress RSS Feed without modifying the Core files.

  1. Copy /wp-includes/feed-rss2.php to your theme folder
  2. Edit it and make whatever changes you desire
  3. In your theme’s functions.php file, add the following function

 

Hide or change name of Publish button for Custom Post Type

Lets assume you are creating a Custom Post Type for publishing events. You do not wish to show the publish button to your editors until all the event fields are properly filled and validated.

This can be achieved using below code

 

Selectively exclude pages from being cached in W3 Total Cache

Selectively exclude pages from being cached in W3 Total Cache

screen-shot-2016-06-08-at-4-37-21-pm-768x243

You may want to exclude some dynamic pages from being cached in W3 Total cache. To exclude a particular page from caching, W3 Total cache just needs below line of code on that page before the html  start tag

For this code to appear on such pages all you need to do is to create some custom field e.g. nocache

Just add this custom field to the post/page you want to exclude from caching and set the value to 1

In your header.php add below lines above the html tag

Other w3total cache options

  1. Disable database caching => DONOTCACHEDB
  2. Disable minify => DONOTMINIFY
  3. Disable CDN (Content Delivery Network) => DONOTCDN
  4. Disable Object Caching => DONOTCACHCEOBJECT

Points to consider before installing a new wordpress plugin

Installing a new plugin is very easy in wordpress. All you need to do is to search for your plugin, select it, install and activate. If you do not find it suitable to your needs, just deactivate, delete it and move on.

However not many people realise what a plugin does in the background once it gets activated and assume that once a plugin is deleted its all gone which is really not true in most cases. A deleted plugin mostly leaves quite a few traces in your system. Depending upon the plugin these traces can severely affect the performance of your system if you try too many plugins without checking what it does in the background

Many plugin developers do not follow WordPress coding standards. They do not provide an unintall function for the plugin. This means you need to manually clean up all the traces of the plugin after it is deactivated and deleted.

I am currently not experiencing any performance issue with my site

Although your site may be performing well currently, if you do not consider cleaning your system then soon a badly developed plugin can cause wordpress queries to slow down. Once the system starts slowing down it will be difficult to clean the system as by then you won’t be sure which tables are currently in use and which records in the database are unnecessary as it is quite easy to forget which plugins you tried in the past.

e.g. Some plugins developers are not quite efficient in their coding. They save each setting as a separate row in the wp_options table. Ideally all settings could be stored in a single row if setting are stored in an array. I remember a plugin which created 300 rows in the wp_options table to store settings with autoload set to yes which means the rows get selected on every Dashboard page load.

WordPress gets all the rows on each Dashboard page. If the table size grows bigger it will definately slow down the sytem.

Points to consider before installing a new wordpress plugin

First of all Install, activate and configure the plugin on your test environment or localhost

Check the source code both on Dashboard and your website: Check how many CSS and JS calls the plugin is making, whether it adds any inline CSS and other extra code.

Some plugins developers do this quite efficiently. They provide a settings screen and ask you on which Posts Types you want the plugin to run which means plugin related CSS or JS files only appear on those Post Types.

Are the queries optimised: Check if your new plugin is executing any queries which can slow down your system. To monitor such slow queries make use of Query Monitor plugin. Here are some examples how to make use of Query Monitor plugin to increase performance of your WordPress site and to detect slow queries hampering your system.

Does it create new tables: Check if the plugin creates any new tables. If yes make a note of those tables somewhere. Check what data it adds to those tables and if the tables are really necessary or the plugin developer could have used WordPress inbuit tables. This will give you an idea if the plugin developer has thought about optimising the code. Additional tables are ok but to use wordpress inbuilt tables would be ideal as wordpress has already optimised queries for those tables.

If you have a multisite, most probably the plugin would create extra tables for all your sites.

What does it add to wp_options table: Some plugin authors add _tansient records to this table. e.g. a plugin used for related links would add related links for each post in this table. So for 20k posts there would be 20k records in this table. These records get selected on every dashboard page load. This would slow down the dashboard to a great extent.

wp_options table is generally used to store plugin settings. Some plugin authors store each setting in a separate row. Ideally all settings should be stored in a single row in an arrow form.

Does the plugin provide an uninstall function: A good plugin developer provides an uninstall function which deletes the tables, capabilities, entries in wp_option table etc once the plugin is deactivated.

 

WordPress Hooks, filters and actions

WordPress Hooks, filters and actions

2572289473_f24c6561fc_z

What are wordpress Hooks

WordPress Hooks provide the ability to enhance, modify or customise a wordpress functionality by writing your own code without modifying the wordpress core code.

A WordPress Hook code can either be written directly in your themes (preferably child theme’s) functions.php or by creating your own plugin (recommended way)

Types of hooks

There are 2 types of wordpress hooks

  1. action hooks: These hooks can also be called as trigger hooks as they gets triggered based on a certain action/event. e.g. when a user registers on your site an action hook can be set up to geocode the user address and add the latitude longitude to the user_meta table.
  2. filter hooks: This hook allows to enhance or modify wordpress functionality or data e.g. it allows to use a custom template for certain post types, allows to use your custom page for lost password functionality, filter user data before displaying on browser or storing in the database.

Examples of hooks

user_register action hook: This action hook allows you to access data for a new user immediately after they are added to the database. The user id is passed to hook as an argument.

template_include filter hook: Allows to select custom template for your custom post types

 

Reference

List of action hooks

List of filter hooks

 

Creating Custom hooks for your own plugin

Creating your own custom hooks is also possible so that other developers can extend and modify it, without having to fork it.

Read more on how to create custom hooks

 

 

Difference between wp_print_scripts, wp_enqueue_scripts and wp_register_scripts

I had lot of confusion earlier while enqueuing or dequeuing a script in wordpress. I was not sure which function to use and would just keep on using various functions on a trail and error basis.

Hope below points would help to clarify atleast a few things with regards to when we should use a particular function

wp_register_scripts

This just registers the script but does not actually queue it for execution

wp_enqueue_scripts

This is used to enqueue a script which is required to be executed on our template. A script can be enqueued without registering it i.e. without using wp_register_scripts.

wp_print_scripts

This is an action which prints/outputs/shows up the scripts on our template for execution

When to use wp_register_script

You may be wondering why would I use wp_register_scripts and why not just directly use wp_enqueue_scripts

The answer to that is if you are developing a custom plugin and wish to execute a script only on certain pages then it helps to just register the script and then programatically enqueue it on the required pages.