9seeds

Building Custom WordPress Solutions | Plugin Development

 

News

Using Memberpress to Convert Free Users to Paid

Posted on

MemberPress is a great WordPress membership plugin that lets you create rules to protect your content and sell subscriptions to access that content. Making customized exceptions to those rules though has long been a bit challenging even for WordPress developers.
Thanks to filters added in the latest version of MemberPress however it’s now much easier to customize MemberPress rules! We did that for a client recently.

Having a Successful Membership Site

A client came to us with an existing site that had a lot of content generated over time and building a sizable list of registered users. They wanted to augment their free subscription model with selling memberships to access some of that same content.

MemberPress was built for this kind of scenario!  They installed the plugin and had already set up the following tags and MemberPress rules:

  1. Made a whole library of premium posts
  2. Tagged posts appropriately: Beginner, Intermediate, and Advanced
  3. Created 3 paid membership levels in MemberPress (Beginner for $5/mo, Intermediate for $7/mo, and Advanced for $10/mo)
  4. Set up 3 MemberPress rules to:
    • Protect all content tagged Beginner and allow Advanced, Intermediate, and Beginner memberships to access it
    • Protect all content tagged Intermediate and allow Advanced, and Intermediate memberships to access it
    • Protect all content tagged Advanced and allow Advanced memberships to access it

With the exception of creating the content, it’s a very straightforward setup, each membership level can access all the content for their subscription level and below.

Converting Existing Users to Paid Users

It’s easy to direct traffic to your sales page and to get first-time site visitors to signup for something free, but what about getting all the existing free registered users to sign up for a paid membership?

It’s also becoming common practice to build semi-permeable content gateways where a visitor can access a little content for free with or without registering but then getting locked out from viewing more content until they subscribe.

There’s no way in MemberPress at the moment to allow limited access to some things if they don’t have a MemberPress membership of some sort though. MemberPress recently added a new hook in their WordPress plugin, however that helps with this exact scenario.

What this hook allows is for a site owner to do is send an email to all their currently registered users and say “Hey, we have all this new premium content, you should buy it but as a long time registered user we’re going to give you unrestricted access to a premium lesson so you can try it out”.

By setting this up in code and allowing an existing user to get access it works out better because there’s no friction to the customer. You lose a certain percentage of people for every click you make them do to get a thing so by handling it this way it just appears to work magically as far as the customer is concerned. Another way to solve this would be to make a new membership and only allow existing members to sign up for it.

We discussed this with the client but they wanted to offer their existing base access to any single lesson they wanted. By creating a membership and then putting in a rule it would either overly give these users access to the entire library or you would have to pick a single lesson to showcase as the “free” premium one.

Custom Code for MemberPress

All of the non-code ideas were a compromise and so we went with the original plan and put in the following snippet for them.

add_filter('mepr-pre-run-rule-content', 'allow_premium_access_9s' ,10,3);
function allow_premium_access_9s( $protect, $current_post, $uri ) {
    $user = new MeprUser(get_current_user_ID());
    $prd = get_page_by_title('Premium Membership', OBJECT, MeprProduct::$cpt);
    //make sure we have a user and the premium membership lookup succeeded
    if($prd->ID && $user->ID) {
        //if the user isn't already a premium member
        if(!$user->is_already_subscribed_to($prd->ID)) {
            $promo_access = get_user_meta($user->ID,'promo_access',true);
            if(!$promo_access) {
                //if the user does not already have promo access to a lesson
                //allow them in to this one
                update_user_meta($user->ID,'promo_access',array('lesson'=>$current_post->ID,'expiration'=>strtotime("+1 month")));
                $protect = false;
            } elseif($promo_access['lesson'] == $current_post->ID && $promo_access['expiration'] > time()) {
                //The user has previously chosen this to be their promo lesson and
                //their special access is not expired
                $protect = false;
            }
        }
    }
    return $protect;
}

