Addons vs Styles

[Ozzy47]

Why are addons restricted from replacing to much of a template, but styles can completely change templates?

No I don’t have any specific styles, just asking because some styles can not achieve the layout they have without major changes to templates.

 

[Chris D]

The resource standards are focused on add-ons because that's the area which has the largest scope to cause issues.

Nonetheless, a style replacing huge amounts of templates can equally break add-ons injecting stuff into templates so it should be avoided where possible.

 

[Ozzy47]

See now there lies the gray area (at least in my eyes), point 18 states to be careful to not replace to much of a template, but for styles it should be avoided if possible?

A designer can say it’s not possible to avoid it to get the desired affect they are after.

 

[Chris D]

It's not something that's ever been brought up as an issue, so I'd really need specifics.

If you're working on some theoretical assumption, I can only tell you it's probably not worth worrying about. If you're working with specifics in mind then either the TM on the add-on side is trying to match too much, or the approach the style has taken is problematic. I'd be surprised if a compromise couldn't be found.

 

[Ozzy47]

Main reason I am asking is because I have an addon that completely overwrites the registration form. It uses much of the same code as in the core, just tweaked a bit.

I have tested it on various styles and with other addons that use the TM system to inject their code into the registration template and so far everything works together.

But I can not release the addon being bound by point 18 of the resource standards.

 

[Chris D]

I'd probably need some convincing that replacing the entire template is necessary.

 

[Ozzy47]

Well I could use the TM system and do 10 -15 different TM to it, but that does not seem optimal to me.

 

[Chris D]

No... Replacing the entire template is not optimal, that's the entire point.

10-15 TMs is less optimal for the developer (from the perspective of having to add and maintain them), but that's it. TMs have no performance impact because they are applied to the compiled template.

So, you're right to be concerned. We wouldn't allow an entire template to be replaced, but the good news is you can put the work in, and apply the changes sensibly, and that would be acceptable and likely to cause the fewest issues going forward.

 

[Ozzy47]

That honestly blows my mind. But I’ll have a go at it when I can devote some time to it.

 

[Chris D]

What blows your mind about it?

 

[Russ]

At least add-ons can utilize template modifications, major edits on styles have no choice but to edit the templates directly.

 

[Ozzy47]

What blows your mind about it?

That 1 - 15 (could be more not at PC to look) find and replace in a template is more efficient than 1 complete rewrite.

 

[Chris D]

It's not a question of efficiency. As I said, the TMs are applied to the compiled template so that happens once, at compile time. There is zero performance impact.

1 complete rewrite, however, will inevitably break things. If not now, then certainly in the future.

 

[Ozzy47]

At least add-ons can utilize template modifications, major edits on styles have no choice but to edit the templates directly.

Yes it’s nice. But the problem is that a style can change major blocks of code in the templates, but a addon can’t.

 

[Ozzy47]

It's not a question of efficiency. As I said, the TMs are applied to the compiled template so that happens once, at compile time. There is zero performance impact.

1 complete rewrite, however, will inevitably break things. If not now, then certainly in the future.

Still blown away. So I can have 50 addons installed, each with 10 TM added, and that does not affect performance at all?

 

[Chris D]

Yes it’s nice. But the problem is that a style can change major blocks of code in the templates, but a addon can’t.

You keep comparing changing major blocks of code (and honestly in many years I don't recall actually seeing any issues arise from this to the point where the issues can't be resolved) to replacing a template entirely.

Still blown away. So I can have 50 addons installed, each with 10 TM added, and that does not affect performance at all?

Correct.

 

[Snog]

I THINK I see what @Chris D is saying here.

Take this template code in the PAGE_CONTAINER template:

<xf:if is="$headerHtml is not empty">
    <div class="p-body-header">
        {$headerHtml|raw}
    </div>
<xf:elseif contentcheck="true" />
    <div class="p-body-header">
    <xf:contentcheck>
        <xf:if contentcheck="true">
            <div class="p-title {{ $noH1 ? 'p-title--noH1' : '' }}">
            <xf:contentcheck>
                <xf:if is="!$noH1">
                    <h1 class="p-title-value">{$h1}</h1>
                </xf:if>
                <xf:if contentcheck="true">
                    <div class="p-title-pageAction"><xf:contentcheck><xf:pageaction /></xf:contentcheck></div>
                </xf:if>
            </xf:contentcheck>
            </div>
        </xf:if>

        <xf:if is="$description is not empty">
            <div class="p-description">{$description}</div>
        </xf:if>
    </xf:contentcheck>
    </div>
</xf:if>

If the intention of the add-on is to change that entire section of code, then it should be done with a template, not just a template modification. IE a template modification that applies the new template under certain circumstances.

If that's not what @Chris D is saying, then the idea that styles can replace that section at will with a different template or a macro call (which happens in many custom styles) is a catch-22 for add-on developers that want to do the same thing. Because it does happen in custom styles and does break add-ons that might look to modify that section of code when it doesn't exist in a custom style.

This is where the rules need to be somewhat flexible and take into account the intent of the add-on. I think this was discussed somewhere when the rules were first published and it was said the intent would be considered when the rules were applied. Otherwise if the rules are hard, steadfast rules, they should be applied to style developers as well since their changes can just as easily break things as an add-on developer's changes.

 

[Snog]

You keep comparing changing major blocks of code (and honestly in many years I don't recall actually seeing any issues arise from this to the point where the issues can't be resolved) to replacing a template entirely.

Even replacing an entire template can cause issues with both XenForo and add-ons. It depends on what changes are made in a XenForo update and what changes were made in the new template for add-ons to interface to them.

If XenForo changes a major point in a template and the custom style contains the old major point XenForo could throw errors. Thus holding the site owner hostage until a style update is issued. Something an add-on would also have to do if the XenForo change affected it's changes.

If the custom style does not contain that major point, then add-ons that might look to modify that point in a template would be unable to do so, possibly fail and throw an error.

Again a catch-22 for add-on developers due to conflicting limitations with style developers. The same condition can exist in a style as an add-on, but add-ons can't make the changes a style can. (contain or not contain the same code as an XF template)

For those that don't know a catch 22 is:

A catch-22 is a paradoxical situation from which an individual cannot escape because of contradictory rules or limitations.

 

[Aivaras]

XF is admin-centric. It is the admin who assumes the ultimate responsibility of running a website. Template syntax is what an admin controls directly and immediately. As a consequence, he or she is granted a greater scope of action.

In contrast, add-on syntax is what an admin does not have the means or competencies to control directly and immediately. The latter situation creates its own risks and XF addresses them through an ad hoc safety measure.

 

[Snog]

XF is admin-centric. It is the admin who assumes the ultimate responsibility of running a website. Template syntax is what an admin controls directly and immediately. As a consequence, he or she is granted a greater scope of action.

In contrast, add-on syntax is what an admin does not have the means or competencies to control directly and immediately. The latter situation creates its own risks and XF addresses them through an ad hoc safety measure.

I agree, which is why I mentioned using a template in conjunction with a template modification. That allows the admin to edit the template if needed, while still preserving the template modification.

However, the idea that you can't replace a large swath of code in a template as a developer is what I'm questioning because style developers do it all the time. If it's done as I described by replacing the large swath with another template, I don't see the problem. But rule 18 is pretty vague about if and how much of a template can be replaced via the method of using a template modification to inject a template. Which leaves it open to interpretation and could be quite limiting on what an add-on can and can't do.