Topics

Tribe Support

Tribe Support's Topics

Scott Crawford

Scott Crawford

5 days ago

Template override inconsistency between servers

Sorry for all the questions lately but this one is striking me as both odd and mysterious.

The Background:

For this project we're enforcing full privacy for content except a few public static pages.  Accordingly, I've over-ridden the template "default" html file using if/else to display a login message if the viewer is a guest and otherwise display content if logged-in.  I'm also including overrides for the "component" and "error" html files but only for minor cosmetic adjustments, but both allow publicly-viewable content.  For good measure, I've also added a new "public" html file that I'm pointing the front-page to use which does not check viewer status.

This is all functioning as expected on my development server.

The Mystery:

I noticed that the "token" page requires public view-ability but is generated using the "default" html file - which in my setup displayed a "login to view" message.  So, I have added an override for the "token" file under com_people in the template/html directories which adds

@service('application.dispatcher')->getRequest()->tmpl = 'component'

This works perfect on my development server.  It also works if I use tmpl='public'.

Odd thing though, is that when do the same on my Amazon EC2 server the "token" override does not seem to work - it's displaying the "login to view" message.

I've even gone so far as to copy the entire full template package from the development server (working) to the EC2 server - and it still doesn't work like it is on the development server.

The Question:

Would something in the server environment cause the same exact template override to function differently than on another environment?  All other overrides on the EC2 are working exactly as on the development server, just this one exception.

  • 3 Comments
  • Last Comment by Scott Crawford
I don't know what's causing this behaviour, but one hypothesis that I can offer is that the template overrides checks for the presence of a layout in the Template before loading the default layout in a Component. It's possible that files paths are constructed differently on your development vs. staging/production server.
Unknown Person liked this
Scott Crawford
Scott Crawford
5 days ago Permalink
This may be it, I’ll know more soon. I’m still working with the owners to get the DNS records updated; at present the EC2 is accessed via IPAddress/anahita/www.
Scott Crawford
Scott Crawford
Yesterday Permalink
This, I believe, turned out to be a non-issue. Seems I had been working in the same browser instance for several hours straight that day, and I suspect the non-functional template over-ride had been cached. Re-checking the next day, and opening a fresh browser, everything worked as expected.

Powered by Anahita