Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • You’ll Probably be Fine with Gutenberg

    You’ll Probably be Fine with Gutenberg

    With WordPress 5.0 getting closer and closer, I know a lot of people are worried about Gutenberg and what that will mean for their themes and plugins.

    Most Themes Will Be Fine

    The majority of themes, every single one you can download from WordPress.org, and the ones from reputable theme shops like StudioPress, will be just fine. Nothing will break, and other than getting a new editor experience, there’s no change.

    What will happen, and yes people will call this breaking, is that not all features will be supported. 

    Right now, most themes don’t support some of the more outré block types. And a lot of themes don’t support text columns like this:

    And then again, Genesis? Does!

    This is a left column

    This is a right column

    And every theme is going to support repeatable blocks which means you’ll be able to build out some nice defaults and standards.

    The reason for all this is that if you’re just using Gutenberg as an editor, not a whole lot has changed with your content. It remains the same as it ever was, just with a fresh coat of paint.

    There are exceptions, like themes that rely heavily on features that alter the post editor. I’ll get there in a minute.

    Most Plugins Will be Fine, Too

    Here again, unless your plugin interest with the post editor, you are going to be just fine. You use Jetpack to publicize your posts? Cool. No change. AMP? No change.  Go look at most of your plugins. Caching? No changes. Google Analytics? No change.

    The reason here is, again, most plugins don’t mess with post editing. I should know. I review them.

    I know what you’re thinking, though. What about plugins like Yoast SEO, which add in a bunch of extra boxes at the bottom and sides of a post? The boxes are called Meta Boxes, and they’re already supported. Plus Yoast went to the extra effort of being on the forefront of Gutenberging.

    The colours to indicate how good your post’s SEO is, however, are missing right now. So is the field to customize your Jetpack publicize content. Basically everything that went on that sidebar on the post edit screen (the Publish Box) isn’t done yet.

    Which brings me to…

    The Exceptions Will Hurt

    Okay.  I won’t sugar coat this. If you use a complex post editor, like Visual Composer or Bold Grid, or if you use a plugin with a lot of custom meta boxes, the world will be very different, and probably unhappy.

    Now that said, Visual Composer will work with Gutenberg! And so will ACF and CMB2 is well on it’s way. But. The problem is people who have bundled those plugins in their themes. And those themes will have to update their packages and make sure users update.

    Anyone who just had a mental image of how many premium themes bundle Visual Composer and tried to calculate the number of users who don’t properly update themes regularly… welcome to my world. I’d like to say I’m ‘against’ the bundle, but the reality is that I’m against premium products using libraries and then not managing those libraries properly. Not that it’s easy, and that’s a different topic.

    The problem in the exception is that there will be a non-insignificant number of people who have no idea they’re using a problematic library that needs an update.

    Where Do We Go From Here?

    This problem is WordPress’ own doing, make no mistake. If the ability to add custom meta boxes and settings and the like was less complicated to begin with, we wouldn’t have needed tools like these to work around it. We still have no decent meta box API, and the settings API is something I regularly call “as intelligent as a bag of wet hair.”

    But. Innovation is necessary. We can’t just not move forward because we didn’t do things right the first time. And in WordPress’ defence, there was no way to know or even write the ‘right’ way back 15 years ago when all this started. The best tools didn’t exist. And all those ways we built to hack around the problem made it more clear what the right way needed to be.

    Which brings us here.

    Most of what you do won’t be impacted by Gutenberg. What is adversely impacted won’t break most things, but it will be really annoying. And then those rare edge case exceptions? Well. We’re back to the words (paraphrased) of Hecht.

    When infrequently used systems break, they do so in big ways.

  • Hashtag your Jetpack with Taxonomies

    Hashtag your Jetpack with Taxonomies

    So maybe you read my post about hash tagging Jetpack Publisher posts with a complex check of “Is this tag also a custom post type?” and you thought “Mika, that’s awesome. But I don’t have a database of shows!”

    To my reporter friend who lamented this to me, I have a solution.

    The Real Problem

    I think most of the problem with Jetpack’s custom Publicize message is that it’s (rightly) hidden by default. Most people don’t need it. But those that do want to see it so we remember “and do this…”

    Publicize Settings on your post sidebar

    And let’s be honest, this visibility issue is going to be worse when we move to Gutenberg.

    Again, I don’t think Jetpack is in the wrong here. The majority of users don’t need to be so aggro about their messages. There are a lot of WordPress sites that we would classify as ‘smaller’ sites. And those who aren’t tend to need very bespoke/custom solutions, which is the problem.

    My solution works for me because it’s easily automated and checkable. We’re very pedantic about tags (seriously, Tracy went through all our tags and cleaned them up), we have a great system to match tag to show, and, most significantly, we know that our social media engagement relies on not just content, but the appropriate hashtags. That is, the shows we’re talking about.

    This means there are two types of ways to do this:

    1) Make all your tags (and/or categories) into your hashtags
    2) Make a custom taxonomy for your hashtags

    Since using all the tags might be a bit much, I went with option 2.

    The Code

    <?php
