Tag: plugins

Google Knowledge Blindspot

With the new release of Yoast SEO 3.6, I decided to test out their new walk-through setup.

As someone who’s been studying SEO to one degree or another since the 1990s, SEO in and of itself is no great mystery to me. The bare bones of how it works, how you make good content, is understandable. But what Yoast SEO does, and what I like it for, is it makes it obvious to people without my experience what is needed. It also takes the generally good SEO of WordPress (and a good theme) and optimizes it for the myriad, constant changes that Google does.

For that, the walk-through is a wonderful idea. I like it. I think new users will love it. I think it’ll lessen the barrier to those people who are told “You need a website!” but no one is willing to (or able to) sit with them and help them get started.

Initially I was super impressed. Yoast had clearly studied the aspects of walk-throughs that had worked and that didn’t, lifting pages from other complex plugins that needed to be used by, perhaps, non-technical savvy people.

Being asked what kind of site I was running was brilliant. For the purposes of this test, I decided to use my community/wiki/library – LezWatchTV. And right away I ran into a problem.

The tool wanted me to say if I was a company or a person.

Well … Neither. I’m a community site. Or maybe a group? Either way, the two designations didn’t really apply properly. Where was “Other”?

This couldn’t be Yoast making a boneheaded maneuver, I realized. Few people know better than Joost and his crew what WordPress is used for. They’re smart people. They’ve seen more of the Internet than most of the rest of us and they know well how it’s used. So could the screwup be Google or Schema.org?

I went to Schema.org to look up how they would classify the site, and determined that DataCatalog was the most appropriate. Alright, knowing there was a good classification, I looked back at Google’s Knowledge Graph.

Google’s Knowledge Graph is a weird thing. It’s Google’s attempt to figure out how to answer your questions. You know how you can type in “How do I do X?” into Google and you get that interesting formatted answer?

That’s from their Knowledge Graph. But more importantly, so is this:

The more you dig into it, the more you realize that the only boxes like that are for people or companies. So the breakdown is that Google has not yet figured out how to flag non-people non-companies.

This means my ultimate question of ‘what I am?’ has become a little more existential than I’d wanted, and a little simple. It’s not a person, therefore it must be a company. And while that is entirely, totally, daftly incorrect, it’s also less incorrect that a person.

Thanks, Google.

5 October, 2016
Sortable Custom Columns: Another Post Type’s Data
And we’re still on LezWatchTV where there are two CPTs: Characters and Shows.

Every Character has a meta key of the Show (or Shows) it relates to. Since this could be 1, 2, or 7 (you get the idea), it’s an array of Post IDs.

On every page for a Show, I do a count for how many Characters link back to it. Since they’re post IDs, I have to watch out for the LINK/IN results (which I mention in my post on querying the characters for their deaths … look it’s a weird site). And in so far as showing this on a front-end post, it’s not hard to run a query of characters, grab the shows (in their meta key) and check if that specific show is in the array. If it is, update the count by one.

But there are problems with this. It’s slow, and as it’s something I run fairly often this makes the site slow. Also it isn’t sortable. I ended up with a lot of ugly, repetitive, code. After screwing around with SQL and the like, I determined (around the same time my buddy Norcross opined the same) that the smart thing would be have the shows all have a meta field for character number and did this:
- Every time a show is saved, check how many characters link to it and save the count.
- Every time a character is saved, check what shows it links to and run the update for shows.
In that way, I can just grab the meta keys and call it a day. It would make everything much easier.

Would have been nice if I’d thought of that 1000 posts ago, huh? Well you live and learn and take down the elephant one bite at a time.

Make a Function to Count Characters

