This topic contains 8 replies, has 2 voices, and was last updated by bernardmoes 9 years, 2 months ago.
-
AuthorPosts
-
October 13, 2015 at 6:20 pm #71374
Hello,
I am implementing this calendar into an existing solution. I have come across a couple of issues with the initial setup.
1 – The connection between the soSimple Settings file and my original solution seems to be fine, there are no red flags in the Settings file. When I load my file on a client computer on my local network the web viewer displays the calendar correctly, but when the file is loaded remotely the web viewer will not load. Are there any other port settings that need to be opened for the PHP server? I have gone through the ports FMI posts for Server 14 and I can’t find any that I am missing.
2 – When are the local variables in the “Actions” script set, specifically “$to” and “$from”? When I create or edit an event from the calendar my date and time fields end up displaying only “?” which is making me think it is not pulling the correct date and times from those variables.
Thanks in advance!!
-Jon -
October 13, 2015 at 6:57 pm #71375
Hi Jon –
1 –
If I understand, the solution works when FileMaker Pro is running on the same computer as FileMaker Server? If that’s the case, make sure that the PHP-URL is set to the actual IP address of the machine, not to “localhost” or to “127.0.0.1”. Those setting are under the Gear Icon.2 –
Make sure you’ve set the date format correctly under “Options”. Question marks usually show up when you use a date format other than the American date format, but you’re set to “American.”
See this article for detailsThe local variables for the Action script get set automatically when you double-click or move the event. You can throw up script debugger if you’re using FileMaker Pro Advanced to see what they’re set to.
-
October 13, 2015 at 6:59 pm #71376
Also, the calendar runs on Port 80 by default. So you need that port directed for remote users. I think I misread the question the first time.
-
October 13, 2015 at 7:28 pm #71377
Thanks for the quick reply Ken!
I’ll double check that I am using the American date and time formats. As for remote users, the calendar loads on any computer on the local network (it is not accessed on the FileMaker server itself), just not computers outside of the LAN. I do have port 80 open already and can open the solution file, it’s just the web viewer that doesn’t load.
Should the PHP-URL be set to the server’s local IP, or it’s public IP?
-
October 13, 2015 at 7:31 pm #71378
If your router’s set up right, the public IP should allow both in-house & outside users access the calendar. The local IP will only allow in-house users access.
-
October 13, 2015 at 11:47 pm #71380
Hi Ken,
I double checked a few things…
1 – I am using my public IP for the PHP-URL, with port 80 forwarded properly, still get timeout error when loading the web viewer remotely. I am using the FM Dev Subscription license of FM Server which occasionally gives me SSL errors because it uses a self-signed test certificate. Could that be causing issues?
2 – The time formats are the same in both the Settings file (American) and in my file (date = MM/DD/YYY and time = HH:MM:SS, 24 hour). I went through the script debugger using the data viewer, and the variables all looked like they were assigning the right values. Got the attached error at the very end after the calendar refreshed and the event disappeared. Is this a normal error?
Thanks again!
-
October 14, 2015 at 12:01 am #71382
Here is a more detailed screenshot from when the date and time fields get changed to improper values (I’m not using an End Date field as all events start and end on the same day).
The variables look good. The right fields are changing. What am I missing that causes the values to turn into “?”
-
October 14, 2015 at 10:17 am #71384
Hi Jon –
1 – For the remote access issues, please make sure you can access the FileMaker PHP technology test page remotely. I don’t think SSL is causing an issue, since it doesn’t sound like you’re using https. You’d have to have specifically pointed to https, and it doesn’t sound like you are. If you are, then you must redirect port 443 as well. But it does sound like somethings wrong with the router or the web hosting setup. First thing to check is the PHP Technology Test page.
2 – I certainly see the issue. Everything you describe seems to be right: the fields are being set by the script, so the names of the fields seem right. The variables in data view all look correct for US format. Did you create this file from scratch, on machine that is set up with US time? There are two things you can look at to see what’s going on:
- debug a different date, like 10/5/2015. Walk it through the debugger. See if the date shows up as May 10 or October 5, or still shows a question mark.
- check the File > File Options > Text tab. If your machine is set up to use US time, make sure that says “Always use current system settings”. If it says “Always use file’s saved settings”, the file may have been created on a system set up with a different date format, and that’s the format being used for interpreting your date entry.
Let me know what you find out.
-
October 15, 2015 at 2:34 pm #71387
Thanks Ken!! Toggling between “Always use current system settings” and “Always use file’s saved settings” has fixed the date and time issue.
I am still not able to load the calendar web viewer remotely, but that appears to be an issue with my test server, not your calendar. It’s interesting, if I load the URL remotely in a browser it works only if I use “https://” even though I have SSL unchecked in my FM Server Admin Console. If I use “https://” in my web viewer URL I get a warning that the SSL cert is not verified (like I said, it’s the one that came with FM Server for testing only) and it will not load the viewer. If I use only “http://” in the web viewer URL the connection times out.
I’ll finish my integration testing the calendar on my LAN and see if this is still an issue when I move everything to my client’s actual server that will have a proper SSL cert.
Cheers!
-
AuthorPosts
You must be logged in to reply to this topic.