Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How To

  • Plex + Roku = TV

    Plex + Roku = TV

    I’m really trying not to add new devices to my life. I picked up a Roku last year so that I could watch CBS’ internet TV on my regular TV. I chose that instead of the Amazon or Apple TV because the Roku also let you add ‘apps’ for regular TV channels (SyFy, Freeform, PBS) and if I missed a TV episode due to travel, I could watch it on the big television.

    Then I wanted to play some shows that I’d saved as MP4s from my laptop to my TV, without a new device like a Chromecast.

    The solution was Plex

    Plex is a media server you can run on your computer that lets you add all your media, even things that don’t exist in iTunes, and organize them sanely. You can manage it in your web browser (or command line) and while you do have to have an account with Plex the service, you don’t have to pay or sign up for any of the services.

    If you have an Apple TV or an Amazon Fire you can use those too, but I used my Roku, added my media, and boom. Watching videos I own from my laptop on my TV.

    A couple caveats:

    1. If you download MP4s from cough torrent cough places, you’ll need to get their subtitles too.
    2. TV show files need to named SHOWNAME - S##E## - EPISODENAME.EXT to work properly.

    It’s not perfect, but it’s better than trying to watch TV on your computer.

  • Loading Common Libraries Smartly

    Loading Common Libraries Smartly

    When you’re writing code, there’s a desire to not reinvent the wheel. This is a good desire. If someone else has made the code you need, using it is a better use of your time. But there’s a right way and a wrong way to include those common libraries, especially in WordPress themes and plugins.

    PHP Is Dumb

    Okay, PHP isn’t dumb, but it’s a very top-down/left-right kind of language. The whole reason we tell people to name functions and classes uniquely in WordPress plugins and themes is that if two people name a function the same thing, PHP gets dumb and errors, telling you it can’t define the same function twice.

    This means that commonly used PHP libraries should also be uniquely named. To their credit, most do. But still, what happens if two WordPress plugins or themes include the same library? That same error comes back about not defining the same function twice!

    What this means is that when using a common library, it’s important that you enqueue it safely and smartly.

    Check If The Library Exists

    The magic is that you need to detect if the code is already included and not re-include it. PHP gives you two straightforward ways to do this: class_exists and function_exists.

    It’s much easier for me when the code is wrapped nicely in a class. Assuming you have a library file that includes the class but doesn’t call it, you can check like this:

    <?php
if ( !class_exists( 'MyLibraryClass' ) ) {
    include( 'path/to/library.php' );
    $mylibraryclass = new MyLibraryClass();
}

    If it does include the class (with a new MyLibraryClass() in the library) then you can leave that bit out.

    When you have a library that perhaps predates classes, you’ll want to pick the primary function and call it like this:

    <?php
if ( !function_exists( 'my_library_function' ) ) {
    include( 'path/to/library.php' );
}

    What About The Weird Stuff?

    There are two things I left out. What about namespaces and javascript libraries?

    First of all, it’s impossible to check for the existence of a namespace. You see, a namespace doesn’t really exist. What does exists are the structures within the namespace. That means if you wanted to check for the class ClassName in the namespace of MyName you have to do this:

    class_exists( '\MyName\ClassName') );

    Second, if you’re looking for javascript libraries, and you’re using WordPress, you don’t have to. Just enqueue it.

    Schnieder from One Day at a Time (2017) going 'Mind blown'

    The WordPress function wp_enqueue_script() registers the script but does not overwrite and enqueues it.

    Now there is a trick to all this. If you use the enqueue command properly, then this always works. By this I mean if you do it this way, it’ll work:

    wp_enqueue_script ( 'chartjs', 'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.6.0/Chart.bundle.min.js' );

    But… A lot of people do this:

    wp_enqueue_script ( 'my-plugin-chartjs', 'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.6.0/Chart.bundle.min.js' );

    And that means WordPress will load both chartjs and my-plugin-chartjs which sucks.

    Also you don’t need to append -js (or -css) to your enqueues, as WordPress will do that for you.

  • You Don’t Know Paths

    You Don’t Know Paths

    A common issue with plugins is where people insist they must call wp-load.php directly so that they can call WordPress functions and data when WordPress isn’t loaded. When I push back on that code, the common rationale is that there’s an external service that needs to ping a reliable URL to run code.

    You Don’t Know Where WordPress Is

    When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using ‘Giving WordPress it’s own directory’ (a very common setup) to break. In addition, WordPress allows users to change the name of the wp-content folder, so any plugin that tries to guess where it is would break on any site that choses to do so.

    This cuts both ways. First your clever script that tries to go to example.com/wp-content/plugins/your-plugin/yourfile.php is going to fail if someone moves that folder. Second your clever file that looks for wp-load.php by going up a couple folders will also fail.

    You can’t know where WordPress is. The only way to know all that would be to do things from within WordPress.

    Never Call Files Directly

    The only files you should ever call directly in your code is your code’s files or if you’re checking for the existence of another plugin or theme. This is the only time it’s smart to be hardcoding in paths of other code directly into your code.

    if ( is_plugin_active( 'plugin-directory/plugin-file.php' ) ) { }

    Since most people call these files to have access to WordPress ‘without loading WordPress,’ the actual correct fix is to tie processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

    Code you add to WordPress should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.

    What’s The Right Answer?

    Okay. There’s one case where it makes sense that you might possibly need to call a URL directly. If you’re hooking WordPress up to a service and you want to have a good URL to call, then yes, you would be well served by having one of the following:

    • example.com/?myplugin=runstuff
    • example.com/myplugin/

    Don’t those look nice? There are two main ways to get there.

    External Rules

    An external rule is basically you adding an redirect rule for a URL to point to a file. You could do this in .htaccess or nginx.conf but if you do it in WordPress, it looks like this:

    add_action( 'init', 'myplugin_external_rules' );
