Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: mailbag

  • Mailbag: When Do I Use “If Exists”?

    Mailbag: When Do I Use “If Exists”?

    Someone pinged me on slack about this. Bear in mind, I tell people “If you got an email from plugins, please press reply and email back, don’t slack me.” because it allows me to keep track of the whole history of a conversation, but also because if I’m sick, someone else can reply to you and you’ll wait less. While, in this case, the answer should have been very short, it grew to be a lot longer than he’d expected because he didn’t quite understand what I meant.

    Unique Prefixes

    One of the requirements of the Plugin Directory is that all plugins have unique function names, defines, and classnames. This is for a pretty obvious reason: it will prevent your plugin from conflicting with other plugins or themes.

    • For plugins, use a function or classname that matches the plugin name: class ThisPluginName{} or function ThisPluginName_FUNCTION()
    • For specific specific sites, use a function class for the domain: class HalfElfOrg{} or class HELF{} or function helf_FUNCTION

    This extends to all things, including defines, namespaces, enqueue’d handles, and on and on. As I tell people, “A namespace or class of MyPlugin is not actually all that unique…” Defines are extra tricky since sometimes you want to define them and allow them to be replaced. But more on that in a minute. No matter what, this is bad: define( 'PLUGIN_PATH', plugins_url( __FILE__ ) );

    Since it’s 2016, I have to tell people that they shouldn’t use two letter slugs anymore as all the good ones are taken. I also tell them not to use wp_ or __ as a prefix.

    And then I say this:

    If those are intended to be in shared libraries, please detect IF the code is already included and not re-include it, as doing so will cause conflicts if two people call the same defines and functions.

    Yeah. It’s messy.

    If Define Exists…

    This is used a lot. Let’s say you know you need the plugin basename (the folder name) in multiple sub folders of you plugin, and it’s a pain in the ass to do plugins_urls( 'foo.css' , dirname( dirname( __FILE__ )) ); to go up two folders. That’s a case where a global define starts to make sense and it’s a case where rarely would you want to bother checking if it exists.

    The code is just this: define( 'MY_PLUGIN_BASENAME', plugin_basename( __FILE__ ) );

    But what if you want to have a default value for an API Key and allow people to override it? Then you can one of these:

    // Option 1:
    if ( ! defined( 'MY_PLUGIN_APIKEY' ) )
        define( 'MY_PLUGIN_APIKEY', 'default key value' );
    
    // Option 2:
    defined('MY_PLUGIN_APIKEY') or define('MY_PLUGIN_APIKEY', 'default key value' );
    

    What those do is check “Does the define already exist?” for you.

    Now keep in mind, I wouldn’t do that. I’d do this:

    $apikey = ( defined('MY_PLUGIN_APIKEY') ) ? MY_PLUGIN_APIKEY : 'default key value' ;

    The best example of this in core WP is how WP_DEBUG is handled. If you delete that from your wp-config.php file, it doesn’t turn on debugging. The code checks for the existence and if it’s not there, it assumes no. For the most part, if you name your defines properly, there’s no need to allow them to be overwritten because you’re not defining them in advance. But in case you do, this code is a wise idea.

    If Function (or Class) Exists …

    Lately I’ve seen a lot of people do this:

    if ( ! function_exists( 'my_awesome_function' ) ) {
    	function my_awesome_function() {
    		//function stuff
    	}
    }
    

    Okay look. This sounds like a great idea until you realize the fatal flaw. What happens when (not if, when) someone else has a function with the same name and their plugin or theme loads first?

    As Lilu Dallas would say “Big badda boom.”

    This is a terrible idea unless we’re talking about shared libraries.

    Use if-checks With Shared Libraries

    That’s my answer here folks. The only time you should be checking if-exists is WHEN you are using a shared library. If your plugin includes a common PHP library, check for it before you include it.

    It’s a little different with Javascript and CSS though. Let’s say you’ve got Bootstrap. This is a commonly used library. A lot of plugins and themes have it, and you’re a good person. You want to make sure you only load it one time no matter how many people include it in their plugins and themes. In this moment, you have to do something paradoxically brilliant.

    Don’t use a unique name for your enqueues.

    function mypluginname_resources() {
        wp_enqueue_style( 'bootstrap', plugins_url( 'css/bootstrap.min.css', __FILE__ ), array(), VERSION );
        wp_enqueue_script( 'bootstrap', plugins_url( 'css/js', __FILE__ ), array(), VERSION );
    }
    add_action('wp_enqueue_scripts', 'mypluginname_resources');
    

    The magic here is specific to how WordPress handles enqueues. It knows “There’s already something enqueued as bootstrap! I don’t need this!” and you’ve sped up sites. Of course there’s a risk here when someone might have an older version loaded first. As far as I know, the enqueue system isn’t clever enough to detect what version is included, and use the newest one (I wish it was), so you may have to do some convoluted checks. Also making this worse is that people don’t name things properly. I’ve see people using bootstrap-js and bootstrap-css for the enqueue names, which is totally unnecessary. WordPress will handle that for you.

    Remember: When in doubt, if coding for WordPress do it the WordPress way.

  • Not Mailbag: Where Contact Forms Fail

    Not Mailbag: Where Contact Forms Fail

    My friend Andy, reading last Friday’s post, remarked no one should have to put up with crap like that. He’s right, and I mentioned that most contact forms don’t allow you to filter via your WordPress blacklists or comment moderation settings.

    Surprised?

    You should be.

    Back in March 2014, I raised this with Jetpack, saying that the Feedback ignores Blacklists.

    You have a moderation list and a blacklist.

    You have a user you want to block from commenting forever. You add them to the blacklist. Surprise! They can still use the feedback form!

    This should behave just like the blacklist on comments: It blackholes them. Done and gone. After all, you didn’t want them around.

    Logically I can see why it doesn’t use the comment checks. If you have a check to only let users who have an approved comment, leave more comments freely, this would be a problem. There’s no ‘pending’ value for feedback.

    And the first reply … Well it made me mad back then. I say this as someone who is good friends with the fellow who commented, but back in 2014, I wanted to smack the back of his head.

    This would be super easy to get around, just changed the alleged from email address. Besides, blacklist tends to be things that shouldn’t be displayed publicly automatically, allowing contacts would let them appeal the blacklist.

    I could see grounds for adding a filter to have grunion follow the commenting blacklist though. Less sold on an admin option.

    Now go back and read last week’s post. I have not blacklisted the rather vile word used in that comment because I have a friend who is dyslexic and often says ‘cuntry’ instead of ‘country.’ It’s an honest mistake on her part. We added in an autocorrect to her phone and tablet. But blocking short words is hard. Still. The IP address? You bet that hit my blacklist.

    If I still had a comment form, that moron could still harass me.

    As I replied to George:

    Sure, and it’s just as easy to get around the current blacklists in WP. The point is, though, if you’ve put someone’s email on your comment blacklist, the assumption can be made that you have a good reason. You DON’T want this person commenting on your site, so why are you making it easy for them to harass you? And yeah, I used ‘harass’ intentionally.

    Certainly I can and do block their emails on the server, but I still have to go in and clean out the messages in feedback once and a while, and I for one get a lot of pretty vile garbage from people. So having one less place to have to read their BS would be beneficial.

    It’s always been relatively easy to work around if you’re a dedicated troll, but if the blacklist just blackholed their contact messages, it does a lot for your mental health.

    Because he’s right that a dedicated asshole will work around the blacklists. They do it today. Still, I feel there’s no reason to make it easier for them. And while I can block from a server level, not everyone has my skills. And for those people, should we not introduce Akismet level scans on feedback forms?

    You see, the reason I was mad at George back then is his argument felt like he was saying “since it can be worked around, this is a bad idea.”

    That is absolutely not what he meant.

    Even if I didn’t know George well, I have simple proof he didn’t think this was a stupid idea, he thought it was an idea that begat caution. What proof? He didn’t close the issue. In fact, he gave it a milestone to review.

    Now, sadly, it’s been two years with no traction. Every so often someone bumps the milestone, which means it’s among the 600+ tickets that need attention. But it lingers. It’s not a priority.

    Jetpack and Akismet are both owned by the same company. If you have the Akismet plugin installed and activated, and have an active subscription, every form submission will be checked for spam.

    They need to take it to the next level. So do all forms plugins. From what I can tell, Ninja Forms has a field simple spam prevention but no blacklists. Gravity Forms has an old, not-updated, 3rd party plugin for a Gravity Forms Email Blacklist.

    In fact … the only contact form plugin I could find that actually uses WordPress’ built in blacklist would be Takayuki-san’s Contact Form 7.

    Let us protect ourselves from abuse.

  • Mailbag: Life Without Contact

    Mailbag: Life Without Contact

    It’s not a secret I deleted my contact form back in February. It’s been a few months since, and for the most part it’s been the greatest feeling when it comes to writing for this site.

    I do miss the random cool questions people had that would lead to new posts. But that is really it.

    The hate mail is a lovely thing to not get. Oh sure people still leave comments in whatever open post they can to tell me off, but those never see the light of day.

    Let me just share with you the common sort of hate mail I get. Please note, this is word-for-word what was said. The only part I redacted was exactly what I’d done (and to whom) to deserve this.

    You are a real piece of shit. Someone came to you with respect and in good faith to ask you but a simple request […] and you chose to fucking lecture them?

    Congrats at showing what an insipid androgynous cunt you are.
    You’ve now lost another user

    Yeah. Someone thought that was okay to talk like that. Wanna know what brought it on? I was explaining to someone that we do not have the technical capability of deleting forum accounts on WordPress.org, and we’re probably not bound by any UN statutes seeing as everything you post on .org is of your own volition. The tl;dr is “If you don’t want things to be in public, don’t post them in public.”

    This guy hid his email … or so he thought. I’m aware of who it is. So are the other forum mods, so if he comes back and acts up on .org, we’re prepared. Following people home and treating them like that is not welcome in any community I’d want to be a part of.

    So deleting the comment form? Smartest thing I’ve done in years.

  • Mailbag: No More Contact

    Mailbag: No More Contact

    On Monday the 8th I deleted my contact form from this site and my personal one.

    That means this may be the end of the mailbag.

    Why did it happen? Well, looking back on the last 7 months of messages I got, I can group them as follows:

    • Requests that were meant for plugins@wordpress.org
    • Password reset requests for the forums
    • Requests to delete forum posts (we don’t do that by the way)
    • Requests to be hired (even though the page said no)
    • Solicitations to write for people for ‘exposure’
    • Questions people should have asked in the forums
    • A ‘quick’ question that’s an essay
    • Complains that I suck
    • Complaints that I blocked someone on Twitter/Facebook
    • Spam

    The legitimate messages that were interesting and thought provoking were few and far between. If I got 4 a month, then it was less than 10% of what my inbox was seeing. And worse, blocking someone via the comment blacklist didn’t stop them from submitting a contact.

    After someone informed me, via the contact form, that a post I commented on in the WordPress forums over a year ago was out of date, I said enough was enough, and removed it.

    How do you contact me?

    Why do you need to?

    Look, my family and close friends already have my email. Anyone from WordPress who absolutely has to get a hold of me knows how to (they can view my email in my forum profile after all). And the random masses of humanity who just want to ask me something for a quick fix?

    You really don’t need to contact me. At all. You just want to because you think it’s faster and cheaper. I value my time more than that these days. I simply cannot spend my time helping everyone. Not with everything else on my plate for WordPress and for work and for life.

    Of course if you post in the plugin forums for my plugins I’ll help (maybe not as fast as people might like, but hey, you’re getting free help). Of course if it’s work related I’ll be there.

    But I’m not for hire. I’m not here for a ‘quick’ email (which by the way, most of you send me essays). And I’m definitely not here for your abuse.

  • Mailbag: Assumptions are the Mother of All Screw Ups

    Mailbag: Assumptions are the Mother of All Screw Ups

    I get a lot of plugin related emails like this:

    Did the rules change?

    Or this:

    You’re not being fair, you let X get away with it.

    Or this:

    They’re liars and you should be ashamed.

    The problem all these people have is they only see one small portion of the world they’re dipping their toe in.

    First of all, if you have a problem with WordPress.org hosted plugins or the repository in general or you think rules are being enforced unfairly or your plugin was closed, you email plugins@wordpress.org and not me directly.

    The plugin team is a team — a group of people who work on the plugins. While you may only be talking to one ‘face’ of the team, when you take conversations offline, you rob us of the ability to track the status of your plugin. Also you prevent us from being able to use the experience to train up new team members.

    So yeah, I get pretty firm about this one. Use the right channel for the right complaint. If someone comes by and tells you “Actually you want to talk about that here with the right people” and you decide not to, well you’re a fool.

    Back to the case at hand. Those three emails had to do with pretty mundane situations.

    The first two were about being busted for a guideline violation. The last was about a review.

    Did the rules change?

    This developer was using a trademark in his domain, which is not permitted, and he was told to fix it. The rules have always been that this is disallowed, but sometimes people (hi) miss things.

    You’re not being fair, you let X get away with it.

    This happened when the developer was closed for using powered-by links. He complained that six other developers were doing it. I replied thanking him, closed the other six, and told him he still needed to fix his plugin.

    They’re liars and you should be ashamed.

    A contentious review-that-should-have-been-a-support-post happened. Then the user came back, apologized, and said he was wrong. After that, the developer replied complaining that the user should have opened a ticket. This began a little snippy argument between user and developer, ending with the user repeating that he already had apologized and would delete his post if he could. The developer became irate when I wouldn’t delete the post (the user can change his review after all) and deleted his plugin.

    Assumptions Should be Checked

    Each person came to the table knowing their small world. I come knowing that there are 42,700 active plugins and over 56k total. I close and open tens of plugins a day. I review more. I see code that makes me sigh and some that makes me celebrate. I also am human and make mistakes. Things slip by reviews, we miss a trademark here and there, and we may not catch everyone doing it wrong.

    But the one thing we never are is malicious.

    We never hunt down one user and punish them because we hate them. Ever. If we have an argument that seems impolite, we hand off the conversation to someone else. We assume good faith from the developers, but we know communication is hard. We know two people may not speak on the same page sometimes. We know that miscommunication happens. The problems all stem from our assumptions. They assumed we were picking on them, singling them out, and punishing them. We assumed they’d understand we’re just enforcing guidelines.

    About the only time we allow ourselves to be mad at people is when we’ve told them “Don’t do this” and they do it anyway. And really this only actually happens if we say “Don’t resubmit, please email us” and they just ignore that message and resubmit. It’s a following directions thing. Trust me, everyone hates you when you don’t follow directions, even if it all works out okay, you’re still acting entitled. If you don’t understand the directions, just ask for clarification.

    English is imperfect. It’s confusing. It’s downright weird. It’s contradictory. On top of that, humans are weird and imperfect and contradictory.

    Assume good faith.

  • Mailbag: The Trouble of Rollbacks

    Mailbag: The Trouble of Rollbacks

    Anonymous asks:

    Why doesn’t WordPress let me rollback a plugin?

    Answer: Because the education of developers as to how to properly tag and number releases hasn’t hit critical mass.

    Other answer: Because no one’s paid me enough yet to sit and manage every single WordPress plugin release to ensure the developers are properly using tags.

    Other answer: No one’s written the code to enforce proper tagging for plugins.

    Look. Let’s step back. Why does rolling back WordPress work? I’m going to assume you disabled auto-updates for a moment. They work becuase WordPress understands semantic versioning.

    • 4.4 is a major release.
    • 4.4.1 is a minor release (bug and security fixes)

    Now go look at your plugins. Look at their versions. Let me show you what I, a plugin reviewer, sees:

    • 20151205-295323 is a major release
    • 3.2.3.1 is a minor release
    • 4.2.1 is a major release
    • 14.4 is a critical bug fix
    • 738741 is a minor release

    It goes on and on.

    But even if we fix that, we have to trust that people will remember to actually use the SVN tags folder. They don’t. Trust me, about half the time I contact a plugin developer about a problem, I have to ask them to please use SVN properly.

    The trunk folder is for the ‘latest’ version of your plugin. This may be a beta, and it may be the same as your stable release. Either way, trunk should be a working version.

    The tags folders are for your releases. Finished up version 1.3.4? Great! Update the plugin readme and the main file to have the new stable version and run svn cp trunk tags/1.3.4 to copy it over. Done. But no, they don’t do that.

    This is the ‘fault’ of open source and freedom, of course. We let plugin developers do what they want, a lot more than themes, and with that freedom comes risks and responsibilities. Different people rise to those responsibilities differently. Most of us stumble along, make mistakes, figure out what best practice works for us, and move on.

    Should WordPress enforce proper behavior? I gotta tell you, I don’t think it would be sustainable. Not without a much smaller repository and not without some sort of signed contract with developers to agree to the guidelines. And I don’t think developers would like it.

    I don’t think we’re (yet) at the point where auto-updating plugins is wise. Themes, yes, but I don’t think plugins are quite there yet. Maybe we’ll get there, but there are so many hurdles before us it’ll be a while yet.