Since I know I’m going to want to check the number of characters from multiple places, it seemed wise to make this a function on it’s own.
```
/*
 * Count Queers
 *
 * This will update the metakey 'lezshows_char_count' on save
 *
 * @param int $post_id The post ID.
 */
function lez_count_queers( $post_id ) {

	// If this isn't a show post, return nothing.
	if ( get_post_type( $post_id ) !== 'post_type_shows' )
		return;

	// Loop to get the list of characters
	$charactersloop = new WP_Query(
		array(
			'post_type'       => 'post_type_characters',
			'orderby'         => 'title',
			'order'           => 'ASC',
			'posts_per_page'  => '-1',
			'meta_query'      => array(
				array(
					'key'     => 'lezchars_show',
					'value'   => $post_id,
					'compare' => 'LIKE',
				),
			),
		)
	);

	$queercount  = 0;

	// Store as array to defeat some stupid with counting and prevent querying the database too many times
	if ($charactersloop->have_posts() ) {
		while ( $charactersloop->have_posts() ) {

			$charactersloop->the_post();
			$char_id = get_the_ID();

			if ( !is_array (get_post_meta( $char_id, 'lezchars_show', true)) ) {
				$shows_array = array( get_post_meta( $char_id, 'lezchars_show', true) );
			} else {
				$shows_array = get_post_meta( $char_id, 'lezchars_show', true);
			}

			if ( in_array( $post_id, $shows_array  ) ) {
				$queercount++;
			}
		}
		wp_reset_query();
	}

	// Return Queers!
	return $queercount;
}
```
When I want to use it, I just call lez_count_queers( POST_ID ) and I get a number of queers for that show.

Update Shows When Saving Shows

I could have done this in one massive function, but I decided to break it apart so I didn’t have to loop through things unnecessarily. That will make more sense when you look at the next function. But for this, I’m taking advantage of the action save_post_{post_type} which lets me trigger my update only when that post type is updated.
```
/*
 * Save post meta for shows on SHOW update
 *
 * This will update the metakey 'lezshows_char_count' on save
 *
 * @param int $post_id The post ID.
 * @param post $post The post object.
 * @param bool $update Whether this is an existing post being updated or not.
 */
add_action( 'save_post_post_type_shows', 'lez_shows_update_char_count', 10, 3 );
function lez_shows_update_char_count( $post_id ) {

	// unhook this function so it doesn't loop infinitely
	remove_action( 'save_post_post_type_shows', 'lez_shows_update_char_count' );

	$meta_value = lez_count_queers($post_id);
	update_post_meta( $post_id, 'lezshows_char_count', $meta_value );

	// re-hook this function
	add_action( 'save_post_post_type_shows', 'lez_shows_update_char_count' );
}
```
The infinite loop check is very important, otherwise every time I ran the update, it would trigger the update and trigger the update and trigger the update. You get the idea.

Update Shows When Saving Characters

Having decided to break the saves apart, I had a very similar command for the characters, only this time I am forcing it into an array. This allows me to compensate for the characters who were added before I updated to the new, array, system. There are only a few left, but better safe than sorry.
```
/*
 * Save post meta for shows on CHARACTER update
 *
 * This will update the metakey 'lezshows_char_count' on save
 *
 * @param int $post_id The post ID.
 */
add_action( 'lez_shows_do_update_char_count', 'lez_shows_update_char_count', 10, 2 );
add_action( 'save_post_post_type_characters', 'lez_characters_update_char_count', 10, 3 );
function lez_characters_update_char_count( $post_id ) {

	if ( !is_array (get_post_meta( $post_id, 'lezchars_show', true)) ) {
		$shows_array = array( get_post_meta( $post_id, 'lezchars_show', true) );
	} else {
		$shows_array = get_post_meta( $post_id, 'lezchars_show', true);
	}

	foreach ( $shows_array as $show_id ) {
		do_action( 'lez_shows_do_update_char_count' , $show_id );
	}

}
```
This time you’ll note the lack of infinite loop check. It’s not needed here, since I’m not updating the character content. I’m also doing two actions here, one for ‘do_action’ and one that is the action. This allows me to handle some odd workarounds like… the catch.

If a character doesn’t have any shows associated with it yet, like a new character, then it won’t update the character until the second save. And just as bad, if a show is changed, it won’t update. And no, I don’t have a complete fix for this yet. Working on it. The best idea I have so far is to schedule a single cron command to run the show update in 5 or 10 seconds. However this won’t solve the issue with changing shows.

Batch Update All The Things

Once I got the code in (and I checked that it worked), I had to update all the posts. Thanks to wp-cli, there’s a handy post update command. And yes, there are a lot of ways around this one but I thought this would be ‘simpler.’ If you want the super lazy way around it, you can view all the pages on the edit screen, select all, pick ‘quick edit,’ and then save them with no changes.

