Tag Archives: WordPress

WordPress Unable to Send Emails

I was recently working on setting up an instance of WordPress multisite. As a matter of fact, this website is most likely being served from that very same instance, right now. In the process of setting it up, I noticed that I was not receiving any emails, like I would normally expect from WordPress. That’s strange, I thought, so I decided to pretend like I lost my password, to trigger an email. I didn’t get it. I continued to investigate, and eventually found there was a message from google, hidden away in the mail folder for the web server user. In response to the email that was sent for me to reset my password, google said the following…

Our system has detected that this message is not RFC 2822 compliant. To reduce the amount of spam sent to Gmail, this message has been blocked. Please review RFC 2822 specifications for more information

After a bit of searching google, I found a thread that said it was most likely something to do with the ‘Date’ or ‘From’ headers. So I went back to the delivery failure notification I received, to look at the original email’s headers. A-ha! The ‘From’ header looked a bit suspicious. WordPress was trying to send the email from “wordpress@*.marslender.com”.

After investigating, this comes down to the way that wp_mail() generates the ‘From’ header, when one is not explicitly provided to it. The function essentially takes the SERVER_NAME and adds a “wordpress@” before it. In addition, nginx is configured to respond to “*.marslender.com” so that any subdomain of marslender.com is directed to this site, so the SERVER_NAME had a value of “*.marslender.com” in this situation.

My Solution

Luckily, WordPress provides a filter for the from email address, called ‘wp_mail_from’. I just created a mu_plugin that hooks into that filter, and removes the ‘*.’ portion of the from email, if it was present.

In addition, it looks like there is a trac ticket related to this issue, so this may be resolved in a future version of WordPress.

WordCamp Portland 2013

WordCamp Portland 2013 is fast approaching. It is Saturday August 10th, at the Eliot Center in Portland, and I’ll be there. WordCamps are informal, community-organized events that are put together by WordPress users. Everyone from casual users to core developers participate, share ideas, and get to know each other. There should be a lot of interesting talks going on, including some by some of my new coworkers at 10up.

I’m really excited for a day full of WordPress oriented presentations and conversations, and hope to see some of you there!

New Job!

A bit late on this post, but I have a new job! I am now working as a Web Engineer at 10up, a premium WordPress agency. I am really excited about the new job, and the opportunity to work with some of the most talented people in the WordPress community. Not only does 10up create awesome websites that are built on WordPress, we also have a rather large handful of employees that are actively involved in developing WordPress core, and one of out directors is even a “Rockstar” leading contributor.

WordPress register_activation_hook doesn’t work with symlinks

I am currently working on developing a plugin, and as such am running apache, php, mysql, etc on my local machine. To make my life easier, I tend to remove the wp-content/plugins directory and replace it with a ‘plugins’ symlink that points to a folder with all of the plugins I generally use in WordPress. I hadn’t ever noticed any issues with this until today, when I was attempting to setup a function to be called on activation with the register_activation_hook() function. Here is how I was trying to implement this, which is the way that is suggested in the codex.


<?php

register_activation_hook( __FILE__, 'plugin_activation' );

function plugin_activation() {

//do the activation stuff here

}

Try this is any WordPress install that doesn’t use symlinks and it will probably work as expected, but when the plugins directory is actually a symlink, it doesn’t work, and this is why; In php, __FILE__ returns the path to the current file with symlinks resolved.

The following is what __FILE__ was returning


/Users/chris/git/myplugin/myplugin.php

WordPress was expecting something more along the lines of this


/Users/chris/domains/wordpress.local/html/wp-content/plugins/myplugin/myplugin.php

When provided with the latter, WordPress is able to remove everything up to and including the plugin directory for the installation, so it would then be left with

myplugin/myplugin.php

Since the path with symlinks resolved doesn’t contain the plugin path as part of it, WordPress gets a bit confused.

To solve this, there are two options. The first would be to just not use symlinks, but I prefer to use them, so I personally chose to do the following.

Instead of using __FILE__ in the register_activation_hook() function, it can be replaced with this


basename(dirname(__FILE__)).'/'.basename(__FILE__)

basename(dirname(__FILE__)) returns the directory that the current file is within, so in this case ‘myplugin’. basename(__FILE__) returns the filename of the current file, which is ‘myplugin.php’. When all is said and done, this ends up returning ‘myplugin/myplugin.php’, which is ultimately what WordPress wants when it is calling the activation function.

For this to work properly, your plugin needs to be in its own directory (within the plugins/ directory) and this should be called from the main plugin file.

How To Use Screen Options in your WordPress Plugin

If you have used WordPress, you have almost certainly noticed the ‘Screen Options’ and ‘Help’ tabs located in the upper-right of just about every WordPress admin screen. These tabs let users get help or manage settings related to their current page. For example, while on the dashboard page, the number of columns can be set, as well as the sections of content to show. While on the posts page, specific columns can be enabled or disabled, and the number of posts to show per page can be set. These options are user-specific, and are stored in the WordPress database so that the next time the user logs in, their settings are retained. Continue reading How To Use Screen Options in your WordPress Plugin