The thing about this rule is that it allows for some sneaky special things anytime you are running a promotion. Another good example is allowing access to a protected post if there’s a special code on the URL. Put that URL code right into your Facebook ad’s target URL and have someone get to see premium content for 1 click. Then when they go off the page you let the unauthorized message do its job and upsell them to membership status.

With the new MemberPress customizations, you can now selectively grant access to protected parts of your site without making complicated interlocking sets of rules for promotional items which sometimes live and die within days.

How to change WordPress permalink structure on WP Engine

Posted on

One of the most user friendly and powerful SEO features of WordPress has always been it’s pretty permalinks feature. Many content management systems (CMS) still to this day have urls that look like http://domain.com/something_incomprehensible/123123c1. Ugly!

WordPress has supported pretty permalinks (human readable and ending a url with a slug resembling the post name) since version 1.0. There was one catch to those however. You needed to include a date in the format before the post slug (that’s /%year%/%monthnum%/%postname%/ for those familiar with WPs permalink formats). This resulted in URLs like this post’s URL: https://9seeds.com/2016/12/19/change-permalink-structure-wp-engine. Pretty!

That format has always still been better for SEO than what other CMSs do with crazy random numbers that mean nothing to human or search crawlers. It’d be a little better without the dates in the way however. You could use just the post slug (that’s just /%postname%/ ) on small brochure websites with just a few dozen pages, but on sites with large numbers of posts things would slow down without dates to break things up.

As of WordPress 3.3 there is no longer any performance hit to using just /%postname%/.  So your URLs can just look like this:  https://9seeds.com/change-permalink-structure-wp-engine/.  Prettier!

But there’s still a catch. You can’t just go into the WordPress Permalinks settings page and change formats or incoming links to your site using the old format may 404 🙁

There’s long been a fix for this and our friend Yoast even built a tool to make generating the needed .htaccess rule here since no one likes writing regex or coming up with htaccess rules.  That’s all well and good if you’re on a simple Apache server and want to edit an .htaccess file, but what if you’re on WP Engine? WP Engine uses a higher performance setup with an Nginx proxy in front of Apache. That means you can put those redirect rules into Nginx and they’ll be even quicker than having put them in .htaccess!  Only you can’t directly modify your nginx.conf files on WP Engine, instead WP Engine gives you a super easy to user redirect tab in their panel.

 

Here’s how you change your permalink structure and setup the needed redirect on WP Engine.

Step 1:

Go to Yoast’s handy tool here and generate the needed rewrite rule. It’ll look something like this:

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(?!page/)(.+)$ https://your-domain.com/$4

If you’re not on WP Engine you can drop that into your .htaccess file before the WordPress section. In fact it’ll work on WP Engine, just it’s better to use the panel than to modify that file directly via FTP.

Step 2:

1. Go to the WP Engine Dashboard and click Redirects rules in the left sidebar

2. Click the Redirect Rules button at the top right

3. Set a memorable name for the Redirect.

4. Take the orange section above, the scary looking Regular Expression that Yoast generated for you (mine is for year/month/date, your maybe be shorter if your existing permalink structure is shorter), paste that into “Source*” from the ^ to the $.

5. Take the blue section above, the less scary url looking Regular Expression from the http to the $4 (my existing permalink has three date modifiers, hence it keeps the 4th chunk, your’s may be different if you’re using a shorter permalink structure).

6. Click the Save button

Step 3:

1. Go to your WordPress dashboard and click on Permalinks under Settings in the left sidebar

2. Change your permalink setting to %postname%

3. Click the Save Changes button

Step 4:

Test!

 

Success? Awesome let us know in the comments below!

WordPress Performance

WordPress Post Editor Performance

Posted on

WordPress Performance sometimes seems like an endless quest, but there are sometimes little things that come along and yield great rewards.

