I've just upgraded from FMS18 (Intel) to FMS19.6.2 (M1) and everything is working fine, except I can not find any way to have WebDirect exit cleanly to a URL of my choice.
I have followed all the instructions for setting up the parameters in jwpc_prefs.xml (which worked fine in FMS18) but no matter what I do (including removing whitespace from the XML file, stopping all processes, rebooting the server, etc. etc. etc.) it does not work. I see I'm not alone (Link)
so, I decided to go to Plan B which is to edit the custom home page (the page you get when your url is https://example.com/fmi/webd ) which I thought was done by editing the file fmwebd_home.html located in /Library/FileMaker Server/HTTPserver/htdocs/httpsRoot but this seems to have no effect.
I see some older threads saying there's a secret file /Library/FileMaker Server/Web Publishing/publishing-engine/jwpc-tomcat/fmi/VAADIN/themes/default/layouts/iwp_home.html but this seems to be for a FileMaker 16 or earlier version - the same file doesn't exist in FMS 19.
the working file has 2 lines, and BBEdit says it's using Unix (LF), and it seems to have garbage characters (Note: BBEdit soft line wrapping is enabled for both windows)
the broken file is pretty formatted, and BBEdit says it's using WIndows (CRLF)
After much trial and error, I finally got it working. Here is my best guess at to what's happening:
the WebDirect process is responsible for saving the XML file
however, the WebDirect process gets the data from the Database Server
however, the Database server seems to cache the data from the XML file, and doesn't notice changes to the XML file
What I found to work was these steps:
turn off Web Publishing Engine (WPE -- not sure if this matters?) and WebDirect.
Stop database server
make edits to the XML file
start database server, then start WebDirect and WPE
If the changes don't "stick" repeat the steps, but this time change the customhomeurl value to something different (this seems to be necessary to get one of these processes to notice the change. Then repeat the steps, changing it back.
XML doesn't care about white space, so the end of line characters are not important. The is representing the unix new line character, if you replaced them with CRLF you'd see the pretty printed XML.
The XML will be used to supply information to the web publishing engine on startup. It reads the file once on startup, it doesn't read it each time it gets a web request.
Agree 100% it should not, but in reading the threads on the Claris site, there are some people suggesting whitespace may actually matter, and in my testing, the "clean/pretty" XML doesn't work, but the mangled XML does. Go figure!
Yes? No? The thing is, it's not a single ASCII 10 character, it's an actual literal string with 5 characters: in the exported XML File.
[Edit to add: ] In fact, I think that HTML entites such as are not legal in XML ( See Wikipedia though I may be mistaken )
Clearly, there's something wrong with the XML importer/exporter Claris is using, it's either not reading or saving the file as proper XML, and/or it's doing some very odd and unexpected caching.
Good questions - I think that I used the BBEdit feature to clean the XML (Markup / Tidy / Clean or Reflow document) it may have changed the filetype to CRLF? As you pointed out above, XML in theory should not care about whitespace / line endings, but in practice it seems to.
I spent about 6 hours fighting this which should have taken about 6 minutes, and at this point, it's working, so I'm afraid to go back and mess with it.
I have found that the XML file "...Web Publishing/conf/jwpc_prefs.XML" with the parameter "customhomeurl" must have multiple values ot work....I know that seems silly, and wrong, but it helps, EVEN THOUGH I also see those grabage characters listed above "
"".
Example:
https://FQDN_1,https://FQDN_2,https://FQDN_3
If I have like three domains listed, even though I only need FQDN_1, then it works, AFTER restarting the Web Publishing Engine, using
• fmsadmin restart wpe -y
I hope this helps someone, or someone shows me a better way!
Good tip; I think that goes along with my experience above where you "have to change something" to get the file to be parsed?
Also be careful about URLs that do (or don't) have "www." in them. I confused myself for a while with that, as the destination server was rewriting https://example.com to https://www.example.com and I was using the www.example.com version in my homeURL parameter, but forgot that I had only set the example.com URL in the XML file.
