Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.9 Theme System #3689

Open
dvz opened this issue Jun 4, 2019 · 7 comments

Comments

@dvz
Copy link
Contributor

commented Jun 4, 2019

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?

@dvz dvz added this to the 1.9.0 milestone Jun 4, 2019

@dvz dvz added this to To do in MyBB 1.9.0 via automation Jun 4, 2019

@dvz dvz pinned this issue Jun 4, 2019

@euantorano

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

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
@euantorano

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

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.

@WildcardSearch

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

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.

@WildcardSearch

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

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)

@dvz

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

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).

@WildcardSearch

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

That sounds great, @dvz

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

@Jessicastrong

This comment has been minimized.

Copy link

commented Sep 17, 2019

Manifest file for an android application is a resource file which contains all the details needed by the android system about the application. ... This is an XML file which must be named as AndroidManifest.xml and placed at application root.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
4 participants
You can’t perform that action at this time.