Since I decided to use WP-CLI, though, I wanted to get a list of all
```
$ wp post list --field=ID --post_type=post_type_shows --post_status=publish
```
This gave me a list of every show that was published.
```
$ wp post update 1 2 3 n --post_status=publish --defer-term-counting
```
And this re-saved every single show that was published with the post status of … published.

Make it Sort

Once I had done all that leg work, I could use the super basic sort by meta key value. The only difference to what we did before is that now we’re using meta_value_num .. since characters are numbers.
28 September, 2016
Review: Ninja Forms 3

I wanted to have this out last week, in time for their release of Ninja Forms 3, but with WordPress 4.6.1 dropping the day before and me breaking the site I use Ninja Forms on, well let’s just say my week ran away with me. See the previous post about how lesbians eat data for more.

Anyway. Ninja Forms 3. It took these guys a year to get it all right, and from where I sit, they did an amazing job. They managed to upgrade with minimal loss of data. And since we’re talking about forms, that’s a huge deal. You see, when you do a major overhaul of how forms are built, you’re changing how the data is stored. You’re also (possibly) changing the shortcakes in the posts where the forms are located.

Making matters ‘worse’ for Ninja Forms, they have add-ons. Now they have to make sure these hundreds of add ons will work with the new version of Ninja Forms, and you can bet that not every developer will be responsive. I know that one for a fact.

What they did was nothing short of phenomenal. You see, they ended up making two plugins and a migrator, wrapped it all up into one plugin, and released it. I cannot stress how incredibly hard that is. And they did it right and well.

Here’s how it worked. I had version 2.9.x and I pressed that happy upgrade button to go to version 3. Nothing changed. I had an alert telling me that “3 is coming!!” which I knew, so I clicked on the link and was taken to a page asking me if I wanted to upgrade. Hold on a second. I was asked to use the new version.

Right then and there I realized they’d not just included some 2.9.x stuff in the plugin as a fall back, no no. They had two plugins. That’s twice the work, but more to the point, they had an upgrader and a downgrade in there. I clicked upgrade, migrated my forms, and that was it. From the visitor’s end, nothing had changed, and that’s how we like it.

For me though, using it was a mind trip. The very first thing I noticed was that it took up my whole screen. Now I’m not a fan of that in general. I want WordPress to look like WordPress. I want access to all my things so I can right click and open a link in a new tab and multitask. And worse, most full screen WordPress tools don’t look like WordPress. The disparity of those kinds of changes bothers me a lot.

Shockingly, Ninja Forms felt like WordPress. It looked and felt like everything else in my dashboard. I’ve only seen this a few times, like with WooCommerce, where the ‘non’ WordPressy pages were still WordPress. This is hugely important to me. The more we make a consistent user environment for WordPress, the better we make the entire WordPress experience for our users.

I hadn’t messed much with Ninja Forms since I first set it up but now I had all sorts of fun things to play with. The drag and drop interface was as slick as it looked in the videos. This has reinvigorated my interest in things and I’ll be adding some more custom forms to the site soon.

Okay, so what don’t I like?

The colors don’t match my site. This is so random, I know, but I like to use different WP Admin themes for different sites. This site is purple, another is blue, and the one using Ninja Forms is 80s Kids – bright blue and pink. I wish that Ninja Forms picked up my admin colors and used that to make their interface.

I’m disappointed about tabbing as well. I can’t press tab and go between fields when I’m editing a form. I try to use my mouse as little as possible when I enter data. If I’m typing in information, like ‘term name’ and ‘value,’ then I want to press tab to jump to the next field.

Finally, and this is going to sound weird, I don’t like that the form editor makes the rest of their settings pages look plain. They did such a kick ass job, I look at the ‘regular’ settings and think they missed something. I know, it’s petty.

16 September, 2016
Lesbians Eat Data
The original title was “Lesbians Broke Jetpack” but it turned out to be even more complicated than all that. And thankfully more rare.

This concerns three things.

1) The website lezwatchtv.com
2) Jetpack for WordPress
3) ElasticSearch

