We've been talking to a few people about this. Obviously it is not something we can control or could have controlled, but we are very sorry for the inconvenience.

As for alternatives, we did look into a few and there were some pretty significant disadvantages to the free alternatives, in addition to the extensive time it would take to re-develop the tons of map-related features we have presently.

That being said, this is a very valid concern. Do you (or anyone else reading this, for that matter) have any numbers you can share about what the impact is currently? Are you getting charges now? Do you have any usage data?

We were looking at possibly new ways we could reduce the API calls as well... so depending on usage, and where the usage was coming from, maybe there are things we can do to reduce usage. Any information you could share would help!

I will revisit with my team about the free alternatives as well, in case things have changed.

(Side note: I will also see if there is an API that will give you usage... maybe we could actually turn it off at a certain point. That's an interesting idea as well.)

Thanks!

This is done and should be released next week!

As of right now - yes, individual sites need to make the decision to allow EU traffic or not, based on their legal situation and/or advice from legal staff.

Yes, please put in a ticket! They will start you on the path... We need to ensure you move to our newest analytics code, and a few other things, and then you'll need to sign a addendum and then you can go live with the new EU "wrapped" solution which blocks third-party widgets when the page is viewed from an EEA country. =)

I have been trying to reply to this all day but have been in meetings! But just to put this out there quickly, and I will add more later tonight... but you won't need to build a new site. We just "wrap" any suspicious items with a code that checks for the request coming from the EU, and if it is from the EU, we turn off anything within that check.

In other words, we would essentially remove any non-compliant third party widgets from your site, ONLY when viewed from the EU.

We are still working on the next stage, which would be some kind of Consent Framework, but we still have many questions that we are still researching and trying to resolve.

Hey Nick,

Both the "Utility: Site Search" and the "Utility: Site Search Range" have a search URL override option.

If you don't see it - perhaps you have a customized version because we did add the Site search version after the Site Search range block. 

Note that by default our system will look for the FIRST search-based URL that it sees in order to perform a search. I believe that if this happens we have ways to fix it in all cases now, but if you have a situation where you create a special search URL for "archives" and then find that obits is now re-directing them when you search - then you need to go through and force the other searches into the alphabetically inferior URL.

And, this works really great for obits! The Search Range block was actually specifically made for obits. Firstly, our testing shows that many obits users just want to browse to the last few days of obits, so that's why the ranges are set up that way. And, search is very popular in obits, so having a separate search URL can help with a few things:

1. You can set up your search to be obituaries/search. This way, all of the search traffic actually stays within the obituaries umbrella so you can track it together in terms of analytics.

2. You can assign specialty ads to the search pages, separately from your other search pages. So, you can sell an obits package that gets impressions on the obits index page, article pages and search pages.

In theory, you could do this with recipes as well.

Let me know if you still can't find this and I can look at your site.