function myplugin_external_rules() {
    global $wp_rewrite;
    $plugin_url = plugins_url( 'yourfile.php', __FILE__ );
    $plugin_url = substr( $plugin_url, strlen( home_url() ) + 1 );
    $wp_rewrite->add_external_rule( 'myplugin$', $plugin_url );
}

    Now the obvious issue here is that you’re still calling a php file directly, which means you don’t get any access to WordPress functions. Boo. Thankfully there’s another answer.

    Internal Rules

    While more complicated and weird, this is a better solution.

    First you need to actually make the rule:

    add_action( 'init', 'myplugin_internal_rules' );
function myplugin_internal_rules() {
    add_rewrite_rule( 'myplugin', 'index.php?myplugin=runstuff', 'top' );
}

    This means that those two example URLs I pitched before are the same thing.

    Next you need to tell WordPress not to stomp all over the query variables:

    add_filter( 'query_vars', 'myplugin_query_vars' );
function myplugin_query_vars( $query_vars ) {
    $query_vars[] = 'myplugin';
    return $query_vars;
}

    You have to do this because otherwise WordPress won’t know what to do with the query variable.

    Finally we tell WordPress what to actually do with your variable:

    add_action( 'parse_request', 'myplugin_parse_request' );
function myplugin_parse_request( &$wp ) {
    if ( array_key_exists( 'myplugin', $wp->query_vars ) ) {
        include 'yourfile.php';
        // Call your functions here!
        // function_name_thingy();
        exit();
    }
    return;
}

    You’ll notice that // your functions here code is waiting for your code. That’s because this time we’re including the PHP file and then in there you’ve theoretically written your code in a nice little function. And that function? Uses WordPress functions because it is one.

  • Flushing Another Post’s Varnish

    Flushing Another Post’s Varnish

    The other day I talked about updating another post’s meta. That’s all well and good, but what happens when you’ve cached that other page?

    Most cache tools work via the simplistic understanding that if you edit a page, you want to empty the cache for that page. The problem with my clever post-meta updating is that doesn’t actually update the post. Oh, sure it updates the data, but that doesn’t perform an update in a way that most plugins understand.

    Thankfully this can be done programmatically in a few different ways, depending on what plugin is used.

    1. Tell Varnish to empty the page’s cache any time post meta is updated
    2. Add a force-empty command to the function that updates the meta

    Using Varnish HTTP Purge

    Since I’m running on DreamPress, my plugin of choice is Varnish HTTP Purge. This is a very simple plugin that has no real interface by design. Mike Schroder and I picked it for use because of it’s beautiful simplicity, and when it was abandoned, adopted it. I’m rather well acquainted with it and at the behest of others, I wrote in code where people could add extra URLs to flush as well as extra events to trigger. There’s even a wiki doc about it.

    However. That’s not what I did here because I wanted to limit when it runs as much as possible.

    When To Empty Cache

    There’s a part of caching that is always difficult to manage. When should a page be emptied and when should a whole section of pages be emptied? The obvious answer is that we should retain a cache as long as possible, emptying select pages only when necessary.

    With WordPress posts and pages it’s pretty easy to know “Update the post, empty the cache.” But when you start talking about things like the JSON API, it’s a lot harder. Most plugins handle the JSON API for you, but if you’ve built your own API (like say /wp-json/lwtv/) and built out a lot of custom APIs (like say stats or an Alexa skill) you will want to flush that whole darn thing every single time.

    The Code

    Okay so how do we do that easily?

    In the function I showed you the other day, I added this right before the re-hook at the end:

    if ( class_exists( 'VarnishPurger' ) ) {
	$varnish_purge = new VarnishPurger();
	$varnish_purge->purgeUrl( get_permalink( $post_id ) );
}

    That makes sure the Varnish plugin is running and calls a URL to flush. Done. If you want to have it do more URLs, you can do this:

    if ( class_exists( 'VarnishPurger' ) ) {
			
	$purgeurls = array( 
		get_permalink( $post_id ) . '?vhp-regex',
		get_site_url() . '/page1/',
		get_site_url() . '/custom_page/',
		get_site_url() . '/wp-json/lwtv/?vhp-regex',
	);
			
	foreach ( $purgeurls as $url ) {
		$this->varnish_purge->purgeUrl( $url ) ;
	}
}

    And then you can add in as many as you want.

  • Updating Another Post’s Meta

    Updating Another Post’s Meta

    Over on LezWatch TV we have two post types, shows and characters. In an added wrinkle, there’s data that exists on the show pages that is updated by the character pages.

    That means when I save a character page, I need it to trigger a series of updates to post meta of whatever shows the character belongs to. But because of the complexities of the data being saved, I need to run it when the show saves too.

    The Code

    add_action( 'do_update_show_meta', 'lezwatch_update_show_meta', 10, 2 );
