Epic - Open Source - Theme to be plugin agnostic

[AmnestyAM]

Sprints allocated

Number of sprints: 2
Link to sprint if known: TBC

Goals

• Make this theme easier to use by grass roots charities NGOs etc
• Rewrite CMB2 options to Options/Settings API
• Move MLP code to brand plugin
• Move Yoast code to brand plugin
• Move WooCommerce code to Donations plugin

Tasks

• Migrate MultilingualPress customisations to Branding plugin
• Migrate WordPress SEO customisations to Branding plugin
• Migrate WooCommerce customisations to Donations plugin
• Implement Options/Settings APIs wrapper interface
• Migrate theme options to Settings API
• Migrate options within Donations plugin to Settings API
• Migrate options within Petitions plugin to Settings API
• Migrate options within CSP plugin to Settings API
• Migrate options within Salesforce Connector plugin to Settings API
• Migrate options within Donations Salesforce Adapter plugin to Settings API
• Migrate options within Petitions Salesforce Adapter plugin to Settings API
• Migrate options within Branding plugin to Settings API
• Migrate options within SharePoint Runner plugin to Settings API
• Migrate options within Theme Companion plugin to Settings API
• Archive CMB2 Message Field plugin
• Archive CMB2 Password Field plugin
• Archive Custom Font plugin

Think about (optional)

• Tickets for translations
• Tickets for content

[jffng]

There are many templates, partials, and functions specific to WooCommerce. Should those be moved to the plugin also?

[AmnestyAM]

Hi @jffng My guess is the Woo related files might end up here https://github.com/amnestywebsite/humanity-donations @jaymcp will let me know if I am wrong here.

[jaymcp]

Some could certainly be moved to Donations, but I'm not sure about the template overrides. I'll have to see whether I can hook into WC's template loading to allow templates/parts to be loaded from a plugin. It's definitely worth investigating, though.

[jaymcp]

I've done some investigation into what it would take to migrate our options away from CMB2.

Generally, it's going to be less troublesome than I first thought, as most of our options are text-based fields. However, there are some considerations to be made around user experience.

For example, we will have to allow the user to (in some cases):

• select media from the media library
• select post object(s)

The UX for these sorts of fields will need some thought in order to provide the user with a similar or better experience than we currently have using CMB2.

Additionally, WP 6.5 introduces the "Block Bindings API", which will allow us to provide data to blocks directly, which could further enhance the UX for certain data.