Add your comments directly to the page. Include links to any relevant research, data, or feedback.

Status

Impact

(due to goal of including GrapeJs into 3.3)

Driver

Alan Hartless 

Approver

Contributors

Add stakeholders

Informed

Due date

ASAP

Outcome

What did you decide?

Background

Since the plan is to include the GrapeJS builders as optional in 3.3, we need a way to hide templates specifically designed for GrapeJS that won’t be compatible with the legacy builder. This is why I will bring over the ability to filter templates based on the builder enabled. The question is, do we want all legacy templates to be available to GrapeJS or only those specifically designed for GrapeJs for the most optimal GrapeJs experience?

Relevant data

I plan to make Mautic aware of which templates are compatible with the currently enabled builder through the template’s config. If the template is missing this configuration option, it will be assumed to be “legacy.” It will be cleaner if I can keep this logic in Mautic and the template configs as it will just require the template’s config to tell Mautic what it is compatible with. However, if we want GrapeJS to load all legacy templates by default, then I will have to push that logic to the builder code as an interface or config option for the builder to tell Mautic what templates it is compatible with.

If we go with the former (my preference) and someone wants a legacy template to be compatible with GrapeJs, they could simply edit the template’s config. We could also default all (or specific) default legacy templates to support GrapeJs in addition to legacy.

Options considered

Option 1: Templates tell Mautic what builder(s) they are compatible with

Option 2: The builder tells Mautic what templates it is compatible with

Description

Each builder will tell Mautic what it is known by (likely the integration name since the GrapeJs plugin is already developed this way).

Mautic simply reads a parameter in the template’s config which tells it which builders it is compatible with and only the applicable themes/templates become visible to the UI based on which builder is enabled (default legacy).

In addition to option 1, Mautic will have to “consult” the builder to know if it supports templates other than its own (eg. grapejs + legacy).

Pros and cons

(plus) Cleaner implementation and less overhead for builder developers

(plus) User gets the best experience out of the box as GrapeJs templates will work best with GrapeJs where legacy templates will work best with the legacy builder.

(plus) It will still be possible for users to simply modify their template’s configs to make them available to any builder of course with the caveat that they are not guaranteed compatible

(minus) Legacy templates (included or custom) will not be available to GrapeJS out of the box

(minus) Those not comfortable with mucking around with template config files may have to learn to do so

(plus) The builder/developer can choose what templates it supports so we can show all legacy templates by default when GrapeJS is included.

(plus) Could still be implemented later as an enhancement.

(minus) More code for the builder developer to implement to tell Mautic what templates it supports.

(minus) Larger effort to write necessary code into core to support this.

Estimated cost

Action items

Add action items to close the loop on open questions or concerns

Outcome

Summarize the outcome below