Posts: 1,101
Threads: 43
Joined: Aug 2017
Reputation:
212
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:
- Filesystem editing of templates offers more flexibility and user-friendliness in general.
- Filesystem editing of templates makes the template/theme design task easier for theme designers.
Cons:
- Filesystem editing of templates makes reliable synchronisation of template/theme metadata impossible.
- 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.
Posts: 9,757
Threads: 389
Joined: Jan 2010
Reputation:
526
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.
Soporte en Español
Discord at omar.gonzalez ( Omar G.#6117 ); Telegram at @omarugc ;
Posts: 1,101
Threads: 43
Joined: Aug 2017
Reputation:
212
(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.
Posts: 2,530
Threads: 124
Joined: Jul 2011
Reputation:
293
2021-04-25, 04:09 AM
(This post was last modified: 2021-04-25, 04:39 AM by martec. Edited 1 time in total.)
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.
Posts: 9,757
Threads: 389
Joined: Jan 2010
Reputation:
526
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).
Soporte en Español
Discord at omar.gonzalez ( Omar G.#6117 ); Telegram at @omarugc ;
Posts: 2,530
Threads: 124
Joined: Jul 2011
Reputation:
293
2021-04-25, 06:08 AM
(This post was last modified: 2021-04-25, 06:30 AM by martec. Edited 4 times in total.)
(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.
Posts: 1,101
Threads: 43
Joined: Aug 2017
Reputation:
212
(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.
Posts: 2,530
Threads: 124
Joined: Jul 2011
Reputation:
293
(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.
Posts: 4,241
Threads: 113
Joined: Jan 2006
Reputation:
111
(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.
Posts: 2,387
Threads: 219
Joined: Jun 2011
Reputation:
234
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'),
];
}
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.
|