Use class_exists() guard for Featured_Content.

[tierra]

This is a work-around to the problem exhibited by wp-cli/wp-cli#917, where the Twenty Fourteen theme manages to define the Featured_Content class first (as plugins are activated after the theme is loaded rather than before like core does).

This should ideally still be fixed in WP-CLI, but this workaround would still be helpful in the mean time.

[blobaugh]

Putting the check around the class in modules/theme-tools/featured-content.php would probably be a better idea than around the include. That way it preserves the functionality in case the file gets included somewhere else.

If you can update it I will accept the pull request.

[georgestephanis]

I actually think the way it is, more as it will preserve consistent merges for featured-content.php between wpcom and Jetpack when we run the merges between the source files there.

[obenland]

I'm not sure this is something we should do. Featured Content in Twenty Fourteen is meant to be pluggable, which is why it checks the $pagenow global for the plugins page to avoid that error.

If I'm reading Jetpack's code correctly, FC gets loaded on 'plugins_loaded', before any theme action anyway, no?

[tierra]

Normally, yes, but it wasn't in the case of WP-CLI (which wasn't setting $pagenow since it's not in the admin panel at all - it does now per wp-cli/wp-cli#917 though). The check doesn't change the loading behavior anywhere else, so it just helps not break in the rare case that it doesn't load in the order it normally does.

[obenland]

it just helps not break in the rare case that it doesn't load in the order it normally does.

When is that ever the case though?

[tierra]

In the current version of WP-CLI, like I said.

[obenland]

I was under the impression WP-CLI wasn't setting $pagenow, causing it to break, not changing the load order.

[tierra]

Twenty Fourteen uses the $pagenow check to avoid including it during plugin activation from the admin screen (where the order changes from a normal frontend page load) where it would break. When using WP-CLI though, because it never set $pagenow to plugins.php (because it's not actually a user using the admin screen, it shouldn't have to technically), Twenty Fourteen includes FC before WP-CLI activates Jetpack (in the same order the admin panel plugin activation does), where Jetpack was missing the guard, causing a fatal error.

Sorry if I gave the impression that the order is different when using WP-CLI, I was wrong about that initially. The load order does change, but it does it in both WP and in WP-CLI in the same way: it changes order only during plugin activation. This also still wouldn't normally be a problem because Jetpack only loads FC during the plugins_loaded action anyway, and that isn't triggered during plugin activation in wp-admin, but it apparently is in WP-CLI.

Putting all of this aside though, this is in fact a problem we've run into, and this change just makes Jetpack a little more robust, and less prone to failure. It doesn't actually change anything inside of normal use, so it really doesn't hurt. Should Twenty Fourteen have even included the FC class in a theme in the first place? Probably not, but now that it's included in two incredibly popular locations (a default theme, and the number one most installed plugin), it really isn't a bad idea to use an include guard just in case for all the weird and wild situations like WP-CLI in which Jetpack is used.