dccharron

Humble apologies. You are right. “Multiple Choice” is a Radio button choice which works exactly as it should (where the user selects one option and all other options are automatically unselected). I had used a Checkbox field by mistake. (Signs of early dementia!) Please forgive my stupidity. You have a great plugin.

Thanks for confirming my exposure to costs.

I’m aware of the $200/month credit on offer by Google but I have no idea how many hits this would permit because I can’t find any “clear” documentation of how much they charge per hit. Nor do I have any guarantee that the $200/month will continue indefinitely (Google are notorious for suddenly changing their mind without notice).

Using the Open Layers is a good suggestion. Had I known about charges from Google I might have picked it. But I’ve decided to embed Google’s iframe on offer through the “share” facility. It’s simple and doesn’t require an API key (at least not that I can see).

As for contacting you via your website, thanks for the offer. I’m not a “Pro” subscriber so assumed that I would not be permitted to get any support. The business I’m doing this work for is a non-profit and I’m trying to keep costs down to a minimum so can’t afford your “Pro” version. Their website gets about 1000 hits per day. So you can see the potential for charges.

My main worry remains the risk of arbitrary charges from Google. I’ve gone to Google Cloud console and tried to delete “something” (I think they called it a “project”) and the response was that it won’t be deleted for 30 days. I have no idea if that’s all I needed to do. A “project” doesn’t sound like an “API key”.

Perhaps you should have a warning in your plugin about the potential cost of using Google maps. If you already have one, I missed it completely.

Issue resolved.

I got a reply from Google Help Communities. My domain had no SPF record in its zone file.

I confirmed this by using whatsmydns.net and searching for TXT records on my domain. None were found.

I added one to my domain’s Zone file (TXT SPF v=spf1 include:secureserver.net -all) waited a few hours for the changes to propagate and ran a new test. All good now.

It was recommended that I should also set up the DKIM but, so far, not required.

Thanks. I’ll try to contact Gmail support. The operative word is “try”.

I should clarify that Gmail still delivers the email to the target email address. It appears in the Inbox. The problem is seen when the message is opened. Gmail adds a yellow banner warning of possible spam as a prefix of the message text. The message does not go to the Spam folder. Also, the email text can still be viewed below the banner. So what I need is a way to convince Gmail that the message does not warrant the yellow banner. There is no way to flag the message as “Not Spam” (that option is only available when a message is delivered to the Spam folder).

I use this plugin on GoDaddy and on Siteground. I only experience the problem when sending via GoDaddy (on two different domains). There is no problem when messages are sent via Siteground.

I think you’ve got the wrong end of the stick. I have no problem in “sending” emails. I have a problem with the way Gmail “treats” the email when viewed. Gmail assesses it as possible spam.

I’ve tried the settings in the 4 year old post you cited. It “sends” the message properly but Gmail still flags it as spam.

Something changed in Gmail on 11 or 12 Jul 2022 in the way Gmail identifies it as spam. I’ve tried this on two different domains I own which use GoDaddy as the SMTP sender. Both result in the message being treated as possible spam. I’m using the “Test Email” facility to send my tests. The message text is changed each time to ensure I can tell which message is being sent.

I hoped you could suggest some other settings.

Resolved. I changed my timezone. This time I found a suitable “geographic” location (I discovered that WordPress does indeed have one for Perth in Western Australia – my bad). All working now.

Have just discovered that I posted this to the wrong support page. Should have posted it to:

https://www.ads-software.com/support/plugin/the-events-calendar/

Many thanks for the reply. I have set my timezone correctly in Settings => General but I am still getting a default of UTC+0 on all new events. I will resend my query to the other support team as you suggested.

The problem was solved by clearing the cache on Chrome but not on Firefox. I had to clear the cache and “refresh” (re-install) Firefox before it started to work on Firefox. All good now. Many thanks for the timely and thorough response. 5 stars

Fixed by 4.1.7. Thank you.

I’ve since paid for the plugin. The “paid” version works as expected and I have heeded your warning about not using PayPal due to the terms and conditions that prevent PayPal from being used for selling raffles and lotteries. I used Stripe instead.

No official updates from Kieran yet. There is a workaround. Change your timezone in Settings => General to UTC+0.

Hi @kieranoshea

Thanks for responding. I was shocked to discover my support post was blown away like that. Perhaps the WordPress moderator didn’t like my revelation that they had screwed up the behaviour of the basic PHP “time()” function? They even closed the topic so I couldn’t repost. Perhaps I breached one of their “rules”? If so, I have no idea which one, so I may well do it again someday. No learning possible when they behave this way. I’m going to complain to them and try to get to the bottom of this rude behaviour.

Thanks for looking into the problem.

An update/correction by Siteground to my ticket has clarified the situation.

1- Apparently my account has always been on Nginx. It has never been on Linux. My bad.
2- They claim that Nginx Direct Delivery has not been turned on yet on my account. So this cannot be the cause of the misbehaviour of my PHP snippets.
3- They claim that they are still using Apache so my .htaccess file is still in play. They also confirmed that the SG Optimizer rules have not been copied to the nginx.conf file.
4- They have disabled some kind of caching that is a default feature for all their clients. I’ve tested my pages with snippets and, so far, they are now all behaving correctly (running the PHP snippet each time). I want to conduct additional tests tomorrow but so far it looks good. If they continue to work this way, I will turn off the default caching (it can be done by editing the php.ini file) on all my websites that use Woody Snippets.

• This reply was modified 4 years, 10 months ago by dccharron.