SideNav difference between local build and publishing to web

This forum is for all Flare issues related to the HTML5, WebHelp, WebHelp Plus, and Adobe Air Targets
Post Reply
aspruck
Jr. Propeller Head
Posts: 8
Joined: Thu Jul 07, 2016 7:47 am

SideNav difference between local build and publishing to web

Post by aspruck »

Hello,

I upgraded to 2018 and opened an existing project and wanted to try using the sidenav skin for my online output. It works and looks great when I build. But when I've published it to our QA environment it breaks down and I'm not sure why. I haven't changed any settings except the skin and the associated styles with the skin. If I revert back to HTML 5 tripane skin then it's fine again.

Project: https://www.interactivebrokers.com/en/s ... tarted.htm

This is the readout when viewing the console:

JQMIGRATE: Migrate is installed, version 1.4.1
gettingstarted.htm:96 Uncaught TypeError: $(...).foundation is not a function
at gettingstarted.htm:96
MadCapAll.js:64 Uncaught TypeError: Cannot read property 'msie' of undefined
at HTMLDocument.au (MadCapAll.js:64)
at i (jquery.min.js:4)
at Object.fireWith [as resolveWith] (jquery.min.js:4)
at Function.ready (jquery.min.js:4)
at HTMLDocument.K (jquery.min.js:4)
Psider
Propellus Maximus
Posts: 811
Joined: Wed Jul 06, 2011 1:32 am

Re: SideNav difference between local build and publishing to

Post by Psider »

Perhaps run through the side nav tutorial to make sure you have all the necessary files to make side nav work?

https://help.madcapsoftware.com/flare20 ... gation.htm
NorthEast
Master Propellus Maximus
Posts: 6359
Joined: Mon Mar 05, 2007 8:33 am

Re: SideNav difference between local build and publishing to

Post by NorthEast »

If it works on your local build but not on your server, then it means your build is ok - and it's the server that you need to check.

I'd check that all files in the build folder have actually been published to the server.

Also check that that's there's nothing with your server configuration that might affect what you see.
For example, our company uses server-side caching, and that causes a delay before certain file types like CSS & JS are updated in the cache, which means we still see the 'old' CSS/JS for an hour or two after publishing.
Psider
Propellus Maximus
Posts: 811
Joined: Wed Jul 06, 2011 1:32 am

Re: SideNav difference between local build and publishing to

Post by Psider »

What Dave said (I blame Monday mornings. :) )
aspruck
Jr. Propeller Head
Posts: 8
Joined: Thu Jul 07, 2016 7:47 am

Re: SideNav difference between local build and publishing to

Post by aspruck »

Thanks, I'm trying to simultaneously work with madcap support and also internally at the company. I know we have something called "mod security" that can mess with files as they move from internal to production. It's also breaking search functionality.
mwmartz
Propeller Head
Posts: 41
Joined: Wed Sep 12, 2007 12:51 pm
Location: Around and about Atlanta, Georgia, USA

Re: SideNav difference between local build and publishing to

Post by mwmartz »

Was there any resolution to this? We're seeing an intermittent problem where the Help works fine locally. But, when we publish it to a server, the navigation intermittently displays strangely. I.e., instead of a side TOC that appears when the user clicks the hamburger menu, all of the TOC items appear at the top of the Help page itself as non-clickable items with no hamburger menu or top banner. So, the user has to scroll down to see the body of the content.

Upon research, the QA team identified this as a potential caching issue. In my experience at other companies whenever there's been a caching issue, the Dev team added something in the string before a Help call to clear the cache before launching the Help. (I have no idea what they did. I just know it worked.) Upon further research, and with the help of Travis at MadCap (yea, Travis!), I added the following meta tag in the header of the master page in the Flare project: <meta http-equiv="Cache-Control" content="no-store" />

I'm waiting for the QA team to test the above to see if it solved the problem. In the interim, the QA lead informed me that every time the issue occurs, the following message appears in the Dev console: jqmigrate: migrate is installed, version 1.4.1

He suspects this message has something to do with the issue.

Any thoughts out there in MadWorld?
Post Reply