Front end and back end WordPress Performance auditing and optimizing is a topic I’ve been meaning to write more depth about since speaking on the topic at a few WordPress meetups, but I wanted to quickly share a performance tip on something I came across today while preparing a bug report for Yoast’s WordPress SEO plugin.

Spotting Performance Issues in WordPress

One of the ways we spot performance issues is to run Query Monitor on most of the sites we work on. Query Monitor is a great tool for a quick view into what’s going on on the backend on every page view and I’ll go into more in a future post.

TL:DR; Skip to #3 at the end.

I am no Chris Lema, which is a abstract way of saying, “I personally don’t spend much time in WordPress post editor”. However, today I was in there investigating a little visual glitch with the WordPress SEO snippet preview metabox when I also noticed that the post editor was loading very slowly. Thanks to Query Monitor I could instantly see the cause was a slow MySQL Query and it was coming from a function called meta_form().

Now, this was on a client’s site with over 100,000 posts and with a site that size performance issues show up rather quickly. This however, does affects smaller sites as well though not to the extent it does large publisher websites like this one. Also just to be clear it is really impacted by the number of rows in the postmeta table, not the number of posts directly, but I figured saying 100,000 post made more sense that 1.8 million rows. On the big site like this one though it was causing a 15 second query. While loading the post editor is infrequent, even on a site like this one with over 100 authors, that 15s is taking up a valuable MySQL thread and certainly frustrating authors.

On my much smaller personal blog it was still delaying page load several seconds and here on 9seeds.com (two sites with no where near as big of a database as our typical client’s site) it was causing a 7s slowdown on the post editor loading.

WordPress Performance
Slow meta_form() database query

Geeky WordPress Developer Details of the slowdown

WordPress runs a function called meta_form() which displays the custom fields meta box. It runs a somewhat intensive query on the wp_postmeta to generate that box (a box most people don’t even need anymore, but that’s a whole separate issue).

That query looks like this:

SELECT DISTINCT meta_key
FROM wp_postmeta 
WHERE meta_key NOT BETWEEN '_'
AND '_z'  HAVING meta_key
NOT LIKE '\\_%' 
ORDER BY meta_key 
LIMIT 30

That’s actually the improved version of the query! When these changes were made to improve the query back in WordPress version 4.3 it seems that only half the needed changes to the database were made for existing sites. The table index was updated to 191 characters, but the field itself was not updated. That mismatch makes that query super slow on large wp_postmeta tables.

There is a new bug report for this performance issue already. While it seems like a trivial thing to fix any time WordPress core needs to modify the existing database on millions of WordPress it’s a pretty big deal and can take a while to get incorporated.

The good news is there are a couple fixes you can implement yourself.

1. (not recommended) My first fix was to truncate the meta_key column to 191 characters with:

ALTER TABLE wp_postmeta MODIFY meta_key varchar(191);

That worked, but it’s a bit dangerous since you could have a very long meta_key and it could get truncated, so don’t do that, there are better ways.

2. (recommended) Much easier, in WordPress 4.4 there was a new filter introduced that short-circuits that query ‘postmeta_form_keys‘ which you can provide a pre-defined array of keys to if you need.

