The 1.9 theme and template system
#11
@Devilshakerz Thanks for the information

        // modify existing template
        \MyBB\ExtendTheme\Template('index.twig')
            ->insertBefore(
                '<a href="custom_page.php">Custom Page</a>',
                '<!-- end: navigation -->',
            ),

sorry for noob question
is the second line inside insertBefore is a reference?
Will find <!-- end: navigation --> and inser before the <a href="custom_page.php">Custom Page</a>?

so no more replace like find_replace_templatesets()?

Personally replace is much more powerful than what is being proposed. Nor does the template hook system overcome this.

I say this because in phpbb extensions, you are not able to replace or delete the elements directly on template because their using template hook system. I honestly did not want to do as in phpbb that has to use javascript to hide element using document.getElementById('xxxxxxxx').style.display = "none";.
Reply
#12
(2021-05-08, 04:35 AM)martec Wrote: @Devilshakerz Thanks for the information

        // modify existing template
        \MyBB\ExtendTheme\Template('index.twig')
            ->insertBefore(
                '<a href="custom_page.php">Custom Page</a>',
                '<!-- end: navigation -->',
            ),

sorry for noob question
is the second line inside insertBefore is a reference?
Will find <!-- end: navigation --> and inser before the <a href="custom_page.php">Custom Page</a>?

so no more replace like find_replace_templatesets()?

Personally replace is much more powerful than what is being proposed. Nor does the template hook system overcome this.

I say this because in phpbb extensions, you are not able to replace or delete the elements directly on template because their using template hook system. I honestly did not want to do as in phpbb that has to use javascript to hide element using document.getElementById('xxxxxxxx').style.display = "none";.

Yes, these are only examples - it would be still possible to modify and replace content in templates.
devilshakerz.com/pgp (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪ keybase.io/devilshakerz
Reply
#13
(2021-05-09, 03:14 PM)Devilshakerz Wrote: Yes, these are only examples - it would be still possible to modify and replace content in templates.

Thanks for reply.
If will keep replace then ok for me.
Reply
#14
[Image: 19-theme-system-extension-inheritance.png]

Nicely laid out and explained, @Devilshakerz. I have just one question at this point re the diagram, which I've reproduced:

Does the ability of extensions (orange) to modify the board theme (dark purple) relate to the "live (compile-time) template hooks" that you mentioned, or could this level of modification be more permanent, as at, e.g., extension (de)activation? I ask because I'm wondering why otherwise extensions would need "two bites of the cherry", so to speak - able to modify both the core theme via the extension layer and then again the board theme.
Reply
#15
(2021-05-12, 09:28 AM)Laird Wrote: Does the ability of extensions (orange) to modify the board theme (dark purple) relate to the "live (compile-time) template hooks" that you mentioned, or could this level of modification be more permanent, as at, e.g., extension (de)activation? I ask because I'm wondering why otherwise extensions would need "two bites of the cherry", so to speak - able to modify both the core theme via the extension layer and then again the board theme.

Yes, we'll need to establish what the Extension layer is :
  • a virtual set of resources that all themes need to inherit from, or
  • or a parallel source of new resources that cannot override the Core theme.

According to the first diagram, resources (and ideally also their properties, like Stylesheets' Attached To) could be modified through:
  • Intermediate layer in the inheritance pathCore theme resources are overridden in the Extension layer, and administrators are informed of inheritance path changes that have to be reflected in used themes.

    Modified Core theme resources would be either inherited without conflicts (if concerned themes did not modify them), or the conflict would have to be resolved. The UI should give its best effort to help apply changes introduced by the extension, and since the Core theme-Board theme changes are unrelated to the problem, in practice, the effect would be the same as Direct theme modification.

    Thus, the difference between a complete layer and a parallel source would be at an abstract level: whether the theme modification instructions (like in the previous post) should be treated as:
    • a way for extensions to be installed in selected themes, or
    • a tool to help bring selected themes to compatibility with how the new system (core + extension) works.

  • Direct theme modification — similar approach to find_replace_templatesets() in MyBB ≤ 1.8, but more fine-grained, controlled, and tracked.

    Status of changes would be displayed for all resources in the ACP, and it should be possible to undo changes even when the plugins are removed or updated.

  • Compile-time modifications — like plugin hooks, no code (resource) is modified permanently, but only modified on output (or, technically, during Twig template compilation and cached for optimization purposes).
    These may be referred to template hooks, but may support changes beyond simple insertion of HTML at selected positions, and potentially coded the same way as Direct theme modification.

    Compatibility status would be displayed in the ACP (some modifications may fail due to heavy layout changes in relation to the Core theme), with more prominent warnings related to active plugins.

The system could allow administrators to mark the theme as compatible with the current version of the plugin manually to allow corrections (e.g. moving a widget to a different place).
Similarly, the extension system could be improved to allow creating files with theme-specific modification instructions.


A more specific diagram for a hypothetical system without a full extension layer, where Core theme changes (other than adding custom resources) have to be applied either by "hard" theme modifications, or "live" modifications that leave the templates & stylesheets untouched in the ACP:

[Image: 19-theme-system-extension-inheritance-2.png]
devilshakerz.com/pgp (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪ keybase.io/devilshakerz
Reply
#16
@Devilshakerz

What you are proposing seems in fact ideal, that is to say I am not disagreeing.
But in practice, all this change looks like it will take a lot of development time.
What is the real reason for needing to make all this change?
Due to using filesystem to save the template? Or just to modernize the code?
Couldn't keep the current system if to keep the template in the database?
Couldn't move those ideas to 1.10 ?

Even though the hierarchy system is resolved with these proposals, there are still several outstanding issues that may be caused by the changes to the filesystem.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)