The 1.9 theme and template system
#1
With 1.9 development hopefully to resume soon, it seems useful to discuss how the key new change - the migration of the template system to Twig - will be finalised. The current plan seems to be to move templates out of the database and into the filesystem, so that they can be more easily edited outside of the MyBB admin interface itself.

There are pros and cons to this. Here are those of which I am aware:

Pros:
  1. Filesystem editing of templates offers more flexibility and user-friendliness in general.
  2. Filesystem editing of templates makes the template/theme design task easier for theme designers.
Cons:
  1. Filesystem editing of templates makes reliable synchronisation of template/theme metadata impossible.
  2. Switching to filesystem editing of templates and discarding the existing DB-based paradigm involves more work, and delays the release of 1.9.
For me, the cons outweigh the pros, but this is not a hill on which I plan to die; if the consensus is to go with filesystem templates, then that's OK with me.

Just briefly, here's why I think metadata is important:

I envisage a future in which the Find Updated Templates feature is largely unnecessary, because on upgrade, the system detects the version on which a template was based, the version to which it is being upgraded, and auto-generates the equivalent of a patch between the two, which it then auto-applies when it can, regardless of any edits the admin has made to the template. (I'd like to see the same for stylesheets too).

This means, though, that when templates (and stylesheets) are edited, one piece of metadata needs to be reliably stored/updated: the version on which the edited template (or stylesheet) was based. We can ensure reliable storage/updating of this metadata when we require template/stylesheet editing to be done through the ACP. We can't when users can edit templates/stylesheets in the filesystem.

Anyhow, there are more than likely other pros and cons, and other considerations. Given that resumption of work on 1.9 is getting closer, I thought it was worth starting a public discussion to get community input.
Reply
#2
It is important to note that the idea is to make the web interface as intuitive as possible to motivate users to not use the file system. With this in mind, and although I agree with the move to file system, it could be delayed for later and improve the ACP module first.
Reply
#3
(2021-04-24, 11:01 PM)Omar G. Wrote: It is important to note that the idea is to make the web interface as intuitive as possible to motivate users to not use the file system. With this in mind, and although I agree with the move to file system, it could be delayed for later and improve the ACP module first.

There was a suggestion in GitHub issue #3686 to integrate Shade's FAStyle plugin into core - perhaps that's one relatively efficient way to improve the web interface.

Separately, I should add that GitHub issue #3689 - 1.9 Theme System - is also very relevant to this discussion.
Reply
#4
sorry for the noob question.

is it possible to use template stored in database using twig?
for me it was not possible that is why mybb was migrating to filesystem.

i checked here...

yes possible use database to store template using twig...

https://twig.symfony.com/doc/2.x/recipes...-templates
https://twig.symfony.com/doc/3.x/recipes...-templates

if it's possible I can't see the advantage of moving to the filesystem.

for me migrating to filesystem will delay the launch of 1.9 even more

and not to mention that modifying to filesystem will change a lot how the plugin developer will deal with modifying a template. This will also have to be taken into account.
unless mybb will be able to keep the function as find_replace_templatesets even moving the template to the filesystem.
Reply
#5
I won't be sure that find_replace_templatesets() will stay, but the ideal would be that designers, developers, and admins use the ACP to edit templates in such a way that they won't need to meddle with the file system.

I think FASTyle could be a nice addition to the core, if it fits (it would be a waste to lose such contribution over the years too IMO).
Reply
#6
(2021-04-25, 05:32 AM)Omar G. Wrote: I won't be sure that find_replace_templatesets() will stay, but the ideal would be that designers, developers, and admins use the ACP to edit templates in such a way that they won't need to meddle with the file system.

maintaining a template in the database is not difficult to maintain this function. Now moving to filesystem will be very difficult, since this function will have to be rewritten practically from scratch if you decide to keep it. Now if you decide to remove this function it will be a considerable modification for plugin developers. Like phpbb which has no similar function and uses hook system to template to their extension. Honestly, the customization capacity is much higher with this function (find_replace_templatesets ()) than a simple hook system.

(2021-04-25, 05:32 AM)Omar G. Wrote: I think FASTyle could be a nice addition to the core, if it fits (it would be a waste to lose such contribution over the years too IMO).

regardless of using FASTyle or not, I think I should keep a template in the database. It is one thing to use this plugin or not, to move or not to filesystem is a totally different matter. And the most important, move to filesystem will delay the release of 1.9.

Although I'm not a big fan of this as well as having unresolved problems https://community.mybb.com/thread-159288...pid1358659 and not to mention that the developer of this is no longer with us.

If Mybb wants to switch to FASTyle it should be at 1.10, everything that could delay the 1.9 release should have a lower priority than the 1.9 with a new theme.

keep in mind that my suggestion has only one goal, not to create more jobs that may delay the 1.9 release. There is no point in wanting to do more than the current team can do with their free time. We are missing out on several potential users for wanting to do more than is possible.
Reply
#7
(2021-04-25, 06:08 AM)martec Wrote: keep in mind that my suggestion has only one goal, not to create more jobs that may delay the 1.9 release. There is no point in wanting to do more than the current team can do with their free time. We are missing out on several potential users for wanting to do more than is possible.

I share this goal. I understand that a blog post weighing up the advantages and disadvantages of filesystem-based templates might be on the way, so the team is definitely open to discussion/explanation of this decision.
Reply
#8
(2021-04-25, 09:10 PM)Laird Wrote: I share this goal. I understand that a blog post weighing up the advantages and disadvantages of filesystem-based templates might be on the way, so the team is definitely open to discussion/explanation of this decision.

Thanks for the answer.
For me, the issues raised here https://github.com/mybb/mybb/issues/3689 will require a lot of work and time.
If stored in a database, many of the issues could be resolved with adaptations to the codes, unlike storing in filesystems, practically everything will have to be written from scratch.
I understand that filesystem can has advantages, but those advantages will not mean anything if there is no release due to those extra jobs.
Reply
#9
(2021-04-24, 10:56 PM)Laird Wrote: I envisage a future in which the Find Updated Templates feature is largely unnecessary, because on upgrade, the system detects the version on which a template was based, the version to which it is being upgraded, and auto-generates the equivalent of a patch between the two, which it then auto-applies when it can, regardless of any edits the admin has made to the template. (I'd like to see the same for stylesheets too).
Yes please. There are so many support threads caused by outdated templates. You can't even blame the users because the upgrade script basically tells them they are done when they are not and the last step is hidden somewhere in the ACP. And even if they find it the diffs are often hard to understand. Auto-applying patches or just guiding them though that step would drastically improve upgrades and stop so many issues.
Changes to stylesheets are currently only mentioned on the blog post and nowhere in the software itself. That needs to be improved, too.

Similarly MyBB should try to update themes when you import themes made for older versions.
[Image: banner.png]
Reply
#10
Save Old Theme Data on Update

Adding versioning support for themes. Instead of overriding all information, MyBB would keep data of previously installed themes when uploading new versions or updating MyBB (and core templates/stylesheets).

This information would be used to create better visual comparison to help with MyBB and plugin updates, and potentially automated patching (or patch suggestions) for themes with changes to templates that were previously inherited.

In MyBB ≤ 1.8, the ACP's Diff Report only compares the parent theme with the child theme — a template content comparison between different versions of the parent theme would indicate changes that need to be applied in the child theme more clearly.

This data could be pruned automatically when not needed (i.e. no potential problems are detected in dependent themes) and manually.


Encourage Good Inheritance Practices

Core templates and stylesheets would continue to be considered read-only, and changes would be picked up during File Verification.

The interface should point out that any customizations (as a result of activating plugins or applying manual changes) should be made in child themes, rather than themes that were downloaded, for easier theme updates and reverting changes. Uploaded themes can be marked as "original" and publicly hidden to help facilitate this.


Theme Extension Functions

Instead of executing custom code to change themes during (un)installation or (de)activation, plugins would return information that would be handled by MyBB as needed.

Example:
function myplugin_extend_theme(): array
{
    // provide an array of theme changes
    return [
        // add a template
        \MyBB\ExtendTheme\Template('custom_page.twig')
            ->setContent('Hello {{ username }}'),

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

        // add a stylesheet from file
        \MyBB\ExtendTheme\Stylesheet('custom_page.css')
            ->setContentFromFile(MYPLUGIN_DIRECTORY . '/stylesheets/custom_page.css')
            ->setAttachedTo('custom_page.php'),
    ];
}

[Image: 19-theme-system-extension-inheritance.png]

These changes would help with:
  • keeping track of automated theme changes more transparently (allowing administrators to review, apply, and revert a plugin's changes in selected themes)
  • building instructions to revert or update changes automatically, reducing extension maintenance overhead
  • adding more instructions for theme changes (cf. IPS' theme hooks)
  • supporting live (compile-time) template hooks

Additionally, extensions could register own paths to Twig templates and stylesheets to avoid modifying themes directly (but themes could still overwrite them).

Old System Plugin Compatibility

For compatibility purposes, activated themes would still populate the mybb_themes and mybb_templates tables to insert theme references.

This could allow plugins to continue to attach custom eval()-based templates to individual themes, potentially reducing plugin breakage to additions/modifications/removals in theme templates (i.e. old plugins could use the old system to render their own templates, but would need corrections to modify a Twig template to add their variables with widgets).

This behavior would be removed in subsequent series.
devilshakerz.com/pgp (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪ keybase.io/devilshakerz
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)