Problem with inherited theme

Support Themes & Styling
1

I have downloaded the Quark based skeleton “Blog Site” and spun up a development Grav site on my local system using the command bin/grav server.

I have installed PHP 7.4.33 - which matches my production servers. The site runs great out of the box. I want to make some tweaks to integrate various plugins and some of my own stuff. I installed the Developer-tools plugin and created an inherited theme called Montana.

I installed all the plugins that match my production system and copied some of the settings from production to user/config/plugins. Everything is running great.

I have copied several html.twig files from the Quark theme to my Montana theme and modified them - verifying everything works between each change. So far I have changed logo.htm.twig, footer.html.twig and added a couple new twig files that are not in used yet.

I copied a vanilla sidebar.html.twig to my theme and added some code to render a list of featured posts. CRASH! Ok - I deleted the file and copied over another vanilla copied and tested my site - no changes. CRASH!

This is the error I get on screen (browser):

Server Error

Sorry, something went terribly wrong!

0 - An exception has been thrown during the rendering of a template (“Object of class Grav\Common\Page\Media could not be converted to number”).

The same file works fine when it is in used with Quark theme. I checked the log. I am not sure it is worth posting all of that text - it is verbose!

I am not sure this should be posted to the Quark repo, as I am creating a new inherited theme. Not sure how to proceed. It is late - I am going to bed.

Thanks for any help.

2

@bjaz, Please help the community help you by providing a succinct question containing only relevant information.

I copied a vanilla sidebar.html.twig to my theme

  • There is no such thing as a vanilla template. No one will know what you have copied.
  • Where from? Do you have a link to the file on Github?
  • Does all work fine using the template?

Please also know that you cannot copy a template from another theme and expect it to work. Each and every theme and its templates have specific requirements and expectations about the configuration and structure of the site, folders, pages etc.

and added some code to render a list of featured posts. CRASH!

  • What code?
  • Did the error disappear after removing your own code?
  • Did the unaltered sidebar.html.twig template run fine?

I deleted the file

  • Did the error disappear?

and copied over another vanilla copied and tested my site - no changes. CRASH!

  • Stop
  • If an error occurs, do not stack more changes on top of that.
  • Go back to the state where everything worked. (That’s were Git comes in very handy.)
  • Make changes step-by-step until you can reproduce the error.
  • Look at the last error in the error log. (You may first want to delete the error log and reproduce the error again to trim down the error log).
    • Look at the last few steps of the trace of the error (starting with Trace #0, then #1, #2 etc.) to see where the error originated. It usually contains a file name from your site (template or php file) and a line number.
    • Share that error information.
  • From the template, share a few lines around the line number found in the error log.

This will be a good start of providing succinct and relevant information…

3

By Vanilla - I mean the twig file that is from the repo - no changes. Here is the file.
The Quark theme works out of the box (i.e. without modification from the repo).

I appreciate this fact. In this case I am working with an inherited theme - inherited from Quark. I might be wrong in my thinking, but I believed that an inherited theme will use the parent theme files if there are not over-riding files in the inherited theme. Assuming that was the case I believed that just copying the source file from the parent theme to the inherited theme should not result in any change to the inherited theme. That is why I was surprised that it crashed the site.

I knew that my own code could be responsible for the crash, but since the crash occurred in the unaltered twig file I felt that my code was a red herring in this discussion. I only mentioned it to help explain how I got to where I was.

No the error did not go away after removing my code. Although I did not actually remove my code - so to speak, but rather replaced the altered file with a fresh copy of the unaltered file. I felt that was safer.

No the unaltered sidebar.html.twig file did not work. It produced the same error.

I was hoping to convey that this is exactly what I did. The issue really occurred with another inherited theme file that I created a week ago. I was just not sure how much I had changed and how much was original, and was unable to walk it back safely - that is why I decided to systematically build a second inherited theme - this time using the dev tools (in case the manual process I used the first time was the issue). I added small changed - tested, and them repeated until I realized the sidebar.html.twig was causing issues,

I tried this but I have to admit that the error logs look like Greek to me. In this case the error log had 66 steps and was 60,000 characters long. I could not make heads or tails of it.

So this morning - with a fresh head I decided to dissect the twig file. I enclosed each section of code that displayed content in comments removing it from being processed. The sidebar.html.twig file had just two lines in it that were actual code:

{% set feed_url = blog.url == '/' or blog.url == base_url_relative ? (base_url_relative~'/'~blog.slug) : blog.url %}
{% set new_base_url = blog.url == '/' ? '' : blog.url %}

I then uncommented a section at a time and refreshed the page to see if the server error was reproduced. After uncommenting all the code the page was working fine.

Now I am really scratching my head. So I saved that file elsewhere (since it works) and repeated my earlier step of copying an unaltered version of sidebar.html.twig from the repo into my inherited theme partials folder. This is what I did before and it had caused a server error. This time testing the page there were no issues.

A ghost in the machine? Something is going on - but I am hard pressed to understand it.

Thanks to @anon76427325 for pointing out some things to help me and the community. I guess the problem fixed itself, but I do not know how.

4

I found it! The issue has to do with the Social Media Links plugin. Specifically code that checks to see if that plugin is enabled. I am not sure why that would cause that error. I looked at the PHP code for that plugin, but since I do not know enough about writing a plugin, I am not 100% sure what is going on inside there. I did open an issue on the repo site.

5

@bjaz, I’m sorry to say, but this is not a problem of the Social Media Links plugin. It’s a PEBKAC problem.

In the issue you’ve created on Github, you’re showing the following code snippet:

{% if config.plugins.social-media-links.enabled %}
  {% include 'partials/socialmedia.html.twig' %}
{% endif %}

It’s the use of dashes (-) that creates the issue. You are actually creating a subtraction: config.plugins.social - media - links.enabled.

media is a Grav object available in Twig and objects do not go well in subtractions…

6

According to the documentation about Config Variable Namespacing the plugin filename is part of the config variable namespace and the filename of the social-media-links plugin includes dashes.

So technically this namespace config.plugins.social-media-links.enabled is correct but as @anon76427325 pointed out will fail because Twig treats each dash as an operator (minus).

Fortunately there’s a solution in Twig as mentioned in the forum post "Test if a plugin is enabled with a plugin name like my-plugin-name.

Changing:
config.plugins.social-media-links.enabled
into:
config.plugins.['social-media-links'].enabled
should do it.

BTW A tour around the official plugins shows that plugins which use Twig never have a dash in their filename.

1 Like
7

@anon76427325

It always seems to be I find. LOL.

Well that explains a lot. I saw that in the plugin PHP code the plugin name was formatted that way:

$pages = $this->config->get('plugins.social-media-links.social_pages.pages');

Is there a reliable way of determining the name of a plugin for use in the twig?

8

Yes there is. Please see my answer just before your last post.

9

@bjaz, Since your issue has been solved, it might be a kind gesture to the developer of the plugin to close the issue you created at Github…

10

Another solution is to use the get function on the config object.

For example, line 7 in user/plugins/flex-objects/templates/flex-objects/page.html.twig reads:

{%- if page_assets.css ?? config.get('plugins.flex-objects.built_in_css') ?? true %}

Like you @bjaz wrote, in PHP one can do:

$pages = $this->config->get('plugins.social-media-links.social_pages.pages');

and so the same in Twig is pretty similar:

{% set pages = config.get('plugins.social-media-links.social_pages.pages') %}