Why this is a CiviCRM- and not a Wordpress-Plugin

[skyslasher]

As noted here, I was asked why this is a CiviCRM- and not a Wordpress-Plugin.

The implementation of Mosaico in CiviMail is done well, and gives mailings the power of the CiviCRM functionality with no further effort. Setting up this framework from scratch in Wordpress would be a bunch of work, since mail editing is only a fragment of the whole email campaign process.

To get the plugin's functionality into the CiviCRM Mosaico implementation, I had to find starting points in the boot process of Mosaico to get the plugin up and running. This had to be done in the Civi space. To reach the backend for the Wordpress post metadata, I first used a Wordpress plugin, but migrated over to a Civi URL route to have everything in one place.

[christianwach]

@skyslasher Thanks for responding!

What I was hinting at was that everything you've done in the extension can, in fact, be done in a WordPress plugin. I don't mean implementing Mosaico or CiviCRM, but simply the modifications and functionality that you've written. My experience with extensions is that the assumption is that they are cross-CMS, whereas a plugin is unequivocally for WordPress.

I had to find starting points in the boot process of Mosaico to get the plugin up and running. This had to be done in the Civi space.

Not quite sure what you mean by this... but...

From what I can see, you're implementing a number of CiviCRM hooks such as hook_civicrm_enable, hook_civicrm_navigationMenu, hook_civicrm_container and hook_civicrm_tokens etc etc. These are all available to a WordPress plugin as, for example, add_action( 'civicrm_enable', 'my_civicrm_enable_callback' ), add_action( 'civicrm_navigationMenu', 'my_civicrm_navigationMenu_callback' ) and so on.

Template and PHP directories can be defined from within a plugin too, so your CiviCRM URL route could have been defined -- although, by the looks of things, it won't be needed once the hooks you propose are in place.

I guess, in the end, all I wanted to do was let you know that WordPress plugins can do anything that CiviCRM extensions can do... and with them there's no ambiguity about which CMS they are compatible with. Plus they can go in the WordPress Plugin Directory and raise CiviCRM's profile there :-)

FWIW, it's great to see new people developing in the CiviCRM-WordPress space. This is an awesome extension and I look forward to seeing it progress.

[skyslasher]

My starting point was the CiviCRM Mosaico plugin to build on. To add my functionality to it, I have to pass a plugin object into the Mosaico startup routine.

The CiviCRM Mosaico plugin has this entry point here. My approach was to replace this template with a slightly adjusted template that might go upstream.

I see your point that CiviCRM plugins should be CMS agnostic. How could this plugin injection be done from the Wordpress side?

[christianwach]

My approach was to replace this template with a slightly adjusted template that might go upstream.

Agreed that some modification of the upstream template seems necessary to accommodate Mosaico "plugins". In the meantime, a WordPress plugin could override the Mosaico template like so:

• Add a callback to civicrm_config - example here
• In that callback, register your template directory
• Place your custom template file in the path custom_template_dir_name/CRM/Mosaico/Page/EditorIframe.tpl in your plugin directory
• That's it - template overridden!

That's exactly how the CiviCRM Admin Utilities plugin fixes the broken WordPress Access Control form in older versions of CiviCRM - the template and logic are overridden unless the plugin detects a version of CiviCRM which has the fix upstream.

[skyslasher]

Thanks for the hint! This is definitely the way to go ... if it would work on the discussed template.

Take a look at the Mosaico template coding. Smarty is called explicitly, this is why the overriding approach did not work. But this is a Mosaico plugin issue that must be resolved there, I simply had no other choice at this point in time to get it working.

[christianwach]

Take a look at the Mosaico template coding. Smarty is called explicitly, this is why the overriding approach did not work.

@skyslasher I created a bare-bones plugin that overrides the Mosaico template for you to have a look at:

https://github.com/christianwach/civicrm-wp-mosaico

Enable it and if you get an alert saying 'Overridden!' then... it's overridden. Works here - without your extension of course (which it will probably break) but it should give you the basic idea.

[skyslasher]

@christianwach It took some time, but thanks to your input I reworked the plugin and split it into three parts:

• https://github.com/skyslasher/de.ergomation.civi-mosaico-plugininterface
• https://github.com/skyslasher/de.ergomation.civi-flexmailer-embedimages
• https://github.com/skyslasher/wp-civi-mosaico

Everything not specific to WordPress (i.e. Mosaico plugin injector, embedding images into CiviMail mailings) is now agnostic to the underlaying CMS, and the WordPress integration is now a native WordPress plugin.

[christianwach]

@skyslasher Great stuff! Thanks for your work on this.