/*
 * Jetpack tweaks
 * @version 1.0
 * @package mu-plugins
 */

class HalfElf_Jetpack {

	public function __construct() {
		add_action( 'publish_post', array( $this, 'custom_message_save' ) );
		add_action( 'init', array( $this, 'register_taxonomy_hashtag' ) );
	}

	public function register_taxonomy_hashtag() {

		//parameters for the new taxonomy
		$arguments = array(
			'label'                 => 'Hashtags',
			'hierarchical'          => false,
			'public'                => false,
			'show_ui'               => true,
			'update_count_callback' => '_update_post_term_count',
			'rewrite'               => false,
		);

		register_taxonomy( 'flf_hashtags', 'post', $arguments );
	}

	public function publicize_hashtags() {
		$post      = get_post();
		$hash_tags = '';

		// If the post isn't empty AND it's a post (not a page etc), let's go!
		if ( ! empty( $post ) && 'post' === get_post_type( $post->ID ) ) {

			update_post_meta( $post->ID, '_wpas_mess', 'test' );

			// First let's add the hashtags
			$post_tags = get_the_terms( $post->ID, 'flf_hashtags' );
			if ( ! empty( $post_tags ) ) {
				// Create list of tags with hashtags in front of them
				foreach ( $post_tags as $tag ) {
					// Change tag from this-name to thisname and slap a hashtag on it.
					$tag_name   = str_replace( '-', '', $tag->slug );
					$hash_tags .= ' #' . $tag_name;
				}
			}

			// Next we add a category in specific situations.
			$post_cats = get_the_category( $post->ID );
			if ( ! empty( $post_cats ) ) {
				// Create list of tags with hashtags in front of them
				foreach ( $post_cats as $cat ) {
					if ( 'MAINCAT' === $cat->slug ) {
						// Change slug from this-name to thisname and slap a hashtag on it.
						$cat_name   = str_replace( '-', '', $cat->slug );
						$hash_tags .= ' #' . $cat_name;
					}
				}
			}
		}

		// Loop back. If there are hashtags, we add them.
		if ( '' !== $hash_tags ) {
			// Create our custom message
			$custom_message = 'New post! ' . get_the_title() . $hash_tags;
			update_post_meta( $post->ID, '_wpas_mess', $custom_message );
		}
	}

	// Save that message
	public function custom_message_save() {
		add_action( 'save_post', array( $this, 'publicize_hashtags' ) );
	}

}

