As the new plugin directory rolls out, I know a lot of people are fussing over the front end. I’m not for a very practical reason. I’m working on making the backend functional and educational.

Information Is Key

A lot of the information about what a various post status means is something I understand from experience. My goal is to expand the team as broadly as possible and in order to do that, I must document. But documentation is more than just writing up a doc and telling people to follow it.

People need contextual reminders of what the status of a ‘thing’ is to understand what they must do next. With that in mind, I leveraged some code by Obenland to make reviewer alerts better. Originally, you see, our plan was to let plugin developers edit things from the admin panel. Everything’s moving to the front end except for the reviewers you see.

On Beyond Plugins

That’s all well and good, but what if I want to do it on my own sites? What if I wanted to have a site message for the editors on my site, so they’d know what posts are ‘done’ and which need some love? What if I wanted to encourage my fellow editors to edit a post I’d worked on?

I made my plan, based off the old stub template from MediaWiki, because that was always a good way to know if a post did or didn’t need some love.

  1. I needed a way to ‘flag’ a post as a stub automatically
  2. I needed it to display on the page being edited
  3. I would like it to display on the front end but only to logged in users (for now)

Stub Qualifications

In order to flag a post automatically, I needed to come up with criteria or qualifications that would mark a post as a stub. Obviously content was part of it, but measuring the quality of the content was going to be difficult.

My initial criteria for a stub was the following:

  • Under 100 words in post content
  • Empty meta value for “Worth it details”

Obviously that second item is unique to my situation, but having it meant I could measure engagement by how much someone knew about a show to enter the data. That criteria seemed too strict though. So I tweaked them to be an OR and not an AND. No matter what, if there was under 100 words it was getting flagged. And no matter what, if there was no meta for worthiness, it would be flagged.

  • Info: No meta value for Worth It
  • Warning: No meta value for Worth It and post content under 200 words
  • Alert: No meta value for Worth It and post content under 100 words

WP Admin Code

The original code that all this is based on is from (not the WordPress code but the stuff that runs the domain).

add_action( 'edit_form_after_title', 'MYSITE_admin_notices' );
function MYSITE_admin_notices() {
	$message    = '';
	$type       = 'updated';
	$post       = get_post();

	switch ( $post->post_type ) {
		case 'post_type_shows':

			$content    = get_post_field( 'post_content', $post->ID );
			$word_count = str_word_count( strip_tags( $content ) );
			$worthit    = get_post_meta( $post->ID, 'worthit_details', true );

			if ( $worthit < '1' ) {
				$type     = 'notice-info';
				$message  = 'Is this show worth watching? We don\'t know. Halp!';
				$dashicon = 'heart';

				if ( $word_count < '100' ) {
					$type     = 'notice-error';
					$message  = 'We clearly know nothing about this show. Help!';
					$dashicon = 'warning';
				} elseif ( $word_count < '200' ) {
					$type     = 'notice-warning';
					$message  = 'This post is a stub. Please edit it and make it more awesome.';
					$dashicon = 'info';

	if ( $message ) {
		printf( '<div class="notice %1$s"><p><span class="dashicons dashicons-%2$s"></span> %3$s</p></div>', esc_attr( $type ), esc_attr( $dashicon ), esc_html( $message ) );


The reason it uses edit_form_after_title and prints the error instead of add_settings_error is that I don’t actually want these alerts to be dismissible and I only want it to show on post editor pages.

The Output

This post needs some attention

There’s some improvements to be made, but this is a start.

Reader Interactions

%d bloggers like this: