1.9 Theme System

MyBB 1.8 themes' information, contained in XML files, are expected to be split into the filesystem directly (templates, stylesheets, and additional assets) and a package.json manifest file with properties and metadata.

• What theme properties should the manifest file include?
• What metadata should the manifest file include?
• How should theme installation & modification work (Composer, CSS pre-processors)? #3686
• How should MyBB compatibility updates work?
• How should stylesheet information be stored?
• How should the new system handle inheritance? How should that information be stored?
• What system could be implemented for applying theme updates?
• What level of support should be left for 1.8 templates & stylesheet to maintain 1.8 extension compatibility? How?

We have also had some discussion about managing JavaScript scripts related to themes. The idea was that we'd have a JS manager similar to the stylesheet manager with some of the following features:

• JS scripts could have dependencies (eg: a.js depends on jQuery.js so we ensure jQuery.js is loaded)
• JS scripts could be combined and minified, then cached
• JS scripts would have cache busting when using combined and minified versions

Regarding theme installation, I would love to package themes as Composer packages so that they can be installed that way as well as via the standard upload procedure (including simply uploading a ZIP file to the ACP I hope).

Composer's JSON schema already has a type property. I imagine us having our own defined types (mybb-theme, mybb-plugin, mybb-translation).

Composer's schema also has an extra feels that allows other arbitrary entries. Given that it contains other fields we'd want to show for themes (author, name, license, URL, etc. I've considered using the standard composer.json as the actual theme manifest. We'd define some standard extra fields that we understand, and otherwise use the standard fields.

As to theme info, I would start by drawing a direct comparison from what we are doing now. As it stands, the inheritance system that is currently in place works fairly well.

The main issue with the current system that I see in practice is that upgrades require quite a bit of knowledge from admins because of how updates are handled. If there was a way to improve this process, that would be a welcome change.

I'm currently in the process of mimicking the existing inheritance pattern for a plugin that needs a similar system. I honestly haven't found any ways to improve the current setup, but I am still looking into it.

As to direct answers to the questions in @dvz's opening post, each of these will need to be referenced individually. For example, to know which theme properties will be essential to the manifest, we would need to do a project-wide analysis to see what is essential pre-load.

Also, I would like to see required folder structures for third-party devs so that we can make a trouble-free auto installer for plugins, themes, and translations. (And as @euantorano said, Composer packages)

The main issue with the current system that I see in practice is that upgrades require quite a bit of knowledge from admins because of how updates are handled. If there was a way to improve this process, that would be a welcome change.

The problem in 1.8 lies mainly with presentation of Find Updated Templates - what's IMO missing the most is a comparison of what's changed in specific upgrade in the master set; these "diffs" would be easier to recognize than master-custom comparison (as unrelated modifications are caught up in the report), along with a suitable UI (perhaps the diff - "suggested changes"/"copy these" - and an editor side-by-side).

That sounds great, @dvz

If it were possible to have a side-by-side comparison, that would be optimal.

Hi,

Can you make a responsive theme please

Yes, that is one of the main 1.9 features.

On Fri, 15 Nov 2019, at 22:55, Jérémy wrote:

Hi,

Can you make a responsive theme please

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mybb/mybb/issues/3689?email_source=notifications&email_token=AAFW24MKQOKZCBLU3POCLSLQT4SH5A5CNFSM4HTEAUV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG646I#issuecomment-554561145, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFW24I5GNSYD6JBLPOMSGLQT4SH5ANCNFSM4HTEAUVQ.

related discussion: https://community.mybb.com/thread-232217.html for me it should store templates in database https://twig.symfony.com/doc/3.x/recipes.html#using-a-database-to-store-templates so it will make it much easier to resolve the issues raised in this ticket, I believe.