On Sept 6th, Jetpack released a new version – 4.3 – and I promptly upgraded. When I did, I started getting weird emails from my server of a “Suspicious process running under user lezwatchtv” and the content looked like this:
```
Executable:

/usr/bin/php-cgi

Command Line (often faked in exploits):

/usr/bin/php-cgi /home/lezwatchtv/public_html/wp-cron.php


Network connections by the process (if any):

tcp: MYIP:39734 -> JETPACKIP:443
```
Being a proper code-nerd, I backed out a few things and tried again. Same error. I went into my process watcher and saw five processes calling wp-cron.php for that domain, but no others on the server. I killed the processes and turned off WordPress cron. Everything was fine. Then I installed WP Crontrol and manually kicked off cron jobs until it happened again.

The culprit was a ‘runs everyone one minute’ job by Jetpack, which struck me as bewildering.
```
		if ( ! wp_next_scheduled( 'jetpack_sync_cron' ) ) {
			// Schedule a job to send pending queue items once a minute
			wp_schedule_event( time(), '1min', 'jetpack_sync_cron' );
		}
```
The sync job is meant to update your data on Jetpack’s servers, which makes sense, and running every minute will copy up everything that changed in each minute. It seemed a little heavy to me, and disabling it stopped my run-away cron jobs. That meant the sync was failing. I reached out to a Jetpack tech and explained the situation. He re-ran the sync manually and it stalled.

We determined the likely issue was that the job was, for some reason, hanging and unable to finish, so it would just stay active forever. And ever. And since it would see that the sync had never done, it would start up all over again until, finally, my server killed the five (yes, five) processes and sent me an angry text about it. Yes, my server texts me.

At this point I emailed support with full details and got a very insightful reply from Brandon Kraft:

I’m interested in if there’s an issue with the server connecting with WP.com (seems unlikely given your other sites sound fine), if there’s a large amount of postmeta or something like that that is throwing a wrench into the system, or something to that effect. We’ve isolated some odd cases where when there is either a lot of postmeta or something yet undetermined in postmeta breaks things in a way similar to what you saw.

DING!

See there are 40 posts, 22 pages and then 1246 Custom Post posts on LezWatchTV.

906 posts are ‘characters’ and all characters have three separate taxonomies, two plain text post-meta values, and two serialized. 340 posts are ‘shows’ with two taxonomies, three plain text post-meta values, three integer (plain text) post-meta values, one true/false, six HTML, and one serialized data.

So if I was going to point at “a site with lot of weird post meta” I would pick this site.

I spent a few hours on the 7th (the day after the release) beta testing their 4.3.1 version. We tried a patch for the bug where full sync wasn’t giving up on wp error. That helped a little, but the error kept happening, limiting itself to two or three processes. I pointed to a special API, I ran some weird wp shell commands, and all we came up with was that at 190 or so ‘chunks’ out of 443, my server would stop sending messages to Jetpack’s servers.

Eventually I zipped up a copy of the theme and plugins and a sanitized DB (all secret information removed) and sent it over for them to play with. And they reproduced it! That was good. It meant it wasn’t my server, but it was my setup and the way Jetpack’s sync worked.

Like everything that has to sync, Jetpack plays the game between ‘sync it all super fast’ and ‘don’t kill the server.’ The way they sync the posts, they apply filters to render the content, including embeds. Because it does that with embeds, it triggers update_post_meta to update the _oembed_time_{long_base64_string} value, so it can know when to update the embed code for best caching.

Wasn’t I just talking about post meta the other day? Why yes! I was talking about optimizing post meta for search! The interesting thing about that is, since I’m using ElasticPress, it scans all my post meta for updates so it knows what to save as searchable data. That means when Jetpack triggers the update, it triggers ElasticPress, and all hell breaks loose.

But why did this happen now? Because I turned on “Sitemaps” for Jetpack. And when you enable (or disable) a Jetpack Module, it triggers a full sync. This happened to be the first time I’d done that since installing ElasticPress.

I did what any responsible person would do, and wrote this all up and submitted a bug report with ElasticPress. Sadly for now I’ve disabled ElasticPress until this can be resolved. I can probably turn it back on safely, since I won’t be triggering a full sync any time soon, but since I don’t want to accidentally crash things, I’ve left it off.

And how was your week?
14 September, 2016
CMB2 And The Dropdown Years
At WordCamp Montreal, I mentioned the database of dead lesbians that Tracy and I maintain. The camper looked at it and said “You know it would be awesome if you showed the shows airdates.”

Good point! Except I just plain struggled with the concepts and how to do them in CMB2. I knew I could make multiple fields in one ‘metabox’ as I read up on the snippet for an address field, but try as I might, I couldn’t make it work.

