Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • 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.

  • Too Many SVGs

    Too Many SVGs

    I was looking into moving a site from Font Icons to SVGs for a few reasons. The primary is that, with an SVG, images will look crisp on all monitors, including the non-retina displays. They literally look better on my crappy old MacBook, instead of just on my iPad.

    Once I had the one site done, I went to look at another. It was a smaller site, running a Hugo as a static site generator, and I thought it would be perfect.

    I was wrong.

    Using SVGs is Easy

    Replacing my font icon with an SVG was as easy as making my Facebook call this:

    <object type="image/svg+xml" data="/images/social/facebook.svg"><span class="screen-reader-text">Facebook</span></object>
    

    Done. It’s tiny (2kb) and there are six similarly sized images which makes for 18kb which is incredibly smaller than the 200kb or more that Font Awesome can be. Simply, I realized I was only using five of the icons (on every page) and how stupid was that? I don’t need the whole library!

    I will note that ‘styling’ SVGs can be an exercise in patience, since you cannot apply CSS styles when you embed as an object. Thankfully, I wanted to make the icon match my style so I edited the style directly (which is the topic of another post). If you use PHP, I recommend using file_get_contents() to get the contents of the svg, and then use normal CSS to style. I was using plain HTML. There are tradeoffs.

    Using too many SVGs sucks

    My initial tests, using the footer first, and my page loaded much faster. Elated, I jumped over to all uses of the fonts, and remembered I had a page that listed a series of items with star rankings (none through five). I changed the generator code behind that to be object icons and reloaded.

    The page was slow.

    It was like dialup modem slow. Absolutely painful.

    After some research, I ran into this post about why SVG was so slow, and found a graphic that explained it clearly.

    Render times per number of objects on a page

    What the graph demonstrates is simply that the more objects you have on a page, the slower it is. That part is obvious. The more anything on a page, the slower it is. So why are SVGs slower than PNGs? Why was I only seeing this on an HTML page with 50 images, and not on a WordPress generated PHP page with the same amount.

    The answer was because the SVGs have to be rendered on the HTML page. I was using <object> tags on the HTML and file_get_contents on the PHP. The way the PHP code works, it pulls the file into content and dumps it out, not processing. Since the files are so small, and since the there’s no object rendering involved, the rendered PHP was faster than a static HTML. In this case.

    Can It Be Faster?

    After I was done face-palming, I asked myself if it was possible to speed this up? Fixing this comes with understanding the cause. Once I determined that the issue was rendering the object and not the SVG itself, the solution unfurled before me.

    Instead of using object tags, I could include SVGs like this:

    <svg version="1.1" id="facebook" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
    x="0px" y="0px" width="50px" height="50px" viewBox="0 0 438.536 438.536" 
    style="enable-background:new 0 0 438.536 438.536;" xml:space="preserve">
    <g>
    <path class="social" d="M414.41,24.123C398.333,8.042,378.963,0,356.315,0H82.228C59.58,0,40.21,8.042,24.126,24.123 C8.045,40.207,0.003,59.576,0.003,82.225v274.084c0,22.647,8.042,42.018,24.123,58.102c16.084,16.084,35.454,24.126,58.102,24.126 
    h274.084c22.648,0,42.018-8.042,58.095-24.126c16.084-16.084,24.126-35.454,24.126-58.102V82.225 C438.532,59.576,430.49,40.204,414.41,24.123z 
    M373.155,225.548h-49.963V406.84h-74.802V225.548H210.99V163.02h37.401v-37.402 
    c0-26.838,6.283-47.107,18.843-60.813c12.559-13.706,33.304-20.555,62.242-20.555h49.963v62.526h-31.401 
    c-10.663,0-17.467,1.853-20.417,5.568c-2.949,3.711-4.428,10.23-4.428,19.558v31.119h56.534L373.155,225.548z"/>
    </g></svg>
    

    The downside is that this looks uglier. The upside? This is hella fast and it’s still lighter weight than including a font icon, and I don’t have to upload images.

    SVGs or Font Icons?

    This is a question for the ages. They can both be made accessibility friendly, they can both be optimized. Arguably, font icons are compatible with more browsers, but it’s also 2016 and if people are still on IE 8 (sorry banks), the Internet looks pretty shitty anyway. I can’t tell you which is better, and I find use for both in different situations. I love font icons a great deal, but just as I love WordPress, there’s a time and a place for them. And a time and a place for something else.

  • Farewell Mothra, Hello Ogra

    Farewell Mothra, Hello Ogra

    For some reason I name my servers after Godzilla monsters. I currently have two – ogra and gamera. Gamera is a new DreamCompute box I’m using to test things on, but ogra is this server.

    Gamera

    There used to be a server called Gamera before Gamera. Original Gamera was my very very first VPS. At the time, I had four websites, all with separate hosting plans, and I mathed out that it would be cheaper to combine them to one VPS and learn that.

    Boy what a jump that was! This was my first experience with a VPS at all, but I think that, in retrospect, it gave me comprehension of the web in a new way. Before, I was just a user of the internet. After, I understood why so many sites behaved differently. Gamera was actually how I got to know Mike Schroder! We’d added ImageMagick to WordPress and he was an aficionado. I was trying to test some things and he pointed out I didn’t actually have it installed. Off to the races!

    Mothra

    As Gamera got long in the tooth, I needed to upgrade some software and realized that doing so wasn’t going to be possible anymore without an OS upgrade. Instead of that, however, I looked into a whole new server on a new system: the cloud.

    This really just meant I had a more dynamically upgradable server. It was easy to add more memory or diskspace. I could spin up new clusters as needed (though I haven’t needed to yet), and it was bigger and faster and better.

    I learned a lot on Mothra. Everything from memcached and nginx to varnish and SSL was done there. I’ll miss it.

    Ogra

    Of course time went by and I installed all sorts of shit on my server. And, eventually, I wanted to upgrade to the newest operating system and test it without downtime. This can be done, but I decided to build a new server on the latest and greatest OS and migrate my sites. Building out the server was easy, as I have a document called “How I Installed Shit On My Server” and I was able to use that to rebuild everything I needed. Some things had changed and got updated, but in general it was pretty much the same thing.

    Since everything was on cPanel and WHM, transferring sites was incredibly painless. Where, five years ago, I had to ask for help, this time I was able to press the pretty buttons and do it myself. The most terrifying part was the DNS. What I did was move accounts over one at a time, starting with the smallest site and building up. Then I’d change my /etc/hosts file to point to the new IP and verify everything worked. As soon as the site was good, I changed it to the new nameservers (ns3 and ns4) and moved on to the next one.

    This was only a problem when I ran into my Aunt’s website, which has the DNS over on Microsoft. A few emails later, I logged in as her and changed the setting (and saved her account information for the next time). Sadly, Microsoft doesn’t let you point a domain to a CNAME, you have to use an A record, which means IP and doing my migration this way required a new IP.

    What Now?

    Now I’m waiting on EasyApache4 and full support for Let’s Encrypt in cPanel.

  • The Beta Tester’s Paradox

    The Beta Tester’s Paradox

    In a nutshell, the paradox is this:

    The more likely a person is to test Beta and RC, the less likely they are to have bad code.

    When people wonder why problems like the recent jQuery flub manage to make it all the way into the wild, they tend to assume the issue is not testing enough. They’re incorrect. The issue is not testing enough.

    Put the lead pipe down.

    What do you think ‘enough’ is? I promise you, the majority of people who have a broken site will say “It needed more time being tested.” And in return, the majority of developers will say “It needed more people with more diverse setups testing.”

    So which one is right? They both are. We need more of the right people testing. We need people who are on the edges of ‘normal’ for WordPress. The problem is that the ‘right’ people are the people who have the worst code.

    Take a look at WordPress 4.5. Not a single beta tester was using a plugin or a theme that used jQuery improperly. Look at Jetpack 4.0. Not a single beta tester had a server config that broke, but within 12 hours they had over 300 tickets about an error 500 on many sites. In both cases, a significant amount of testing was performed. People banged on the code and outright tried to break it. Just not the right people. And the worst thing is we cannot know who is the right person until after something breaks.

    This leads to the other part of the paradox.

    Someone whose site breaks after an upgrade is less likely to want to beta test.

    This is because we’ve broken the trust. They cannot accept that their site went down, or their computer crashed. Or maybe they can’t afford to be Janie on the Spot and jump every time their site needs a bit of an extra hand when an upgrade goes bibbeldy.

    Of course, this is why the people who are testing are less likely to have a problem. They don’t want to waste time debugging stupid code problems, so they put the time in front to make sure they don’t introduce bad code to their environment.

    We create a vicious circle, because the only way to get better results from beta is to get more people beta testing. But few people are willing to fully beta test on a live site, and say what you will, there’s nothing quite like live testing on a real, production site. You can’t stress test reality until you get your setup on your server on your design on your everything.