Newcomer evaluating Grav - Theme switching

Beyond the subject, I have been trying to eval Grav for just under a week. I have availed myself of the documentation and topics in the “Learn” section. I have worked through a fair number of problems and errors. I have hesitated to post here because I was convinced there had to be something obvious I was missing. And I have been able to get the software working several times and with various themes. For the sake of full disclosure, I am new to Grav and the “CMS” world. Not so new to everything else. And I cut my teeth on on BSD because I hated AT&T SysV.

That said - as I evaluate this product - which I admit looks wonderful, and very promising - I appear to be missing something where themes are concerned. I agreed to help a dear friend build a personal web-site complete with blog and image galleries and all that wonders of technology.
But starting with a theme that is close to what they want is a good idea. Except that EVERY TIME - no exceptions - EVERY TIME I try out another theme - I get all sorts of errors, because obviously the “warning” about pages/layouts not necessarily supporting the new theme are something more than warnings. So I set about installing every plugin/extension I could find, hoping that just one of them would be “easy theme switcher”.

Now it seems to me, were I designing this app, I would make sure that the simple selection of a theme didn’t break my web-site. So I would provide a compatibility test function, but more importantly, a MIGRATE function. If my pages don’t work, WHY? Can you fix them? Or should I delete them and start over? SOMETHING. ANYTHING. That prevents the site from just breaking.

I have no problem with a cli - I’ll spare the “Oh I was around when all we had was cli”.
But I have spent 90% of my time evaluating this product making love to google and using command line stuff that could have easily been placed behind the click() of a button.

My question is - Does switching to test out a new theme work this way?
Because that makes my decision pretty easy.

If I am just old and cranky and it’s causing me to miss something obvious because I’m frustrated, tell me that too. And if I have this right - am I the first one to say - That ain’t right. Switching themes, a UI component, should not break any app or site, ever. For any reason. Period. Then again, I’m old.

Any insight - pointers - all welcome.
If I’m wrong, telling me should include a solution otherwise what’s the use?

Welcome! I’m glad you’re not just giving up. Grav is an incredible CMS—certainly my personal favourite.

If I’m understanding you correctly, when you download a new theme and switch to it, you have rendering problems because of a mismatch in the names of templates and pages.

The root of this problem is that there are no required or hardcoded template names. The Theme Basics docs encourage theme writers to be consistent (see the “Templates” section). But there’s nothing stopping a theme developer from using any names they want.

So when you want to apply a new theme to existing content, there may be some manual tweaking you have to do. But usually all have to do is rename the content files, which you can do pretty quickly on the command line. I personally haven’t run into this problem with your basic blog. The good blog themes are pretty uniform in their naming.

While I agree with the sentiment that switching themes shouldn’t break an app, it’s somewhat unavoidable in a system as flexible as Grav. Grav doesn’t enforce certain template names, but it does encourage them and model them.

I hope this helps. Let me know if I misunderstood the problem.

Greetings and thank you for the quick reply! Absolutely I am not giving up so quick!
I’m frustrated, but I’m old school so I immediately think about how I can either write an extension to improve things or contribute code.

Yes, theme switching is the major issue currently.
I have not determined that it’s a naming problem, but I have seen a great deal of THESE:

The issue at hand is that to evaluate the product, before taking the time to create a bunch of pages using it(!!!) - right? You want to check out some of the possibilities using templates (or the skeletons which I’ve tried too). But 1: a theme with no demo pages is worthless unless you want to spend the time building pages using it - which - if I understand - are probably NOT going to work in any other theme! and 2: the loading of a theme does not “reset” the app in any way, meaning pages/settings and anything else that theme established REMAIN and will - to my finding - almost ALWAYS break your site.

I won’t mince words, having a theme that can alter the overall system such that it won’t work after being deactivated - causes me concern about the architecture of Grav. Again, I mean no offense. But to have themes where I take the time to build a set of pages - let’s say 20 on the low end - and then I say, hmmm, I really like the appearance of this new theme, let me TRY it out - and bam, none of my pages work anymore? I just dunno about that, and it seems to not work in real life.

I should mention that I develop commercial software apps, some which get marketed. And so the concept of styling/theming/skinning - not new to me. Also, my most recent apps include an extension framework which allows run-time assembly of any dotnet language, so extension technology, I get that. I’m just having a hard time where appearance interferes with functionality.

Enough of my sermon! (Us old guys we got sermons for days)

I appreciate your suggestions - and clarification. I have dealt with that fine balance between enforcing restrictions but yet allowing powerful extension. (see above about letting people write c# code that touches my apps! LOL) But I would suggest that a tool to “restore to sane” would be helpful.

In terms of renaming - I have no issue with that. HOWEVER, I have found no indication that’s what is going on. The errors are generic, and massive (lines and lines of errors from the same problem, bubbling up, not always good!).

So 1: is there a way for me to KNOW that a theme is playing by the rules or if it’s about to break everything I spent hours building? (If not, WHY not? Seems simple enough to build given there are guidelines, no?) Second, is the only real alternative here for me to do a full backup - test a theme and see how badly it breaks things - then restore? That wouldn’t be a problem, I know backups are zips, but a button to restore would be nice. And frankly seems like a pretty big oversight.

I appreciate your insight - and I continue to push forward!

I hear your frustration. Unfortunately I can’t speak to why the developers did things the way they did. But I can confirm that the error you’re seeing is indeed signalling a name mismatch. In your content you have a file named but the theme doesn’t have a corresponding home.html.twig template. I think front is the more common template name.

You can see what templates a theme supports by looking in it’s templates folder (here’s such a folder in my own theme, Knowledge Base). If there’s a mismatch, you can either change the name in the theme itself (not recommended because they’ll revert when you update), create a child theme and copy the template with the new name, or rename the file names of your content (again, doable from the command line).

And you don’t need to do some “full” backup. The only files you need to worry about is your user folder (which themes won’t touch) and the themes folder. So if you don’t like a theme, just change the config setting to point to the previous one. If you renamed your content files, you may have to rename them again. But none of this is going to corrupt your core install.

Ah, ok I’m getting this I think. And first - THANK YOU, sincerely. I am realizing that if I took the time to read all the readily available information about how themes work I probably would have realized some of this. Some themes put out demo pages, which make use of resources in that theme, and are named accordingly. And switching to another them that doesn’t have demo pages (or does either way), still has those other demo pages to contend with and they may not abide by the same rules.

And definitely good to know where the data I need to back up is stored, but again, I guess if I were more patient and read more I woulda knowed (I honestly did do a lot of reading, just not enough!)

Thank you again - I like what I’ve seen - and in the end the only 2 criteria that mean much to me are 1: the community of people helping each other and 2: being able to extend the software if I wish. And I’m pretty happy these are well met here.