add_action( 'save_post_post_type_shows', 'lezwatch_update_show_meta', 10, 3 );
add_action( 'save_post_post_type_characters', 'lezwatch_update_show_meta_from_chars', 10, 3 );

function lezwatch_update_show_meta( $post_id ) {

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

	[Update all the post meta as needed here]

	// re-hook this function
	add_action( 'save_post_post_type_shows', array( $this, 'lezwatch_update_show_meta' ) );

}

function lezwatch_update_show_meta_from_chars( $post_id ) {
	$character_show_IDs = get_post_meta( $post_id, 'lezchars_show_group', true );
	if ( $character_show_IDs !== '' ) {
		foreach ( $character_show_IDs as $each_show ) {
			do_action( 'do_update_show_meta' , $each_show['show'] );
		}
	}
}

    This runs three actions, saving shows and characters, and also a custom one that the character page will call. It needed to be split like that because some characters have multiple shows.

  • Remotely Hosting SVGs

    Remotely Hosting SVGs

    I prefer to use SVGs whenever possible instead of pngs or font icons. They can be resized, they can be colored, and they’re relatively small. But I also have a set of 700 icons I use and I don’t want to have to copy them to every single site. Instead, I’d like to have them all on a central repository and call them remotely.

    To The Cloud

    You can use S3 or really anything for this, but I chose DreamObjects since it’s open source and I work for DreamHost.

    For this to work, you create a bucket in DreamObjects with whatever name you want. I tend to name them after the website I’m working on, but in this case I’m making what is essentially a media library so a better bucket name would be the service. Keep in mind, while you can make a DNS alias like media.mydomain.com for this, you cannot use that with https at this time. Sucks. I know.

    On DreamObjects, the accessible URL will be BUCKET.objects-us-east-1.dream.io — hang on to that. We’ll need it in a bit.

    Upload Your Files

    Since I plan to use this as a collective for ‘media’ related to a network of sites, I named the bucket for the network and then made subfolders:

    • backups
    • site1
    • site2
    • svg
    • svgcolor

    Backups is for everything you’re thinking. Site1 and Site2 are special folders for files unique to those domains only. Think large videos or a podcast. Since they’re not updated a lot, and I want them accessible without draining my server resources, the cloud is perfect. I separated my SVG files into two reasonable folders, because I plan to generate a list of these later.

    Calling An Individual File

    This is the much easier part. In general, PHP can use file_get_contents() for this. But we’re on WordPress and there is a more reliable way about this.

    $svg = wp_remote_get( 'https://BUCKET.objects-us-east-1.dream.io/svg/ICON.svg' );
