Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • Catch a Session

    Catch a Session

    When I was at WordCamp Chicago in 2013, Brian Richards asked me if I’d be interested in giving a WordPress ‘Session.’ Since not everyone can make a WordCamp, what if there was a live, online, session they could watch to get the same information? Thus was born WPSessions!

    I said yes, and months went by. Then he pinged me again, asking if I was still interested, and would I might talking about eCommerce and Easy Digital Downloads? That was new! Most people want support, community, or multisite. Since I’d recently written a book about running an ecommerce bookstore, I said yes again, and on Thursday gave a session.

    If you missed it, and you probably did since I did a terrible job promoting (sorry Brian!), you can check it out at WPSessions – eCommerce for Site Owners. It’s $30 for four sessions (mine is 51 minutes long), and while my slides are online , you never get quite the same impact as seeing me give them, do you?

    http://slides.halfelf.org/wpsedd/

  • Whatevergram: The Honeymoon is over

    Whatevergram: The Honeymoon is over

    I’m not a photographer. I’m not artistic in that particular way and I don’t want to learn to have to be. The joy of Instagram is I can take a photo, slap a filter on it, put a border, and boom. Done. Share it with friends. The sad part about Instagram is putting that photo on my blog. It’s all machinations and annoyances.

    What I wanted:

    1. An easy way to take ‘styled’ pictures.
    2. An easy way to push those pictures to my blog.
    3. An easy way to determine how I want the pictures to post.

    That’s all, three things. Now, Instagram wins at , and Pressgram wins at , and the both suck at .

    a cameraThat third one is the hardest, I guess, but what I want is that when I upload a file, it either makes an individual post or makes a gallery post of the whole day. And in both cases, I get the option of making a post publish right away or save it as a draft. I kind of love the idea of ‘This week in [Insta|Press]gram’ as a post for a photo blog. In looking at my options, I determined there’s one Pressgram plugin and a million Instagram, but none really do all of that.

    But really … Pressgram 2.0 fixed most of my issues with UI, and for that I’m very happy about the new version. It’s easier to read and use, the layouts make sense. I’m even okay with the in-app purchases for things (though charging for some of the things Instagram offers for free strikes me as a poor call). Lacking the nice, snazzy filter names (imagine naming them after WP Themes) and borders/patterns means that if I want those in a quick way, I use Instagram and the maybe Pressgram to upload.

    Except that isn’t what happens. I take a bunch of photos. At the end of the day I manually upload them all to my blog. Manually. What an annoying thing. I can’t do the one thing I want, which is make a gallery post. By default Pressgram 2 publishes my posts, so I have to use a plugin to not do that. Or I can use a plugin to import from Instagram (though again, it’s a single post per image). Of note, people recommended Instagrate to me, but it’s not Multisite compatible (says so on the plugin page) and that means it’s either poorly written or it’s doing something really wrong, since Multisite shouldn’t matter at all for that. Also it’s manual.

    The best plugin I found was one that daily pulls in my Instagram pictures and saves them as draft, leaving me to manually merge and make a “This week in Instagram” gallery. There was another that can make a weekly post, but it’s old, out of date, and doesn’t actually save as draft anymore. There’s not really a perfect way to do that, though, as even the ‘import on demand’ plugins seem to have gaffs and time delays. Obviously Pressgram’s ‘Post direct’ method is going to be more precise, but even then it doesn’t have a ‘collect everything from a week’ if it’s going that.

    I know I said the Honeymoon is over, but to be honest, I don’t know that it was ever here to begin with.

  • Why Can’t Multisite…

    Why Can’t Multisite…

    Many times people complain that WordPress isn’t ‘complete’ because it doesn’t have the features they feel are indispensable. While explaining, and educating, to people that they can’t always get what they want out of core is often fruitless, the point remains that WordPress cannot, and should not, do everything. That’s a part of a longer post, but once you are willing to accept the fact that WordPress will never be everything to everyone, we can move forward.

    There are practical reasons why Multisite doesn’t do everything people envision, and there are also some weird impractical reasons. Sometimes the answer to this is a very simple one, sometimes it’s confusing, and sometimes it’s technical. But there are reasons, even though we don’t like them, and over time they change or go away as issues are resolved.

    Here’s a list of the common questions I get and their answers.

    Why can’t I manage everything about all sites from the network admin?

    Mailbox FaceIt would slow your site down. You’ve probably heard me say something like “WordPress Multisite was intended to be multiple separate sites managed by one install of the WordPress files.” When I say that, I don’t mean ‘managed’ the way some people envision managed. When I say ‘managed’ what I mean is “You manage your network settings from the network dashboard, and you manage your per-site settings from the per-site dashboard.”

    Not every site has the same settings, anyway. The point being, if WP had to query every site for every setting (like all your comments), it would get really really slow when you have 11k comments on your blogs. And you’d be mad.

    Why can’t I set all defaults from the network?

    Oh you want them to be all the same? I’m not sure you should be using Multisite, but since you are, this one is annoying.

    In normal WordPress, you shove everything into wp_options and call it a day. On Multisite you have an options table per site, so wp_2_options and so on, but you also have wp_sitemeta. Some settings and plugins have been coded in a way to fall back, so it grabs defaults from that table. But. Not everything has been, because there’s a tacit assumption they don’t need to be.

    Now there are plugins that will let you force in defaults on new site creation, but given that every single site admin can go in and change them, it would defeat the point. They’ll just change them! Thankfully, it’s a growing trend for plugins to include a Network Admin Settings page, where you can determine how to control things for your network. But that’s only going to be for things like caching and probably Jetpack. Not ecommerce. Yet.

    Why can’t I share media?

    Because media is content and content is per-site.

    There’s a plugin called Network Shared Media which purports to being able to do this, but by it’s nature, content is sacrosanct and separate.

    Tennis Only

    Why are usernames using characters like – . _ are not allowed?

    Because they’re not permitted in subdomain URLs and since the blog URL is generated from your login name, it’s not allowed. The site admin can do it from the back end, though. This is highly imperfect, and perhaps should be changed (so maybe we could also have less than four characters in a name, which not even an admin can fix). The logic to do the detection would be a pill though, and you’d still want to do it on things like a mapped domain.

    Why can’t I just map a domain!?

    That’s being worked on. Eventually WP will have that superpower.

    Actually that brings me to the biggest reason why Multisite can’t… It’s not that it can’t, it’s that it probably shouldn’t, or it will be able to do so eventually. If you consider what the original intent of Multisite was, much becomes clear. Open Source Development doesn’t move at your pace, not even if you’re Matt Mullenweg. It moves at the pace of everyone involved in the coding and testing, and it moves at the pace of their ability to innovate. That means sometimes what you want isn’t there yet because it’s not easy, or because it’s not ready, or maybe because no one agrees with you right now that it’s a priority.

    After all, sometimes we’re wrong about Open Source Developmen.

  • Very Voluminous Vagrants

    Very Voluminous Vagrants

    I finally sat down and installed Vagrant.

    Specifically I installed Varying Vagrant Vagrants. I read, like I do, and the directions were thankfully pretty clear for a change about what the prerequisites were, and I found myself with an install of Vagrant up and running within an hour. At this point I joked “Now what?”

    Vagrant is yet another tool you can use to create test websites. It’s a super-powerful command line tool one might use instead of DesktopServer or MAMP. Now, I love MAMP. While I find DesktopServer more ‘flexible’ in that I can spin up a client’s site really fast to check it, MAMP is even faster to boot when I just want to see one site and test a plugin on it, in part because I use MAMP No Password and run it on port 80 (which lets me use Multisite).

    But… Sometimes when I want to test, I want to test different configurations at once. Like I want to test on current (3.8.1) and trunk, and I probably want a Multisite Network as well. But Vagrant is way more than just a lot of different environments in one go. I mean, if that was all it was, I could edit my hosts file and make a couple extra sites in MAMP or DesktopServer and be done.

    What do you get?

    You get a lot with VVV, and if all that seems weird to you, it’s okay. The more I work on servers, the more I see a varity of weird setups and the more I want to mess with them for testing. This isn’t to say VVV is perfect. You can’t switch (easily) between PHP 5.2 and 5.3 and 5.4. There’s a whole discussion ticket on the matter.

    Vagrant makes multiple servers. Not PHP/Apache instances. Servers. They’re virtual, but let’s be honest, so is the server this site is running on. That means I can mess with the server, install extra features if I need to test a clash with PHP version or add ons or whatever, I can do so without blowing up my laptop (or a real server) pretty quickly. That means my plugins test site (on a live server) may not be needed anymore, which led me to the first actual thing I had to do with Vagrant: Make my own sites.

    My own sites!

    You get five ‘default’ sites when you use VVV:

    That’s four, I know. The fifth is “vvv.dev” which lists the other four sites. That’s pretty much what most of us need when testing. A local site, one on trunk, one using src, and one with grunt for those CSS/JS things.

    I needed more:

    Those all run stable. I though about naming them wordpress-something, but I needed the subdomains and it was easier to just make multisite.dev for that. I know what it is, and this is for me first. The way you do this is with Auto Site Setups, where Vagrant looks in your www folder and if it finds more folders with the right files, will build sites! Natually that means I made a little Github repo for this called VVV ASS. Because you’ve met me before, right?

    What do you do with it?

    Test all the things, really. Bang on plugins and code that isn’t right, make patches, and have a generally clean environment to play with. It’s also good for building on (core or plugins or themes).

    I’ve been struggling with PHP Unit Tests, as well. I understand them, but I don’t really grok them yet. While I dig the idea of unit tests, creating them is a little complicated to me. Suffice to say, I know WordPress on push day wants to unit test all the things, so I should get used to this.

    1. In terminal, navigate to your clone of the VVV repo.
    2. Run vagrant ssh to connect to the virtual machine.
    3. Run cd /srv/www/wordpress-develop and go into the folder.
    4. Run phpunit

    And there you go. What did all that do? A lot. Check out the Core Handbook on Automated Testing. Beyond that, I cannot tell you. Yet. Expect more on that later when I’ve gotten someone to explain it better.

    Do I have to use VVV?

    Nope! There’s VIP Quickstart, by Automattic (yes, that Automattic) which lets you bring up a WordPress.com-esque site. And there’s WP Vagrant which gives you more testing environments, so when you want to blow up core on PHP 5.2, you can do it easy as another vagrant up.

    Am I sold?

    Developer Ipstenu is sold. User Ipstenu still likes MAMP best. “Yes, I’ll fix your site” Ipstenu likes DesktopServer. Each has their own place. I’m so comfortable in CLI now, it’s more natural to use MAMP and VVV. DesktopServer comes in to play for me when I need to spin up a site specifically to test an existing site someone else broke.

  • Easier Control

    Easier Control

    In a WordCamp I heard a developer say something along these lines:

    “I include my own jQuery because it’s easier and I can control things.”

    The moment he said this, I clamped my mouth shut and bit my tongue. It was not the subject of this presentation, and multiple other people in the room had already pointed out that WordPress has it’s own version. Afterwards, someone remarked she saw steam coming out my ears. All I said in the room was “We reject themes and plugins from the .org repositories for including their own copies of jQuery.” and then shut up. After all, I was in the room because I wanted to learn about something I didn’t know, and that wasn’t jQuery.

    Control KnobsIt’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’

    You may think that if you force install your own jQuery, you can be sure a random upgrade of WordPress won’t break your theme. You have full control over the theme, after all. And you may think that you can make your theme or plugin faster if you compress all the JS together yourself, rather than having WordPress load a dozen separate files. Those thoughts are both true, but you’re wrong. You’re never ‘master of everything’ unless you only use WordPress core and the themes and plugins that you built. And even then, you’re still not.

    While it’s perceived as easier and faster to write code if you assume you know the truths of your website and will always be it’s master, the fact is the assumption is plain ignorant. These days, it’s rare you’re ever the sole developer of a site. You may be hired to make a theme, I’m hired to make a plugin, and someone else is titularly in charge of both of us, but probably doesn’t know a lick of code while still being the driving force behind the website. Not to mention we’re not the webmasters of the site. That may be some intern nephew of the boss, who will take over once we’re done.

    And that is exactly where using our own versions of scripts will get us into trouble.

    You’re master of your plugin, or your theme, but you’re not master of the rest of the world. Even if you’re making it on spec for someone for a specific purpose to be used on a specific site, there’s no guarantee that it’s the only time and place your code will ever be used. There’s no assurance that then 10 other plugins you tested with today will never upgrade, or that they won’t add more. If you get hit by a bus tomorrow, there’s no promise your code will remain untouched. Basically we’re running on pure arrogance that not only are we crystal clear about the present, but we’re totally perfect about knowing the future. And that just ain’t possible.

    old men hitting each otherSo. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?

    “Picture this. Your theme has jQuery 2.0. So it de-enqueues WPs and re-enqueues yours. My plugin is using version 1.7. I do the same thing. Bob’s plugin uses 1.11, HE does the same thing. Joanne over there properly uses WP’s. Which one of our jQuery files wins?”

    The problem is that you’re emphasizing short term gains (speed of development, speed of site) over long term sustainability (regression conflicts, duplicate files). You’re making your life a little easier, and actually harming the website you’re trying to make because tomorrow, you will be gone and they’ll be trying to figure out why the site is so slow. Or why it’s breaking when they upgrade Jetpack. After all, you tested with Jetpack, right? You were selfish, short sighted, and just … wrong.

    But it’s okay. You can learn to do things better. You can do it right with your code and fix those mistakes. You can let the wookie win, and let WP control what it’s supposed to control, while only augmenting what you must control. And you can do it all in a friendly, sustainable, updatable, extendable way. Which is how WP wants it.

    Should I use my own jquery flowchart?

    Oh and how to I handle minification? I have a proxy service do it for me. In my case, Google’s mod_Pagespeed compresses and combines all my JS and CSS to make it one file that loads faster.

  • Resilient Responses in Reviews

    Resilient Responses in Reviews

    I review a lot of code. A lot.

    ALOTOn average, I look at around 100 plugins and themes (combined) per day. If I’m not reviewing code for the WPORG plugin repository, I’m debugging sites for customers, writing my own code to make it better, testing patches for WordPress, and pretty much dancing the dance a lot. I like this sort of thing a lot, since I get to see all sorts of different methods to madness, and it improves my abilities to see people doing it right and wrong.

    That said, I’m not the best coder in the universe. I don’t claim to be, I don’t plan to be, and I don’t worry that I’m not. We all have our skills and mine is not to be a psycho awesome super coder. Mine is debugging, breaking, helping people debug and break, and writing. We call that support, generally, and it’s a noble profession! But more on that another day. The fact is I don’t know all the code in WordPress. I’m guilty of doing_it_wrong() often enough. And yet, I don’t see my ignorance to be a detriment to what I do.

    In an article “Probability and Possibilities”, my father talks about how we react to natural disasters, and how that impacts how we predict them, and their costs. Near the end, he talks about being prepared by having resilient responses, and lists the following traits of those people/groups:

    1. Drawing on experience
    2. Questioning that experience
    3. Intuition
    4. Improvisation, or making the most of materials at hand
    5. Listening and speaking
    6. Examining preconceptions
    7. Ignorance + knowledge = wisdom
    8. Recognizing and taking advantage of luck

    Alot of BugsI didn’t realize it at the time, but my dad raised me to be resilient, because those eight traits are ones I apply constantly to my code reviews. It’s because of those that I’m able to do all those plugin reviews, even when I don’t know all the right moves. As a senator once said, I know it when I see it.

    Many times, I’ll review a plugin and flag it saying “This is not secure” or “This is not done properly” and sometimes I’ll take a moment to explain exactly why, but given the sheer volume of reviews I need to get through to keep up my end of the review process I will often use some standard ‘predefined’ replies. I don’t review all plugins, nor do I reply to all the emails, though sometimes I know it looks like I do. Still, if one person has to review 25 plugins a day, and craft a reply for half of them (yes, about half the plugins we get need some sort of reply that isn’t ‘approved!’), how am I, a non-uber coder, capable of actually knowing that the code is wrong?

    I’m going to tell you the biggest secret of support ever. You ready?

    You don’t have to know how to fix what’s wrong to know that it is, in fact, wrong.

    That’s it. Not knowing how to fix things was, I admit, one of the leading causes as to the impostor syndrome feelings I had when writing my WordPress Plugin Support ebook. But the thing was, I knew that the code was right or wrong most of the time. Oh, sure, I make a couple mistakes, but if I see someone calling wp-load.php directly in their code, I’ll tell them it’s not permitted and then they get a canned reply as to why, with some general suggestions.

    I stopped worrying about not being able to help someone debug their own plugin for a couple reasons, though. It’s (generally) not my job to help you write your own code. If you have a jquery conflict or need help calling WP functions outside of WP (please don’t), I can help you with a search or suggestions where to ask, but just because I don’t know the answer doesn’t make my telling you that you’re not permitted to do something in the WPORG repository invalid.

    Ah, there’s the crux isn’t it? Someone was doing code in a totally janky way. It happens. Most of the time, we end up doing this by accident, not knowing there’s already a WP function or action to use for it. We reinvent the wheel by accident. Let’s pretend this guy was using his own copy of jQuery. Now, as we all know, you don’t need to do that! WordPress comes with jQuery and you can just enqueue it. So there’s a canned email we send, explaining you can’t include your own, nor can you call it remotely, please use ours.

    The reply comes back “My code won’t work without my own.”

    So I reply to the effect of “Please correct your code to work with our version of jQuery. The most common cause of these conflicts is not writing your code to work in no-conflict mode.” And then there was a series of links.

    He replied, “Why don’t you just tell me what I did wrong?”

    Alot of PatchesI explained I would if I could. But I don’t know his code, I’m not awesome at jQuery, I don’t care to reverse engineer everything to figure out exactly what’s broken, and it’s not my plugin anyway. So … no. I don’t know how to fix it, but I do know that, having listened to a lot of smart people and having read a lot of code, that the primary cause is an issue with no-conflict mode. So I can Google that and get wp_enqueue_script() – jQuery noConflict Wrappers as a hit (this is the WordPress Codex) and read that this happens if you use the $ shortcut, so I take a second look at his code, determine this is the case (though perhaps not the cause of all issues), and reply back with that info and a link. I’m helpful.

    He doesn’t agree. “If you know so much, you should fix it.”

    No, sorry. This time I explain I don’t know much more than that as I’m not great with JS yet, and now I expect to get smarmy commentary on how, if I don’t know how to fix it, I don’t have the right to tell him it’s wrong. After all, I’ve heard that a hundred times before. Instead, this guy says “Yeah, I don’t know either, so who am I to judge? Okay, any suggestions where to ask for help?” After picking my jaw off the floor, I sent him to wp-hackers and stack-exchange, after doing a quick search to see what other direct links might help, including one on SE that looked like the absolute answer. He came back, said the SE answer was it, and everyone was happy!

    I solved the issue by being resilient, and giving the ultimate support. Also now the guy has the tools to do it himself next time.