Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • JSON Rest API (In Peace)

    JSON Rest API (In Peace)

    This week I’ve been talking about my list of dead characters, which I needed to order by year and wanted to display the most recent death in a widget.

    Part of my end goal with all this was a dream I had to let people have a widget on their own site where they could display the most recently dead character. There were other ideas I had, like a ‘this day in YEAR, Character X died.’ But for now, I wanted to start my delving into the JSON API with something more simple.

    Because this is my first serious go at it.

    Sketching Out The Concept

    To do this, I broke my concept down into the logical steps of what was needed.

    • Output the data
    • Create a JSON URL
    • Format the data there

    And no, I have no idea how to do any of that, except outputting the data.

    The Rest API

    To initialize the Rest API, you have to call a function on init() and that’s where it defines the URL that will be called. There are three (or four) parts to a URL:

    • Namespace
    • Version
    • Route
    • Arguments

    The version isn’t technically required, but in the interests of future proofing, it’s probably a good idea. And in this specific case, I don’t have any arguments I want to pass through. You’re going to get just the output of the last dead. In deciding that, I was able to determine the most sensible structure.

    My namespace should be for my site, not just this ‘show the dead’ feature. This is not always going to be the case, but since I’m adding in what I presume will be the first of some APIs, it’s wise to name in a way that is forward thinking. Similarly, I need my route to be logically named, and in this case I’m showing the last death, so I called it last-death.

    This makes my desired URL /wp-json/MYSITE/v1/last-death/ and the code is this:

    public function rest_api_init() {
    	register_rest_route( 'MYSITE/v1', '/last-death', array(
    		'methods' => 'GET',
    		'callback' => array( $this, 'rest_api_callback' ),
    	) );
    }
    

    The callback code is what gets my data, and based on my original widget resulted in the page displaying the following:

    "It has been <strong>2 months and 6 days<\/strong> since the last death: <a href=\"https:\/\/example.dev\/character\/gina\/\">Gina<\/a> - December 7, 2016"
    

    But I didn’t want it to be formatted like that. Instead, I wanted the code to spit out an array. To do that with my existing setup, I rewrote the dead_char() function, taking out all the parts that generated the days since the last death and instead put that in a separate plugin. Now this one gives an API output:

    {"name":"Gina","url":"https:\/\/example.dev\/character\/gina\/","died":1481068800,"since":"5792233"}
    

    That has the added bonus of letting anyone who wants to call it on their own for whatever they want isn’t stuck with my design. Yay, open source!

    The Code

    My JSON code went into a class like this:

    class MYSITE_Dead_Character_JSON {
    
    	/**
    	 * Constructor
    	 */
    	public function __construct() {
    		add_action( 'init', array( $this, 'init') );
    	}
    
    	/**
    	 * Init
    	 */
    	public function init() {
    		add_action( 'rest_api_init', array( $this, 'rest_api_init') );
    	}
    
    	/**
    	 * Rest API init
    	 *
    	 * Creates the callback - /MYSITE/v1/last-death/
    	 */
    	public function rest_api_init() {
    		register_rest_route( 'lwtv/v1', '/last-death', array(
    			'methods' => 'GET',
    			'callback' => array( $this, 'last_death_rest_api_callback' ),
    		) );
    	}
    
    	/**
    	 * Rest API Callback
    	 */
    	public function last_death_rest_api_callback( $data ) {
    		$response = $this->last_death();
    		return $response;
    	}
    
    	/**
    	 * Generate List of Dead
    	 *
    	 * @return array with last dead character data
    	 */
    	public static function last_death() {
    		// Get all our dead queers
    		$dead_chars_loop  = MYSITE_tax_query( 'post_type_characters' , 'cliches', 'slug', 'dead');
    		$dead_chars_query = wp_list_pluck( $dead_chars_loop->posts, 'ID' );
    
    		// List all queers and the year they died
    		if ( $dead_chars_loop->have_posts() ) {
    			$death_list_array = array();
    
    			// Loop through characters to build our list
    			foreach( $dead_chars_query as $dead_char ) {
    
    				// Date(s) character died
    				$died_date = get_post_meta( $dead_char, 'lezchars_death_year', true);
    				$died_date_array = array();
    
    				// For each death date, create an item in an array with the unix timestamp
    				foreach ( $died_date as $date ) {
    					$date_parse = date_parse_from_format( 'm/d/Y' , $date);
    					$died_date_array[] = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
    				}
    
    				// Grab the highest date (aka most recent)
    				$died = max( $died_date_array );
    
    				// Get the post slug
    				$post_slug = get_post_field( 'post_name', get_post( $dead_char ) );
    
    				// Add this character to the array
    				$death_list_array[$post_slug] = array(
    					'name' => get_the_title( $dead_char ),
    					'url' => get_the_permalink( $dead_char ),
    					'died' => $died,
    				);
    			}
    
    			// Reorder all the dead to sort by DoD
    			uasort($death_list_array, function($a, $b) {
    				return $a['died'] <=> $b['died'];
    			});
    		}
    
    		// Extract the last death
    		$last_death = array_slice($death_list_array, -1, 1, true);
    		$last_death = array_shift($last_death);
    
    		// Calculate the difference between then and now
    		$diff = abs( time() - $last_death['died'] );
    		$last_death['since'] = $diff;
    
    		$return = $last_death;
    
    		return $return;
    	}
    
    }
    new MYSITE_Dead_JSON();
    

    You may notice that I don’t seem to have a loop, and I call this instead:

    $dead_chars_loop  = MYSITE_tax_query( 'post_type_characters' , 'cliches', 'slug', 'dead');
    

    For various reasons, I reuse a lot of loop calls. To make my own theme and plugin more human readable, that function does the query. It looks like this:

    function MYSITE_tax_query( $post_type, $taxonomy, $field, $term, $operator = 'IN' ) {
    	$query = new WP_Query ( array(
    		'post_type'       => $post_type,
    		'posts_per_page'  => -1,
    		'no_found_rows'   => true,
    		'post_status'     => array( 'publish', 'draft' ),
    		'tax_query' => array( array(
    			'taxonomy' => $taxonomy,
    			'field'    => $field,
    			'terms'    => $term,
    			'operator' => $operator,
    		),),
    	) );
    	wp_reset_query();
    	return $query;
    }
    

    Since I have to do a lot of odd calls for the statistics on that site, it became smarter to do it that way.

    Calling the Data From YOUR Site!

    I made an endpoint! This is all well and good, but the new question is “How does someone else include this on their site?”

    The answer there is they need a widget. And it’s a widget I’ve mostly already made! All I had to do was create a plugin that made the widget and instead of calling the loops locally, just call the API.

    class Bury_Your_Dead {
    
    	public function __construct() {
    		add_action( 'widgets_init', array( $this, 'last_death_register_widget' ) );
    	}
    
    	public function last_death_register_widget() {
    		$this->widget = new BYD_Last_Death_Widget();
    		register_widget( $this->widget );
    	}
    
    	public static function last_death() {
    		$request  = wp_remote_get( 'https://example.dev/wp-json/MYSITE/v1/last-death/' );
    		$response = wp_remote_retrieve_body( $request );
    		$response = json_decode($response, true);
    
    		$diff = $response['since'];
    
    		$years = floor($diff / (365*60*60*24));
    		$months = floor(($diff - $years * 365*60*60*24) / (30*60*60*24));
    		$days = floor(($diff - $years * 365*60*60*24 - $months*30*60*60*24)/ (60*60*24));
    
    		$since = '';
    		if ( $years != 0 ) $since .= sprintf( _n( '%s year, ', '%s years, ', $years, 'MYSITE' ), $years );
    		if ( $months != 0 ) $since .= sprintf( _n( '%s month', '%s months', $months, 'MYSITE' ), $months );
    		$since .= ( $years != 0 )? ', ' : ' ';
    		$since .= ( $months != 0 )? __('and ', 'MYSITE') : '';
    		if ( $days != 0 ) $since .= sprintf( _n( '%s day', '%s days', $days, 'MYSITE' ), $days );
    
    		$response['since'] = $since;
    
    		return $response;
    	}
    }
    new Bury_Your_Dead();
    
    class BYD_Last_Death_Widget extends WP_Widget {
    
    	protected $defaults;
    
    	function __construct() {
    
    		$this->defaults = array(
    			'title'		=> __( 'The Most Recent Death', 'MYSITE' ),
    		);
    
    		$widget_ops = array(
    			'classname'   => 'dead-character deadwidget',
    			'description' => __( 'Displays time since the last WLW death', 'MYSITE' ),
    		);
    
    		$control_ops = array(
    			'id_base' => 'lezwatch-dead-char',
    		);
    
    		parent::__construct( 'lezwatch-dead-char', __( 'The Latest Dead', 'MYSITE' ), $widget_ops, $control_ops );
    	}
    
    	function widget( $args, $instance ) {
    
    		extract( $args );
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    
    		echo $args['before_widget'];
    
    		if ( ! empty( $instance['title'] ) ) {
    			echo $args['before_title'] . apply_filters( 'widget_title', $instance['title'] ) . $args['after_title'];
    		}
    
    		$dead_character = Bury_Your_Dead::last_death();
    
    		echo sprintf( __('It has been %s since the last death', 'MYSITE'), '<strong>'.$dead_character['since'].'</strong>' );
    		echo ': <a href="'.$dead_character['url'].'">'.$dead_character['name'].'</a> - '.date('F j, Y', $dead_character['died'] );
    
    		echo $args['after_widget'];
    	}
    
    	function update( $new_instance, $old_instance ) {
    		$new_instance['title'] = strip_tags( $new_instance['title'] );
    		return $new_instance;
    	}
    
    	function form( $instance ) {
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    
    		?>
    		<p>
    			<label for="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>"><?php _e( 'Title', 'MYSITE' ); ?>: </label>
    			<input type="text" id="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>" name="<?php echo esc_attr( $this->get_field_name( 'title' ) ); ?>" value="<?php echo esc_attr( $instance['title'] ); ?>" class="widefat" />
    		</p>
    		<?php
    	}
    }
    

    Whew. That’s huge, I know! And you may have noticed I snuck some translation in there. Always look forward!

  • It Has Been X Days Widget

    It Has Been X Days Widget

    Yesterday I talked about ordering posts by post meta in a weirdly unique situation. Today I’m going to tell you about an even weirder one.

    As I mentioned, what I’m working with is a list of all the dead characters recorded on a site. One of the aspects of this is to allow for us to show a widget that tells visitors how many days it’s been since the last death, and who it was. There are a lot of ways to do this, and one of them is manually updating, but no one likes this. If an event can be automated, everyone wins.

    Since I’d already done the lion’s share of the work, forking it over into a widget and grabbing the last (i.e. most recent) death was easier.

    The Code

    I broke this up into two classes because it’s habit. I have no other reason.

    class Dead {
    	public function __construct() {
    		add_action( 'widgets_init', array( $this, 'register_widget' ) );
    	}
    
    	public function register_widget() {
    		$this->widget = new Dead_Widget();
    		register_widget( $this->widget );
    	}
    
    	public static function dead_queers() {
    		// Get all our dead queers
    		$dead_chars_loop = new WP_Query( array(
    			'post_type'       => 'post_type_characters',
    			'posts_per_page'  => -1,
    			'meta_query'      => array(
    				array(
    					'key'     => 'chars_death_year',
    					'value'   => $thisyear,
    					'compare' => 'REGEXP',
    				),
    			),
    		) );
    		$dead_chars_query = wp_list_pluck( $dead_chars_loop->posts, 'ID' );
    
    		// List all queers and the year they died
    		if ( $dead_chars_loop->have_posts() ) {
    			$death_list_array = array();
    
    			// Loop through characters to build our list
    			foreach( $dead_chars_query as $dead_char ) {
    
    				// Date(s) character died
    				$died_date = get_post_meta( $dead_char, 'lezchars_death_year', true);
    				$died_date_array = array();
    
    				// For each death date, create an item in an array with the unix timestamp
    				foreach ( $died_date as $date ) {
    					$date_parse = date_parse_from_format( 'm/d/Y' , $date);
    					$died_date_array[] = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
    				}
    
    				// Grab the highest date (aka most recent)
    				$died = max( $died_date_array );
    
    				// Get the post slug
    				$post_slug = get_post_field( 'post_name', get_post( $dead_char ) );
    
    				// Add this character to the array
    				$death_list_array[$post_slug] = array(
    					'name' => get_the_title( $dead_char ),
    					'url' => get_the_permalink( $dead_char ),
    					'died' => $died,
    				);
    			}
    
    			// Reorder all the dead to sort by DoD
    			uasort($death_list_array, function($a, $b) {
    				return $a['died'] <=> $b['died'];
    			});
    		}
    
    		// Extract the last death
    		$last_death = array_slice($death_list_array, -1, 1, true);
    		$last_death = array_shift($last_death);
    
    		$diff = abs( time() - $last_death['died'] );
    		$years = floor($diff / (365*60*60*24));
    		$months = floor(($diff - $years * 365*60*60*24) / (30*60*60*24));
    		$days = floor(($diff - $years * 365*60*60*24 - $months*30*60*60*24)/ (60*60*24));
    
    		$days_since = '';
    		if ( $years != 0 ) $days_since  .= $years .' '. _n( 'year, ', 'years, ', $years );
    		if ( $months != 0 ) $days_since .= $months .' '. _n( 'month', 'months', $months );
    		if ( $years != 0 ) $days_since  .= ',';
    		if ( $months != 0 ) $days_since .= ' and ';
    		if ( $days != 0 ) $days_since   .= $days .' '. _n( 'day', 'days', $days );
    
    		$return = 'It has been <strong>'. $days_since .'</strong> since the last death: <a href="'.$last_death['url'].'">'.$last_death['name'].'</a> - '.date('F j, Y', $last_death['died'] );
    
    		echo $return;
    	}
    }
    new Dead();
    
    class Dead_Widget extends WP_Widget {
    
    	protected $defaults;
    
    	function __construct() {
    		$this->defaults = array(
    			'title'		=> 'Bury Your Dead',
    		);
    
    		$widget_ops = array(
    			'classname'   => 'dead-queer deadwidget',
    			'description' => 'Displays days since the last death',
    		);
    
    		$control_ops = array(
    			'id_base' => 'dead-person',
    		);
    
    		parent::__construct( 'dead-person', 'Days Since Last Dead', $widget_ops, $control_ops );
    	}
    
    	function widget( $args, $instance ) {
    		extract( $args );
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    
    		echo $before_widget;
    
    		if ( ! empty( $instance['title'] ) ) {
    			echo $before_title . apply_filters( 'widget_title', $instance['title'], $instance, $this->id_base ) . $after_title;
    		}
    
    		echo Dead::dead_chars();
    
    		echo $after_widget;
    	}
    
    	function update( $new_instance, $old_instance ) {
    		$new_instance['title']      = strip_tags( $new_instance['title'] );
    		return $new_instance;
    	}
    
    	function form( $instance ) {
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    		?>
    		<p>
    			<label for="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>">Title:</label>
    			<input type="text" id="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>" name="<?php echo esc_attr( $this->get_field_name( 'title' ) ); ?>" value="<?php echo esc_attr( $instance['title'] ); ?>" class="widefat" />
    		</p>
    		<?php
    	}
    }
    

    Which looks like this:

    Bury Your Queers

    An Explanation

    Some things to note.

    While I only allow for customizing the title, I’ve left my arguments as an array in order to let me extend it later. What if, for example, I want to display the featured image as well?

    I’ve also left in some ‘default’ calls to Genesis’ StudioPress theme with regards to the widget layout. That’s because I wrote this for a StudioPress theme.

    The whole reason the death year is an array is that, as I mentioned the other day, people may die multiple times. Insert Buffy singing “Hey I died twice” here. I have to get all the dates, pick the largest number (which is the most recent date, remember Unix timestamps are forever increasing), and save that one. Once I find the ultimate largest number, I know that’s my character to save. Problem is I have to go through them all to figure out who died last.

    I’m inordinately happy about getting to use array_slice() to grab the final item in an array, and ditto array_shift() to move the multidimensional array to a single dimension.

    Using array_shift() changed this:

    Array ( 
        [gina] => Array (
            [name] => Gina 
            [url] => https://example.dev/character/gina/ 
            [died] => 1481068800 
        )
    )
    

    to this:

    Array ( 
        [name] => Gina 
        [url] => https://example.dev/character/gina/ 
        [died] => 1481068800 
    ) 
    

    And getting to finally use _n() in a non-translation sense was fun.

    The reason the dead characters are in a function in the first class is that I plan to extend this code later on, maybe making a shortcode or a JSON API call. Who knows!

    Finally, I mentioned that there were two ways to list the dead characters. One was by a taxonomy of character clichés and the other was by the death date post meta. In this case, I opted to sort by the taxonomy because if someone has a death date but is not marked as dead, then they were dead and came back to life.

  • Display Posts, Ordered By Post Meta

    Display Posts, Ordered By Post Meta

    One of the things I’ve been working on over on my tv project was getting better lists of characters who died. Initially all that we recorded was the year. However we started getting the idea of a timeline and a calendar and a ‘this year in queer TV’ section, and I realized I needed more precise data.

    I’m going to skip the headache part here, but I changed the year dropdown to a calendar date field that stored the date as MM/DD/YYYY. While some calculations would have been easier with the time saved as a UNIX timestamp, having it be text let me search as text to collect all the death for a year. There were pros and cons to both sides of the coin of how to save the data. The other trick was I needed to save the data as an array. Just in case someone died twice.

    Suffice to say, here’s your scenario. I have meta data in the post containing the date of character death, and I want to display it in a specific way, not supported out of the box by the default queries.

    Display all the dead in a list ordered by date

    The simple part in WordPress is to get a loop of all posts in a type that have the meta for death. Using WP_Query I grabbed the array and instead of saving all the post’s data, I extracted the data I needed:

    • character name and URL
    • date of death
    • list of shows and their respective URLs

    This I turned into a very simple array that I can use in multiple situations:

    $dead_chars_loop = new WP_Query( array(
    	'post_type'       => 'post_type_characters',
    	'posts_per_page'  => -1,
    	'meta_query'      => array(
    		array(
    			'key'     => 'chars_death_year',
    			'value'   => $thisyear,
    			'compare' => 'REGEXP',
    		),
    	),
    ) );
    $dead_chars_query = wp_list_pluck( $dead_chars_loop->posts, 'ID' );
    
    foreach( $dead_chars_query as $dead_char ) {
    	$show_info = get_post_meta( $dead_char, 'chars_show', true );
    	$died = get_post_meta( $dead_char, 'chars_dead', true );
    
    	$output_array[$post_slug] = array(
    		'name'  => get_the_title( $dead_char ),
    		'url'   => get_the_permalink( $dead_char ),
    		'shows' => $show_info,
    		'died'  => $died,
    	);
    }
    

    This array is made by looping through those WP_Query results and, for each character, grabbing the post meta data for shows and death. The simple array $output_array contains only the data I need for display. So no post content, no author, nada. Just the name, the URL, the shows, and the death. That said, I’m omitting my insane extra loop for generating $show_info with its links because it deserves its own post. Suffice to say, it’s weird. Oh and $thisyear is a page variable based on the URL you visit. If you go to /this-year/2015/ it will populate as ‘2015’ and so on.

    Side note. Characters actually have both a taxonomy for being dead and a lost meta for the date. That was a happy accident that allowed me to search for everyone who had died, and perhaps wasn’t currently dead. The time traveling Sara Lance is jokingly called Schroedinger’s Bisexual, since she is both alive and dead at any one given point in time.

    Fix The Date

    Okay! With my simple array of data, I can output the list however I want, depending on the way I ordered the query. The problem is that the query has a limited number of possible sorts, and they all have to do with the post subject, the title, not random post meta. Plus my post meta was saved in a way that wasn’t easily sortable.

    To solve this, I converted the date into a Unix timestamp:

    // Date(s) character died
    $died_date = get_post_meta( $dead_char, 'chars_death_year', true);
    $died_date_array = array();
    
    // For each death date, create an item in an array with the unix timestamp
    foreach ( $died_date as $date ) {
    	$died_year = substr($date, -4);
    	if ( $died_year == $thisyear ) {
    		$date_parse = date_parse_from_format( 'm/d/Y' , $date);
    		$died = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
    	}
    }
    

    I put this in the foreach( $dead_chars_query as $dead_char ) {...} section and it transformed my date from 01/01/2017 to it’s commiserate Unix timestamp.

    Fix The Order

    The next step was to re-order my array based on the value of the death time. I wanted to go from smallest value to largest, as Unix timestamps increase over time.

    For this I used uasort to order the entire array by the date:

    // Reorder all the dead to sort by DoD
    uasort($death_list_array, function($a, $b) {
    	return $a['died'] <=> $b['died'];
    });
    

    This produced my desired results. Excellent. But now I have the date in a non-human readable format!

    Fix It On output

    Thankfully making the date human readable wasn’t all that messy. Once I have my finished array, I output it and clean it up:

    <ul>
    	<?php
    	foreach ( $death_list_array as $dead ) {
    		echo '<li><a href="'.$dead['url'].'">'.$dead['name'].'</a> / '.$dead['shows'].' / '.date( 'd F', $dead['died']).' </li>';
    	}
    	?>
    </ul>
    

    Voila!

    This Year example for 2014

    An ordered list of dead characters.

  • When a Page is an Endpoint

    When a Page is an Endpoint

    In making a site with non-standard WordPress pages, I ran into a common problem. How do I make a page that calls the data? To put it in a different way, I needed a URL (say, domain.com/stats/) to show site statistics. A ‘virtual page’ if you will.

    The Easy Way

    The first way I did this was the ‘easy’ way, though I’m loathe to really call it that. I made a page in WP Admin called ‘stats’ and I set that page to use a custom page template that, instead of calling post content, called my stats code. Custom page templates are pretty powerful, and having the page be a page meant I could allow editors to write and edit the page all they wanted.

    But the downside is that making ‘sub’ pages gets messy, and what happens if someone changes the slug or deletes the page or changes the template? No. There had to be a better way that let me force generate the page.

    The ‘Better’ Way

    This brings me to custom endpoints.

    Now there is a huge problem with this, and it’s that if you want to make your custom virtual pages look like the rest of your WordPress site, it’s … messy. This is why BuddyPress generates pages automatically for you. It needs the pages. No matter what, I was going to have to make pages. But there is a distinct difference between 19 pages and 5.

    My (unique) situation was that I wanted to have a series of sub pages. That would let me make one page, for example, for ‘roles’ and then automagically generate pages for /role/regular/ and /role/guest/ and so on. And yet, this brings up the other major problem.

    You see, it would also mean the slugs /about/regular/ could exist. Obviously there are ways around it but the point to hammer home here is that endpoints are not meant for this. They’re meant for if you want a custom endpoint (hah) on every page of a type.

    The (Really) Better Way

    Thankfully, there’s a better way!

    Rewrite rules and custom query vars will let me do everything I wanted, with only one page for each item.

    The Setup

    I have five types of pages with ‘extra’ sub pages: newest, role, star, stats, and thumbs. Each one has a few accepted types, but I don’t need to really worry about that just yet, because how I handle it differs on each page (more on that in a second). First I made a list of all my pages, the ‘kind’ of extra they had, and their custom template. Because yes, each page has a custom template.

    • page slug: newest, extra: newtype, template: newtype.php
    • page slug: role, extra: roleype, template: roletype.php
    • page slug: star, extra: starcolor, template: starcolor.php

    You’ll notice I went with a theme there. It makes it easier to remember what’s what. Each template is heavily customized for the data within, since each page is wildly different from each other. The one check I make on every page though is that the ‘extra’ value matches what I think it should. For example, here’s the stats header:

    $statstype = ( isset($wp_query->query['statistics'] ) )? $wp_query->query['statistics'] : 'main' ;
    $validstat = array('death', 'characters', 'shows', 'lists', 'main');
    
    if ( !in_array( $statstype, $validstat ) ){
    	wp_redirect( get_site_url().'/stats/' , '301' );
    	exit;
    }
    

    That means if you go to /stats/humbug/ it redirects you back to the main stats page.

    Cool, right? So the question next is how did I get /stats/characters/ to work if there’s no commensurate page?

    The WordPress Way

    The answer is add_rewrite_rule and query_vars. I made an array with all my page slugs and their extra, which you’ll remember was the same name as the template file. This let me use a series of loops and checks so my code is simpler.

    My query arguments are this:

    $query_args = array(
    	'newest'	=> 'newtype',
    	'role'		=> 'roletype',
    	'star'		=> 'starcolor',
    	'stats'		=> 'statistics',
    	'thumbs'	=> 'thumbscore',
    		);
    

    Notice how that matches exactly what my design was above? That’s why I take the time to plan all this out.

    The next thing I did with all this was to set up my query variables. These loop through the query array and set up a variable for each one.

    add_action ('query_vars', 'helf_query_vars');
    function helf_query_vars($vars){
    	foreach ( $query_args as $argument ) {
    		$vars[] = $argument;
    	}
    	return $vars;
    }
    

    What that does is makes a URL like this work: http://example.com/?pagename=stats&statistics=death

    It also means this works: http://example.com/stats/?statistics=death

    Neither of those are particularly ‘pretty’ permalinks, though, are they? That means it’s time for add_rewrite_rule!

    foreach( $query_args as $slug => $query ) {
        add_rewrite_rule(
            '^'.$slug.'/([^/]+)/?$',
            'index.php?pagename='.$slug.'&'.$query.'=$matches[1]',
            'top'
        );
    }
    

    This code is actually in an init function, but what it does is make a custom rewrite rule so we can call the URL like this: http://example.com/stats/death/

    Which is what I want.

    The Whole Code

    The following is actually the code I use. Feel free to fork! I put it into a class and did some extra work to call the right templates on the right pages.

    class LWTVG_Query_Vars {
    
    	// Constant for the query arguments we allow
    	public $query_args = array();
    
    	/**
    	 * Construct
    	 * Runs the Code
    	 *
    	 * @since 1.0
    	 */
    	function __construct() {
    		add_action( 'init', array( $this, 'init' ) );
    
    		$this->query_args = array(
    			'newest'	=> 'newtype',
    			'role'		=> 'roletype',
    			'star'		=> 'starcolor',
    			'stats'		=> 'statistics',
    			'thumbs'	=> 'thumbscore',
    		);
    	}
    
    	/**
    	 * Main Plugin setup
    	 *
    	 * Adds actions, filters, etc. to WP
    	 *
    	 * @access public
    	 * @return void
    	 * @since 1.0
    	 */
    	function init() {
    		// Plugin requires permalink usage - Only setup handling if permalinks enabled
    		if ( get_option('permalink_structure') != '' ) {
    
    			// tell WP not to override
    			add_action ('query_vars', array($this, 'query_vars'));
    
    			foreach( $this->query_args as $slug => $query ) {
    			    add_rewrite_rule(
    			        '^'.$slug.'/([^/]+)/?$',
    			        'index.php?pagename='.$slug.'&'.$query.'=$matches[1]',
    			        'top'
    			    );
    			}
    
    			// add filter for page
    			add_filter( 'page_template', array( $this, 'page_template' ) );
    
    		} else {
    			add_action( 'admin_notices', array( $this, 'admin_notice_permalinks' ) );
    		}
    	}
    
    	/**
    	 * No Permalinks Notice
    	 *
    	 * @since 1.0
    	 */
    	public function admin_notice_permalinks() {
    		echo '<div class="error"><p><strong>Custom Query Vars</strong> require you to use custom permalinks.</p></div>';
    	}
    
    	/**
    	 * Add the query variables so WordPress won't override it
    	 *
    	 * @return $vars
    	 */
    	function query_vars($vars){
    		foreach ( $this->query_args as $argument ) {
    			$vars[] = $argument;
    		}
    		return $vars;
    	}
    
    	/**
    	 * Adds a custom template to the query queue.
    	 *
    	 * @return $templates
    	 */
    	function page_template($templates = ""){
    		global $wp_query, $post;
    
    		if ( array_key_exists( $post->post_name, $this->lez_query_args ) )
    			$the_template = $this->lez_query_args[$post->post_name].'.php';
    
    		foreach ( $this->lez_query_args as $argument ) {
    			if( isset( $wp_query->query[$argument] ) ) {
    				$templates = dirname( dirname( __FILE__ ) ) . '/page-templates/' . $the_template;
    			}
    		}
    
    		return $templates;
    	}
    
    }
    
    new LWTVG_Query_Vars();
    

    PS: Yes, I totally built it all out in endpoints before I got smarter.

  • On Uninstalling WordPress Plugins (and Data)

    On Uninstalling WordPress Plugins (and Data)

    Someone asked me why WordPress always says it’s going to delete files and data when it only removes the files and not the database options. There are two parts of the answer to this, one being a little historical and the other being a bit unhelpful.

    The Message: Delete Files and Data

    Once upon a time, when you uninstalled a WordPress plugin, it looked something like this:

    The Delete Plugin Screen

    That was a very simple screen. You were asked to delete the plugin files, you clicked that you were, done.

    Now you see this thanks to Shiny Updates:

    Shiny Updates - Delete Hello Dolly

    It’s a different message, telling you it’s deleting data!

    What Is The Data?

    The part you don’t see is that WordPress would also remove all the data as well as those files.

    Any time WordPress showed you that message to delete files and data, it was saying that it found a file called uninstall.php which would, presumably, delete the data set by the plugin. By this I mean the options and settings you chose for your plugin. Some plugins have data and others don’t. For example, Hello Dolly has no data, just files. It doesn’t need an uninstall file. On the other hand, a plugin like Jetpack has a lot of settings it should remove from the database on cleanup.

    Why Do We See ‘and Data’ If There’s None?

    Okay, so if Hello Dolly has no data to delete, why did we see that message? In part, this stems from the following idea:

    Delete plugin files AND data

    We wanted it to be more clear as to what was being deleted when you delete, and that was part of a proposed change to WordPress core to tell you if and when database settings are removed on uninstall, and let you leave it alone if needed. Wouldn’t that be nice? Letting you pick which way to go?

    Well. There’s a problem with that dream, and the name of the problem is “Plugin Frameworks.” No, not the CMB2 stuff, I mean the boilerplate plugin frameworks that are oh so popular.

    I hate them. Because they always have an uninstall, and most of the time people leave it alone. That’s right, your brilliant boilerplate will flag an alert that it’s deleting data when it’s not. This doesn’t impact the functionality of the base idea, but it does change the message.

    So Why Does It Say Data?

    Because when you uninstall a plugin, if it was well written, it removes the files and the data.

  • Show Featured Images on Post List

    Show Featured Images on Post List

    Let’s say you want to be sure every single post, in ever single post type, has a featured image. And you know someone might forget but you don’t want to have to open up every damn post to see.

    There are a lot of answers to this problem, and I love that there’s a plugin that will add in a Featured Image Column that shows a teeny featured image. But it wasn’t what I wanted. It was over kill.

    All I needed was a simple check mark for if there was an image and an X if there wasn’t, and that would suit me fine. And I wanted the column to be small, without a lot of fuss or folderol. I wanted something simple:

    My Featured Image Column

    That gives me a fast overview of if everything is what I wanted and where I wanted.

    The Code

    The code itself is the most basic column code, with a little bit of magic to put it as the first column on the list. Since I want to show this on all post types, I used the generic functions.

    /*
     * Show mark if featured image is set
     *
     * @since 1.1
     */
    
    add_filter('manage_posts_columns', 'helf_fi_manage_posts_columns');
    function helf_fi_manage_posts_columns( $columns ) {
    	if ( !is_array( $columns ) ) $columns = array();
    	$new_columns = array();
    
    	foreach( $columns as $key => $title ) {
    		if ( $key == 'title' ) $new_columns['featured_image'] = '<span class="dashicons dashicons-camera"></span>';
    		$new_columns[$key] = $title;
    	}
    
    	return $new_columns;
    }
    
    add_action('manage_posts_custom_column', 'helf_fi_manage_posts_custom_column', 10, 2);
    function helf_fi_manage_posts_custom_column( $column_name, $post_ID ) {
        if ($column_name == 'featured_image') {
            $post_featured_image = helf_fi_manage_column_check( $post_ID );
            $output = '<span class="dashicons dashicons-no"></span>';
            if ( $post_featured_image && $post_featured_image == true ) $output = '<span class="dashicons dashicons-yes"></span>';
            echo $output;
        }
    }
    
    function helf_fi_manage_column_check( $post_ID ) {
        $post_thumbnail_id = get_post_thumbnail_id( $post_ID );
        $post_thumbnail_img = false;
        if ( $post_thumbnail_id ) $post_thumbnail_img = true;
    	return $post_thumbnail_img;
    }
    
    add_action( 'admin_print_scripts', 'helf_fi_admin_print_styles' );
    function helf_fi_admin_print_styles(){
    	echo '
    	<style>
    		th#featured_image,
    		td.featured_image.column-featured_image {
    			max-height: 25px;
    			max-width: 25px;
    			width: 25px;
    			color: #444;
    		}
    		td.featured_image span.dashicons-no {
    			color: #dc3232;
    		}
    		td.featured_image span.dashicons-yes {
    			color: #46b450;
    		}
    		div#screen-options-wrap.hidden span.dashicons-camera {
    			padding-top: 5px;
    		}
    	</style>';
    }
    

    Fork and enjoy!