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

SideNav difference between local build and publishing to web

Postby aspruck on Fri Jun 29, 2018 11:04 am

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)
aspruck
Jr. Propeller Head
 
Posts: 8
Joined: Thu Jul 07, 2016 7:47 am

Re: SideNav difference between local build and publishing to

Postby Psider on Sun Jul 01, 2018 7:18 pm

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
Psider
Propellus Maximus
 
Posts: 614
Joined: Wed Jul 06, 2011 1:32 am

Re: SideNav difference between local build and publishing to

Postby Dave Lee on Sun Jul 01, 2018 11:43 pm

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.
Dave Lee
Master Propellus Maximus
 
Posts: 5745
Joined: Mon Mar 05, 2007 8:33 am
Location: UK

Re: SideNav difference between local build and publishing to

Postby Psider on Mon Jul 02, 2018 12:14 am

What Dave said (I blame Monday mornings. :) )
Psider
Propellus Maximus
 
Posts: 614
Joined: Wed Jul 06, 2011 1:32 am

Re: SideNav difference between local build and publishing to

Postby aspruck on Mon Jul 09, 2018 8:10 am

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.
aspruck
Jr. Propeller Head
 
Posts: 8
Joined: Thu Jul 07, 2016 7:47 am

Re: SideNav difference between local build and publishing to

Postby mwmartz on Tue Dec 10, 2019 12:51 pm

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?
mwmartz
Propeller Head
 
Posts: 41
Joined: Wed Sep 12, 2007 12:51 pm
Location: Around and about Atlanta, Georgia, USA


Return to Web-based Outputs

Who is online

Users browsing this forum: No registered users and 2 guests