add_filter('postmeta_form_keys', array('my_key1, my_key2');

3. (most recommended) Just ditch loading the ancient custom fields box entirely with:

/**
 * Remove Ancient Custom Fields metabox from post editor
 * because it uses a very slow query meta_key sort query 
 * so on sites with large postmeta tables it is super slow
 * and is rarely useful anymore on any site
 */ 
function s9_remove_post_custom_fields_metabox() {
     foreach ( get_post_types( '', 'names' ) as $post_type ) {
         remove_meta_box( 'postcustom' , $post_type , 'normal' );    
     } 
} 
add_action( 'admin_menu' , 's9_remove_post_custom_fields_metabox' );

Added to your theme or a core functionality plugin.

Please do let me know if this helps you in the comments, and stay tuned for a deeper dive into WP site performance auditing and fixes.

The tools you use, the way you want. Wrapping Help Scout in Nativefier

Posted on

One of the things we love about WordPress is that it lets us affordably build custom functionality into business’ websites that not long ago would have required tens if not hundreds of thousands of dollars invested in custom software development costs. Which is to say we think people should be able to have software their way.

Wrapping Slack “Making WordPress” in Nativefier

wp-core-slack-900x900In that vein I was delighted when Jason Cosper wrote last week about using Nativefier to create a mini app for the Making WordPress Core Slack Team.

Like so many businesses these days we use and have quickly come to rely heavily on Slack for our internal team communications. Increasingly however we’re also using it for external communications to keep in touch with specific groups, largely in the tech space but outside it as well.  I’ve heard of families starting their own Slack Team just to keep in touch.

Personally I belong to 14 Slack Teams: 5 WordPress groups, 7 non-WordPress technology and local community groups, 2! groups dedicated to just to coffee and a few others. It’s crazy.

One of those WordPress groups is “Making WordPress”, which is a massively huge group of over 10,000 members. It’s a vital communication channel though for everyone involved in the broader WordPress Community. Everything from Core development to organizing WordCamp events to updates to the WordPress.org website to securirty alerts gets discussed there.

Less to it’s core mission it’s both a great way to keep in touch with friends made at WordCamps as well as a great back channel between agencies working in the WordPress space.

Jason Cosper discovered the cause of something that had been driving me crazy the last few months with the native Slack app though.  It had become extremely unstable It was frequently crashing and taking up 100% cpu. That’s really frustrating when it’s something you rely on nearly every minute of your work day.

It turns out a big cause of that was including “Making WordPress” and it’s 10,000+ members in the native app. Jason removed that channel and wrapped it up in it’s own desktop web app using a new tool called Nativefier. It’s much like Fluid and what we called an SSB (Site Specific Browser) apps if you ever used those back in the day.  Since removing Making WordPress from my native Slack app, like Jason, I’ve found it to be much snappier and hasn’t crashed once.

The now isolated Nativefier app version of Making WordPress still gives me critical desktop notifications of direct messages, plus has the added benefit of staying out of my way most of the day. As you might imagine with 10,000+ members it can be a bit noisey.  It’s a win win.

Wrapping Helpscout Making WordPress in Nativefier

Nativefier-Help-ScoutIt occurred to me I could do the same thing with a few websites I like to keep open all the time. Starting with Help Scout which we use for tracking and responding to plugin support requests.

Steps for Mac OS X

Step 1:
Install Nativefier.

Ok, it’s a bit more complicated. You need to have Node NPM installed first, but if you’re a developer of any kind you probably already do have that. Then just at the command line:
npm install nativefier -g

Step 2:

Wrap up a web page in Nativefier, I did this in ~/Applications and then moved it to /Applications.

nativefier --name "Help Scout" "https://secure.helpscout.net"

Step 3 (optional):

It’ll grab the favicon by default, but his is often low res and ugly.  Replace it with a nicer icon.

I used https://iconverticons.com/online/ to convert a Help Scout PNG I scrped from their site into the ICNS format I needed for the dekstop app.  You can grab them here for Help Scout if you want: https://iconverticons.com/icons/93a786b5f69feea3/ or create your own.

Final Step:

Right click on the new app and select Open. You’re going to need to right click open on it the first time because it’s not an officially signed by Apple app, but you created it so you can probably decide trust it when the pop-up warning about it being untrusted comes up.

Now if the < 5 minutes it takes to go through those steps yourself is too much, or you don’t have NPM installed, or if your command line shy.  You can download my Nativefier wrapped up app of the Help Scout website here: Nativefier – Help Scout.

 

I can imagine others using this for Gmail, Calendars, all sort of things…  Let us know what you’ve used it for in the comments!

Creating a WordPress User when you don’t have an existing admin login to use

Posted on

A long time ago we wrote a post on how to insert yourself into WordPress as an admin that has been very popular.

Just to be clear, this won’t help you hack a WordPress site. You have to have some kind of server level access to make use of any of these, but in our work we often have scenarios where we only have access to a server.

There are 3 quick ways to create a WordPress user from outside the WordPress dashboard.

Creating a WordPress user with WP CLI USER CREATE

My new favorite way is using WP CLI.  This requires that WP CLI is installed on the server, but recently WP Engine started rolling out WP-CLI Support to Select Partners for Beta Testing.  

It’s not just a WP Engine thing though, a few other hosts provide WP CLI support via shell access and if you’re running on your own server you can install it.  You’re not likely to be able to install this yourself on shared hosting.

Assuming you do have access to WP CLI it’s as easy as SSH’ing into your server or using the WP Engine portal, and typing 

wp user create name [email protected] --role=administrator

You can specify a password with –user_pass=”Password!” or if you don’t it’ll create a random and very secure password for you!

Create-User-WP-CLI

Create a WordPress user via MySQL

If you don’t have SSH access and WP CLI already installed the next quickest way is to insert a user via MySQL.

Here is the code snippet you can use, hopefully it’s obvious that you should replace the login, pass and email on the first 3 lines with your own. Otherwise, you’ll be giving us, and everyone that reads his post access to your site. 

SET @user_login := '9seeds';
SET @user_pass  := 'muDAy2CUcTcuPnyCBXfqJysD';
SET @user_email := '[email protected]';

INSERT INTO `wp_users` 
(`user_login`, `user_pass`, `user_email`, `user_registered`) 
VALUES 
(@user_login, MD5(@user_pass), @user_email, now());
SELECT @user_id := LAST_INSERT_ID();
INSERT INTO `wp_usermeta` 
(`user_id`, `meta_key`, `meta_value`) 
VALUES 
(@user_id, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
INSERT INTO `wp_usermeta` 
(`user_id`, `meta_key`, `meta_value`) 
VALUES 
(@user_id, 'wp_user_level', '10');

Most hosts include PHPMyAdmin so you can just jump into there, select the database you want to insert a user into, then go to the SQL tab and paste this code in. Don’t forget to edit the values on the first three lines before clicking the Go button to run the SQL query.

Create-User-MySQL

Create a WordPress user via FTP

This used to be my favorite way because often all the access I was given to a site was FTP access and I was less comfortable with MySQL then I am these days. Still it’s easy and reliable, especially if running running MySQL commands scares you.

You simply FTP to root directory of the site you need access to and create a new empty PHP file (or just “duplicate” an existing file and clear it out, that’s fine too).

Open up the file and insert the PHP code below. Again be sure you change the user, pass, and email values and save the edits to the file. Then, visit the file in web browser.  You should get a ‘Success!’ message.

Once you’ve run the file once you should delete the file just to be safe.

<?php
/**
 * Script to create administrator user in WordPress
 *
 * @package none
 * @link https://9seeds.com/creating-a-wordpress-user-when-you-dont-have-an-existing-admin-login-to-use/
 */

$s9_password = 'PASSWORD';
$s9_username = '9seeds';
$s9_email    = '[email protected]';

if ( 'PASSWORD' === $s9_password ) {
	die;
}

require_once 'wp-blog-header.php';

if ( ! username_exists( $s9_username ) && ! email_exists( $s9_email ) ) {

	$user_id = wp_create_user( $s9_username, $s9_password, $s9_email );

	if ( is_int( $user_id ) ) {
		$wp_user_object = new WP_User( $user_id );
		$wp_user_object->set_role( 'administrator' );
		echo 'Success!';
	} else {
		echo 'Error with wp_insert_user. No users were created.';
	}
} else {

	echo 'This user or email already exists. Nothing was done.';

}

That is it!  3 fairly easy ways to create a WordPress user when you don’t already have administrator level access to the WP dashboard.