Blog Module Template inheritance

<%- if @topic_view.topic.tags.present? %>
<%= t 'js.tagging.tags' %>: <%- @topic_view.topic.tags.each do |t| %> <%= t %> <%- end %>
<% end %>

SS4.1

I’m trying to get the blog module to recognise my templates in the mysite folder. What’s the best way to do this, and what is the order of inheritance?

1 Like

Given the following structure, this is the inheritance order:

  1. Custom themes, e.g. themes/mytheme/templates/SilverStripe/Blog/Model/Layout/Blog.ss
  2. Your project code, e.g. mysite/templates/SilverStripe/Blog/Model/Layout/Blog.ss
  3. The blog module, e.g. vendor/silverstripe/blog/templates/SilverStripe/Blog/Model/Layout/Blog.ss

When you have multiple themes the inheritance order is defined by the priority you give themes in your YAML configuration, for example:

# File: mysite/_config/theme.yml
---
Name: mythemeconfig
---
SilverStripe\View\SSViewer:
  themes:
    - '$public'
    - zoos
    - businesses
    - '$default'

In the example above a template that exists in the “zoos” theme will be used over the “businesses” theme. After that SilverStripe looks at mysite (or whatever your project code is stored in) and finally will go through the modules alphabetically (ascending) until it finds one that matches. This means that a Blog.ss in the correct folder structure under vendor/foobar/blog is going to be used over vendor/silverstripe/blog. Note that this alphabetical behaviour is probably not totally safe to rely on - you’re much better off using cascading themes to control priority.

2 Likes

Thanks, all working now.

Where are the $public, $project & $default variables defined (or what do they refer to)?

@Peter_Koopman $public is a placeholder theme name for enabling the public webroot available in SS 4.1 and newer, and will allow backwards compatibility for it.

$default is a placeholder for any module templates, e.g. your project (mysite), framework, CMS, blog.


When you see $project referenced in configuration you’re either defining what it should be (default: mysite) or using it to control module load order via SilverStripe\Core\Manifest\ModuleManifest.module_priority. At time of writing the reason your project code/templates are loaded before any core modules is because of this framework configuration:

---
Name: modules-project
Before: '*'
---
SilverStripe\Core\Manifest\ModuleManifest:
  module_priority:
    - $project
2 Likes

In SilverStripe 3.6 it was possible to override templates by creating a custom directory containing templates like so:

blog-custom/templates/Layout/Blog.ss

Is this possible at all in SilverStripe 4.1?

1 Like

Thanks Robbie, that’s great. Good reference post as well.

Got another issue on this topic - the blog on my local is displaying correctly, but on the dev server it uses the default blog templates, and it won’t read my custom templates in mysite. As far as I can see everything is the same except the .env file. Any idea where I should start looking?

Definitely flushed - multiple times. I did change the folder to public on the server, but it didn’t seem to make any difference.
Then I got the following error when I ran composer vendor-expose:
PHP Parse error: syntax error, unexpected '.', expecting '&' or variable (T_VARIABLE) in /var/www/vhosts/cheersold.org.nz/cheersss4.truedigital.co.nz/vendor/silverstripe/vendor-plugin/src/Util.php on line 13

Sanity check - did you flush when you deployed? Also check that your settings are the same in terms of the public web root (if you’re using SS 4.1 or newer), that is that your web server is serving from /projectroot/public instead of /projectroot and that your $public is added to the themes list. This shouldn’t affect templates, but also re-run composer vendor-expose to ensure assets are symlinks correctly.

1 Like

Which suggests it may be a php issue. I’ll investigate further

It is, but you need to match the namespace of the original template in your folder structure. eg:
blog-custom/templates/SilverStripe/Blog/Layout/Blog.ss

…as well as making sure that the modules load in the right order.

1 Like

It looks like you might be using an incompatible version of PHP. SilverStripe 4 requires PHP 5.6 or newer.