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.