Hi Alex,

Thanks for reaching out to us. The customers will not receive two texts when they book. By default, only the confirmation email is sent (depending on the appointment status). If configured to "approved", customers will receive the "Appointment approved" notifications. If configured to "pending", they receive "appointment pending" and so on. 

"Details changed" notification is only sent when somebody changes the details of the existing appointment. Once a customer books an appointment, it will be visible in the backend and this is where the details can be changed. No issues like this have been reported so far.

As for the notifications, as previously mentioned, this will be fixed in future updates. Unfortunatelly, it's not something that you can just apply without testing (yes, we do testing before releasing the updates). 

Apologies for the inconvenience again and thank you for your understanding. 

Alternatively,

I will double-check with the developers to make this a priority. As said, we are aware that this is an issue that needs to be fixed as soon as possible.

Hi Alex,

The customer and employee both have the same phone number booked for the same timeslot. I'm not sure if you are testing with the same customer, but the email "details changed" is only sent when there is already a group booking, and this one is sent to the employee, while the other "appointment approved" is sent to the customer. So, if you are testing, make sure that there is a different phone number (information in general).  Also, it's not recommended to delete the notification template, it's enough to disable it. It wont be sent, especially if there is a use case different from the one mentioned above. We tested this and we can confirm that the "details changed" notification is not sent when there is a booking from the front end. 

As for the mode changes, this is also tested and it doesn't revert to text mode by itself. Yes, there is currently an issue when you have HTML code added, and you change to text mode manually, but once saved to either text or HTML mode, it doesn't change automatically. We are looking forward to adding the option of selecting a default editor in settings, so changing this in notification settings would be removed. 

Hi Alex,

That's pretty much it. It won't delete the data, but reinstalling Amelia should restore the interface (restoring the missing notification templates). If it still doesn't work, then we will log in to take a better look. 

Hi Alex,

The cron job is not configured properly actually. You should be using the PHP option for this.

So,  "PHP Cron event" radio button, and add the URL you copied from Amelia/Notifications in this form:

file_get_contents("yourURL");

If you don't see the PHP button, please take a look at this official WP Crontrol Page, in the FAQ section, find this question "which users can manage PHP cron events".

They mention a possible reason why users can't see the "PHP Event" radio button (the user you're logged in to WordPress with most likely doesn't have the edit_files capability).

Crons are scheduled tasks of the server, and this is a 3rd party plugin, so it is not an issue coming from Amelia.

Please make sure you have the latest WP Crontrol version installed and go through the steps explained in their FAQ section, which is mentioned above.

Also, there's a possibility that a security plugin disallows file editing, which as a result hid that "PHP cron event" option selection in WP Crontrol. In iThemes Security there's a "Disable File Editor" option in settings, and that needs to be turned off as well. If you're using a different security plugin, look for a similar option, or reach out to that plugin's support team.

SiteGround Optimizer -> Frontend Optimization -> Javascript -> Defer Render-blocking JavaScript (uncheck)

Hi hiegl,

Apologies, but i would have to ask you to open a new ticket with all the details there and we will kindly provide assistance.

Thank you for your understanding. 

Hi Alex,

Great to hear that, indeed! You can use the placeholder %time_zone% in Notifications template / To Customer

This should read the timezone in the Notification that is sent to the customer 

Hi Alex,

Apologies for the delayed answer, I took some time to test the notifications. These are the placeholders that I've added to the notification template for both customers and employees. It's a default text with the time zone placeholder

If I go ahead and book an appointment manually for a customer (from the backend), these are the emails that I receive 

The information coming from the placeholder is visible on both emails, but Amelia doesn't store the timezone of the customer, currently. It recognizes the IP address from where the customer is booking an appointment and therefore it can assign the notification language (you can configure this in customer information), but it doesn't store the timezone information.

Please feel free to search through our feature suggestion page,  to see if someone may have already suggested this feature. If you can't see it, feel free to add your suggestion there, and as more people vote, the feature will move higher on the priority list.

You can certainly follow our changeLog page if you'd like, where we state any changes/new features/bug fixes during updates and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

Hi alex,

As per my previous test, i couldn't reproduce this issue. This is working properly. Here is one more test. Booked an appointment from the backend (blue color means it's booked from the backend)

An email sent to the customer looks like this 

And here is the SMS that I've received 

Hi Alex,

Thanks for the credentials and apologies for the delayed answer. Apparently, the placeholder is not working, it's not reading the information, but I wasn't able to reproduce the issue on our local server. May I ask for the staging site so I can forward the use case to devs for further troubleshooting? 

Hi alex,

For some reason, i'm getting this error now when I want to access your wp page, not sure why

But, exactly how it was working with my previous testing, it also works when booked from the backend, as well. I've been trying to reproduce this on both local environment and our server, and it works in both places. 

Hi Alex,

Apologies for the inconvenience, but I'm not sure what went wrong with your configuration. From the moment you've reported the initial issue, we weren't able to reproduce the same issue on our server. All the issues you've mentioned were working properly on our side. So we can conclude that the setup is incorrect or perhaps there is a conflict. What I can do as the last solution is to forward this to the developers for further troubleshooting, but you would need to enable access and provide a staging site. 

Hi alex,

I understand that's one of the choices, of course. As previously mentioned, I've tried all possible workarounds to reproduce the issues you are experiencing, but that wasn't possible. Should you feel like we should continue troubleshooting, please let us know.