Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • Types of Related Posts

    Types of Related Posts

    At it’s heart, related posts are the drive to help people find more content on your site. They serve no other purpose than keeping people on your site by piquing their interest in your words.

    But what if I told you there were multiple types of related posts for WordPress?

    Categories and Tags

    The first type of related posts are really just organization. I have three main categories on this site: How It Is, How It Works, and How To. I also have a million tags, like everyone else. If you wanted to read my thoughts on how things are, or rather why they are, you’d scroll through the category of “How It Works.” If you wanted to see everything I wrote about SVGs, you would check out my tag of ‘svg’ or possibly ‘images.’

    The point here is that categorization is a type of related posts. It’s entirely manual, but it’s the best way to say ‘These posts are like each other.’ And they have a fatal flaw. You see, if I wanted to read all the “How To” posts about SVGs, WordPress doesn’t easily cross relate. That is, I can’t list all the items in a category and a tag.

    Which is why we have …

    Related Posts Plugins

    There are two main types of plugins for this. There are the services, like Jetpack’s related posts, that scrape all your posts, toss them into a database, and use some complex algorithms to sort out what is and isn’t related. The other sort scan your posts locally and figure the same thing out.

    So which is better? Well. Jetpack requires you to trust Jetpack, or whatever service you pick, with your data. For some people, this can be a deal breaker. On the other hand, if you run it locally, you’re at the behest of how fast your site runs. For example, if it scans your posts live and you have, say, 300k posts, then that could be really slow. Or if it makes it’s own database table, how often is it going to update and cross relate?

    By the way, the 300k posts is not an exaggeration. That’s a site I looked at recently.

    Alertnative Relations

    There’s a secret third option, actually.

    I called it Semi Related Posts, and while I did it across post types, you could use the general logic. The concept is that instead of letting your site try and divine relations, you could manually connect them. It does require more upfront work, but cross relating posts by hand gives you the ultimate control.

    Of course, you’ll note that I did automate this as much as I could. I’m not crazy you know. If you can find a way to do that, maybe code a way to list 4 other posts in the same category and tags as this post, then you’ve automagically automated the simple.

    Until you hit that 300k post limit. Then you’ll have to rethink things again.

  • Safari and SameOrigin

    Safari and SameOrigin

    I was updating a site I’ve been neglecting. Due to reasons, it’s been about four months since I’ve looked at it, let alone done any work. But as I was cleaning up the data, moving ads around, and messing with widgets, I found myself stumped.

    Customizer was a blank screen.

    Debugging Javascript

    Now I happen to know that the WordPress customizer makes heavy use of javascript, so I popped open the console and found this error:

    [Error] Multiple 'X-Frame-Options' headers with conflicting values ('ALLOW-FROM https://example.com/wordpress/wp-admin/customize.php, SAMEORIGIN') encountered when loading 'https://example.com/2017/post-name/?customize_changeset_uuid=0774a706-2a5b-4700-a8fb-2c294708687c&customize_theme=utility-pro&customize_messenger_channel=preview-0'. Falling back to 'DENY'.
    
    [Error] Refused to display 'https://example.com/2017/post-name/?customize_changeset_uuid=0774a706-2a5b-4700-a8fb-2c294708687c&customize_theme=utility-pro&customize_messenger_channel=preview-0' in a frame because it set 'X-Frame-Options' to 'ALLOW-FROM https://example.com/wordpress/wp-admin/customize.php, SAMEORIGIN'.
    

    Right away, I knew that the problem wasn’t Javascript.

    Safari is Special

    A quick search netted me two possible tickets. First, there’s the problem with customizer failing to load if there was a home/siteurl domain mismatch and second, there’s the issue that customizer fails to load in Safari due to X-Origin Header mismatch.

    In reading those tickets, I determined that it was possible that since this site has WordPress in a folder (yes, named wordpress) but runs from the main domain, that could break it. There was also a possibility that NGINX or Apache were set to restrict SAMEORIGIN. Finally, there was the absolutely daft problem that Safari was special and didn’t like extra rules.

    Now, since this server runs multiple sites, and only this one was having any problems, I threw out all possible server related causes. I also discarded any Multisite related causes, as the site wasn’t the network. Next I determined it absolutely was Safari, by testing on Firefox and Chrome. That left me with the following probable causes:

    1. Some code on my site was breaking customizer

    No, really. That was it.

    The Solution

    Two choices here. Figure out what was broken or stop using Safari.

    I have reasons for using Safari, so I knuckled down. I searched all lines of my code for anything related to X-Frame-Options and came up empty. I tested by commenting out the relevant lines in WordPress core, which worked, but wasn’t tenable.

    Then I changed my search and looked for X-Frame-Options in all .htaccess files, and found this:

    <IfModule mod_headers.c>
         Header set X-Frame-Options "SAMEORIGIN"
    </IfModule>
    

    Removed that, and done.

    Why Was It There?

    I actually put that code in to prevent clickjacking. Clickjacking is what’s called a “UI redress attack.” It happens when a malicious attacker uses transparent or opaque laters to trick someone into clicking a button or a link on page, when they were intending to click another. Usually this is to steal private information.

    WordPress already does this for the login page, and for this site, that’s actually the only time ‘private’ data is sent on this site. Which means it’s mostly safe enough to leave be. There are ways I could do this in PHP code, but since WordPress isn’t the only tool on the site, it’s harder to maintain.

    The better fix would be to, with Apache or NGINX, check the domain and URL, and only apply clickjacking when I’m not in Customizer.

    Of course I have no idea how to do that. Yet.

  • Reordering Facet Displays … For Death

    Reordering Facet Displays … For Death

    Isn’t that a catchy title?

    I’m using FacetWP to help me order and sort archives in ways that are reflective of the content. One of the things I sort are characters (yeah yeah yeah) and some of those characters are dead. It occurred to me that wouldn’t it be nifty if I could sort the characters by when they died?

    There was just one problem. Actually there were two. One was Sara Lance, and she’s my personal demon. The other was my own stupidity and lack of foresight. Neither were insurmountable.

    How FacetWP Changes Sort Order

    Before I get into the weeds, let’s have a moment to talk about sort order. FacetWP has a way to filter the sort orders.

    So for an example, I have post meta value for the number of characters saved as lezshows_char_count for all shows. If I wanted to sort shows by the most characters to least, I can add this in:

    $options['most_queers'] = array(
    	'label' => 'Number of Characters (Descending)',
    	'query_args' => array(
    		'orderby'  => 'meta_value_num', // sort by numerical custom field
    		'meta_key' => 'lezshows_char_count', // required when sorting by custom fields
    		'order'    => 'DESC', // descending order
    	)
    );
    

    It looks very similar to WP_Query and that’s what makes it easy. Except for my two problems…

    Problem One: Formats

    The first problem was not the Sara Lance problem. It was the ‘Mika didn’t think about things 4 years ago’ problem. I was saving the dates of death in the format of MM/DD/YYYY

    If you’re an American, you’re wondering “So what?” and if you’re anyone else, you’re giving me a death glare because “08/05/2010” could be August 05 OR May 08, and damn it, I knew better. For what it’s worth, the output on the front end is always “05 August 2010” but that’s not here nor there.

    You see, the issue isn’t that I was using stupid date/time formats, the issue is sorting.

    In the previous example, I have an order of meta_value_num which is literally a number. What’s the one for dates? You get meta_value_date or meta_value_datetime and neither of them work with the date format I’d chosen.

    So for this to work, I had to go and change everything from MM/DD/YYYY to YYYY/MM/DD – Not fun, but doable. And it led me to my Sara Lance Drama…

    Problem Two: Arrays

    How many times has Sara Lance died? Right now, three.

    When I decided to sort by the date of death, which one did I pick? Long pause.

    I decided to pick the last one. That is the most recent death. If someone’s actually still dead, the most recent death is the one that stuck. If they’re not, then death was pretty arbitrary to begin with and there ya go.

    The question became how and where did I save the death? I went with a post meta of lezchars_last_death and had it auto update on post save, like this:

    add_action( 'save_post_post_type_characters', 'characters_update_meta', 10, 3 );
    function characters_update_meta( $post_id ) {
    
    	// unhook this function so it doesn't loop infinitely
    	remove_action( 'save_post_post_type_characters', 'characters_update_meta' );
    		
    	// get the most recent death and save it as a new meta
    	$character_death = get_post_meta( $post_id, 'lezchars_death_year', true );
    	$newest_death    = 0000-00-00;
    	foreach ( $character_death as $death ) {
    		if ( $death > $newest_death ) $newest_death = $death;
    	}
    
    	if ( $newest_death !== 0000-00-00 ) {
    		update_post_meta( $post_id, 'lezchars_last_death', $newest_death );
    	}
    
    	// re-hook this function
    	add_action( 'save_post_post_type_characters', 'characters_update_meta' );
    }
    

    If there is a latest death, we get to set it as the YYYY-MM-DD value and off we go. But…

    Problem Three: Orderby Hellscape

    Surprise! I ran into a third problem! Remember how I was using the orderby of meta_value_num in my example? And I mentioned that I wanted to use meta_value_date or meta_value_datetime to sort by date?

    Yeah no.

    If I’d converted the date into unix time, sure. But I was reusing this logic in a couple places, and I didn’t want to re-save everything like that. I also use a query to grab all deaths in a year, and basically I do need to keep it with the format I have. That just messed up my sort until I found the magic of orderby' => 'meta_value',

    End Result?

    It works. It’s got yet another post meta, which I’m not super happy about, but sometimes that’s really just the simplest way to solve a problem. The data is always updating itself, and it’s relatively easy for me to tweak it. Also now I can do a lot more searches in different ways.

    Since I don’t have to worry about database size at the moment, nor speed, since I’ve designed it well, this works for me.

  • The Invisible Facets

    The Invisible Facets

    I’ve been using FacetWP for a year or so and it’s, hands down, the smartest WordPress plugin I’ve ever bought. Certainly I could have coded it, but not having to and being able to extend it to do what I need has saved me months of work and support.

    This is not to say it’s perfect. I’ve run into multiple quirks and headaches that resulted in me writing weird code to solve. And the solution to the null entry was no different. But it was, at the end, solvable.

    A Null Entry

    The majority of my data is saved in custom taxonomies. This makes it easy for me to grab and process. It’s also easy to list, because I can point people at /taxonomy/term and FacetWP magically populates properly in the sidebar.

    However. In one case, I have a checkbox. This is a simple post-meta to say if we love a show or not, and that check box, if it exists, is detected by FacetWP and I can easily get a list of all loved shows. The reverse is, sadly, not easy.

    That’s because if the checkbox is empty, there is nothing saved. No post meta. And if there’s no data, then when FacetWP builds out it’s list, there’s nothing saved for the non-existent data, and therefore no way to list nothing.

    An Imaginary Entry

    The other problem, related to this, is that I use Taxonomies in a different way. That is, while I use them like everyone else does with tags and categories, I also use them to track ‘stars’ – gold or silver etc. Obviously that makes it easy to track with /stars/gold/ buuuuuuut what if I wanted to list all the shows without any stars?

    How do I tell FacetWP ‘if there’s no taxonomy data saved for this, use a default?’

    A Fake Facet

    The answer lies within making a fake, that is unused, facet.

    The tl;dr to how FacetWP works is that it generates it’s own table with the data it collects from it’s facets. In general, there’s a 1-to-1 relationship with the facet and how it outputs. If you’re saving the terms of a taxonomy (like star colors), then there’s an entry in the database for the show and it’s star. If something has multiple values (like tags) then it has multiple entries.

    You can then alter the

    The Facet

    In order to make entries for my null or imaginary values, I made a facet that I didn’t use that I called all_the_missing and I gave it the data source of “Post Types”:

    An example of the facet

    The rest doesn’t matter. I’m not planing to display this, and I picked post types because it’s a quick bit to add the database without making it too heavy or complicated. Also I know it’ll exist for all my data.

    The Filter

    The magic to all this is my filter for facetwp_index_row:

    if ( 'all_the_missing' == $params['facet_name'] ) {
    	// If we do not love the show...
    	$loved = get_post_meta( $params['post_id'], 'shows_worthit_show_we_love', true);
    	if ( empty( $loved ) ) {
    		$params_loved = $params;
    		$params_loved['facet_name']           = 'show_loved';
    		$params_loved['facet_source']         = 'cf/shows_worthit_show_we_love';
    		$params_loved['facet_value']          = 'no';
    		$params_loved['facet_display_value']  = 'No';
    		$class->insert( $params_loved );
    	}
    	// If there are no stars
    	$stars = get_the_terms( $params['post_id'], 'the_stars' );
    	if ( empty( $stars ) ) {
    		$params_stars = $params;
    		$params_stars['facet_name']           = 'show_stars';
    		$params_stars['facet_source']         = 'tax/the_stars';
    		$params_stars['facet_value']          = 'none';
    		$params_stars['facet_display_value']  = 'None';
    		$class->insert( $params_stars );
    	}
    	return false; // skip default indexing
    }
    

    Now this is also wrapped in an if ( get_post_type( $params['post_id'] ) == 'post_type_shows' ) {...} check so this particular one only runs when shows are saved. But you can see what I do is when I run that specific facet, I check if the other data is available and if so, save it.

    Improvements

    I’d like to actually not have to save data when I don’t need it, but the need is enough that having this work was paramount. I can now sort when there’s no data, and that was what I needed.

  • Processing Numbers with WordPress

    Processing Numbers with WordPress

    The very idea of ‘I should make statistics’ or ‘what are the metrics of this’ starts from the same place. We have a desire to understand what a thing is. Statistics, like traffic, and metrics, like speed, can tell us obviously important information about our sites. Faster sites do better. More traffic gets you more… whatever.

    But those are the obvious things. There are easy to understand numbers and there are difficult to process numbers. And it all matters where you save the data.

    Getting At The Data

    When I set about making statistics for LezWatchTV, the biggest problem I faced was determining what I wanted to show. Some things were simple. How many characters died and what percent of all characters was that? How many shows have dead characters?

    Since I chose to use WordPress features, like custom taxonomies, for the majority of the aspects of the site, getting those numbers was simple. There were, of course, some that were very difficult to get at, and this is fully of my own design. Sometimes there will be data you want to use that is just harder to get at than others.

    This means the question of understanding your numbers begins with understanding where they belong.

    Save Data in Smart Places

    I say this over and over. Use WordPress’ native features first.

    I mean use the taxonomies and the custom post types and the post meta wisely. But. When you’ve got a lot of data that needs to be cross related, consider saving it someplace else. For example, the reason FacetWP is so damn fast is that it doesn’t query WordPress all the time, and instead uses it’s own tables.

    Having it’s own table means there’s less overhead as they can make direct SQL calls to pull the data. When you have data spread across three post types, this becomes pretty much an imperative. You just have to script the code to save it properly.

    External Data

    While FacetWP does save data to it’s own tables, there is another option, and that is external locations. You’re most familiar with this with regards to Google Analytics. Some data makes sense to keep local, but keep in mind what you’re doing and what you’re generating with the data. When it’s just posts, local is perfectly logical. When you get into statistics… Well. Maybe you should export it.

    That brings up the next question. What data to you export, and to where.

  • Customizing Which Random Post

    Customizing Which Random Post

    Back in December, I posted about how I generated a random post of the day.

    After running it for 60 days, I realized I needed to exclude three things:

    1. Posts with a specific ‘placeholder’ image
    2. Posts with content ‘TBD’
    3. Posts with one of two specific meta values

    So today we will talk about how awesome WP_Query is.

    The Basic Query

    As a reminder, your basic query for a random post is this:

    $args = array( 
    	'post_type'      => 'posts',
    	'orderby'        => 'rand', 
    	'posts_per_page' => '1'
    );
    $post = new WP_Query( $args );
    

    Now, let’s extend it!

    Posts With An Image

    In this example, I have a very specific default image I use – the mystery person – to indicate the post doesn’t have it’s own image yet. I went and found the image in my media library and took note of the value – 949. Then I added a meta query which said “If the _thumbnail_id does not equal 949.”

    	'meta_query' => array( 
    		array(
    			'key'     => '_thumbnail_id',
    			'value'   => '949', // Mystery Person
    			'compare' => '!=',
    		),
    

    Seriously. It’s magic.

    Posts Without ‘TBD’

    We also have a standard convention for when we have a pending data post, but we need it for statistical reasons. Since, as of WP 4.4, you can use negatives in searches, just add this to the basic query:

    	's'              => '-TBD',
    

    This could be useful for your stores, if you wanted to list a product of the day but perhaps not ones with “Coming Soon” in the description. Of course, you should also have some meta flag but you get the idea.

    Posts With One of Two Values

    Okay. Here’s fun. Let’s say you have a post meta field called example_site_group and there are six choices in it but you only want one and two. Well, for that you need to use an array and a LIKE:

    	'meta_query' => array( 
    		array(
    			'key'     => 'example_site_group',
    			'value'   => array ( 'baseone', 'basetwo' ),
    			'compare' => 'LIKE',
    		),
    

    This is a little messier, but it certainly does work. Even with serialized data.

    Put It All Together

    Here’s the real code:

    // Grab a random post
    $args = array( 
    	'post_type'      => 'post_type_characters',
    	'orderby'        => 'rand', 
    	'posts_per_page' => '1',
    	's'              => '-TBD',
    	'meta_query' => array( 
    		array(
    			'key'     => '_thumbnail_id',
    			'value'   => '949', // Mystery woman
    			'compare' => '!=',
    		),
    		array(
    			'key'     => 'lezchars_show_group',
    			'value'   => array ( 'regular', 'recurring' ),
    			'compare' => 'LIKE',
    		),
    	)
    );
    $post = new WP_Query( $args );
    

    And voila.