if ( $svg['response']['code'] !== '404' ) {
	$icon = $svg['body'];
}

    By using wp_remote_get it’s possible to check if the file exists before displaying the content of the body. Which is, indeed, how one displays the content.

    The reason, by the way, we want to use wp_remote_get and not file_get_contents is that there’s no way to check if the file exists with the latter. You could still use file_get_contents to display the file, but once you’ve done the remote get, you may as well use it.

    Getting a List Of All SVGs

    I’d done this before with local images, getting a list of all the SVGs. You can’t do a foreach of a remote folder like that. So this is a little messier. You’ll need the Amazon AWS SDK for PHP for this. I’ve tested this on the latest of the 2 branch – 2.8.31 – and the 3 branch – 3.32.3 and the code is different but can work.

    In both cases, I downloaded the .phar file and included it in a function that I used to save a file with a list of the image names in them. By doing that, I can have other functions call the file and not have to query DreamObjects every time I want to get a list.

    function get_icons() {
	include_once( dirname( __FILE__ ) . '/aws.phar' );

	$svgicons = '';

	// AWS SDK Code Goes Here

	$upload_dir = wp_upload_dir();
	$this_file  = $upload_dir['basedir'] . '/svgicons.txt';
	$open_file  = fopen( $this_file, 'wa+' );
	$write_file = fputs( $open_file, $svgicons );
	fclose( $open_file );
}

    I left out the SDK code. Let’s do that now.

    SDK V2

    The V2 is actually what’s still officially supported by CEPH, but the PHAR file is larger.

    	Version 2
	$client = Aws\S3\S3Client::factory(array(
		'base_url' => 'https://objects-us-east-1.dream.io',
		'key'      => AWS_ACCESS_KEY_ID,
		'secret'   => AWS_SECRET_ACCESS_KEY,
		'version' => 'latest',
		'region'  => 'us-east-1',
	));

	$files = $client->getIterator( 'ListObjects', array(
		'Bucket' => 'BUCKET',
		'Prefix' => 'svg/',
	));


	foreach ( $files as $file ) {
		if ( strpos( $file['Key'], '.svg' ) !== false ) {
			$name         = strtolower( substr( $file['Key'] , 0, strrpos( $file['Key'] , ".") ) );
			$name         = str_replace( 'svg/', '', $name );
			$symbolicons .= "$name\r\n";
		}
	}

    SDK V3

    I would recommend using V3 if possible. Since you’re only using it to get data and not write, it’s fine to use, even if it’s not supported.

    	// Version 3
	$s3 = new Aws\S3\S3Client([
		'version' => 'latest',
		'region'  => 'us-east-1',
		'endpoint' => 'https://objects-us-east-1.dream.io',
		'credentials' => [
			'key'    => AWS_ACCESS_KEY_ID,
			'secret' => AWS_SECRET_ACCESS_KEY,
		]
	]);

	$files = $s3->getPaginator( 'ListObjects', [
		'Bucket' => 'BUCKET',
		'Prefix' => 'svg/',
	]);

	foreach ( $files as $file ) {
		foreach ( $file['Contents'] as $item ) {
	
			if ( strpos( $item['Key'], '.svg' ) !== false ) {
				$name = strtolower( substr( $item['Key'] , 0, strrpos( $item['Key'] , ".") ) );
				$name = str_replace( 'svg/', '', $name );
				$symbolicons .= "$name\r\n";
			}
		}
	}

    Side Note…

    If you’re on DreamHost, you’ll want to add this to your phprc file:

    extension=phar.so
detect_unicode = Off
phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar

    That way it knows to run phar files properly. And by the way, that’s part of why phar files aren’t allowed in your WordPress plugins.

    Which is Better?

    That’s a difficult question. When it comes to loading them on the front end, it makes little difference. And having them on a CDN or a cloud service is generally better. It also means I don’t have to push the same 400 or so files to multiple servers. On the other hand, calling files from yet another domain gets you a down check on most site speed checks… But the joke’s on them. The image is loaded in PHP.

    Of course the massive downside is that if the cloud is down my site can be kinda jacked. But that’s why using a check on the response code is your lifeline.