new HalfElf_Jetpack();

    A Little Explanation

    You may notice I added in a bit that looks for a specific category:

    if ( 'MAINCAT' === $cat->slug ) { ... }

    The reason here is that on the specific site I wrote this for, they have four (yes four!) categories:

    1) Announcements
    2) News
    3) Fandom (actually named FOR the fandom)
    4) Miscellaneous

    They wanted item to be a tag, so it would always #JanelleMonae (for example). For them I did a super basic ‘if the fandom, then the hashtag’ but a slightly more common situation would be someone having a category for ‘Fandoms’ and then subcategories our fandom. For that you’ll want something like this:

    foreach ( $post_cats as $cat ) {
	$cat_mom = $cat->category_parent;
	if( $cat_mom > 0 && 'fandoms' === $cat_mom->slug ) {
		// Change slug from this-name to thisname and slap a hashtag on it.
		$cat_name   = str_replace( '-', '', $cat->slug );
		$hash_tags .= ' #' . $cat_name;
	}
}

    Enjoy your hash tagging!

  • Conceptualizing Privacy

    Conceptualizing Privacy

    I know a wonderful human named Heather Burns who cares about privacy and GDPR and has made me quite passionate about understanding what the heck I’m talking about. She’s infectious, smart, and well worded. When she talks I listen.

    Earlier this year, she posted her slides from a speaking event, PHP Yorkshire. One of them resonated with me to the point that I keep thinking about it:

    US vs UK/Europe concept of Privacy
    Source: Heather Burns’ PHP Yorkshire Slides

    I sat and read it a few times, and I realized that I absolutely 100% agree with all of the UK/Europe concepts and only one of the US’s. I won’t touch on all of them, but here are the ones I spend a lot of time pondering.

    Ownership vs Freedom

    In the US, there’s a massive misconception that you have a right to say what you want about what you want without consequences. This is absolutely not true. Freedom of speech, in the United states, does not exculpate me from what happens to me after I say a thing. But we have a big bugaboo here about how our freedoms are fundamental rights. So even though the first few Amendments to the Constitution are quite clearly about their direct applications to ‘against the government’ and ‘in a militia,’ people take them, twist them, and make them apply to everything else.

    This runs into an issue with GDPR and people in the UK and Europe, where the law is that you own your own data. You have a right to it, and to what’s said about you. Yeah hang on there. Folks in the US have a right to say what we want. Folks in the UK/Europe have a right to make us shut up.

    That’s working out about as well as you’d think, mostly because we disagree about this other thing…

    Data Ownership

    Really, it should be pretty simple for the freedom of speech to coexist with the right to be private. If I post lies about you, you are legally within your rights in the US to demand I take them down. If I post information about you that wasn’t public, like I know you like burn Beanie Babies (those are stuffed animals, folks), then in the US you’re kind of out of luck unless you can prove it caused you ‘harm.’ Across the pond? I have to delete it.

    And right there, I agree with the Europeans. If I take privileged information and make it public, I’m a horrible human first of all. I’ve betrayed your trust, and I’ve probably done it for financial gain. On the other hand, if I take public information (like a photo of you from the Associated Press of you burning a Beanie Baby in Central Park) and share it, I’m still a pretty horrible human, but not in the same way.

    As a human, I think I should have the right to own my own data. But this comes with a measure of responsibility. In other words, I’m responsible for what I put out there. If I make it public that I’m a lesbian (which I did), am I legally allowed to demand you remove all references to me being one on your site? In other words, do I get take-backs if I make things public?

    Maybe, but over yonder, I should at least ask first!

    Cooperation Before Court

    There’s a concept called “Assume good faith” and it’s one of Wikipedia’s fundamental principles. It’s related to the concept that we should never attribute to malice that which can be ascribed to ignorance. Generally this comes up when I talk to people about copyright or trademark violations. I never assume people meant to violate those things, just that they were unaware of things.

    The idea that someone has to ask me to remove a thing before suing me would be a lovely thing. The closest I can think of in the US is the way DMCA requests are handled. That is, I can issue a counter notice and either state “Hey, removed it!” argue back that it’s fair use. But that isn’t the same as the idea that we should talk before we go to lawyers. And that’s, you know, respectful.

    I spend a lot of time thinking about this based on two other sites I run, where there is personal information of other people. It’s all public-personal information, but in general if someone asks me to remove data, I’ve complied. There was one instance where I didn’t, and I explained why not and the other person agreed it was a fair representation of the situation.

    What Happens Now?

    Well. A lot of confusion and arguments about who has the right to what and where and when.

    There’s going to be a lot of change in your future.

  • How Many Plugins Is Too Many To Create?

    How Many Plugins Is Too Many To Create?

    That wasn’t the way you expected that title to end, I bet. You were thinking “How many plugins is too many to have on my site” and that’s absolutely not the topic here. No, instead I’m asking how many plugins is too many for a developer to create?

    I Got 99 Problems …

    I think that plugins should be specific. That is, I’m not a fan of a conglomerate of plugins like Jetpack, that do a little of everything. Instead, I like a plugin that does the thing it’s supposed to do, preferably simply and well, and it moves on. That means I often have 20-30 plugins installed on a site, and that’s okay.

    At the same time, as a developer, having to support 20-30 plugins is a drain on my limited resources. Becuase here’s what I have to do:

    1. Keep up with all core changes
    2. Include and test all library updates
    3. Test with every release
    4. Update my readme
    5. Review reviews and support posts to make sure I’m not missing things

    Multiply that by 20 and it’s a lot of work. And is that work I feel like I must do?

    Gimmie One Reason …

    The reality of having plugins for WordPress, or any add on for any project, is that it’s generally thankless work and you will have more bad days than good. That’s true of many things in life, and as depressing as it can be, it’s important to keep an eye on the reality of the situation. 

    Developing software is very analytical art. You create something out of nothing, you design and test and change and tweak, and then present it to the world. Of course those days when people tell you “I don’t like the color” suck, but being humans, we discard that and grab on to the days when someone says “I love the carrot!”

    And the reality of the question at hand isn’t how many is too many, but how many are worth the work and the little reward?

    Bring it Together …

    Lately I’ve been advocating something different. Instead of making 13 separate types of gallery plugins, I’ve suggested people make one plugin for galleries and include those 13 types as display options. The amount of work is roughly the same, but it means I only have one plugin to manage instead of 13 separate readme files to edit and installs to spin up. I also have one place to look for any support posts or reviews.

    Obviously this doesn’t always work. Sometimes you have to split things up. There’s little point it combining a WooCommerce plugin with a NextGen Gallery one (unless the plugin is implementing NextGen with Woo products…). But if you can connect your projects by type, you may find out that there’s crossover. Instead of spreading your user base out over 10 plugins, you can keep them manageable with 5 to 8.

    Working For The Man …

    And what about Jetpack? It’s effectively XX separate types of plugins:

    • Writing
    • Sharing
    • Discussion
    • Traffic
    • Security

    Except when you look at that, it suddenly all connects. When I write I want to share and I want people to discuss. I also want to keep an eye on my traffic and being secure…. Okay that last one might be better off on it’s own, but it’s a suite of related apps. 43 separate apps, but they are all related when you get down to it.

    Which means even if you’re making a plugin for your company, you can probably combine it with other things safely. And that means less access and security concerns for you too, as you only have to keep track of who has access to one plugin instead of 50.

    How Many Is Too Many?

    This is as subjective as all get out, but I’ll say this. Once you personally support 20 plugins for WordPress, take a good hard look at how much time you’re spending and ask yourself… is it worth it?

    It’s okay to say no.

  • Future Proof Names

    Future Proof Names

    The other day I was talking to someone about the name of their plugin.

    No, not about copyright and infringement, though that comes up a lot. I was talking to them about the meaning of the plugin name. They wanted to pick a name that was memorable, meaningful, and descriptive. I wanted them to drop the last one. Or rather, to reconsider the last one.

    Names Aren’t Descriptions

    My name, Mika, is not a description, it’s an identifier. Even my handle, Ipstenu, is an identifier. My domain ‘HalfElf.org’ actually is a bit of a descriptor, but it’s also an identifier. I am a Half Elf Rogue to many people, and that’s as it should be. But a descriptor is “Professional Lesbian” not “Half Elf on Tech” and yes, this matters.

    A good name is memorable (check), meaningful (check), and descriptive without being a description. Because a name is how we identify and remember the weird tech site we went to, versus the tools we use.

    In so far as plugins go, however, you have one more thing to think about, and that’s the plugin slug. The slug is like this post’s URL. Changing it comes at a cost and in the case of plugins, it’s impossible. So while I’m content to allow people to pick some silly names, I’m pretty sticky about the plugin url.

    Woo(Commerce) There It Is

    Whenever people submit plugins named “WooCommerce Thingy” they find their slugs changed to woo-thingy instead of the expected woocommerce-thingy because, well, they’re not WooCommerce. This sometimes incurs their ire, generally because they didn’t read the FAQ, and I’ve become resigned to linking them back to it. Most of the time, people just go “Oh, okay I get it.” and move on. Sometimes when the slug is less easy to ‘correct’ for them, like if they call a plugin “Google Fast Typing” (slug google-fast-typing) I have to email them and sort out a new name (probably “Fast Typing for Google” unless “Fast Typing” is trademarked by the Googs).

    Like I mentioned before, I don’t really push too much about a display name. You can change it as many times as you want, and coming back in a month to remind you “Hey, if you’re not Google, you shouldn’t start your plugin display name with ‘Google.’ They may get snarky at you.”

    But the display name is also very much abused. People use it as an extra ‘short’ description, which really only goes to annoy people who see “Luxembourg – A new plugin that will solve all your woes!” as a plugin name. Thanks. But that’s what the description is for.

    Gutenbye-bye-bye

    Gutenberg is a very popular plugin to make an add-on for these days. And a lot of people want to name their plugins things like “Joe’s Author Blocks for Gutenberg” which nets them the slug joes-author-blocks-for-gutenberg and I don’t know about you, but I find that excessive.

    See, you don’t want to have “Gutenberg” in your plugin slug at all. Unlike WooCommerce (or Google, or Facebook), we know Gutenberg is going to go away. Remember, the goal of Gutenberg is to be in WordPress 5.0!

    So that means naming your plugin author-blocks-for-gutenberg is shortsighted. In another four years, will anyone remember Gutenberg was the project name? Quick way to check, ask people at a local meetup “What’s MP6?” and see who knows.

    Name Better

    Think about the future of your plugin, the project, and the related items. Locking yourself into a name you regret later is one thing, but since a display name can be anything, you can name your plugin anything! Making a feature rich Gutenberg add on? Manutius is a great name! Changing the look entirely? Call it Reformation. Making a simple author block editor? halfelf-author-blocks is an okay slug, but “Block Your Authors” sounds pretty bad.

    Just remember, it’s eye before flea, except after sea.

    Someone carving hieroglyphics, when someone reminds him "It's eye before flea, except after sea."
  • Bad Faith Names

    Bad Faith Names

    One of the things about Open Source is we can name things whatever we want. This comes with a great amount of responsibility though, since we have to both come up with unique, memorable names that make sense and respect everyone else.

    Respect is a funny thing with names. For example, in order to respect my friend Tracy, I wouldn’t name my company LYKES Inc, because that would be very similar to her company of YIKES Inc. But also I know she’s trademarked the domain, which is a smart choice, and that means I have to respect her trademark as well.

    Speaking of Trademarks

    When it comes to trademarks, everything’s a little messier too. 

    This isn’t about not naming your plugin “Google Analytics.”

    This is about when you own a trademark and people are infringing on it, and how you can chose (or nor) to behave.

    This is about being cocky.

    There’s no other way to explain this, but a romance novelist trademarked the word ‘cocky.’

    No, this isn’t a joke. Since 2015, for a number of reasons, the word ‘cocky’ has been super popular with romance authors, and one of them decided to trademark the word. In 2018 she applied for, and got, a trademark on the word. Not just the word mark (which is like Pepsi’s trademark on the word and the font), but also the actual word cocky, as used in romance novels.

    And then she did exact what you’re thinking, and she decided to sue everyone else who was using it.

    Trademark Bullying

    Fallen Hopkins said her reasoning was her users. “I receive letters from readers who lost money thinking they bought my series. I’m protecting them and that’s what trademarks are meant for.”

    When you hear it that way, it does sound a little sensible, doesn’t it? She wanted to help her readers be less confused that “The Cocky Cowboy” isn’t a book in her series “The Cocky Series” (in which there is a book called “Cocky Cowboy”). She kicked the author of “The Cocky Cowboy,” who renamed her book “The Cockiest Cowboy To Have Ever Cocked” and now I’m a little in love.

    Now most of the time you can’t actually do that! I mean, I could name a book “Catcher in the Rye” if I wanted to, because you can’t copyright book or story titles. What you can do is the title of the book as it pertains to non-book goods and services, as long as the goods aren’t the book. With a trademark, if I have a book series, I can trademark the series name (see “Harry Potter and …”), but not a single individual title. Until I make a movie.

    But more to the point here, Hopkins was being a damn bully by deciding she was going act in bad faith.

    Yes. It’s legal, but it’s bad faith.

    Bad faith is simply you doing something that is legal but you know it’s the bad thing to do.

    That’s not a legal definition, by the way. If you look it up in a law dictionary, it involves the intent to deceive, which is a weirder thing. The real question is why is this legal? Right? Why would someone possibly be able to trademark cocky!?

    Turns out, it’s actually not hard to trademark a common word if you do it right. Take Apple, for example. You know, Macintosh the company? apple.com? Right, they trademarked Apple, but only as it relates to computers. I can name my car company Apple Cars if I wanted, but I better keep away from self-driving cars, eh?

    There’s a catch to all this. If you’re in the USA, you may be aware of the First Amendment. You know the one? Well there’s a doctrine about all this that basically exists to stop trademark law from stomping all over our rights. People build careers on this stuff, so the short version for you is that folks who are chapped about this have a damn good case against her doing this maliciously, and getting the trademark overturned.

    The problem is they need lots of money, which they don’t have. We’re talking about a bunch of indie e-book authors, after all. They may not have money but they have the internet, and they’ve been using it to savagely take down Hopkin’s reputation.

    You really should never piss off people who are good with words.

    Cockygate Doesn’t Hold Up

    The good news in all this is the trademark’s being canceled. The bad news is that someone else with deeper pockets probably has a great idea now and is going to be an even bigger problem for people later on.

    People will get confused. People can’t even tell differently named web hosts apart, so of course someone will think “Joe’s Google Analytics for Sports Sites” is an official Google plugin on WordPress.org (seriously someone did). They just don’t read and think, and all the trademark protection in the world isn’t going to help them out.

    But think about how you’re approaching this. Ask people to change the display name of things, and ask them to make sure it’s clear they’re not related to you. And when someone gets confused, point out “That plugin/app doesn’t have my trademark’d logo, so you can see it’s not mine. Sorry about the confusion, here’s mine.”

    If you’re interested, read Vox’s explanation on cockygate and please, don’t be a cock when you’re protecting your trademark.