Allow hide theme for email and page constructors Mautic 5

[Syrgak-Alan]

Q	A
Bug fix? (use the a.b branch)	[No]
New feature/enhancement? (use the a.x branch)	[Yes]
Deprecations?	[No]
BC breaks? (use the c.x branch)	[No]
Automated tests included?	[No]
Related user documentation PR URL	mautic/mautic-documentation#...
Related developer documentation PR URL	mautic/developer-documentation#...
Issue(s) addressed	Fixes #...

Description:

Allow Themes to be hidden in the theme-Selection when creating an email or page

Idea:

• Have a toggle in the theme’s config.json to hide the theme in the GUI
• So the Mautic GUI should not offer the hidden themes in https:///s/emails/new

Steps to test this PR:

• Upload the theme
• Go to emails/pages
• Create new email/page
• Check if theme is visible in the overview
• Go to CLI and manually change the toggle in the config.json to hide the theme(cd themes/<name_of_theme> && nano config.json after add "hide" and set to it true value)
• Go to emails/pages
• Create new email/page or edit already existing
• Check if theme is now hidden

Manually add

[kuzmany]

Thanks! I really like this feature. For me, there's no need for a toggle – this simple trick works perfectly. I would suggest using the parameter hide = 1 or true when we need it, instead of isVisibleInGUI. It's much more common.

I also recommend adding icons with titles to the theme list to clearly indicate which themes are hidden. Similarly, these themes should be hidden, for instance, in the theme selector in forms.

fa-ban

or fa-eye-slash

[oltmanns-leuchtfeuer]

Nice little feature - works as described. Also, the little Icon is nice and suited very well.

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 61.04%. Comparing base (55ee880) to head (06c3bd8).
Report is 1 commits behind head on 5.x.

❗ Current head 06c3bd8 differs from pull request most recent head 60e30d1. Consider uploading reports for the commit 60e30d1 to get more accurate results

Additional details and impacted files

@@             Coverage Diff              @@
##                5.x   #13539      +/-   ##
============================================
- Coverage     61.30%   61.04%   -0.27%     
+ Complexity    34002    33941      -61     
============================================
  Files          2238     2237       -1     
  Lines        101646   101457     -189     
============================================
- Hits          62312    61932     -380     
- Misses        39334    39525     +191     

Files	Coverage Δ
app/bundles/CoreBundle/Helper/ThemeHelper.php	70.47% <ø> (-0.48%)	⬇️
app/bundles/CoreBundle/Form/Type/ThemeListType.php	91.66% <75.00%> (-8.34%)	⬇️

... and 62 files with indirect coverage changes

[Syrgak-Alan]

@kuzmany issues are resolved and your change requests are done, could you please check it

[PatrickJenkner]

Worked as described when tested 👍

[RCheesley]

Just adding the UX team for review - please make a PR for the documentation which explains what the icon means and how/why to set it.

[andersonjeccel]

Hey, thanks for this improvement!

I’d like to point something to make this enhancement even better:

We could have an option, inside the dropdown, to allow administrators or roles with theme management permission being able to set a theme hidden or not…

Bc the way this functionality is being implemented right now, only technical people will benefit from it

Is there a possibility to add this link for an automatic toggle?

I’d also suggest to use the icon ri-eye-off-line (new icon pack)

[shinde-rahul]

I agree with @andersonjeccel; having an action or toggle button to hide will make more sense than updating the info file.

[shinde-rahul]

Currently, we don't have an entity to hold the theme meta information, just like the plugins table.

[kuzmany]

Currently, we don't have an entity to hold the theme meta information, just like the plugins table.

@shinde-rahul I recommend not using a toggle in this scenario. Even though it's possible to add one, it would require a significant amount of code and involve saving changes to the config.json file for each theme, among other things.

@escopecz what do you think?

[shinde-rahul]

@kuzmany, I am not suggesting the theme files update. It should mimic how the Campaign/Email/Plugins Published (Enabled) toggle button uses the theme as an entity to hold the data.
The approach will be,

• Add a new entity named 'Themes` with properties like name, author, features, supportedBuilders, status, dates
• Then populated the db on the first install and then with the command to reload the themes like plugins
• Maintain the status for each of the themes we have

That way, administrators can control what themes to list and what not for the editors.

This is good to discuss with others, too, so tagging @RCheesley @escopecz @oltmanns-leuchtfeuer

[kuzmany]

@shinde-rahul I understand, but that's a lot of work (test coverage), and I bet the original author cannot spend on it, @Syrgak-Alan can it?

Then we should discuss about real options (merge, or not merge it)

[escopecz]

Thanks for tagging me. It reminded me a PR that we have in Campaign Studio for the same feature. I quickly pushed it here: #13723

Please review which is better.

[kuzmany]

Close favor to #13723