Monthly Archives: March 2024

Whitelisting an email or domain in Mailgun

Leave a reply

Recently a client who uses Mailgun to send email from their website had a problem where one of the clients own email addresses had been “suppressed” in Mailgun, meaning Mailgun would no longer send email to that address. It was caused by the client’s mail server having a problem for long enough that Mailgun decided they couldn’t send email to the particular address.

Mailgun have the ability to “whitelist” individual email addresses or whole domains so they will not stop sending to them. That’s exactly what I needed to put in a long term fix for this problem. It’s not available through their website, but you can do it through their API. That was fine, we’re using the API for other things so I can adapt some code to use it for this.

Unfortunately, the docs for whitelisting an email address are currently incorrect. I had some back and forth with their support people and they gave me the following curl example for how to whitelist an email address:

curl -i -X POST  -u api:[your api key] https://api.eu.mailgun.net/v3/[your mailgun domain]/whitelists -F address=[your email address]

Where [your api key] and [your mailgun domain] and [your email address] get replaced by your details.

Remember that if you’re in Europe, you’re probably using the EU API, not the one in the docs, so you’ll need to change the API domain to https://api.eu.mailgun.net

To whitelist a whole domain, use:

curl -i -X POST  -u api:[your api key] https://api.mailgun.net/v3/[your mailgun domain]/whitelists -F domain=[your email domain]

Finally, to check the whitelist, use this:

curl -i -X GET  -u api:[your api key]  https://api.mailgun.net/v3/[your mailgun domain]/whitelists

This was a frustrating situation as it took a while for their support to understand that giving me back the incorrect examples from the docs wasn’t helping, but they did come through for us in the end and were polite and trying to be helpful throughout. Hopefully they’ll get their docs updated soon.

Using ACF Blocks by default in a new post in WordPress

Leave a reply

One of my clients has a website using Advanced Custom Fields (ACF) Blocks to style everything in the site, including their News section.

To make a new post in News, they had to load a Pattern of the relevant Blocks. This being a multi-step process, and a bit annoying if you just want to get on with posting your article, I looked for a way to load the blocks into the new post by default.

You can do this by putting this code in your functions.php (with amends explained below)

function site_post_register_template() {
    $post_type_object = get_post_type_object( 'post' );
    $post_type_object->template = array(
        array( 'my-blocks/news-header' ),
        array( 'my-blocks/news-article' ),
        array( 'my-blocks/news-article-related' ),
    );
}
add_action( 'init', 'site_post_register_template' );

In this case, I have three Blocks loading – the specific header, the article, and a strip of related articles. I can load in as many Blocks as I want.

To make this work for you, find where you have saved your blocks and list them out in the same way, in an array for each.

You will have to change ‘my-blocks’ to the prefix of your ACF Blocks. To find that prefix, go to the directory where you store the code for the relevant Block and open the block.json file. Copy the details from the “name” line to be inside the array( '' ), above.

Now, when a new Post is started, it automatically loads in the ACF Blocks and my client can get on with posting their news, not thinking about how they load in the Pattern and where they left my instructions for doing so.