Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Why I Don’t Use Git Flow Anymore

    Why I Don’t Use Git Flow Anymore

    Please don’t get me wrong. I love git-flow. I think it’s great. But it was great to teach me how to use git. It taught me not to use master for my development, and how to make branches and all that. Git Flow got be in the habit of doing good things and testing and showed me how to work with multiple projects. It was a great crutch to get comfortable with the ideas of Git that (for a long time) confounded me.

    But I don’t need it anymore. Instead, I do things very, very simply and my flow is as follows.

    $ git checkout master ; git pull

    I always start by assuming I’ve forgotten something and need to sync up. This works for me, since I run on two computers.

    $ git checkout NewProject

    Once I’m in the new project, I start making all my edits, add my code, etc. Now here’s where I get a little silly. If I’m working on my own stuff, it’s Coda, always, so I’ll constantly ‘commit all changes’ and fill in my commit messages and then cancel out. I do this over and over until I’ve reached a point where I think “This code is ready to be tested.” Then I commit for real.

    This means my commit logs look like this:

    Convert Font Icon to SVGs

 - Add new images for social media
 - Optimize CSS for pagespeed
 - Remove unused function.php file
 - Add shortcodes

Fixes #1234

    There are other ways to do this, of course. I’m a huge proponent of keeping change logs but a commit message should be useful too.

    It’s too easy to put in this: git commit -m "Adding new icons"

    While it’s more time consuming, just use git commit and put in a good message like I did up at the top. Now, this is not new. A hundred people have all said this before, but it bears repeating.

    • The first line is your subject, keep it to 50 characters.
    • Capitalize the subject line but don’t use a period
    • Use the imperative mode – “Add new icons” and not “Adding new icons”
    • Leave an empty line between subject and body
    • Explain what you did in the body, keeping lines to 72 characters
    • Bullet points are okay – use a space before a hyphen for best compatibility
    • Reference any issues at the bottom – “Fixes: #123” or “See Also: #456 #789”

    If, like me, you commit and then, before merge, realize you have changes, use git commit --amend to add your new changes to the existing commit.

  • Encrypting Source Code Doesn’t Make It Safer

    Encrypting Source Code Doesn’t Make It Safer

    I’d love to think that’s all I have to say on the matter, that you all will read the subject, go “Yup!” and we’re done.

    The reality is that I have to argue this, regularly, with people.

    Here’s the code from a plugin out there:

    <?php ${"\x47L\x4fB\x41\x4c\x53"}["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"]="\x73l_s\x65arch\x61bl\x65\x5fc\x6f\x6cu\x6d\x6e\x73";${"\x47L\x4fBAL\x53"}["\x66\x6b\x78xg\x63\x6ap\x68\x6d\x6ft"]="\x73\x6c\x5fdb";${"\x47\x4c\x4f\x42AL\x53"}["\x65\x62\x67\x79\x6b\x66\x64"]="\x69\x73\x5f\x73\x6c\x5fca\x74e\x67\x6f\x72\x69\x7a\x61\x74\x69\x6fn_\x63\x6f\x6c\x75\x6dn";${"\x47\x4c\x4fBA\x4c\x53"}

    The whole file is like that. The developer explained it was done that way for ‘security’ — it would make things harder to hack. I pointed out that’s simply not true.

    Here’s what having encrypted, hashed, packed code does:

    1. It makes your build process take longer.
    2. It adds another failure point into your code.
    3. It makes it harder for the end users, other developers (who write plugins), web hosts to debug, and you to debug.
    4. It makes you look like a developer with evil intents.
    5. It sets an expectation with users that this kind of code is ‘normal’ in WordPress.

    Recently Sucuri posted about a redirect hack that works by putting junk code in your header.php file which looks rather similar:

    Malicious injection in your header.php

    The issue here is that an end user, your normal WordPress user, cannot tell the difference between the somewhat safe code I quoted before and this code. They see ‘gibberish’ where as I know they can use a hex decoder to translate ["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"] into ["wsxnifioql"] … which is still pretty terrible.

    Well written code, well named functions, are self-explanatory. You see a function called redirect_404_pages() and you have a pretty good idea of what it’s for. You see a function named wsxnifioql() and good luck knowing what the heck that’s for. This goes back to the claim that the code is more secure. It’s not. It’s needlessly complicated, and as I shoed with the hex decoder tool, it can trivially be decrypted and read.

    So what is the real point of hiding your code? Who are you trying to protect? What’s ‘safer’ about any of this?

    The answer is that it’s about about you, you, you. You don’t want someone to take your great idea.

    That’s it. And that’s foolish.

    WordPress is GPLv2 (or later). Furthermore, to be hosted on WordPress.org, your code cannot be encrypted or hidden or otherwise non-human-readable. The basic reason is that WordPress’ success is due to it’s understandability and extendability. Anyone can read WordPress’ core code, parse it, learn from it, and enhance it. When you take that away from users, you isolate your code and prevent people from extending it.

    This person, this developer, charges upwards of $1000 for the add ons to their code. Yes, a plugin that costs over a grand. It sounds economically sound to try and lock things down so people don’t steal their intellectual property. We can all understand that impetus. I support it. I also feel that part of being in an open source community is being aware of how your actions impact the world at large.

    Because WordPress is open and because there is a standard expectation of non-encrypted code (except by evil-doers), the burden moves to developers to not hide their code that is installed on users’ servers. The code that is deployed to an end-user is expected to be human readable. This comes at a risk. I have a copy of a theme I bought, and I could give it away to anyone I wanted. They may not get updates, which means I have to be aware of the risk I’m introducing to my friends when I give them something like a premium theme or plugin.

    Similarly, what are the risks of telling people it’s okay to install plugin code in uploads instead of the plugins folder? What are the risks of allowing people to think that encrypted code is generally okay? In and of themselves, neither action seems particularly dangerous. PHP code is PHP code, right? If it runs, you’re good. But the reality is not so. By installing code in uploads I’ve made it so it’s no longer fully protected by WordPress and ‘standard’ security practices. I’ve also made it riskier that my code would even run, since many hosts prevent executable code from running out of that folder for security.

    So how do I meet the (assumed) criteria of not having someone rip off my code?

    You don’t. Your machinations aren’t preventing it now, and they won’t prevent it tomorrow. Hexcode is easily parsed. Even the Zend framework has to be able to be reversed to be run, so a dedicated person will always find a way around it. And the majority of your users aren’t going to be the problem. It’s those extremes. So what you’ve done is wasted time, effort, and money to annoy the majority to stop the minority. Let people inspect your code. If someone steals it, there are laws to help you handle them. Use them. Theft is theft. The GPL may allow them to take your code, copy and expand on it, but it doesn’t let them violate your copyright.

    All the work you’re doing to hiding your code is about as useful as preventing right-click on images. It doesn’t protect the end users, and it doesn’t protect your intellectual property.

  • PSA: DreamObjects URL Changes

    PSA: DreamObjects URL Changes

    If you use my DreamObjects plugins, don’t worry, I’ll have them updated before September.

    What Changed?

    As part of ongoing service improvements, DreamHost made a subtle, but critical, change to how everyone accesses DreamObjects. Specifically, they changed the DreamObjects hostname to prepare for upcoming enhancements.

    Old hostname: objects.dreamhost.com
    New hostname: objects-us-east-1.dream.io

    I’m a developer who uses DreamObjects. What do I need to do?

    If you were ever using the URL objects.dreamhost.com in your site, you need to change it to objects-us-east-1.dream.io and everything will be awesome.

    Is it really that simple?

    Not always. For some plugins and code, it is that simple. For my backup plugin, I added in a new option:

    if ( !get_option('dh-do-hostname')) {update_option( 'dh-do-hostname', 'objects-us-east-1.dream.io' );}

    This way I can later make it a dropdown for people to select as they want.

    But for my CDN plugin there’s a major issue. You see, the way it works is that it updates the URLs of images within your posts. It, literally, edits your post content. And that means a change has to go back and fix all the URLs. I had to write some fairly weird code to do this. I’m still testing it fully, and I think it’ll do everything I need, except it’s not going to perfect.

    Right now it does it’s utmost best to fix any URLs on a site, however it will only fix the ones for images it can detect are on DreamSpeed. I am aware that some people with a phenomenal number of images manually copied their uploads folder to DreamObjects and ran a command like this:

    wp search-replace 'example.com/wp-content/uploads' 'objects.dreamhost.com/bucketname/wp-content/uploads'

    Or maybe they used the InterconnectDB script or another plugin. Those people you’re going to have to watch out for and inform in a useful way as to how to fix it.

    I’m an end user. Do I need to care?

    Yes. You do. Do not try to fix it on your own just yet. Not until the plugins you use have updated and said they’ve corrected the issue. Then read the FAQ or any alerts to make sure you don’t need to do anything else. If you’re not using DreamObjects as a CDN, this should be pretty painless.

    If you did, or if you moved it all manually, you will have to do it again before September 5th, 2016 or all images will break.

    Thankfully, if you’re on DreamHost, you can run the following command:

    wp search-replace objects.dreamhost.com objects-us-east-1.dream.io

    That will upgrade everything for you. If you’re not, you’ll need to use the search/replace tool of your choice.

    Again: WAIT until any plugin you use for this has been updated. I personally contacted everyone in the WordPress.org repository and informed them about it, but since I know that’s not perfect, I’m doing this too.

    This sucks!

    I know. It does. But I don’t see a better way around it.

    When will your plugins be updated?

    Before the end of May. I just want to test it on as many large sites as I can find.

  • Aiding Symbol Selection

    Aiding Symbol Selection

    Last week I was talking about the difficulties I was having with Symbol Selection. At it’s crux, the issue is explaining something visual that’s clear to me but may not be to others.

    What I ended up doing was making in-line documentation. When you edit a category, you see the option to change the icon, but now it has some exposition:

    Exposition has a link to help you visualize things

    This is pretty simple, I now, but the point is that if you get that far and go “Wait, what?” your eyes will hit that link and you’ll probably click on it and get the new Appearance page:

    A page to show you all the symbolicons

    The page is generated by an mu-plugin, and quite simply it scans the folder for all the symboicons and shows you each one. Since it’s in an mu-plugin and the images are a part of the theme, I put in an extra check to see if the folder is there and, if so, show an error.

    class SymboliconsSettings {

    public function __construct() {
        add_action( 'init', array( &$this, 'init' ) );
    }

    public function init() {
        add_action( 'admin_menu', array( $this, 'add_settings_page') );
    }

	// Sets up the settings page
	public function add_settings_page() {
		$page = add_theme_page(__('Symbolicons'), __('Symbolicons'), 'edit_posts', 'symbolicons', array($this, 'settings_page'));
	}

	// Content of the settings page
	function settings_page() {
		?>
		<div class="wrap">

		<style>
			span.cmb2-icon {
			    width: 80px;
			    display: inline-block;
			    vertical-align: top;
			    margin: 10px;
			    word-wrap: break-word;
			}
			span.cmb2-icon svg {
			    width: 75px;
			    height: 75px;
			}
			span.cmb2-icon svg * {
			    fill: #444!important;
			}
		</style>

		<h2>Symbolicons</h2>

		<?php

		$imagepath = get_stylesheet_directory().'/images/symbolicons/';

		if ( !file_exists( $imagepath ) && !is_dir( $imagepath ) ) {
			echo '<p>Your theme does not appear to have the symbolicons folder included, so you can\'t use them. How sad. It should be installed in <code>'.get_stylesheet_directory().'/images/symbolicons/</code> for this to work.';

		} else {

		    echo '<p>The following are all the symbolicons we have to chose from and their file names. Let this help you be more better.</p>';

			foreach( glob( $imagepath.'*' ) as $filename ){
				$image = file_get_contents( $filename );
				$name  = str_replace( $imagepath, '' , $filename );
				$name  = str_replace( '.svg', '', $name );
				echo '<span role="img" class="cmb2-icon">' . $image . $name .'</span>';
			}
		}
	}

}
new SymboliconsSettings();

    It’s not perfect, but it helps.

  • De-fontification

    De-fontification

    I love fonts. They’re a great way to make your site unique. Back in the early 2010s, we were all using them all over the place.

    It’s time to retire them. (more…)

  • The Perils of Symbol Selection

    The Perils of Symbol Selection

    When I started my little experiment with showing icons on custom taxonomies, I began with a text field. This was because it was the easiest to edit and change right away. Next I changed it to a selection dropdown, based on the content of the folder where the I’d stored my images.

    And for the most part, that’s pretty cool. Except for the part where drop-down select boxes can’t show images. This meant I had to show the image name. Generally that’s okay. I know the name of the image I wanted to use. The problem is that I know that because I know the images I uploaded. For someone else, that’s 800 images or so they have to guess at, based on names.

    After playing around with selections and forms for a while, I determined there really isn’t a great way to show a list of images natively. No matter what I was going to have to mess with this the un-fun way because the easy way, CSS, failed. You can use background-image in Firefox but not Chrome or anything else that people use.

    Good news! As of jQuery UI 1.11, the selectmenu widget exists. Bad news! It’s not actually simple to implement. In fact, I absolutely failed at implementation. Let’s talk about why I failed, because it’s not just a matter of how convoluted the code is.

    A large part of my failure in this is due to the scale. If you only have one or two images, it’s less stupid. But when you get around to sets of 800 images, you start to understand why WordPress has a media uploader the way it does.

    The biggest factor, though, is that searching ‘visually’ is a difficult system to maintain. Symbology, the art of getting a ‘thing’ to represent another ‘thing’ is incredibly hard to pin down. Look at your WordPress dashboard. Why does a pushpin represent posts when they’re not all that different than the ‘two sheet’ icon of pages in functionality? Why is users a single person icon and not multiple people?

    Ask yourself this: if you’re adding in a new menu item, what do you make your icon? Do you make it your brand logo (a G in a circle for StudioPress’ Genesis theme)? Maybe you make it a cloud with a down arrow to indicate downloads (as does Easy Digital Downloads). We wanted to add in a new Custom Post Type for ‘Characters’ and ‘Shows’ for my database site and Tracy, who is amazing at this sort of thing, cheekily picked a video camera for ‘shows’ and a name tag for ‘characters.’

    I had a related but slightly different issue when I wanted to use Mark Jaquith’s meta I Make Plugins plugin. I wanted to see my plugins on the sidebar with a more unique icon. I couldn’t use the most logical one, a plug, since we’re already using that for Plugins. I went with a little ‘awards’ icon.

    In both cases, we studied the list of Dashicons and picked the ones that made the most sense, but it required a visual study of what we really needed and an understanding of how they all worked. Scrolling down a massive list of all of those is annoying, but necessary. You need to look at your options, think about them, and feel what they mean contextually.

    I haven’t yet figured out a perfect solution, but I’ll let you know when I do.