Remove extra RSS feeds in WordPress

Posted on 16.05.2013 by neill

Here’s a WordPress snippet to remove RSS feeds for comments while keeping the main one available.

RSS is super nifty. It’s a great way to keep on top of breaking news and articles from your favourite blogs and/or aggregators (I’ve got over 100 subscriptions in my feedly reader).

So it’s a wonder then that WordPress offers RSS feeds for comments on all your posts. I presume there’s a group of people who really like to track conversations, but in my experience, it’s the minority. This functionality should really be an additional (and not core) part of WordPress. If you want to prevent your site serving pointless additional RSS feeds, you’ll need to remove them from wp_head.

Removing them, however, is a two-step process. Add the following to your functions.php file:

  // First, we remove all the RSS feed links from wp_head using remove_action
  remove_action( 'wp_head','feed_links', 2 );
  remove_action( 'wp_head','feed_links_extra', 3 );
  // We then need to reinsert the main RSS feed by using add_action to call our function
  add_action( 'wp_head', 'reinsert_rss_feed', 1 );
  // This function will reinsert the main RSS feed *after* the others have been removed
  function reinsert_rss_feed() {
      echo '<link rel="alternate" type="application/rss+xml" title="' . get_bloginfo('sitename') . ' &raquo; RSS Feed" href="' . get_bloginfo('rss2_url') . '" />';
  }
  //

// First, we remove all the RSS feed links from wp_head using remove_action

remove_action( 'wp_head','feed_links', 2 );

remove_action( 'wp_head','feed_links_extra', 3 );

// We then need to reinsert the main RSS feed by using add_action to call our function

add_action( 'wp_head', 'reinsert_rss_feed', 1 );

// This function will reinsert the main RSS feed *after* the others have been removed

function reinsert_rss_feed() {

echo '<link rel="alternate" type="application/rss+xml" title="' . get_bloginfo('sitename') . ' » RSS Feed" href="' . get_bloginfo('rss2_url') . '" />';

}

And that’s it. The first two actions strip the RSS using remove_action with a high priority. The final add_action call tells WordPress to load our function when processing wp_head. This will go through and reinsert the main feed, leaving the comment feed out.

Congratulations! Your post conversations are now untrackable.

WordPress: Add page slug to body class (including parents!)

Posted on 09.05.2013 by neill

Add something

Are you using WordPress as a CMS? Do you want to style pages with CSS logically? You might want to try this.

By default, WordPress will inject the page and its ID into the body class. That’s great if you’re only running a single install, or if you really really don’t care what your CSS looks like.

Let’s face it – you care. Otherwise, you wouldn’t be here. Here’s a snippet that will inject the current page’s slug and all slugs of its parents into the body class of your HTML.

Add this to functions.php

function mytheme_add_body_class($classes) {
    global $post;
    // You can modify this check so it will run on every post type
    if (is_page()) {
        global $post;
        // If we *do* have an ancestors list, process it
        // http://codex.wordpress.org/Function_Reference/get_post_ancestors
        if ($parents = get_post_ancestors($post->ID)) {
            foreach ((array)$parents as $parent) {
                // As the array contains IDs only, we need to get each page
                if ($page = get_page($parent)) {
                    // Add the current ancestor to the body class array
                    $classes[] = "{$page->post_type}-{$page->post_name}";
                }
            }
        }
        // Add the current page to our body class array
        $classes[] = "{$post->post_type}-{$post->post_name}";
    }
    return $classes;
}
// Add a filter for WP
add_filter('body_class', 'mytheme_add_body_class');