I tweeted my headache and ended up talking to Justin Sternberg who asked me if I could explain my use case better.
I have 300+ posts, all of which have a start and end date. Some may have an end date of “current” however.

Examples of valid data:
- 1977-1979
- 2016-current
- 2000-2016
I also need to sort by start and end year. So I can search for all posts with a start of 2014.

I could have two year-sorts, easily, but that makes for a clunky interface as it would be separate fields. I know CMB2 can have a combined field (like addresses) but while I got it to save, it wouldn’t properly display on the edit page.

This only needs to be editable on the WP admin edit post.
That night, he replied and asked if this year-range field type would work.

Mind? Blown. It works exactly how I need it to. I tweaked the code (and threw in a pull request) to set up a way to reverse the years (show newest first) which is more useful for my needs.

Now? Editing 319 show entries.
8 August, 2016
WordPress Reviews: The Good, The Bad, and the Stalker

The following is the original notes on my WCEU talk about WordPress reviews. It’s more or less what I said, though the video will no doubt be up soon.

30 Months In Jail Over a One Star Review

This is a true story. In late 2014, a man violently assaulted a woman who left a bad review on his self published ebook. He stalked her, sorting out her pseudonym, finding her real name, address, and work location. He traveled 500 miles, found her at work in Scotland and hit her over the head with a full bottle of wine. He received 30 months in jail for the assault and stalking.

An Extreme? Not So Much

Every day people leave hundreds of reviews on WordPress themes and plugins. They talk about how much they love or hate a plugin, there is rarely any middle ground here, and they are as passionate as the developers themselves. This passion leads to a large amount of confrontation on the WordPress Review Systems.

Your Code Is Bad< And You Should Feel Bad<

We are all going to get the bad reviews, and while you might want to dismiss the idea of being a stalker or a violent offender, because YOU would never do it, I promise you this. You will react badly to a poor review. It’s human nature. You’ve worked for hours on something and someone just said your code sucks. It hurts. And while I say this simply, it’s incredibly hard to do what I’m about to tell you…

Learn: Reviews Are Lessons

You have to learn from the reviews. Even the worst review has something you can take from it. If you can put aside your own ego to try and see the world from their side, you can many times take the lessons, apply them to your code, and make everything better. Maybe it’s a fix to code, but more often it’s a documentation issue. There is no 100% perfectly intuitive system out there. Not even life itself. We all had to learn how to use a toilet after all. So what can we learn from reviews?

The Points Don’t Matter; Everything Is Made Up

People concentrate on getting good reviews, on getting five stars. That’s the wrong approach. A five star review is useless for your ongoing improvement of your product and tells you nothing. All you can do is begin a humanization of your code, leaving a reply of ‘thank you’ perhaps, but you can learn little from these.

Context Is Everything: Room For Improvement

The review you want is the one that tells you they mostly like your work, but can see room for improvement, and they leave you suggestions. The review where someone has trouble finding information is another good one. That tells you what your FAQ is lacking, for example. These are people who are probably willing to have a conversation and just need you to begin it. Don’t be afraid to ask “What was it about the cowbell feature that bothered you?” or “I do explain this in the FAQ. Would it have helped you if I put an in-line note?” Engage them and learn from them.

There Will be Anger: To The Pain

The review you don’t want is the one where people are livid. Where they all you names and abuse you. No one wants that, and sometimes you can talk to them and get details, but you’re starting in a disadvantageous position and you have to fight to get answers. If you talk to this person, which I do recommend, be prepared for snarky replies and snide remarks. When you get to the troublemakers who complain they wanted to leave a ZERO star review, you have to be strong and not reply in kind. Sometimes there’s no salvaging the relationship.

A Review Is An Experience, And It’s Not Yours

The trick of all this is to remember that a review is not always a review on how a product worked. It’s also about how someone FEELS when looking at and using your product. A review is THEIR experience with your product, and the users experience with your code doesn’t necessarily start with them using your code. You need to understand who they are, why they feel this way, in order to properly handle their review. The experience begins with how people are introduced to your product, so if that’s an email marketing campaign or a website with a lower-case P, this will impact their experience and thus their review.

Handling A Review… It’s Not Easy

