Replace integration points with hooks

[GaryJones]

Is your feature request related to a problem? Please describe.
There are several points within the code where support for Genesis, YARPP, Jetpack, WPML and Polylang (and possibly others according to the readme.txt) are "hard-coded" into the logic. This can make it hard to find exactly what support there is, and more importantly, for other plugins / site developers to add their own integrations.

Describe the solution you'd like
At all the points where an integration has been made, add an action or filter hook, and make any key values available to callbacks to those hooks.

Then create files for each integration, like /integrations/genesis.php, that contain callbacks hooked into the relevant hook, and document them. Have a file like integrations.php which acts like a factory to allow registration of known integrations, and the ability to instantiate the relevant classes and call a common method to apply the hooks.

Using hooks in this way aligns with the Open/Closed Principle; It's open to extension (from others), and the original code is closed for modification.

Describe alternatives you've considered
Leaving support for multiple plugins and theme(s) scattered throughout the code-base, with ever-increasing support for others cluttering up the default logic, while not allowing others to easily add their amendments.

Here's a quick and dirty approach as a starting point / example:

View code

// integrations/Integration.php

namespace PodsFramework\Pods\Integrations;

interface Integration {
	/**
	 * Apply the hooks that integrate the plugin or theme with Pods
	 *
	 * @since x.x.x
	 */
	public function integrate();
}


// integrations/Genesis.php
 
namespace PodsFramework\Pods\Integrations;

class Genesis implements Intergration {
	/**
	 * Apply the hooks that integrate the plugin or theme with Pods
	 *
	 * @since x.x.x
	 */
	public function integrate() {
		add_action( 'pods_some_action_hook', ( $this, 'my_action_callback' ), 10, 2 );
		add_filter( 'pods_some_filter_hook', ( $this, 'my_filter_callback' ) );
	}

	/**
	 * Do something.
	 *
	 * @since x.x.x
	 *
	 * @param string $a Foo.
	 * @param array  $b Bar.
	 */
	public function my_action_callback( $a, $b ) {
		?>
		<!-- Some more fields or something. -->
		<?php
	}

	/**
	 * Filter something.
	 *
	 * @since x.x.x
	 *
	 * @param string $c Baz.
	 * @return string Amended Baz.
	 */
	public function my_filter_callback( $c ) {
		// Some logic.
		return $amended_c;
	}
}


// Integrations.php

class Integrations {
	private $integrations;

	public function register_integration( $class, callable $condition, $file_path = null ) {
		// Allow registration of integrations. File Path if not autoloaded.
	}

	public function integrate() {
		// Loops through each registered integration, checks of the condition
		// is truthy, and loads the file, instantiates the class and calls ->integrate();
	}
}


// Some init step:

// Add built-in integrations:
$integrations = new Integrations();
$integrations->register( 'Genesis', function() {
	return class_exists( 'genesis' );
});
$integrations->register( 'Yarpp', function() {
	return defined( 'YARPP_VERSION' );
});
$integrations->integrate();

[sc0ttkclark]

@JoryHogeveen I have the first few integrations (as handled in the post type supports options) migrated into the new classes at src/Pods/Integrations/*.php

See the Pods\Integration\Service_Provider class for where to run hooks etc.