liveblog_features filter appears not to run

[jonathanstegall]

I've been trying to disable the hashtags feature using variations of this code:

add_filter( 'liveblog_features', 'mytest_liveblog_features', 1000, 1 );
function mytest_liveblog_features( $features ) {
	$features = array( 'commands', 'emojis', 'authors' );
	error_log( 'features is ' . print_r( $features, true ) );
	return $features;
}

I tried unsetting hashtags if it was the value in a foreach, which also failed. I've also tried using various priority numbers (-1, 0, 1, 10, 1000) with no change.

[GaryJones]

The filter is called in WPCOM_Liveblog_Entry_Extend::load(), which is called in WPCOM_Liveblog::load(), which in turn, is unfortunately called globally in the main plugin file.

This means that as soon as the plugin has loaded, the filter will run, before you've had a chance to hook a callback to it.

There doesn't appear to be any action hook available between the main plugin file being parsed, and the filter you want to amend being called.

In the meantime, you could try adding your filter to a mu-plugin, so that it is parsed before the liveblog and other plugins are parsed. Not ideal, but it may work for what you want.

[philipjohn]

@GaryJones What are your thoughts on adding a liveblog_init hook at the beginning of load()?

I see one semantic problem in that we already have a after_liveblog_init hook which refers to the initialisation of an individual liveblog, not the plugin loading. Perhaps liveblog_load would be a better name?

[GaryJones]

liveblog_plugin_init / liveblog_plugin_load ?

The issue is that we don't have ubiquitous language i.e. "liveblog" could refer to the plugin, the archive of entries, or potentially even an individual entry.

[philipjohn]

"liveblog" could refer to the plugin

We might not have that problem soon :)

[GaryJones]

We might not have that problem soon :)

Right, but we'll still need the same prefix, so the inclusion of the _plugin_ removes some of the ambiguity.

[GaryJones]

Investigation Findings

The root cause is that WPCOM_Liveblog::load() is called globally at plugin parse time (liveblog.php:2229), not on a WordPress hook. By the time other plugins can register callbacks, the liveblog_features filter has already run.

Call chain:

1. liveblog.php:2229 - WPCOM_Liveblog::load() called during plugin file parsing
2. liveblog.php:270 - calls WPCOM_Liveblog_Entry_Extend::load()
3. class-wpcom-liveblog-entry-extend.php:50 - apply_filters('liveblog_features', ...) executes

Proper Fix (2.0)

Defer initialisation to the plugins_loaded hook:

// Instead of:
WPCOM_Liveblog::load();

// Use:
add_action( 'plugins_loaded', array( 'WPCOM_Liveblog', 'load' ), 0 );

This is technically a breaking change (any code expecting Liveblog to be fully initialised at parse time would break), so it belongs in 2.0 alongside broader architectural refactoring.

Workaround (1.x)

Use a mu-plugin to register your filter callback. Mu-plugins load before regular plugins, so your callback will be registered before Liveblog parses:

// wp-content/mu-plugins/liveblog-features.php
add_filter( 'liveblog_features', function( $features ) {
    return array( 'commands', 'emojis', 'authors' ); // without 'hashtags'
} );