Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Get Sassy

    Get Sassy

    Elf is Unimpressed at SassI was lucky enough to corner Tracy Rotton at Contributor Day and bully her into a private “Sell me on Sass!” Class while we were both at WordCamp San Francisco. I’m a hard sell on something ‘new’ not because I hate change, but because I don’t see the point to learn something new in order to do something I’m already capable of doing. But that said, CSS and theme design aren’t my ‘thing.’ I can muddle through, but I don’t love them like I do writing.

    In order of my WP skills it goes like this: writing, support, debugging, plugins, themes, databases. See how that goes? So I knew Tracy was big on this stuff, and I realized I had a perfect opportunity to get someone to explain, in a place where I could go “But why do I care?”

    Why do you care?

    Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and a ton of other stuff. For me, the nested rules earned an unimpressed face. Testing things in a ‘new’ way means I have to re-learn how to do things. And being able to define ‘font color black’ and use variables so I only have to change one thing is useless, as I’ve mastered grep and regex. Tracy laughed and then pointed out I could have Sass do the math for me.

    Full stop.

    If you’ve spent any time designing responsive themes (which most of us do) then you’ve probably run into the extended math part of CSS where you have to calculate font sizes, relative to each other, and then you have to sort out the percentages to make the width and height right and.. Well, I went and read Tracy’s post about saving time with sass later and felt way smarter for it.

    But we’re still back to the fact that I don’t theme. It’s not me. So I had all this info and sat on it for a while. In fact, months. I started writing this post during WordCamp San Francisco. Next month is WordCamp Las Vegas. It’s pretty much been half a year.

    What changed? MP6, or rather, the removal of MP6 and introduction of it as a core part of WordPress 3.8. Suddenly the plugin was useless. Less than useless, it broke display. So I looked at my options. I knew they were working on a plugin to bring the MP6 styles back, but right now they didn’t have my favorites and I really don’t like all black. I ripped open MP6, pulled out the color-schemes folder, stripped down the colors.php to just the part that added in more options, and thought I was done.

    Mikayla and Obama are UnimpressedI was wrong. It looked ugly. It didn’t match, it was broken. And there was only one thing left I could do. It was time to get sassy!

    What you nee to do this is a Sass ‘App’ – Now Coda 2 lets me edit Sass files directly, but not compile, so basically I have a nice highlighter. Booooring. There are plugins for this, and installing stand alone Sass compilers on my mac is as easy as $ sudo gem install sass which lets me then convert my file ala sass-convert style.css style.scss and now I have a sassy file! The other option, and this was where I ended up, is CodeKit.

    Yes, I could use Grunt, Tracy, but I want to learn one things first, understand it, and move to the next. Grunt? Yes, I need to learn it. But right now, my need was to take five scss files and convert them into the right name css files.

    What it looks like is plain weird. A scss file is weird. It’s this:

    $base-color: #523f6d;
    $icon-color: #ece6f6;
    $highlight-color: #a3b745;
    $notification-color: #d46f15;
    
    $form-checked: $base-color;
    
    @import "../_admin.scss";
    @import "../_colors-fresh.css";
    

    And then it looks like this:

    @import 'variables';
    @import 'mixins';
    
     {
    	background: $body-background;
    }
    
    
    /* Links */
    
    a {
    	color: $link;
    
    	&:hover,
    	&:active,
    	&:focus {
    		color: $link-focus;
    	}
    }
    
    ....
    

    Oh wait, it also has this! … No, wait, that won’t work. It kind of goes on like that for a while, like Russian Nesting Dolls, or a TARDIS. But in essence it let me make files where I could define what the CSS became. One file is my ‘define’ file, that was the first one I showed you. The next was my _admin.scss file, which had two more includes and a mess of what looks like CSS, if CSS had variables (which you know it doesn’t).

    Look. I can’t, and won’t try to explain Sass. I’d do a crap job, worse than you think I’m gearing up for here. I’ve only been seriously playing with it for about three hours. But in those three hours I went from unimpressed (I’m a hard sell) to understanding. I was able to generate fancy CSS files without have to search/replace. All I did was make a new define file, tell it to output into a folder, and I had my Ectoplasm back.

    Will I be using this a lot? Maybe. I can’t say I feel it revolutionizes theming for me, and it won’t for a lot of us. When don’t need to be able to spin up more CSS like this, CSS is something that generally remains static. It should, in my opinion. But the point would not be on the fly fix CSS, but to build out ‘themes’ of CSS. So perhaps for Brian Gardner it might change his world (hi, Brian).

    You see, every Genesis Theme comes with color ‘choices.’ Usually these are green, blue, orange/red, and purple. Imagine being able to spin up your own by making one small file, generating the CSS from that, put it in a folder in your child theme, and you’re done. Heck, if someone wanted to get really sassy they could make a plugin that would pull in special Genesis files and folders from your wp-content, much like we have a languages folder today.

    wp-content/genesis/themename1/color-style.css
    wp-content/genesis/themename2/color-style1.css
    wp-content/genesis/themename2/color-style2.css
    

    And so on. That could dynamically be searched for by Genesis and add in more color themes as desired. This way, I can make new styles for my theme without needing a child theme at all, or another CSS editor plugin (which is what I use today – this site is customized by mostly CSS).

    But. As Otto rightly points out, this over complicates things. Can’t I just search and replace blue for teal? Sure. But having the scss in the first place means I can look and see the four places I’d need to adjust colors to make it work. Or ten. So I can very quickly spin up a custom design, and I can tuck it away where my client won’t break it.

    So no, while I like Sass, and I think it’s incredibly interesting, I’m not really sure that adding code to CSS and requiring compiling will be needed for everyone. Where it’s a major selling point for WordPress core is easy to find. It lets them easily break apart the massive admin CSS files into sections, edit one at a time, and then on ‘build’ pull them all into one file, so we don’t have messy @imports all over the place.

    So it’s a good idea for me to learn Sass I suppose. And Grunt. Grunt is next.

  • Don’t Say WordPress

    Don’t Say WordPress

    This time I’m absolutely 100% serious. Yes, I can be sarcastic and humorous when I talk about WP, but in this case, I’m being honest, and I promise you serious. I work for DreamHost as a WordPress Guru. I’ve been training people, and teaching them one at a time, and in doing so, confirmed a bias I’ve had for years: Tech Support goes blind sometimes.

    Man with tape over his mouthI don’t think this is really their fault. They have to handle 60 to 100 tickets a day about everything from “How do I reset passwords?” to “My Database is speaking in R’lyehian. HALP!” In order to get through that volume, they look for the key words, the important ones that tell them that this is the problem. And one of those keywords is “WordPress.”

    This is not great, because sometimes the problem isn’t WordPress. Like a PHP isn’t running, or the DB is missing, or a hundred other ‘It’s not WP’ problems. Naturally, that means a handful of tickets escalated to me aren’t WordPress at all, and I have to dig into it, and explain why.

    Before my coworkers think I’m pointing figures or blaming them, I really don’t. It’s a volume thing, and it’s got to do with how the customer presents the error. If they tell you “My WordPress site is down, I’m getting an error 500 on all pages!” you think “Oh, it’s probably .htaccess or they’re using too many resources.” Those are the most common causes after all. After that, you start getting messy and into weird things like “PHP memory is set too high, causing WP to crash” (which I didn’t even know you could do to be honest until November). And sometimes it really takes someone who knows how WordPress works to put the pieces together and determine “Oh! This is it!”

    However, hands down, when I’m working with Multisite and I see someone say “My wildcard subdomain isn’t working!” and the ‘error’ page they get is not a WordPress styled 404, I will tell them “DO NOT mention ‘WordPress’ or ‘Multisite’ to your host. Tell them this:” and here’s my copy/pasta:

    I’m trying to set up a wildcard subdomain, so anything.mydomain.com will pull the files from mydomain.com, however I’m having problems. I’m getting a server error instead of seeing the content on my site. Is there a trick to setting this up on this server?

    Now some hosts will look and say “Oh well you’re using WordPress, that’s why.” and I want to kick them a little. No, that’s not why. When you go to a subdomain and get the server error (like subdomain not found) or worse a DNS error (like Google saying the domain doesn’t exist), then the problem is not, and cannot be WordPress.

    That’s why it’s really important to present your error in the best way possible. The most accurate to the actual problem. Of course, if you have no idea, then you should just be honest and say what you did. If you really, truly, didn’t do anything, though, be prepared for someone to ask “Are you sure? You didn’t change a setting on the dashboard?” And sadly this is because a lot of people lie, a lot of people misrepresent the facts, and a lot of people play dumb. There is a very small percentage of people who will come back and say “You know, I may have done something, but I cannot remember what I did.” I like those people a lot. They’re my people. They admit they may have, but they can’t recall.

    WordPress FauxGo
    WordPress FauxGo (yes, this is the FAKE logo)
    Sadly all those people who aren’t quite as truthful screw it up for the rest of you, which is why there’s a time and a place to point at WordPress, and there’s a time and place to not do so.

    How do you know the difference? Well you have to think. Is what you’re trying to do something you do with a plugin or theme? Did it happen after you made a change to your site’s settings? It’s probably WordPress. However if you’re trying to do something outside of WordPress, like domain mapping or wildcard subdomains or creating a database? Then don’t mention WordPress.

    It’s counter-intuitive, I know. I’m telling you to be honest and say what you did or what you’re doing, but at the same time I’m telling you to leave out what might be important information. And that’s why you have to think. Is the error a WordPress error? Learning that takes a long time, so for a lot of rookies, the easier question is “Does the error happen without WordPress involved?”

    Let’s go back to that subdomain thing. Turn off Multisite. Does the same problem happen? Probably not WordPress. So don’t bring it up just yet. Now if they ask “What are you trying to do?” or why, tell them. “I’m trying to setup wildcard subdomains so I can use it with WordPress, but at this point, I’m not even getting a WordPress error.”

    Of course, it’s not always that simple. Like what if I told you that, on Multisite, not getting the CSS to display on subsites could be a server error? That’s when you get to say:

    My complex .htaccess rules don’t seem to be honored by my server. Is AllowOverride set to either All or Options All in the httpd.conf (or equivalent) file?

    Notice how I didn’t mention WordPress? This is because I know that if my .htaccess rules are right, the problem’s not me. Unless of course my host blocks that on purpose because they don’t want to let me run Multisite on a shared box.

    It’s not cut and dried, it’s not ‘If this, then that!’ But what it is, is education and thinking. As long as you can learn what is and is not WP, you’re on your way to knowing when you ask about WordPress problems, and when you ask about server problems.

  • Sometimes The Answer Sucks

    Sometimes The Answer Sucks

    I’m good at what I do. I’m really good. I’m an expert, and I’ve rarely run into a WordPress site I couldn’t fix, or at least get back to usable. This doesn’t mean I can code everything, but it means I can take a broken site and get your content back. I can’t, however, perform miracles all the time. You saw how I said ‘rarely’ right?

    The real issue here is that sometimes the answer I give people is a horrible, terrible, sucky answer.

    Scotty_JefferiesTubeWhile Montgomery Scott always saved the day giving the engines more power, and skipping through the Jefferies Tube like the most bad-ass red shirt in existence, the sad reality of life is that sometimes we can’t save your website. If we can’t figure out why it broke, we may not be able able to fix it.

    For example, a site suddenly lost all the plugin settings. They were just gone. Poof. No one had done anything, so the obvious cause is the database having a snafu, right? Well no. The DB was checked, everything seemed in order. We tried a restore, no-go. At that point, the only thing I could tell the person was to re-apply all the changes again, manually. The user was pissed off and it’s totally understandable why! I was pissed off. I couldn’t solve a problem and yes, when I can’t solve things, I get very upset with myself. And I was upset that the answer was so sucky! Redo your hard work? What a crock! But no matter what I did, no matter how I tried to pull the settings back, I was just getting further and further down that rabbit hole, and I knew I absolutely had to cut my losses.

    Kirk_AngryIn all likelihood, someone did something without checking it was right and without making a backup first. This happens. We know we shouldn’t mess with ‘production’ but we all do it. So that means sometimes we’re really reckless and we shoot ourselves in the foot without protection. While we can, and do, try really hard not to be stupid anymore, accepting that you (or perhaps your captain) has made a boneheaded mistake is really important. Equally so? Accepting that cleaning up that mistake may not be the answer we wanted to hear.

    No one wants to hear ‘Start over.’ That’s pretty much a given. And yet we’ve all done it before. When I studied music, the number of times I had to start over because I’d made a mistake is uncountable. When I was learning to connect pipes in plumbing? Oh I ripped things out a hundred times before getting it right. I even restarted this entire blog post a couple times. And that’s not the only time the answer sucks. You changed user roles and capabilities and now you can’t log in? Congratulations, you get to reset them and start over.

    I could go on with example after example of things we do, without realizing how dangerous they are, and how much trouble they get us in, but I suspect the point is made. We do amazing things to ourselves and can’t always fix them. Should you be upset when it happens to you? Of course. And should you be annoyed when you didn’t do anything and they break? You bet! But ….

    Your website is like a car that’s always running. Eventually something is going to break, and when it does, the only hope you have of salvation are your backups. Everything really comes back to that, doesn’t it? I deleted the wrong table in a DB and had to restore the whole thing from the day before. Lost a day’s work. Nothing to be done to fix it but that. I had a file, for no reason I could see, go corrupt and refuse to let me edit it. Thankfully the backup was the version I wanted to edit, so I deleted and re-uploaded and moved on.

    These things will happen.

    The answer will suck.

    Decide if you’d rather spend your time complaining about how it’s sucky, or if you want to knuckle down and get to work.

    Scotty and Scotch

    Or drink scotch.

  • Presentations Are Not Transcripts

    Presentations Are Not Transcripts

    After my review of SEO Slides (they’re pie, not cake), someone remarked to me that my slide decks are useless because I don’t put all the information on the slides. They pointed out, correctly, that my slides are image heavy with, at most, a couple lines of text (with one notable exception: WordCamp Chicago 2012), except my ‘Who am I?’ slide. I told them “Yes, this is true.” and then Tweeted about it.

    SlidesMy belief (and this is shared by a lot of people) is that slides should accent and relate to my talk. If you just need to read the slides to get all the information, why am I there? Coming to a live presentation to just watch someone reading off slides seems counter intuitive to me. Heck. I could go pester my coworker and get the studies showing that when you have a slide with a lot of text, people read the text, then look at you. That means that they aren’t listening until they read, and if, when they’re done, they come to find you’re just reading what they read? They’re probably bored.

    When I give a presentation, it’s usually on a topic I’ve written about before. Actually, that’s generally how I decide what I want to talk about! I picked “Don’t use WordPress Multisite” for WordCamp SF 2013 because it is still, to this day, the most popular post on my site. And it’s my most popular presentation. Some may ask “Why would you give a presentation on something I could read?”

    BoredPeople learn in different ways. I, personally, suck at learning from videos. However I learn well from presentations in person, where someone talks to the room, pays attention to our energy, and teaches, using the slides as an emphasis. I also learn well from a written post. Finally, I learn best by doing things. So for me, if I’m blowing up a site, it means I’m learning in a speed unparalleled. There’s a converse to this, and if I hit a blocker were I can’t do something, I get really upset.

    What does this have to do with slides and why mine are mostly pretty pictures with a sentence for emphasis? I don’t write my slides to be a transcript because I’m going to write a much longer blog post on the topic, with the same pictures probably, if I haven’t already. So for the person who wants to read the content, I’ll have you covered. And for the person who wants to be inspired by looking at slides? Well I have that. Finally for the person who wants to watch a video, WordCamp does that for me, thankfully.

    This is not a perfect system, of course. Like I said, people learn in different ways, so there’s probably someone out there who loves slideshows of text on pictures who is grumpy. They probably also like infographics. Which I don’t. You see a trend here? I don’t like getting my information from pictures. Because of that I suck at writing them, so I just don’t.

  • Make It Pretty

    Make It Pretty

    This one is a visual.

    Here’s what my WordPress toolbar looks like on WP 3.8 on a site where I show Jetpack Stats in the bar:

    badmenu

    And here’s what it looks like on a site where I don’t show the stats:

    goodmenu

    And here’s an even worse menu:

    worsemenu

    So what does this tell you? As a developer, you need to spend some time making sure your menus look nice. I already went to the Jetpack blokes about this, but the real crux here is ‘toolbar menu items get janky.’

    This has always been the case, of course. It’s just a little more prominent in the MP6ified world, and it is getting better, but what needs to happen is plugin and theme developers who add in toolbar menu items take stock of how their items are used.

    The obviously easy fix is to use wp_is_mobile() to check if the device is a mobile one and if so, simply not show the menu item. After all, the odds of someone needing to adjust SEO via the toolbar on a mobile is slim. An exception might be emptying cache for that page, and for them I suggest an alternative. When you really do have a major use-case for a toolbar menu item on mobile, have it degrade via wp_is_mobile() to show just an icon on mobiles. For caching, I’d use [genericon icon=”trash”] (there’s one for Dashicons: dashicons-trash).

    I know this one’s really crazy short, but it’s one of those things that really needs a reminder. You’ve got to test your toolbar additions! WordPress 3.8 is due out three days from this post. Get on it!

  • eCommerce Dream

    eCommerce Dream

    At the end of my WordCamp San Francisco talk, I said I had a dream. A dream about a plugin that can share an inventory between WordPress sites on a Multisite Network.

    Firefly_-_WhitefallImagine, if you will, a store with a physical products (Geisha dolls). The store has a bunch of different types of dolls. The store has satellite stores, one in Ariel (their flagship store) but now one on Bellerophon and another on Whitefall. While the Companion-Style dolls sell well on Ariel and Bellerophon, the Cowboy-Style ones sell best on Whitefall. Also each store has a different kind of clientele.

    So the Dollhouse Store makes a website, and then using Multisite, makes another site for each location: whitefall.dollhousestores.com and so on (or maybe whitefalldollhouse.com even). At first, the webpages are just a list of the local store products, come and buy them here, photos of the locale, employees, and local events. Then they decide to sell stuff on line. But they only want to list items for sale under specific criteria.

    1. All items for sale are stored on the network admin
    2. Each store can select what products they have at their store
    3. Each store controls product volume.
    4. Stores can request more product from homebase

    Now of course they could have a separate store for each site, but they want to manage what possible items could be sold online, so having that controlled by the network makes sense, doesn’t it?

    Firefly4_LMeanwhile another store sells cows. All the cows live at Persephone, and are shipped out to Jiangyin and other stores. They’re doing well with everyone going to cowship.com, but they too want to have jiangyin.cowship.com and so on. Each store lists what cows are for sale that live well in each location because Holsteins’ don’t like Bellerophon, who knew? This way, someone on Jiangyin can order Holsteins but not Texas Longhorns. Obviously they need to control which product can be sold at each location, same as the Dollhouse, but they also have a different problem. Their product amounts must also be stored in one location and shipped out from there, so they want to make sure they don’t oversell their cows.

    Their criteria:

    1. All items for sale are stored on the network admin
    2. Network admin controls absolute amount of products
    3. Network selects what products they have at each store
    4. Orders per store base product volume on the network amount

    These are pipe dreams. Today there is no plugin that ‘shares’ an estore across multisite sites on a network. You can’t even do it with ‘digital’ products which now that I say it aloud, I think Pippin should totally get on that.

    Today, all sites are separate, and since estores have their content saved per-site, there isn’t an easy, friendly way (if there is at all) to pull data between sites in a way that preserves shopping carts and such. I wish there was. I get asked about this at least once a week, and I have to say “Today, there is no plugin that can share an inventory between WordPress sites on a Multisite Network.”

    But this is a complicated thing. Multisite itself isn’t actually built to handle that kind of thing, since the network doesn’t have posts or pages. You’d have to dedicate a site on the network to the shop and pull in content from there, which of course has a switch_to_blog() overhead penalty. I can’t even begin to get past the paper thoughts I have here.