You’re going to get angry. If you’re like me and sometimes, when you’re mad, you feel your face heat up and you literally see red? Walk. Away. Don’t reply. If you cannot reply, in public, politely, DO NOT REPLY. Okay? Shut up, don’t do it. What you do in response to a review will be PUBLIC and you WILL be weighed by it. So don’t shoot yourself in the foot. Once you’re calm, you can process the reviews.

The “Support” Review: “I don’t know how to use it.”

This one drives people nuts. A review that should have been a support ticket, or maybe it could have been solved by looking at the FAQ. While you can’t make them do the right thing, you can offer help in the review. Explain how they should report this next time and try to find a solution. These suck. A lot. I hate them. But they happen everywhere, even Amazon. Try to fix the issue, but don’t give it any more attention than you would a normal support post. Be careful not to let these become the next kind of review…

The “Blackmail” Review: “You don’t have a feature I want.”

This is my least favorite. One star review because a plugin didn’t do something they wanted. It feels unfair, too, because you’re being judged on something you didn’t do and weren’t even planning on doing. It makes me seethe. And there isn’t a fix here. You have to be able to say “no” and not feel guilty, which is hard. Your trick here is remembering it’s okay to not have your code do everything. If your theme changes colors based on photos, it’s okay not to want to support changing for animated gifs. Speaking of reviews of the wrong things…

The “Commercial” Review: “I bought the pro version and it sucks.”

The reviews on WordPress.org should be for your free product on WordPress.org. Sometimes they’re not. If you’re upselling your products from the free version, if you have ads on your plugin and tell people “for more features, use the pro version!” then you’ve opened yourself to the painful review of how that upgrade process goes. The best you can do is offer to help them via official channels, but if someone’s upgrade to your pro version goes poorly, you’re going to get a bad review. You cannot ask people to upgrade and give you money and not expect them to have an opinion.

The “Way Too Angry” Review: [CENSORED]

Oh boy. This one. The review that you read that is insane. You know this one, right? It’s filled with language so foul and so appalling you can hardly process. Don’t reply. Don’t. This person is a lost cause. If you say anything, keep it to “I’m sorry you feel this way” but frankly I wouldn’t.<

The “Mistake” Review: Spam, sockpuppets, wrong plugins, and more!

I actually like these reviews. They’re easy to deal with because all I do is have them deleted. Tag the post ‘modlook’ and then spam or sockpuppet or wrongplugin and walk away. I wish they could all be this way…

Learn: Mistakes Will Happen

The biggest takeaway from this, if you want to distill this entire talk into a tweet, it would be this: Don’t post angry. Don’t attack anyone. Remember we are, all of us, humans. And really, this should be simple for everyone and every thing. This is humanity at work, we can be nice and respectful in the face of adversity, thinks would be be better all around. But maybe that’s the wrong take away. The wrong drive. So let me say this a different way.

Your Business Is Not Code, It’s You

Read that. Your business is not your code, your product, your output. Your business, every business, is people. If you’re replying to the reviews, you are the face of your product, and if you’re here, I’m assuming your company. One or five people, ten or ten hundred, your company is the face and if you’re the face then how you act, in public, will impact your business more than any one-star review ever will.

A Final Thought… Don’t Be The Bad Guy

Let me conclude with another true story. There was a plugin that had a troubling user. The user bought the premium upgrade and was disappointed. Nothing worked right. The plugin developers tried to fix it, but were unable. It was an incompatibility between their plugin and another. The user wanted his money back. The developer argued they’d gone above and beyond the call of duty and were not going to refund as per their policy. The user threatened to leave bad reviews if there was no refund and carried through this threat. The developer capitulated BUT held onto the money and said they would only refund if the reviews were altered. The user said no and things went even more downhill from there.

You Can Say No; Defeat Does Not Mean Loss

This is the hardest lesson of all. It’s okay to say no. It’s okay to walk away. It’s okay to tell someone “I’m sorry, but I can’t help you.” or “I’m sorry, but this is against our policy.” This hurts. It makes you feel inadequate and like you’re a faker. You’re not. It’s mathematically impossible to be perfect, so while you should try to be the best you can, it’s okay to concede to defeat. The trick is understanding that defeat, accepting you cannot help everyone, does NOT mean you lose. It doesn’t kill your plugin or theme or business. It teaches you what you can do better next time.

4 July, 2016