Breaking templates up

[Arantor]

Right now, a template file contains multiple templates all related to a given section - e.g. Profile.template.php contains all the profile pages.

I'd like to see each individual page become a single template file in its own right, e.g. profile_summary, profile_stats, replicated throughout the entire platform.

That means if a themer wants to replace any individual part of the platform with something different, this is trivial. It also means people customising the platform themselves can focus on just the one thing without worrying about maintenance of everything else.

On top of that, I'd suggest some of the things that logically should be reusable components get turned into just that: partial templates that can be reused somewhat on their own, e.g. the display of a single board (from board index, message index), or some of the individual components that people want to change independently of everything else (linktree, pagination)

Heck, you could even make 'category heading' a component so if you wanted to change the markup everywhere for whatever reason, you could do this beyond futzing with styling. I think it would also make it easier for mod authors to build mods that followed the style of themes if they could just use components and pull them in however.

As an aside, this is also super convenient for turning into something you could do with a template engine, where instead of making people fight with raw PHP for edits, they can wrestle with something safer that you can edit in the admin panel where you can sanity check it and report on errors before saving. (You can even go down the road of keeping edit history at this point.)

[Antechinus]

Umm, yes, sort of. TBH I am wary of fragmentation for the sake of fragmentation, having seen that in another forum app. You can end up chasing opening and closing tags across separate files, etc, and it can become a real PITA for theming. Quite apart from the sheer number of files to keep track of. There is something nice about having all the profile bits in one place. IOW, fragmentation is a swings and roundabouts deal to some extent, not an unmitigated bonus. So I could be in favour of it, if it was done sanely, but could get quite annoyed with it if it was just done for the sake of doing it.

Template engines? Pffft. You can still klll your site with a parse error even if the template is running Twig. Ask me how I know. My 2c is Twig , etc are just more crap to deal with and more syntax to learn. I'd rather keep the raw PHP. I can sanity check it easily enough anyway.

[Arantor]

Twig without safety rails, sure, you can screw it up. But what I was suggesting was having safety rails to prevent that exact thing. Like other platforms do.

None of this is new, or surprising, this is just catching up to what grown-up platforms were doing a decade ago.

Just because it's more convenient for you personally doesn't mean it's more convenient for the majority of SMF's admins doing tweaks.

I mean, it's not like I haven't actually... oh, I don't know... tried it or anything.

Oh wait. I did... https://github.com/StoryBB/StoryBB/tree/master/Themes/natural/templates

[Antechinus]

I've only seen Twig on phpBB, which does not appear to have safety rails (do not get me started on phpBB templating). If there are sane ways of adding these safety rails, that should be fine.

[Arantor]

So my version doesn't have the safety rails because I ended up stuck with a different template engine for stupid reasons and I haven't had the energy to rewrite all the templates AGAIN to Twig yet. But safety rails on Twig (or actually any other template engine) is easy enough if you're doing it inside the admin panel for all the people who aren't themers, and for the people who are you don't *really* want the safety rails so much anyway because they'll just get in your face when doing things. It doesn't seem to have been a huge drama for XF to implement and they rolled their own template engine while they were at it.

But whether it's Twig or Laravel or anything else, the notion of having a layout with slots to insert general things as placeholders, then treat smaller chunks as pages with components, so you keep the content in each layer of the template structurally encapsulated - it's really not a new idea.

[Antechinus]

I'll take your word for it. As I said, I've only seen it running on phpBB and their implementation of it is, to be frank, a total pig's breakfast.

... for the people who are you don't *really* want the safety rails so much anyway because they'll just get in your face when doing things...

Give me a way around muppet-proofing, and I will move the world.

[Arantor]

their implementation of it is, to be frank, a total pig's breakfast

What in phpBB doesn't qualify under that description, though?

[Antechinus]

Exactly. Ergo my comments about fragmentation. I don't doubt that you would do it sanely, but you're not going to be in full control of what happens in the SMF repo.

[Oldiesmann]

Breaking up templates definitely sounds like a great idea. It will make things a lot more flexible for one and possibly encourage themers to play around with the layout a bit more

[Bloc]

This was discussed years back but never caught on...but for what its worth it has my vote.

I did some work on making themes OOP for my-one-time-SMF-fork, it seemed interesting to just build on the parent themeobject. In the end I realized it wasn't so much different from just replacing templates, but at least you could more easily swap out a subtemplate routine by just replacing any function through the object. I think i had to do several objects though..don't remember exactly atm.

EDIT: looked it up: I was doing 2 objects under the themeobject umbrella: one that contained the functions that always loaded, like index.template and then a separate [any]-template-object for whichever section  was loading. The themeobjects in the custom theme would only contain the changed functions so they were smaller(as opposed to replacing a full on template in SMF).

[Bugo]

Each template engine is good in its own way.


SMF's PHP:

Code Select Expand

if (!empty($items))
{
    echo '
    <ul>';

    foreach ($items as $item)
    {
        echo '
        <li>', $item, '</li>';
    }

    echo '
    </ul>';
}

PHP, short syntax:

Code Select Expand

<?php if ($items): ?>
<ul>
<?php foreach ($items as $item): ?>
<li><?= $item ?></li>
<?php endforeach ?>
</ul>
<?php endif?>

Twig:

Code Select Expand

