On one site that I run there are several different functions, primarily provided by disparate plugins with custom actions/filters, that send emails both to site administrators and customers. For most emails that are sent from WordPress itself and several of the plugins, the content type is set to plain/text allowing me to use WP Better Emails to wrap content in an easily edited header and footer. WooCommerce on the other hand proved to be a little more tricky – there is the option to send emails via plain/text, but they definitely lack valuable formatting when displaying order information to a customer. This is further compounded if you insert any custom HTML into the content.

Conceptually all that needs to be done is to first remove the WooCommerce email header and footer, and second have WP Better Emails process it even though it has a content type of text/html. After checking out the code for both of the plugins in question, I devised a way to make it work.

Remove WooCommerce Email Headers and Footers

If you view the source of any of the WooCommerce email templates (at least the default ones) you will see a line for <?php do_action( 'woocommerce_email_header', $email_heading ); ?> and <?php do_action( 'woocommerce_email_footer' ); ?> which are the hooks that WooCommerce itself uses to insert the header and footer contents. By setting our own functions to these hooks earlier and later than the WooCommerce priorities, we can capture all of the content and hide it with ob_start() and ob_get_clean() to capture and clean the output buffer contents. We are also setting a filter to return true any time the woocommerce_email_header action is run.

Common sense says that we could just unhook all functions from these actions, however in my testing I found that some other, non-UI, logic was being performed in some of the attached functions. This method allows the code to run, but prevents the output from being inserted into the generated email.

Apply WP Better Emails Template

Next we need to apply the email template that WP Better Emails did not, because the content type was wrong – text/html and not text/plain. This is actually a good thing because we also want to avoid some of the formatting that WP Better Emails applies to the typical plain text email content. We can do this using the global $wp_better_emails and hooking into phpmailer_init after most of the work has been done – priority 20 works fine.

This example uses anonymous function which require PHP 5.3+, however you could also use create_function().

// Determine if it's an email using the WooCommerce email header
add_action( 'woocommerce_email_header', function(){ add_filter( "better_wc_email", "__return_true" ); } );

// Hide the WooCommerce Email header and footer
add_action( 'woocommerce_email_header', function(){ ob_start(); }, 1 );
add_action( 'woocommerce_email_header', function(){ ob_get_clean(); }, 100 );
add_action( 'woocommerce_email_footer', function(){ ob_start(); }, 1 );
add_action( 'woocommerce_email_footer', function(){ ob_get_clean(); }, 100 );

// Selectively apply WPBE template if it's a WooCommerce email
add_action( 'phpmailer_init', 'better_phpmailer_init', 20 );
function better_phpmailer_init( $phpmailer ){
	// this filter will return true if the woocommerce_email_header action has run
	if ( apply_filters( 'better_wc_email', false ) ){
		global $wp_better_emails;

		// Add template to message
		$phpmailer->Body = $wp_better_emails->set_email_template( $phpmailer->Body );

		// Replace variables in email
		$phpmailer->Body = apply_filters( 'wpbe_html_body', $wp_better_emails->template_vars_replacement( $phpmailer->Body ) );
	}
}

Success!

Your WP Better Emails templates should now be applied to your WooCommerce emails.

The post Using WP Better Emails with WooCommerce Email Templates appeared first on Justin Silver.

I recently switched over from Apache to NGINX for my WordPress hosting, and it was surprisingly easier than I expected. Alongside the W3 Total Cache plugin to handle my minification and object/db caching my sites are blazing fast. The one problem I did run into was random 502 errors on some pages. The fix was to update the server{} block of nginx.conf to include parameters for proxy_* buffers and fastcgi_* buffers. In my configuration this is in an include file so that it can be easily imported into all the different servers that I run on this host.

My full configuration for WordPress (which also supports pretty URLs, MultiSite, BuddyPress, and WooCommerce) is:

# Use the Nginx-Helper plugin to automatically generate this map
# https://wordpress.org/plugins/nginx-helper/
map $http_host $blogid {
    default                         0;
    include /var/www/example.com/html/wp-content/uploads/nginx-helper/map.conf;
}

server {
    # accept connections on all IP addresses, port 80
    listen                          80;

    # listing on SSL port 443?
    #listen                         443 ssl;
    #ssl                            on;
    #ssl_certificate                /etc/nginx/ssl/example.com.crt;
    #ssl_certificate_key            /etc/nginx/ssl/example.com.key;

    # name this server
    server_name                     example.com www.example.com;

    # set the root folder for web files
    root                            /var/www/example.com/html;

    # MultiSite Configuration ################

        # avoid PHP readfile()
        location ^~ /blogs.dir {
            internal;
            alias                       /var/www/com.rovair/www/html/wp-content/blogs.dir;
            access_log                  off;
            log_not_found               off;
            expires                     max;
        }

        # WPMU files
        location ~ ^/files/(.*)$ {
            try_files                   /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1;
            access_log                  off;
            log_not_found               off;
            expires                     max;
        }

    # End MultiSite Configuration ############

    index                           index.php;

    # serve static files and send everything else to WordPress
    try_files $uri $uri/ /index.php?$args;

    # send PHP requests to fastcgi (uses spawn-fcgi)
    location ~ \.php$ {
        # zero-day exploit defense.
        try_files                       $uri =404;

        # performance boosts for PHP
        sendfile                        on;
        tcp_nopush                      off;
        keepalive_requests              0;

        # proxy buffers - no 502 errors!
        proxy_buffer_size               128k;
        proxy_buffers                   4 256k;
        proxy_busy_buffers_size         256k;

        # fastcgi buffers - no 502 errors!
        fastcgi_buffering               on;
        fastcgi_buffer_size             16k;
        fastcgi_buffers                 16 16k;

        # max timeouts (should match php.ini)
        fastcgi_connect_timeout         600s;
        fastcgi_send_timeout            600s;
        fastcgi_read_timeout            600s;

        # index page
        fastcgi_index                   index.php;

        # pass request to fastcgi/php-cgi via spawn-fcgi
        fastcgi_pass                    localhost:53217;

        # default fastcgi_params
        include                         fastcgi_params;

        # override fastcgi_params
        fastcgi_param                   SERVER_NAME $host;
        fastcgi_param                   SCRIPT_FILENAME $document_root$fastcgi_script_name;

        break;
    }
}

Some quick notes:

• The various buffer parameters prevent semi-random 502 errors, for example trying to logout of a BuddyPress site always resulted in a 502, and remaining logged in
• try_files will test to see if a file/directory exists and if not passes it off to WordPress’ index.php file – the ?$args at the end is important for WordPress to receive the entire $_REQUEST

The post 502 Bad Gateway on NGINX with BuddyPress appeared first on Justin Silver.