FMS 19 WebDirect - homeurl or custom home page?

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.

Help?

I just remembered I have a server running FMS 19.5 where HomeURL is working fine. If I compare the two XML files, I see an interesting difference:

jwpc_prefs.xml in FMS 19.5 - works!

jwpc_prefs.xml in FMS 19.6.2- broken

I see a number of differences:

  • 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)
  • the broken file is missing the serverid value

More weirdness: On the broken server, if I turn off WebDirect:

and wait a few seconds, then the XML file gets updated on disk, reverting to the weird format. However, it's still missing the serverid chunk:

And if I start the WebDirect process, it jumps back to the clean multi-line XML format. This is very weird.

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.

What a terrible UI/UX...

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.

Question: You are running FMS on MacOS. The default line endings will be LF. Why are you editing a file with Windows CRLF line endings?

Have you tried changing the line endings in the broken file to LF and removing the 


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 pass the torch to the next brave soul :slight_smile: