Open alexstandiford opened 2 years ago
It would also be very nice to be able to tie actions to standardized sets, as well. This would drastically simplify a lot of logic around writing integrations. For example, let's say you wanted to add some kind-of hook on any event plugin that's activated, and supports event creation:
foreach ( underpin()->integrations()->events()->filter( [ 'is_active' => true, 'supports' => 'event_creation' ] ) as $integration ) {
// Behind the scenes, 'event_created' is basically a proxy for whatever the actual action is specific to this plugin.
// This also may give us a chance to apply an adapter to the event item that is passed.
$integration->add_action( 'event_created', function ( Adapted_Event $event ) {
// Do something with this event.
} );
}
Now, instead of needing to write custom integration classes for every integration, you only need to ensure the hooks are supported by the integration built-into underpin()->integrations()->events()
I think it's clear that most of this functionality won't exist inside Underpin, but it will exist as packages that work with Underpin.
The question is, what needs to be in Underpin in-order to facilitate this functionality?
Something I've been thinking about a lot for a few years now is how nice it would be to integrate Underpin in a way that makes re-using code between plugins easier. A way to-do this would be by building different plugin "types", wrangling up as much of the common functionality as possible, and running them through some kind-of consistent pattern that can be re-used throughout other plugins.
This could drastically improve plugin development speeds, and make working with third party plugins significantly easier.
TL;DR
I think Underpin needs a way to load in pre-made integration classes that contain all of the information needed to work with different plugin types in a consistent fashion. The goal would be to make it so that long as a developer sticks to the methods that are included in the Underpin integration class their plugin should be able to be compatible with all of the plugins that work with the integration for free.
From this, we could build integration packages for Underpin that pre-make the integrations form common plugins. These could be installed, and used directly.
Example:
This would allow developers to integrate with several plugins at one time, and also prevent common pitfalls with coupling their code directly with a forms plugin directly.
This could also make it possible for theme developers to integrate with more plugins without re-writing a bunch of code in the process.
The Scenario:
You build a plugin for a customer that integrates Ninja Forms in some cool way. Later on, you need to do something identical for another customer, only this time you have to set it up to work with Gravity Forms, instead.
To accomplish this in Underpin, I would probably create a custom loader called
integrations
that would actually use whichever plugin is installed. Something like this:How Could this be Improved?
This is a common scenario - building a third party plugin that needs to integrate with multiple, similar plugins. It would be nice if Underpin had some libraries pre-built to make it possible to work with these systems directly. So take all of the example code above, modify it to work as an integration, and make these work as loaders. This integration could be loaded in using composer, perhaps something like
composer require underpin/forms-integration
, which would contain all of the information needed to work with any forms plugin that is registered in the system. So, as long as a developer sticks to the methods that are included in Underpin's integration class, their plugin should be able to be compatible with all of the plugins that work with the integration for free.This would allow developers to integrate with several plugins at one time, and also prevent common pitfalls with coupling their code directly with a forms plugin directly.
This could also make it possible for theme developers to integrate with more plugins without re-writing a bunch of code in the process.
Here's a few possible patterns:
Since this is technically a loader registry, you could also query registered integrations, and run something on each:
Now with the example above, let's say you wanted to automatically submit a form when something else happens on your site. You don't actually care what forms plugin is used, you just want the data to be submitted.
Other potential integrations that could work with this:
I'm sure there's many more.
So What Needs Changed?
get_forms_integration()->get_fields()
? The resulting array of fields needs to be normalized in a standardField
object, so that the signature doesn't change between plugins. Something likeget_forms_integration()->get_fields()->get_value()
should work for every single type of forms plugin. Underpin might need to have some kind of abstraction to facilitate this.plugin_name()->integrations()
, and theIntegrations
class should extendLoader_Registry
so we can use helpers likefind
andfilter
.filter
andfind
methods can query against it.is_active
, but it would be useful if the system knew that whenactive
is added to filter/find that it would filter those plugins out.This implementation probably needs to be coupled with a pre-built integration. This will help us figure out the nuance of working with a system like this, and also give us a concrete example of how to use/extend integrations.