[SOLVED] Txp serving template from different theme than the 1 selected

johnstephens · 2018-09-14 22:08:05

Today I upgraded one of the most complex sites I operate from Textpattern 4.6.2 to 4.7.1.

After the upgrade, I copied and exported the default theme, so I could make some template changes. After making the changes, I imported the copied theme, and changed the section to use that theme instead.

But after reloading the page multiple times, checking and rechecking the Theme and Section settings, and doing some manual testing in the Forms panel, I found that Textpattern was still serving a certain form from the default theme instead of the copy.

I finally resolved the problem by deleting the default theme in Textpattern. After that, Textpattern loaded the form from the selected theme, and I could see there was a tag error on the page. My impression was Textpattern was automatically redirecting the request to the default theme when it ran into the tag error, instead of showing me the error so I could fix it.

But there was no message on the front end or in Textpattern about why Textpattern was showing the form from the wrong theme, and my server logs didn’t show any errors either. This is just a report, in case you find it useful to add some kind of warning in Textpattern when this happens.

But I also wanted to post here in case I do the same thing again one day and I can’t remember—maybe Google will find it for me. ;)

jakob · 2018-09-15 07:49:43

Could that have something to do with your site status and you being logged in or not?

If you check the intro post on themes on textpattern.com, there’s a description of how the themes capability allows you to edit without affecting the live site until you are ready. As I routinely use etc_flat to work on templates, which requires its own deliberate syncing to make live, I’ve forgotten exactly how that works.

If, on the other hand, your observations show that a theme is automatically sourcing default forms (i.e. when the form / list_form attribute is not specified) from another theme than the one selected, that might be a potential bug.

Bloke · 2018-09-15 09:53:34

I admit this is potentially a confusing element to the themes system and I’m interested to know if there’s a way we can make this behaviour more obvious, e.g. perhaps by displaying something on the admin-side about what theme is currently “in force” for the current user. The fact that the pages/forms/styles panels show this by virtue of the Theme dropdown is fine, but if you’re beavering away on other panels, you might not notice this.

I do, however, think that the ability to preview site changes on the fly to logged-in users is worth keeping because the alternative is:

Going through the pain of making fake sections in which to assign your new theme assets, and moving content into them or making dummy content.
Making an entire staging site and then having to worry about how to sync the databases on go-live.

That’s faff I’m convinced we can do without.

etc · 2018-09-15 12:03:58

Bloke wrote #314049:

I’m interested to know if there’s a way we can make this behaviour more obvious, e.g. perhaps by displaying something on the admin-side about what theme is currently “in force” for the current user.

I even think that this “something” should be displayed for admin users on the public side, each time his theme is different from the public one.

I do, however, think that the ability to preview site changes on the fly to logged-in users is worth keeping

absolutely!

Bloke · 2018-09-15 17:13:52

etc wrote #314052:

this “something” should be displayed for admin users on the public side, each time his theme is different from the public one.

That’s a neat idea. Like something overlaid in the corner or along the bottom edge?

It would probably need to be session-based and dismissable for the session or until the theme is changed again, in case the site in question is being tested on a mobile device. Don’t want precious real estate taken up by something permanent, imo.

colak · 2018-09-15 17:26:21

Bloke wrote #314053:

Don’t want precious real estate taken up by something permanent, imo.

+1

etc · 2018-09-15 20:06:30

Bloke wrote #314053:

It would probably need to be session-based and dismissable for the session or until the theme is changed again, in case the site in question is being tested on a mobile device. Don’t want precious real estate taken up by something permanent, imo.

Oh, it could be just a 3 seconds unobtrusive reminder with pointer-events:none in non-live mode. If we must complicate it further, something better could probably be found.

Bloke · 2018-09-16 09:08:20

etc wrote #314055:

it could be just a 3 seconds unobtrusive reminder with pointer-events:none in non-live mode.

That’d certainly do.

etc · 2018-09-16 21:41:26

On the second thought, you’ll be mislead by this “live” dev preview every time your site is using more than one theme at once. That’s not ideal and not ideal is not txp. We should probably delegate this feature to some explicitly “sandboxed” view.

NicolasGraph · 2018-09-17 07:34:44

etc wrote #314069:

On the second thought, you’ll be mislead by this “live” dev preview every time your site is using more than one theme at once. That’s not ideal and not ideal is not txp. We should probably delegate this feature to some explicitly “sandboxed” view.

Couldn’t the reminder be displayed only after a section+theme couple checking?

etc · 2018-09-17 08:35:02

NicolasGraph wrote #314076:

Couldn’t the reminder be displayed only after a section+theme couple checking?

It’s not only the reminder. Suppose that your final site is designed in such a way that Section A uses Theme A and Section B uses Theme B. You have stopped working on the design but continue publishing articles. So you are still logged in and served the assets from your last working theme, say A, even when viewing section B. If they differ (otherwise what’s the point of using two themes?) you can get a wrong view. And if later you add a Section C with its own Theme C, the whole site is switched (for you) to Theme C.

We might introduce two themes fields per section: live theme and dev theme. You could then choose per section which themes are served to visitors/admins.

Bloke · 2018-09-17 08:55:49

etc wrote #314078:

So you are still logged in and served the assets from your last working theme, say A, even when viewing section B.

Very true. The preview feature has limitations, especially if using different Page names or, as you say, when using multiple Sections throughout your site. Its primary benefit is when you want to clone an existing design and tweak it ‘live’ without having to worry too much about damaging the experience for existing site viewers while you’re tinkering.

It’s useful if previewing a theme you’ve obtained from someone else, only if its Page names match the ones in use on your live site. That’s why we have a kind of semi-enforced convention that your front page is called default; it makes theme swapping and previewing simpler (at least on the front page) if people stick to the conventions. If you don’t, well, ymmv.

We might introduce two themes fields per section: live theme and dev theme. You could then choose per section which themes are served to visitors/admins.

That’d work and would certainly offer fewer surprises, if we can make sure it’s uncomplicated enough to be of use. However, adding a second theme per section requires a Page and Stylesheet too, so it’s three new database fields, plus whatever admin-side management we need to put in place to support them.

Let’s give this some thought and see if we can figure out the best path.

Textpattern CMS

Textpattern CMS support forum

#1 2018-09-14 22:08:05