FMS 19 WebDirect - homeurl or custom home page?

Questions
1

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?

2

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!

image
image1422×640 195 KB

jwpc_prefs.xml in FMS 19.6.2- broken

image
image1486×774 190 KB

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
1 Like
3

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

image
image1296×284 24.5 KB

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:

image
image1446×772 194 KB

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

4

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...

5

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.

6

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.

7

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 


8

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:

9

FYI, I had the exact same problem with FMS20: I updated several servers, and one of them just would not honor the customhomeurl value.

After many tries, the changes finally stuck, but I still do not have a recipe for how to make it work consistently.

1 Like
10

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 "&#10"".

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!

2 Likes
11

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.

12

For whom might run into this in FMP20 i saved the old file:
jwpc_prefs.xml_edited
Copied the text from with vi and put in into a plain text editor (in text only mode. eq osx TextEdit > Format > Plain text where I made the changes including 3 home URL (see previous posting)
back to terminal and

vi jwpc_prefs.xml

Switch to insert mode and past the text in. Do not edit now. Save and quit vi

next

chmod 775 jwpc_prefs.xml
sudo chown fmserver:fmsadmin jwpc_prefs.xml
fmsadmin restart wpe -y

And test

The file so created worked. So I think that vi adds some kind of char that WebD chokes on.

Good luck

2 Likes