Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 4076 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Display errors when publishing a WordPress site using UTM.

Alan Kearley

A post  from many years ago is very similar to the issue I am having, but following the thread suggestions didn't fix my issue.

The site has been developed for a local Mini (Automotive) Group.
For comparison I have created two ways to access the site, one via UTM and a second using NGINX reverse proxy.

UTM -->> http://k2s-2.hopto.org/MiniMeetWest (output formatting fails)
NGINX -->> http://k2s.asuscomm.com/MiniMeetWest (output formatting as designed)

Viewing the two sites you can see that the UTM link is missing a lot of formatting.   I have reviewed the information I can find on this forum but have been unable to overcome the issue.  Any help with solving this issue would be greatly appreciated.

Wordpress is version 5.6.2 with the JupiterX Theme (1.20.0 core) running on Ubuntu 20.04.

As I am also a HAM radio operation I and hosting a copy of javAPRSSrvr locally. I have published the associated status web site through the WAP and all appears to be working correctly on this site (custom java code, no Apache server, custom port).  This site can be viewed -->> https://k2s-2.hopto.org:14501/detail

Post from many years ago, which didn't solve my issues. https://community.sophos.com/utm-firewall/f/web-server-security/74553/publishing-wordpress-site-through-webserver-protection-strips-every-design-features-and-graphic-display

Any help with solving this issue would be greatly appreciated.
Alan



This thread was automatically locked due to age.
Parents
  • 0

    With more exploring and looking at a lot of log files I have discovered reason for the issue.   It turns out the "Real Server" was not running in HTTPS response mode and the javascript links being returned to the browser were HTTP and not HTTPS, resulting in the javascripts being dropped.

    Switching the Apache server  "Real Server" to use HTTPS: allows the pages to display correctly.

Reply
  • 0

    With more exploring and looking at a lot of log files I have discovered reason for the issue.   It turns out the "Real Server" was not running in HTTPS response mode and the javascript links being returned to the browser were HTTP and not HTTPS, resulting in the javascripts being dropped.

    Switching the Apache server  "Real Server" to use HTTPS: allows the pages to display correctly.

Children
No Data
Unfiltered HTML