function mytheme_add_body_class($classes) {

global $post;

// You can modify this check so it will run on every post type

if (is_page()) {

global $post;

// If we *do* have an ancestors list, process it

// http://codex.wordpress.org/Function_Reference/get_post_ancestors

if ($parents = get_post_ancestors($post->ID)) {

foreach ((array)$parents as $parent) {

// As the array contains IDs only, we need to get each page

if ($page = get_page($parent)) {

// Add the current ancestor to the body class array

$classes[] = "{$page->post_type}-{$page->post_name}";

}

// Add the current page to our body class array

$classes[] = "{$post->post_type}-{$post->post_name}";

}

return $classes;

}

// Add a filter for WP

add_filter('body_class', 'mytheme_add_body_class');

And that’s it! You can then start chaining together page classes to target little overrides that your clients are probably hassling you about.

Help! register_activation_hook isn’t working!

Posted on 17.01.2013 by neill

Add something

If you’re developing a plugin, chances are you’ve been caught out by the WordPress activation/deactivation hooks.

I’ve been working on an Instagram plugin for WordPress, and in doing so have needed to use the functions register_activation_hook and register_deactivation_hook.

However, I – like many others, it seems – can’t get the hooked functions to execute. They simply don’t fire. To illustrate the problem, here’s an example from the code:

define('MY_INSTAGRAM_PLUGIN_PATH', plugin_dir_path(__FILE__));
require_once MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram-widget.php';
$my_instagram = new My_Instagram();
class My_Instagram {
    /**
     * Standard constructor to initalise hooks and options
     *
     * @return void
     */
    public function __construct()
    {
        register_activation_hook(__FILE__, array($this, 'install'));
        register_deactivation_hook(__FILE__, array($this, 'uninstall'));
    }
    /**
     * Set up the table and options
     *
     * @return void
     */
    public function install()
    {
        ...
    }
    /**
     * Drop the table and options associated with the plugin
     *
     * @return void
     */
    public function uninstall()
    {
        ...
    }
}

define('MY_INSTAGRAM_PLUGIN_PATH', plugin_dir_path(__FILE__));

require_once MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram-widget.php';

$my_instagram = new My_Instagram();

class My_Instagram {

/**

* Standard constructor to initalise hooks and options

* @return void

public function __construct()

{

register_activation_hook(__FILE__, array($this, 'install'));

register_deactivation_hook(__FILE__, array($this, 'uninstall'));

}

/**

* Set up the table and options

* @return void

public function install()

{

...

}

/**

* Drop the table and options associated with the plugin

* @return void

public function uninstall()

{

...

}

I would fully expect the system to execute the functions hooked within the constructor. Had that been the case, I wouldn’t have lost a day debugging a non-existant problem.

Finding a solution

Of course, everyone’s setup is different. There were many suggestions for fixing the problem. For the sake of usefulness, here’s the other major suggestion:

Your global variables aren’t global

If (like me), your plugin is a global, you actually need to explicitly define it as such with the global keyword. For example, the snippet

$my_instagram = new My_Instagram();

1	$my_instagram = new My_Instagram();

should instead by written this way:

global $my_instagram;
$my_instagram = new My_Instagram();

1 2	global $my_instagram; $my_instagram = new My_Instagram();

Why? Well, for this, we need to consider how the plugin has its code loaded. After installation, your plugin has its code included “normally” with standard includes. This creates the global scope that you would expect. However, when you register a function with register_(de)activation_hook, it is called from within another function’s scope, effectively hiding your non-explicit globals.

Confused? Consider the plugin example from earlier. The variable $my_instagram is declared in the global scope, with global visibility. When your code executes, your plugin is included at the same scope, meaning you will have access to the variable (as they share the same suitably-high scope). Due to the way the hook/filter system in WordPress works, your activation/deactivation hooks are executed within a localised (not global) scope.

Screen beans – the only thing worse than scope.

This scope-confusion applies to all functions created using create_function, or (in our specific example), functions called with call_user_func (and call_user_func_array). These functions have their own scope and are thus shielded from the cheap-and-nasty pile of implicit “globals” that haven’t been properly declared as such.

You can find a suitably more technical (and probably correct) write-up at the WordPress Codex page for register_activation_hook.

tl;dr: Explicitly declare your globals if you want them to work everywhere.

Ok, that’s great, but what’s the answer?

After having accidentally (and rather unwillingly) been given a very rough refresher on scope, I found that this was not my problem at all. Even running proxy functions (which eliminates scope issues) failed to call the functions specified in the hook.

After much trial and error (and I mean much), I found that the paths within register_(de)activation_hook were not matching the path found in plugin_dir_path. In fact, __FILE__ was returning a completely different path.

The problem? I had symlinked the theme directory in my install, meaning that __FILE__ returned a different path to plugin_dir_path. This is especially important, as the file path specified by the first parameter of register_(de)activation_hook is included before the function specified by the second parameter is called. So, if the path in the first parameter is wrong, you probably aren’t going to be executing many functions today.

The Fix

This is always my favourite part. To fix the symlinking problem, you just have to be very specific when you’re asking WordPress to execute a hook for you.

Fixing the first example, we get:

define('MY_INSTAGRAM_PLUGIN_PATH', WP_PLUGIN_DIR . '/my-instagram/');
require_once MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram-widget.php';
global $my_instagram;
$my_instagram = new My_Instagram();
class My_Instagram {
    /**
     * Standard constructor to initalise hooks and options
     *
     * @return void
     */
    public function __construct()
    {
        register_activation_hook(MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram.php', array($this, 'install'));
        register_deactivation_hook(MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram.php', array($this, 'uninstall'));
    }
    /**
     * Set up the table and options
     *
     * @return void
     */
    public function install()
    {
        ...
    }
    /**
     * Drop the table and options associated with the plugin
     *
     * @return void
     */
    public function uninstall()
    {
        ...
    }
}

define('MY_INSTAGRAM_PLUGIN_PATH', WP_PLUGIN_DIR . '/my-instagram/');

require_once MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram-widget.php';

global $my_instagram;

$my_instagram = new My_Instagram();

class My_Instagram {

/**

* Standard constructor to initalise hooks and options

* @return void

public function __construct()

{

register_activation_hook(MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram.php', array($this, 'install'));

register_deactivation_hook(MY_INSTAGRAM_PLUGIN_PATH . 'my-instagram.php', array($this, 'uninstall'));

}

/**

* Set up the table and options

* @return void

public function install()

{

...

}

/**

* Drop the table and options associated with the plugin

* @return void

public function uninstall()

{

...

}

The most important changes occur on lines 1, 16, and 17. The first line fixes the definition by manually specifying the path using the base plugin directory (instead of an automagic WordPress search). Lines 16 and 17 specify the main plugin file itself as the path (instead of relying on __FILE__).

This allowed WordPress to find the plugin files without a hitch, which is especially important in the installation/uninstallation phases.

Moral of the story? Check your paths first.

Paths

Pink Ribbon Breakfast

Posted on 11.07.2012 by neill

Add something

I don’t normally plug work that I do in my daily grind, but this one is for super-great cause. Instead of our usual advertising selves, we’re using our powers for good and completely upgrading the National Breast Cancer Foundation‘s Pink Ribbon Breakfast site. Their goal is to have 0 deaths by 2030, which is a pretty nice goal all-round.

We built the site using Zend Framework, CSS3, and a healthy dose of jQuery-inspired Javascript.

Jump over to the site and check out our relatively-quiet first phase launch while we get ready for the donation-crazy second phase. And be sure to visit the donate link if you know someone with breasts.

Using a single controller in Zend Framework

Posted on 08.05.2012 by neill

Add something

Are you using Zend? Do you have only a core controller and don’t need extraneous URL parameters? Try this.

Most of the time, I am using Zend Framework to its (mostly) full capacity. Models, Controllers, View Helpers – the whole box-and-dice. However, there has been several occasions where I’ve only needed a single controller serving up mostly static pages, or pages leveraging an external service.

The biggest problem that arises in this case when using the default Zend Router, is that action names are treated as controller names. I don’t know about you, but I personally hate seeing http://example.com/index/my-action when what I actually want to see is http://example.com/my-action.

Here’s a nice way to completely tidy up all your actions, serving them from a single controller. (I use a Bootstrap file to initialise my application):

/**
 * Set up routers for the system
 *
 * @return void
**/
protected function _initRouters()
{
    $router = Zend_Controller_Front::getInstance()->getRouter();
    $route = new Zend_Controller_Router_Route(
        ':action/*',
        array(
            'controller' => 'index',
            'action' => 'index'
        )
    );
    $router->addRoute('default', $route);
}

/**

* Set up routers for the system

* @return void

**/

protected function _initRouters()

{

$router = Zend_Controller_Front::getInstance()->getRouter();

$route = new Zend_Controller_Router_Route(

':action/*',

array(

'controller' => 'index',

'action' => 'index'

)

);

$router->addRoute('default', $route);

}

This basically says that my first parameter is always going to be an action name, and everything else is to be parsed as normal. I set request defaults in the array. In this case, the default controller is “index”. This allows everything to be passed straight through to my IndexController.

Addtionally, if you are using modules and want to retain routing for these also (for example, a one-controller site with an admin module), you can add this route rule to your system:

$route = new Zend_Controller_Router_Route(
    'admin/*',
    array(
        'module' => 'admin'
    )
);
$router->addRoute('admin', $route);

$route = new Zend_Controller_Router_Route(

'admin/*',

array(

'module' => 'admin'

)

);

$router->addRoute('admin', $route);

This says that anything starting with “admin” needs to be routed to the admin module, and the rest of the URL is to be parsed as normal.

That’s it! This will allow you to route all requests to a single controller for the front-end, and still maintain a complete module for the administration on the back-end.

Hopefully this cleared up some things for others, as I found the Zend Framework documentation to be quite dismal.

Using memcache and Zend_Cache

Posted on 27.03.2012 by neill

Add something

Probably one of the more useful things you can do with memcache is drop it into Zend Framework. Here’s how I did that.

Following on from the previous post, here is an example of how you can set up memcache to serve as a cache for your Zend project.

I like to use the method style of bootstrapping my application, so here’s the function that builds the cache for me.

/**
 * Set up caching using memcache
 *
 * @return void
 **/
protected function _initMemcache()
{
    if (extension_loaded('memcache'))
    {
        // Configure caching backend strategy
        $cacheBackend = new Zend_Cache_Backend_Memcached(
            array(
                'servers' => array(
                    array(
                        'host' => '127.0.0.1',
                        'port' => '11211'
                    )
                    // Other servers here
                ),
                'compression' => true,
                'compatibility' => true
            )
        );
        // Configure caching frontend strategy
        $cacheFrontend = new Zend_Cache_Core(
            array(
                'caching' => true,
                'cache_id_prefix' => 'MyApp_',
                'write_control' => true,
                'automatic_serialization' => true,
                'ignore_user_abort' => true
            )
        );
        // Build a caching object
        $memcache = Zend_Cache::factory($cacheFrontend, $cacheBackend);
        Zend_Registry::set('cache', $memcache);
    } else {
        // Handle a non-existent extension here
    }
}

/**

* Set up caching using memcache

* @return void

**/

protected function _initMemcache()

{

if (extension_loaded('memcache'))

{

// Configure caching backend strategy

$cacheBackend = new Zend_Cache_Backend_Memcached(

array(

'servers' => array(

array(

'host' => '127.0.0.1',

'port' => '11211'

)

// Other servers here

'compression' => true,

'compatibility' => true

)

);

// Configure caching frontend strategy

$cacheFrontend = new Zend_Cache_Core(

array(

'caching' => true,

'cache_id_prefix' => 'MyApp_',

'write_control' => true,

'automatic_serialization' => true,

'ignore_user_abort' => true

)

);

// Build a caching object

$memcache = Zend_Cache::factory($cacheFrontend, $cacheBackend);

Zend_Registry::set('cache', $memcache);

} else {

// Handle a non-existent extension here

}

Originally, I was getting the “Memcache::addServer function expects at most 6 parameters, 8 given” warning. To force Zend to play nice with memcache (and send the right parameter count), you need to make sure you have the compatibility option set to true in the backend options array.

Here’s an example on how to use:

$cache = Zend_Registry::get('cache');
if (!$request = $cache->load('dataset')) {
    $request = LargeQueryOrDataset();
    $cache->save($request, 'dataset');
}
var_dump($request);

$cache = Zend_Registry::get('cache');

if (!$request = $cache->load('dataset')) {

$request = LargeQueryOrDataset();

$cache->save($request, 'dataset');

}

var_dump($request);

Hope this helps in getting started with Zend_Cache (even on a technology as old as memcache).

Enabling memcache under MAMP

Posted on 27.02.2012 by neill

Add something

I know the tech is a bit old, but sometimes you need to make do with the tools you’ve been given. Here’s how I enabled memcache under MAMP.

First, grab the precompiled binary file (memcache.so) from here. There were no problems using this on Snow Leopard (for me, at least).

Second, copy the file to your MAMP extensions directory. You should be able to find it here: /Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-[date].

Next, you’ll need to enable the extension in MAMP. Switch it off, then open up php5.ini by going to File > Edit Template > PHP5 php.ini

Find the extensions section (about line 540 or so) and add this line to the list of extensions:

extension=memcache.so

1	extension=memcache.so

Once that’s done, save php.ini and reboot MAMP. You should be able to see an entry for memcache when opening your phpinfo page.

Watching your Language

Posted on 15.12.2010 by neill

Add something

Inspired somewhat by Dave Ray’s post “Say Something Nice About Every Language You’ve Used“, I’ve decided to do the same.

PHP
Fairly easy to learn, and with an improving OO model, Web development will only get better. Syntax is pretty straight forward and it’s easy to get something working relatively quickly.

Visual Basic
Very simple syntax, and a good introductory language for learning Windows programming.

C/C++
I like C (and C++) because you can do with it what you will. There’s a lot of flexibility and room to move for whatever problem you have.

Java
It has a similar syntax to C, but automatic garbage collection makes me weep tears of joy.

Javascript
One of my favourite aspects of web development is putting on my Javascript hat and adding very slick functionality to my site. Simple syntax and a lot of power for overriding default objects.

Objective-C
Very quick to learn the basic syntax, and it forces a separation of code into conceptual pieces that I agree with.

That exercise is actually enlightening. I think focussing on the strengths of a particular language allows you to leverage it for maximum effectiveness. I’m fairly sure I’ve picked up more languages than this in the past, but not with enough experience for any sort of nice opinion. Perhaps next time I’ll just bitch and moan about all the languages I’ve used.

Return JSON data with Zend Framework

Posted on 30.11.2010 by neill

Add something

Getting Zend to return JSON data can be tricky at times. The JSON helper likes to send the ‘official’ JSON header (application/json), and most browsers are treating that as a download link, resulting in no data to the client and an unfortunate download box.

To bypass this default behaviour, you’ll need to tell the controller how to serve your JSON data:

// In your controller
public function outputAsJSON()
{
    $content = $some_var;
    $this->getResponse()
        ->setHeader('Content-Type', 'text/html')
        ->setBody(json_encode($content))
        ->sendResponse();
        exit;
}

// In your controller

public function outputAsJSON()

{

$content = $some_var;

$this->getResponse()

->setHeader('Content-Type', 'text/html')

->setBody(json_encode($content))

->sendResponse();

exit;

}

The key part of this stub is the exit; line. It prevents the view renderer from sending anything, keeping your JSON data intact. Note: json_encode and json_decode only works from PHP version 5.2.1

To output all of your view’s variables in this way, replace $some_var; with:

json_encode($this->view->getVars());

1	json_encode($this->view->getVars());

Hopefully this saved someone a headache or two when dealing with Zend’s puzzling JSON implementation.

Quick Zend Cache Setup

Posted on 29.08.2010 by neill

Here’s a quick solution to get a cache running on your Zend Framework install. It’s very simple and should provide a good solution for most small-scale sites.

You can put this code inside of your bootstrap file. I like to use the method style for invoking the bootstrapper.

// Disable auto buffer and instead leave it to the cache
Zend_Controller_Front::getInstance()->setParam('disableOutputBuffering', true);
$frontendOptionsCore = array(
    'automatic_serialization' => true,
    'lifetime' => 600
);
$frontendOptionsPage = array(
    'automatic_serialization' => true,
    'lifetime' => 600,
    'default_options' => array(
        'cache_with_get_variables' => true,
        'cache_with_session_variables' => true,
        'cache_with_cookie_variables' => true,
        'make_id_with_get_variables' => true,
        'make_id_with_session_variables' => true,
        'make_id_with_cookie_variables' => false
        )
    );
$backendOptions  = array('cache_dir' => APPLICATION_PATH . '/data/cache');
$coreCache = Zend_Cache::factory('Core', 'File', $frontendOptionsCore, $backendOptions);
$pageCache = Zend_Cache::factory('Page', 'File', $frontendOptionsPage, $backendOptions);
// Start running the page cache immediately
$pageCache->start();
// Set global cache objects
Zend_Registry::set('coreCache', $coreCache);
Zend_Registry::set('pageCache', $pageCache);
// Start running the DB/Core cache
Zend_Db_Table_Abstract::setDefaultMetadataCache(Zend_Registry::get('coreCache'));

// Disable auto buffer and instead leave it to the cache

Zend_Controller_Front::getInstance()->setParam('disableOutputBuffering', true);

$frontendOptionsCore = array(

'automatic_serialization' => true,

'lifetime' => 600

);

$frontendOptionsPage = array(

'automatic_serialization' => true,

'lifetime' => 600,

'default_options' => array(

'cache_with_get_variables' => true,

'cache_with_session_variables' => true,

'cache_with_cookie_variables' => true,

'make_id_with_get_variables' => true,

'make_id_with_session_variables' => true,

'make_id_with_cookie_variables' => false

)

);

$backendOptions = array('cache_dir' => APPLICATION_PATH . '/data/cache');

$coreCache = Zend_Cache::factory('Core', 'File', $frontendOptionsCore, $backendOptions);

$pageCache = Zend_Cache::factory('Page', 'File', $frontendOptionsPage, $backendOptions);

// Start running the page cache immediately

$pageCache->start();

// Set global cache objects

Zend_Registry::set('coreCache', $coreCache);

Zend_Registry::set('pageCache', $pageCache);

// Start running the DB/Core cache

Zend_Db_Table_Abstract::setDefaultMetadataCache(Zend_Registry::get('coreCache'));

What this snippet does is initialise two related caches – a core cache, and a page cache. The core cache (in this instance) is attached to our database table abstract class, which allows results to be stored as serialized strings. The page cache is invoked whenever template output is due to occur, and saves pre-rendered HTML for immediate output.

You can find all the documentation for tweaking your cache settings in the Zend_Cache documention.

timneill

your second opinion

Tag Archives: php

Remove extra RSS feeds in WordPress

WordPress: Add page slug to body class (including parents!)

Help! register_activation_hook isn’t working!

Finding a solution

Ok, that’s great, but what’s the answer?

The Fix

Pink Ribbon Breakfast

Using a single controller in Zend Framework

Using memcache and Zend_Cache

Enabling memcache under MAMP

Watching your Language

Return JSON data with Zend Framework

Quick Zend Cache Setup