MyBB Community Forums

@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";.

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

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

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.

(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 path — Core 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:

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

@Devilshakerz,

It was difficult for me initially to understand your proposal, which is why it has taken me so long to reply: I kept on putting off spending the necessary time to read and reread your proposal so as to fully understand it. However, the point at which 1.9 development resumes is near, so I have now spend the time necessary to understand what you propose.

To be sure that I understand you correctly, here's a summary of what, on reflection, I think you're proposing, perhaps in a slightly more concrete way than your more abstract description. I hope you correct me if/where I've misunderstood:

In your diagram, "Core theme" refers to the default theme supplied with MyBB core.

Custom theme developers base their custom designs upon, and inherit from, that core theme. This leads to what we might refer to as a "Custom-designed theme" or "Custom theme" for short (terms not used in your diagram), such as might be uploaded to the Extend site. These (raw) custom-designed themes are not explicitly shown in your diagram.

Extensions then provide to an "Extension layer" (per your diagram) a set of instructions as to how the core theme should be modified to satisfy the functionality of each extension. The extension layer then modifies the core theme according to those instructions. The result of applying these instructions to the core theme alone, resulting in an extension-modified core theme (as opposed to an extension-modified custom theme) is not shown in your diagram. In terms of your diagram, we would visualise this situation as one in which a custom theme is identical to the core theme, standing in for it.

At the same time as modifying the core theme, the extension layer modifies all custom themes according to those instructions, resulting, for each custom theme, in an "Original theme" (per your diagram). Conflicts may need to be manually resolved in the process of modifying custom themes into original themes. The changes made by the extension layer, including the resolutions of conflicts, are permanent; that is, they are stored across requests and do not need to be regenerated for each request.

Extensions then get a second bite of the cherry: they can again modify original themes in an almost identical way as they modified custom themes - that is, by supplying a set of instructions - with the result, for each original theme, being a "Board theme" (per your diagram). These changes are, as for changes made by the extension layer, stored permanently.

Finally, extensions get a third bite of the cherry: they can dynamically adjust board themes per-request by hooking in to the template system. These dynamic changes are - as "dynamic" implies - not permanent, and are not stored between requests; they are regenerated on each request.

Does that seem like a fair summary of your diagram/proposal?

(2021-07-08, 12:41 PM)Laird Wrote: [ -> ]Does that seem like a fair summary of your diagram/proposal?

In the interests of increasing bandwidth, I'm going to at this point assume that it is, and suggest that, given my understanding, a more accurate[1] diagram would be something like the following. Please forgive my poor diagramming skills - it's been many years since I've done this, and the tool I chose (LibreOffice Draw) seems imperfect, and does not want to properly connect the start of the second arrow from "Extensions".

[1] Based on including the "custom-designed themes" (or "custom themes" for short) that above I noted were explicitly missing from your own diagram.

As you can see from the diagram based on my understanding of your proposal, there is in fact no room for three "bites at the cherry", only two.

Even then, we might wonder what the purpose of the "second bite" is. Is there any need for plugins (extensions) to modify themes/templates dynamically? In what scenarios would dynamic modification be useful over and above permanent modification?

Based on my last two posts, here are some thoughts on @martec's response:

(2021-05-13, 04:19 AM)martec Wrote: [ -> ]@Devilshakerz

What you are proposing seems in fact ideal, that is to say I am not disagreeing.

Hmm. I am not so sure that it is ideal though. In particular, I'm not convinced of a need for plugins to have even two opportunities to modify themes, let alone three. I'm open to being convinced that one or the other is a good idea though.

(2021-05-13, 04:19 AM)martec Wrote: [ -> ]But in practice, all this change looks like it will take a lot of development time.

Agreed. Even if we can be convinced that it is a good idea for extensions to have multiple (at least two if not three) opportunities to modify themes, we should probably prioritise the release of 1.9 over developing these features, which would rob us of precious time.

In my diagrams, the earliest effect of extensions is appending custom resources (like templates and CSS files) that can be overridden, without affecting the core theme. Core theme and Extension resources can be understood as independent and parallel origins at the root of the inheritance chain.

An Original theme could be downloaded from Extend, and the system would discourage editing it directly - instead, a child Board theme would be modified for plugin compatibility and manual, board-specific adjustments.

The second effect of extensions builds upon the current way templates are modified by plugins. In most cases in 1.8, the only controls are activating and deactivating individual plugins, and it affects all themes - this operation may fail, be undesired for all themes, or be unnecessary due to the administrator intending to customize the extension's edits further. It should be possible to track these changes and allow administrators to review/apply/revert these changes with more precision and per theme.
This is not required for 1.9.0, but the system shouldn't add any additional hurdles to implementing this.

The third effect of extensions relates to dynamic changes shortly before output, and can be treated as an experimental alternative to modifying templates permanently.
That's the second way for extensions to modify templates, and is certainly not required for 1.9.0, but included here for completeness of a potential plan for the final architecture.


This diagram includes additional notes and indicates that the inheritance chain is not limited to one Original or Board theme.