{% if items %}
    <ul>
        {% for item in items %}
            <li>{{ item }}</li>
        {% endfor %}
    </ul>
{% endif %}

Blade:

Code Select Expand

@if ($items)
<ul>
@foreach ($items as $item)
<li>{{ $item }}</li>
@endforeach
</ul>
@endif

Latte:

Code Select Expand

<ul n:if="$items">
{foreach $items as $item}
<li>{$item}</li>
{/foreach}
</ul>

Antlers:

Code Select Expand

{{ if items }}
<ul>
{{ items }}
  <li>{{ value }}</li>
{{ /items }}
</ul>
{{ /if }}


[Tyrsson]

Personally, I prefer to use Template engines, or should I say Renderer implementations, that:

• Uses or allows the simplified syntax if(condition):
• Uses or allows the use of the short open tag <?=

Depending on how the "modifications" are going to work in future versions of SMF and the approach taken in the core software itself. It could very well be possible to support more than a single template engine. I know that will never happen. Nearly all of the major template engines/renderers in development today handle the loading of templates in very similar (if not identical) ways. Because there is only so many different ways to accomplish it with anything resembling sanity. That's really the easy part. The hard part is when we start talking about modification of those templates in respect to mods. What direction is the TSC looking at taking the software in future versions in respect to that portion of the dev roadmap?

[Arantor]

It could very well be possible to support more than a single template engine

Please dear god no. That just guarantees time and energy spent with absolute futility.

Reasoning: mod authors will pick either what the core uses for compatibility, or they'll pick the one that's convenient to them, which means things won't be tested properly and it'll just fragment. Sort of like what happened to Postgres support.

What direction is the TSC looking at taking the software in future versions in respect to that portion of the dev roadmap?

I have no idea. I'd love to see the roadmap. I'm not worthy.

[Tyrsson]

@Arantor I threw that in there just for you  Wish I couldve been there when you read that suggestion roflmao

I think this is one of the major hurdles that has to be tackled to get from 2.1 to 3.0. I can  think of, see, several ways of how to get the data to the templates themselves, which is easy. The issue I think comes when how to provide the most seamless way to have mods incorporate themselves in the view/template layer of the application without directly modifying the file or incurring too much overhead to determine. Which I really do not see a way around...

[Bloc]

I have often been puzzled about the distinction between themes and mods in SMF..they are after all, conceptualwise, both "modifications". My earlier themes(and prob future ones) tend to blur that because I think with a more expanded "theme settings" functionality a lot of minor mods - and even some bigger ones - could easily been done in a theme(and thereby better security). I have tried making custom menu managers, selection of boards etc. as "theme settings/functions" in earlier themes, and now its even possible to allow themes to use hooks..but not without difficlty(since its not built especially for that).

The really complex mods with their own data tables etc. will always need to be just that, mods, but you could easily for example make simpler galleries or make certain boards use extra theme settings..and so on. It would not make that "theme mod" transferrable to other themes of course - unless the theme system was built such that theme settings can be carried over to other themes. 

Overall, in my mind it makes more sense to build on that, than to introduce another template engine. But there also very few that really use the theme system to its potential so i guess its a moot point..going down to a lesser capable but more secure template system makes sense. But its no fun in doing that IMHO.

[Arantor]

So I'm experimenting with what I would like to see in my own world.

I took the simplest template I could find that wasn't entirely straightforward - the first screen of the forget-password process. It's a form with the standard heading/roundframe panel look, a button and such like.

Using Twig plus a thing called TwigComponents I managed to get that page to be:

Code Select Expand

<form action="{{ remind_url }}" method="post" accept-charset="UTF-8">
<x-panel.heading>{{ txt('authentication_reminder') }}</x-panel.heading>
<x-panel.body>
<p class="smalltext centertext">{{ txt('password_reminder_desc') }}</p>
<dl>
<dt>{{ txt('user_email') }}:</dt>
<dd><input type="text" name="user" size="30"></dd>
</dl>
<x-form.button>{{ txt('reminder_continue') }}</x-form.button>
</x-panel.body>

{{ csrf() }}
{{ token('remind') }}
</form>

csrf() and token() emit the hidden inputs for security, txt() is a helper function that fetches language strings.

As for x-panel.heading, this is a very straight macro out to the normal <div class="cat_bar"><h3 class="catbg"> type markup, with x.panel-body being <div class="roundframe">.

It's just a way of creating standardised components that you can set up and use so modders can create a look that's consistent without having to worry too hard about maintaining it - meanwhile this gives themers much flexibility without having to hack up many templates.

But as you can see it's a work in progress.

[Tyrsson]

For my own projects, I think I am moving to this:

https://platesphp.com

[Arantor]

That honestly seems like the worst of all possible worlds; if you're going to do that, you might as well not bother with their boilerplate and just use PHP *as* a template language and be done with it.

[live627]

I sometimes use Liquid (when making a Jekyll site)

[Tyrsson]

That honestly seems like the worst of all possible worlds; if you're going to do that, you might as well not bother with their boilerplate and just use PHP *as* a template language and be done with it.

You know, I had wrote like 3 paragraphs explaining why its a perfect solution for what *I* am doing, but then realized that I'm not even going to waste the time to finish that reply. I posted the link in case anyone else might want to check it out, not because I wanted a review, thoughts, or opinions on it. Just thought it might work for someone else.