Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Plugins: Double the Damage

    Plugins: Double the Damage

    Sit down for a fun ride in what I can only call … The plugin equivalent of Revenge Porn.

    Player 1 forked a plugin from Player 2. Player 2 attempted to claim Player 1’s work as his own. Insanity occurs. And if you’re thinking it’s a simple case of he-said/he-said, it’s actually not. They both agree on a number of facts, but disagree on what the facts ‘mean.’ And it is hard to work around that.

    I’ll start by introducing our players (not their real names):

    • Ken – an existing plugin dev who was already on thin ice for submitting the same plugin over and over, due to not reading emails
    • Andrew – a new (to us) dev who possibly stole code

    Before The Drama

    Ken. He’d been a plugin dev for a few years, but he’d always been a problem. Not worthy of an outright ban, but he’d had a number of cautions and warnings.

    Ken’s biggest issue was his own head-in-the-sand arrogance, and a refusal to read. No, I’m serious. He had a history of not reading the emails, even when they were one sentence. This made his reviews take a hog’s age, and it made dealing with him something I had to psych myself up for.

    I was already frustrated enough to leave a note in his user account about it. Ken would read subject lines only, if at all. It was maddening and he was on his last warning already about communication. To whit, if you cannot (or will not) communicate with people, why are you here?

    Submission Wars

    On Monday, doing the usual weekend clear-out, I started like always. See, I preferred to start with low-hanging fruit. I would reject the outright bad or incorrect submissions (like people submitting Akismet) and pend trademark issues. This is, if you’re wondering, why I ended up writing so many blockers for submissions. It took that morning ‘easy’ work from 2 hours to under 1! Doing that work takes little brain power, though it was always time consuming, and let me ease into the day.

    That day, I ran into Andrew who had a trademark issue out of the gate. The name of his plugin started with ‘WoCommerce’. Yes, one O. Around then was when I’d just introduced the blocker on starting with ‘WooCommerce,’ and for the life of me, I don’t know why people see that they cannot use a trademark and decide it’s smart to ‘tweak’ the trademark.

    Note: For the love of the flying spaghetti monster, DO NOT try to ‘get around’ a trademark issue with a clever spelling. The legal concept you’re violating is ‘intent to infringe’ and I have to tell you, Facebook has zero tolerance for that.

    Back to the plot, I emailed Andrew and explained the plugin was pended due to trademarks. Also it’s Woo with two O’s.

    Imagine my surprise on Tuesday when I saw the same plugin submitted with the same name typos and now a ‘Free’ at the end (because the original name was used). Now usually this happens when someone doesn’t fully read the email that says to reply with your code attached. Sometimes it’s two people with the same idea and, since we blocked multiple submissions, it’s often someone using two separate accounts to resubmit. Giving this new one the benefit of the doubt, I checked and saw it was an existing dev, Ken!

    I downloaded this new plugin and then Andrew’s and compared. Guess what? Same code. The readmes, mostly, were different, but not in a good way. Ken’s was a half-edited version of Andrew’s, and Ken’s plugin headers also credited Andrew.

    This means, whoops, Ken submitted a copy. That gets Ken’s rejected and Ken is told that either he stole this (bad) or he’s working with Andrew and resubmitted instead of following directions (also bad).

    Meanwhile, I also emailed Andrew asking “Are you working with someone else and did you goof the reply?” Andrew replies promptly, with the new code, explaining a very odd story.

    Andrew said that Ken will claim Andrew stole Ken’s plugin. He named Ken! I was stunned and kept reading. According to Andrew, he made a more complex plugin and had offered it as a patch, but Ken said no. Then Ken stole it back from him since, per Andrew, Andrew’s code was cooler. Furthermore, Andrew said Ken was likely to claim Andrew stole it from him (Ken) who sold the plugin, but not with Andrew’s features.

    So this is already a bit of a mess as you can see. And no, Ken didn’t take it well, already ranting that we rejected his plugin.

    Who Stole First?

    My first thought had been that Ken was 100% wrong, and Ken had taken Andrew’s code. Now it looked like Andrew forked Ken’s plugin and Ken wanted to steal it back. Who is right in this situation?

    I did my due diligence and confirmed Ken was selling a plugin that claimed to do the same thing. It was over $100 USD mind you, and that’s a lot for a 3 file plugin (including the readme). I was surprised that Ken’s version was riddled with security flaws not all found in Andrew’s version (no sanitization, no escaping, no nonces, trademark abuse, broken translations, etc etc). No one was going to pay $100+ for that! Also why would he not take Andrew’s fixes?

    Since Ken had emailed claiming it was his work and I was wrong, I replied and pointed out his plugin submission was copying much of Andrew’s work. This means even if the core plugin was his, he would have had to credit Andrew. Oh and could we please see the original, premium, plugin to see what Andrew ripped in order to address that part.

    But looking at Ken’s bleak history, I realized this was going to be a big problem. Ken jumped right into the blame game and name calling, as I feared.

    After a gut check with others and confirming it sure looked like Ken made a spite submission, I was leaning towards a ban. He was already replying in anger and now he was shouting that Andrew stole from him, but he refused to share the premium plugin lest I steal it. While I’ve received hundreds of premium plugins to do an ownership/copying check on, I have never kept them without buying them. Once or twice I found a plugin I’d pay for, and I did. But the rest I deleted them as soon as I can. Ken’s claim was we would take his code and host in on .org for free. Which… no.

    Ken actually confirmed he did take Andrew’s ‘version’ of the code, but refused to credit because Andrew forked his code, and he didn’t have to credit since his was the original plugin. And anyway, Ken said he did it in order to hurt Andrew. This made it clear. He had made a SPITE submission.

    In Ken’s email about being banned I said this:

    After you submitted [plugin], which was clearly at least partly someone else’s work, we did some research on how you came to take that code and misrepresent it as your own. In doing so, we have determined that your actions were of an intentionally abusive nature. This behavior of yours is unwelcome here in our community.

    Me in an email to Ken.

    Andrew was given the benefit of the doubt as I tried to figure out if he really forked or not (remember I had not seen Ken’s original plugin yet!), but he too was flagged for possible naughty behaviour. The odds were he had a disallowed fork, and he was cautioned that if the plugin was a premium one, we couldn’t host it on .Org.

    At this point, here’s where we are:

    • Ken charged over $100 for a piece of shit code.
    • Andrew (may have?) forked it because it’s shit and submitted it after Ken said he didn’t want it.
    • Ken submitted the same code as Andrew’s version.

    Since Ken’s been a known bad-egg, was is now intentionally acting badly, and already started to rant, it was a no-brainer. Ken was a problem, Ken was acting hatefully and spitefully, and Ken had a bit of conspiracy paranoia going on.

    What Did I Expect?

    I did not expect over 40 emails over a week, ranting. Most made it pretty clear Ken only read the subject lines of the emails, and never the content.

    First Ken claimed it was originally his, even though the version Ken submitted literally credited the other guy. Then Ken claimed he just copied the readme, but again, the code credited Andrew. It had the same formatting to boot. You can see where this is going right?

    Next, Ken claimed he ‘accidentally’ uploaded the nulled version Andrew had posted to the web prior to uploading on .org … except Ken’s version has his partly rewritten readme. That is pretty weird. How does one upload a partly ‘corrected’ nulled version? The obvious answer is that he realized (as had I) that Andrew’s code was better than his and stole some of it! Actually a lot of it.

    Ken’s argument became “I am releasing the basic version as a Albert is stealing my code!” And if you just went “Who the flying fuck is Albert?” so did I. Five emails from Ken came in, including claims we ‘stole’ his plugin.

    Yes. The Plugins Team stole his plugin. How you ask? Well it transpired that Ken believed the plugins team, by accepting the submission from Andrew, had commited theft, even though we had not approved the plugin. It was in pending, at this point.

    I suppose you could maybe argue someone attempted to use WordPress.org as a fence for stolen goods, or a money launderer. But since the Plugins team did not accept the goods, we stole nothing.

    Where Are the Clowns?

    At this point, Ken kept linking to his code (still too much money) and saying I should look at his code (not going to pay for it). Ken also said he’d sue if we didn’t reply to his emails (there were like 10 separate emails from the last time I’d replied, I was trying to catch up). He also claimed he wrote the plugin with two other guys, one of which was Albert! Our mystery guy!

    Officially once you say the magic words invoking legal action, the Plugin team stops talking to you, save to point out we aren’t qualified for legal stuff and here’s the foundation’s contact. Keep in mind, Ken’s emails were minutes apart, so no one had a chance to reply even if we wanted to.

    Naturally Ken went on to claim we were “in cahoots” with with Andrew and he would handle it from his legal team. Then he demanded we do the “right thing” and reinstate his account and host his code. Also he claimed Andrew was a scam artist who was harassing Ken. (Remember this, it comes back to haunt Ken.)

    I said ‘no’ because it was damn clear Ken was operating in bad faith, not to mention he had a history and had been on a final warning at the start. This prompted Ken to claim he wasn’t warned, except he was. Not only was he warned, the read-receipts in HelpScout showed he’d opened the email! When that was pointed out, Ken said he’d not read the email, as he’d been asleep.

    I found the hypocrisy of not reading emails while being pissed I was reading all before replying to be amusing.

    Either way, though, he was up and reading things now, and yet still hadn’t read the other email. This goes back to longstanding issues with him not reading. But hey, Ken claims he did read the chat logs and knows exactly who Andrew is (or Albert).

    Ken went on. Andrew was harassing him, stole from him, was a racist, tried to hack his site and so on. Also WordPress.org would be enabling him and we needed to stop hosting his code.

    I had not approved Andrew’s plugin and pointed that out. We didn’t host it. And when a plugin is rejected, the zip is deleted so we don’t have it anymore.

    There Is a Point

    All of that said, I absolutely DID take Ken’s claim seriously! Yes, Ken was an angry and vengeful man, but theft isn’t okay! So I pointed out (again) that Ken needed to email the code of his premium plugin to the plugins team. I had zero intention of signing up since I was sure he’d take that information to abuse/harass me.

    Finally he sent the code, and guess what?

    Andrew’s code was not the same.

    The code was not even close, except for one page, which had some of the same security issues as Ken’s plugin (most were fixed), and that means this was what would normally be considered a legitimately different fork. Even if you just compared Andrew’s code to the license-checked-removed code of Ken, there were distinct differences (some worse, some better).

    The problem, however, is that it was a fork of a premium plugin that was non GPL (same as the previous post). WordPress.org couldn’t host it.

    But before we could reply, there were another 10+ emails. Yeah, 10.

    After threatening to sue WordPress, Ken finally broke down and gave us the whole deal from his side. According to Ken, over and over, the real story is as follows:

    • Ken charged $100+ for his plugin.
    • Andrew bought and stole his plugin by putting a nulled version up for download a null software site. He linked to it.
    • Andrew used stolen credit cards to buy the plugin in the first place.
    • Ken did not take anyone’s code.
    • Andrew was a racist.

    The problem with that story is:

    1. The post on the nulled site did not match the timeline. It was made after the plugin submission, which was over the weekend.
    2. Ken’s submission literally said “Yadda Yadda Plugin Written By Andrew LastName”
    3. The code Ken (eventually) shared as his version was totally different save for one page (the settings page).

    Also we had no evidence that Andrew was anything other than a frustrated dev who just wanted the code to work without conflicts (Ken’s really didn’t), and was mad that Ken blew him off.

    Now. I do give people the benefit of the doubt, but that changes once people jump up and want to sue you. Not to mention Ken’s version of events didn’t pass the sniff test.

    Andrew forked Ken’s code, and Ken retailed by stealing Andrew’s.

    I (Don’t) Know The Law!

    At this point, we moved into lawyer stuff. Ken named his lawyer and I looked him up. He was a personal injury lawyer based out of California (Ken claimed to be from somewhere in the midwest). But hey, maybe he side hustles? The lawyer also does corp law counselling, which maybe would have helped Ken, if he had a leg to stand on.

    This prompted Ken to claim a judge would rule in his favour as WordPress.org didn’t follow “details” and didn’t investigate any copyright claims. I knew that was unlikely. A judge would say “They didn’t host the code, they rejected it. They’re not at fault here. They didn’t steal your code.”

    He went on to talk about how he had to read 26 emails (he sent all of them!) and proved his plugin was older (not in doubt at the moment). Ken continued, because the code wasn’t allowed to be forked (GPL), and a judge would certainly agree.

    He was wrong. Since I had rejected Andrew’s code already (because it was a fork of a premium plugin), I was sure we’d been in the clear. We had, in fact, agreed with Ken and did the right thing by rejecting Andrew’s plugin. And yes, I told Ken that.

    Ken replied and shared private information which actually … hurt his argument. In the “evidence” there was a bunch of screenshots of chats where in Ken called Andrew a “stupid [racial-slur] scammer” and a “dumb fucker” which frankly even if Ken’s right about theft, that’s not how you handle things.

    Remember how I said the racism thing would come back? Ken was the racist. He had some more slurs that made me feel a bit ill in his messages to Andrew who, at worst, told Ken he was a dumb bitch. Not nice, but nowhere near the level of Ken’s insults, and none were racist.

    The End Results

    Ken remains banned. He’s got anger issues and doesn’t understand how to play well with people. He has since asked to come back with a new account and was told no. But also:

    We will, at this point CONFIRM with you that we’re not hosting the code submitted by anyone else either, so don’t worry about that.

    We won’t allow anyone to host your code here.

    Plugins team via Email to Ken

    After that he asked to make a third new account and was told no, mostly because he jumped to suing.

    As I mentioned, Andrew’s submission was rejected as it’s a fork of the premium plugin by Ken, and we don’t allow that. Andrew read the email and said nothing in response, which is fine.

    I still have no idea who the hell Albert is.

  • Appreciation

    Appreciation

    I’m not often speechless but today, I was.

    Since I retired from Plugins, it’s been really quiet for me. Which is the way I like it. I still sit on the sidelines, happy to advise and dredge up old history. I covered a couple exceptional cases with developers who were on the verge of being banned (and happily managed to get one on the right track). But the only plugins I reviewed were for work or myself.

    Today, working on some in-depth learning (because we’re always learning), the doorbell rang and a large package was delivered. My wife asked if I ordered a frame for some art we’re thinking about hanging, but I hadn’t. As soon as I opened it, I caught a glimpse of a drawing by Ben Dunkle, which has hung in various places in my office since my very first WordCamp San Francisco.

    I must have repeated “What!?!” a dozen times as we unwrapped it and saw this:

    An "album" that shows a drawing of me with the title "Mika Epstein - A Retrospective" -- Album notes are in the text below.

    Greatest Hits

    • 9 Make Teams Contributed
    • 83 Core Contributions
    • 2,823 Make Posts
    • 29,094 Plugins Approved
    • 57,094 Plugins Reviewed
    • 138,935 Replies Sent

    I know that WP Release leads get things like that after their ordeal is through.

    I was, in no way, expecting anything like this.

    To Matt and all, you are very welcome. And this is appreciated in a way you might never understand, but I am touched from the bottom of my heart.

    I never actually counted how many plugins I reviewed over the years… And that doesn’t even touch on the myriad closures, re-openings, and transfers.

  • Plugins: Bad Thief

    Plugins: Bad Thief

    The summary of this story is: The GPL does not mean WordPress.org has to host whatever code you want it to, regardless of what you think.

    I promise it gets there.

    Starting off bad

    The story of Donald (fake name) begins with a plugin submission he never finished. Back in August 2021, he submitted a plugin with a number of security flaws. And a review to which he never replied. The plugin was rejected in February ’22 and resubmitted in March (one month later).

    Per usual, Plugins flags those and asks the dev “Hey, you gonna reply this time?” because it’s a waste of everyone’s time to review shit they don’t use here. Donald ensured he would, so he got a full, lengthy, review.

    I’ll admit, his reply was pretty unique.

    It was a massive rant which I cannot share (privacy) but here are the key takeaways:

    1. He has been a developer for umpteen years
    2. He copied a plugin to make his own
    3. He thinks he bought the code via WordPress.org
    4. He would not make the security changes we listed
    5. The original plugin had the same flaws
    6. Other plugins have flaws too
    7. He thinks he bought the ‘source code’ (oh no…)
    8. He wants us(?) to fix it

    Oh no…

    A clip of an Alex Norris cartoon where the amorphous blob says “oh no”

    I pinched the bridge of my nose. Anytime someone jumps to the old chestnut claim of “I am a developer of a bajillion years!”, it never ends well. Seriously. If you’re a developer since day one of WordPress, you should know not to break the guidelines.

    I rejected the plugin and clarified a couple things.

    • In no way did Donald buy a plugin from WordPress.org
    • We don’t review every release of every plugin so yes, some have flaws
    • If it’s your plugin, you have to fix it
    • If it’s not your plugin, you can’t host it on .org
    • Removing the copyright and not making any changes isn’t a fork, it’s theft

    That went over about as well as wearing a Yankees hat to a Cleveland baseball game.

    What did he buy?

    People will argue left right and center that it’s not stealing if the code is GPL. The part they always seem to miss is that it’s not their work, and it’s a lie to claim it is (this is why you add copyright, folks!) and when it’s a PREMIUM plugin, like this is, it’s stealing because you broke their license. And yes, he did.

    But Donald was stuck on this weird part that he believed buying a plugin meant he owned it and could do whatever he wanted. Now if it was GPL, technically he could do that, but that doesn’t mean we have to do what he wants. And WordPress.org will not host code that you didn’t write, or at least reasonably fork.

    I purchased the rights to the source code directly from the author.

    Donald via Email

    And he cc’d the original developer, Adam (fake name)!

    I took a look at Adam’s account on .org and found his plugin. It was a free version of the one in question, and yes had security issues. In fact, it had been closed about a year ago.

    Adam replied before I did and said “bro, no you did not.” I backed Adam, explaining what Donald bought was the code to use, and the license on Adam’s website said it could not be resold (remember it was non GPL code).

    Good, we’re done!

    Donald replied with proof. What proof? A bunch of PDFs that (he said) proved he owned it.

    It did not. The attachments showed he bought a yearly license for a number of domains.

    Donald and Adam had a lot of back and forth about how that wasn’t how a license worked (Adam) and insisting he owned it (Donald).

    The next attachment PDF showed he paid for a license (again) and a new one that said it’s a charge and how much (though not what for…). I assume he paid that for the ‘source code’ and I made this face:

    Lucille Ball making an “ewwwww” face

    At this point, Plugins was never CC’d on any reply from Adam (remember Adam’s plugin was closed because of securit), and Donald just kept going.

    It’s Mine!

    It got a little hard to figure out what was what, because Donald would reply-all and Adam wisely only replied to Donald. However since Donald quote-replied, we ended up getting almost everything.

    Donald moved on to explain this was a fork, a term he learned from me, and he could prove it because he used fewer files and it was organized differently. The problem was the code was the same. About 80% or so the same. Not a small amount. And Donald insisted the GPL meant he could do this.

    Again, yes he could, if the original code was bloody GPL to begin with! And it wasn’t. Oh and he didn’t meet the GPL requirement for copyright (GPL says you gotta retain copyright and add yours) nor WordPress’ for disclosure (you gotta credit the OG devs). Thus, Donald failed the sniff test.

    This went on for hours and I didn’t reply.

    Now, if you’re wondering “Why didn’t anyone reply?” it’s because that bevy of emails came in between 4pm and 4am Pacific Time. At this point, though, it was crystal clear that Donald had:

    1. Copied code and did, in the end, make a fork
    2. Copied premium code from a non GPL source
    3. Did not disclose the copying/forking in his readme nor source code
    4. Thinks he bought the rights to the source code (… that’s not what that means, but okay)

    Oh and he was still insisting he bought it from WordPress.

    So I tried again. I repeated the facts (you didn’t buy it from WordPress.org and it doesn’t meet the guidelines to be hosted on WordPress.org as a ‘fork’) and then followed up with banning him since, after 14+ emails overnight, it was obvious the cheese had fallen off Donald’s cracker.

    I did take a moment to recommend he not post the code on GitHub due to the GPL issue, and if he did, Adam might have a legal case. I also told Adam I told Donald that, so Adam had a chance to protect himself.

    Enter Crazypantsland

    This time Donald agreed he didn’t buy it via WordPress.org, however he insisted he’d paid for the code (quoting half the price that was in the pdf I will note).

    Again, you are wrong, I DID NOT take the premium plugin. What I took was the code base of [the version] I purchased provided to me by the author after he received payment. Only [then did I rebrand] and modify […] the code as my own.

    Donald via email (removed identifying information)

    Honestly I sat back.

    His argument was he didn’t take the premium code, he took the code he purchased. I took a deep breath. I mean, maybe he just failed to make that connection? But I (and Adam) had already explained that before so who knows.

    Donald’s email went on to …

    • Agree that I was correct to not host the code
    • Disagree that he’d ever claimed he bought it from WordPress.org
    • Agree that he bought the code from Adam
    • Disagree he should be banned

    To be fair, few people would agree to that last one.

    I tried again to explain how what he did was harmful, and the fastest summary of what he did is this:

    Three panel comic. The first has someone showing off a ball and saying “I made this!” Another person takes the ball and says “you made this?” The next panel just has the second person holding the ball. The last panel has the second person declaring “I made this.”

    Donald put some bells on it, but that’s basically what he did.

    The gist again is “I did not take his code, I bought it and used it.”

    He took something, which in that moment he had the legal right to take! But it’s still taking. If you bought a copy of the Sherlock story “A Study in Scarlet” (which is public domain!) and then re-released it with your name on it and a modern update, it’s not YOUR work anymore. It’s Sherlock the TV series, who bally well credits the source properly. But they don’t call it their original work, they call it an adaptation.

    They credit.

    Donald did not, and would not.

    My Cousin Vinny

    Marissa Tomei aside, Donald explained his legal rep (a family member) had told him he didn’t buy the code the way he thought he did. Donald had bought a license to use the code

    Blessed hallelujah! I thought it was done. Alas, Donald went on to say he was going to clarify that little license matter with Adam (he never did, Adam refused), and then said that since it was legal to take code and reuse it, per GPL, he was good to go, please host his code.

    This is after he agreed we were right about the non-GPL thing.

    I explained, again, that the bottom line is WordPress.org will not host forks of premium code, will never allow non-GPL code, and would not accept forks that don’t credit the OG. Donald hit the trifecta. I recommended he ask his lawyer-family-person about the concept of “fruits from the poisoned tree.”

    Donald went on to make all sorts of entirely wrong legal claims that the GPL allowed this, so WordPress had to let him host the code, and on and on. Then he threatened to sue.

    At that point, I stopped. He got the final reply with the official “you are banned and we won’t read your emails anymore because you clearly do not get it” message.

    The weekend happened and on Monday I found an email saying Donald had complained legally, and they too marvelled that someone would have a lawyer explain they were wrong, only to double down on the wrong.

    I still need to send a sympathy gift to that poor person who had to deal with Donald.

  • Interlude: Gutenberg Moves Fast

    Interlude: Gutenberg Moves Fast

    I’m taking a pause on my plugin posts to talk about Gutenberg.

    I really love Gutenberg. I’m not kidding! I find it far more enjoyable to write (stories) in plain apps (I used Apple Pages because it syncs between laptop and iPad, yes, I am often using my iPad to write my novel, yes, I will let the world know when it’s done). But when I write for the web, it’s a more visual medium, and Gutenberg is fantastic to represent what I’m writing as it will be properly seen by all!

    But.

    Gutenberg moves fast. Hella fast. So fast it can leave you in the dust, and it has a critical flaw that I feel has been stifling it’s growth and usage among developers.

    JS isn’t your Momma’s PHP

    This is obvious. Javascript ain’t PHP. PHP is a simple language that can be coerced into doing complex things if you understand basic algebra. Surprise! Everyone who considers themselves good at PHP? You’ve mastered the concepts of algebra! Alegrba is one of the easier ‘complex’ mathematic concepts to wrap your head areoud. You get “if a + b = c and a = 10 and c = 11 then b = 1” and you win!

    Javascript though, it’s a little more like calculus and trig, in that you have to understand the formulas a little deeper, and they have that thing where not just numbers and letters appear, but weird symbols.

    [nb: Like all analogies, this falls apart at scale, don’t read too much into it.]

    For the thousands of developers who whet their teeth on PHP, jumping into JS feels like you’re a first-year high schooler in senior maths! It’s scary, it’s complicated, and worst of all … it isn’t actually documented at the micro level, because it’s generally compiled.

    Micro vs Macro / Interpreted vs Compiled

    The macro scale is, more or less, the big picture of what your code is supposed to do. Micro would be each individual element. For PHP, you can clearly identify both the macro (the overall function) and the micro (each teeny process in that function). This is less so for JS because the languages are different.

    There are two primary types of code languages. PHP is what we call an interpreted language, because while the PHP binary is a compiled app, what you write is interpreted by the compiler. Basic JS (like jQuery) is also an interpreted language!

    Compiled languages need a “build” step – they need to be manually compiled first. And if that suddenly made you think “Wait, Gutenberg is JS but I have to build it!” then you have spotted the quirk! The JS we use in Gutenberg is actually JSX!

    JSX was designed for React (which is what we use to build in Gutenberg) and while it may contain some plain Javascript, it’s impossible to use the code without React. That’s why we have the build process, it takes the JSX, compiles it into JS, and saves it to a file.

    The Compilation Downfall

    This is where it gets messy … messier.

    When there’s an error in PHP, we get the error message either on the page or in our logs, depending on how we set up our environment. I personally pipe things to debug.log and just keep that file up as I bash on things. Those errors tend to be incredibly helpful!

    $mastodon not defined on /path/to/file.php:123

    In that example, I know “Ooops, I’m calling the variable $mastodon on line 123 of file.php and forgot to declare it!” Either I need an isset() check or (in this case) I brain farted and copied a line but forgot to rename the variable so I was setting $tumblr twice. Mea culpa, pop in, edit, save, done.

    On the other hand, I was testing out some blocks and modernizing them a little when suddenly … the block didn’t load. I got the WP notice of the block had an error. You’ve probably seen this if you’re a dev:

    Example of an error which says "This block has encountered an error and cannot be previewed"

    or this:

    An error: This block contains unexpected or invalid content.

    And if you’re like me, you used foul language and wondered ‘well… now what.’

    Enter the Console

    Unlike PHP, the errors don’t go to a nice debug.log file, it goes to your in-browser console. This is because, again, PHP is being directly interpreted on the server, and the server happily converts the PHP to HTML and Bob’s your uncle.

    JS (and JSX in this case) aren’t processed by the server. They’re processed on the fly in the browser. If you’ve ever wondered why too much JS, or bad JS, cause your browser to hang, that’s why. We moved the processing from the server (PHP) to the browser. On top of that, it’s also why JS content isn’t really cachable by traditional methods! But that’s another story.

    In this case, I got the first error (cannot be previewed) and being somewhat savvy with the world of Gutes, I popped open the console and saw this gem:

    wp.blockEditor.RichText value prop as children type is deprecated

    The rest of the message was warning me that the thingy would be removed in WP 6.3, and it had a link to ‘help’ resolve it. Spoilers? It didn’t. But take a deep breath. Let’s debug.

    Debugging Gutenberg

    The first issue was that the error came on a page with multiple blocks. I happened to be using a custom plugin I wrote that contains about 6 blocks, you see, so I opened a new page on localhost and added each block, one at a time, until I determined the issue was my incredibly simple spoiler block.

    How simple is this block? It’s basically a custom formatted paragraph, so everyone could use the same design without having to remember the exact colours. I could have made it a ‘reusable block’ on the site but, at the time, I wanted the practice.

    Next I went to that link, which was for “Introducing Attributes and Editable Fields“. I admit, I was a little confused, since I was already using attributes and editable fields! But I did the logical thing and searched that page for the word ‘children.’ My thought process was that if something was being deprecated, it would have a warning right?

    Gif from Blazing Saddles, where Dom DeLuise is a director and walks up to an actor who made a mistake. He uses his bullhorn to scream WRONG! at the man, and bops him in the head with the bullhorn.

    Okay, maybe I was looking in the wrong place. This error is specific to RichText so I clicked on the link to read the RichText Reference and again, looked for “children.” Nothing. Zip. Nada. I followed the link for the more in-depth details on GitHub and still nothing.

    At this point, I ranted on Mastodon because I was chapped off. I also popped open the Gutenberg Deprecations page, and looked for “children” but all I could find was a message to use children!

    RichText explicit element format removed. Please use the compatible children format instead.

    Logically there should be a note that “children is deprecated, please use…” but there is not.

    Now, here is where I accidentally stumbled on a fix, but after I made my fix is when I found the Github issue about this!

    If you are still using “children” or “node” sources in the block attribute definition, like so:

    content: {
     	type: 'array',
     	source: 'children',
     	selector: 'p',
     }
    

    Then change it to use the “html” source instead to get rid of the deprecation warning:

    content: {
     	type: 'string',
     	source: 'html',
     	selector: 'p',
     }
    

    And in fact, that was the correct fix.

    Here’s the Flaw

    None of that was properly documented.

    The link to ‘help’ fix the error didn’t mention the specific error, it talked about attributes at the MACRO level. I was (obviously) already using attributes, else I wouldn’t have had that error at all.

    There is no proper documentation that could help someone fix the issue on their own UNLESS they happened to be trawling through all the issues on GitHub.

    As I put it to my buddy, the reasons developers are salty about Gutenberg are:

    1. It changes pretty much every release
    2. There’s no real way to tell people if it impacts you so you have to check every release and read the console logs, which is not what devs are used to
    3. The JS console won’t tell you (I don’t know if it can) what file caused the warning, so finding it is a crap shoot
    4. The documentation is high level, which is not helpful when you get micro level errors

    Okay, can we fix it?

    At this point, if you’ve made a WordPress Block for Gutenberg, make sure you test every single release with the JS console open. If you don’t do this, you will have a rude awakening until things are made a little better.

    How can things be made better? It will have to begin with a culture shift. Traditionally WordPress has used a “release and iterate” model. With Gutenberg, we’ve become “move fast and break things,” but that is only sustainable if everything broken can be documented for a fix.

    That means I see only one way to correct this, and it’s to slow down Gutenberg enough that deprecations AND THEIR CORRECTIONS are properly documented, and the error messages link to a page about deprecations.

    We need to not link to the general “here’s how attributes work” page, but instead to a specific page that lists those deprecations along side the WordPress versions impacted.

    Another matter is we should be posting in the Field Guide about these things. Currently the 6.3 field guide links to all the various pages where you can find information, but that means you have to click and open each one and hopefully find your exact usage. In my case, those links to the ten Gutenberg versions being ported to core never mention the issue I had.

    If we don’t start slowing down and paving the road for developers, we will begin haemorrhaging the very people who make WordPress a success.

  • Plugins: I Hate Security Plugins (mostly)

    Plugins: I Hate Security Plugins (mostly)

    Do not get excited. This is not going to be a name and shame post. No plugin will be named directly, though I bet a number of people will wonder if I meant their plugin.

    So here is your one and only explanation. After reviewing plugins for something between 12 and 15 years, as a pretty much daily process, I have incredibly strong opinions about development, companies, and ideologies. If you, while reading this, think I might mean you … probably not. You folks have no clue how many of the same problems I’ve seen!

    Actually, if you’ve read stories like ArsTechnica on how a plugin was tracking users, you have an idea. But it gets worse.

    With that done, I hate …

    99% of ‘Security’ Plugins

    This includes Jetpack. I know I said I wasn’t going to name and shame, and I’m not. Jetpack is the perfect illustration of the first problem with security plugins, and that is their WAF (web application firewall) requires editing files, and multiple times it’s broken on upgrade.

    I repeat, this is not a shame! The problem isn’t Jetpack is bad or wrong, here. The problem is even within a webhost, you get a dozen different versions of server software! Trust me, your webhost would loooove if all our sites were on the same server, but that isn’t how it works. You acquire servers in batches, so you get batches of ‘like’ and then god knows.

    But. Because of the myriad versions of server setups, it is impossible for Jetpack (or any WAF type plugin) to work perfectly 100% of the time. And this is especially true of upgrades, where servers prioritize different processes.

    Basically, I hate them because they can’t do the one thing for everyone, and I accept that.

    The real thing I hate about security … The things I hate…

    • They aren’t secure
    • They’re the wrong tool for the job
    • They slow your site
    • They think they know everything for everyone

    Safety in Danger

    Not being secure is as galling as you think. I have seen the vast majority of security plugins have the most basic wrong code out there. We’re talking not sanitizing, wrong sanitizing, not using prepare with SQL calls, not escaping, using sanitize functions to escape (and vice versa), and no nonces.

    All that was seen in a plugin I reviewed back in late 2022, and I remember just putting my face in my hands and shouting ‘aaaaarrrrrrgggggghhh’ loud enough to wake my aged cat. And it was not the only one.

    There are very few security plugins that have ever passed an initial review without having to be held back for security. I can only think of one in 2022-23, and they had a unique WordPress.org-only error (stable tags).

    Because of that, I’m probably never going to use anyone’s security plugin. I just cannot trust plugins that, by their nature, are trying to protect, but are not safe. It’s like locking your front door and leaving your patio doors wide open.

    Hammering with a Spoon

    I also have long said that most security plugins are the wrong tool. This directly relates to making your site slow, because you are using WordPress to monitor and secure itself. That’s always gonna be slow, folks. And honestly having your app be the check for itself has the blindingly obvious flaw of … if the site gets hacked, that plugin is gonna be useless in 10 seconds.

    The correct place for a firewall is a separate app on your server (or via DNS). The wall comes outside the town, people! It draws the line between dangers and safe.

    PS I would rename any plugin that’s a WAF to a castle or something beside wall. You’ve built a tiny fortress castle and WordPress is the noble who lives inside. You’re the last line of defence.

    The Need for Speed

    How do security plugins make a site slow? This should be obvious. If a plugin has to run on every single load of your site and check it the person visiting is an evil doer… it slows things down. The more checks, the slower.

    That’s it. Pretty simple.

    This is another reason I think they’re the wrong tool. They’re on WordPress, and run using the same specs that WordPress can. PHP is usually more limited than other commands on a server.

    I Know You Know

    The whole “I know better” schtick was popularized by Steve Jobs. He claimed he knew what customers wanted before they did.

    There was a plugin developer who had a security plugin that thought that. He got into a pissing match with another plugin that is hard to explain without naming names. Now, in this case I don’t feel the need to protect. They took to the forums and outed themselves. Heck, you can see some of the details of this saga on WPTavern.

    Even though there is a little more to the story, it really doesn’t pertain to this. Suffice to say, some of my burnout is directly related to that event, which was years before I retired from plugin reviews. Oh and no, it’s not about a safe-space situation that people seem to think I run in when I tell them I’m not going to continue a conversation. I just don’t feel the need to waste time and energy on someone who refuses to compromise. I feel that if I’m at an impasse and won’t be able to change the other’s mind, I will agree to disagree and stop arguing.

    That event is far from the only time I’ve seen someone decide “I know what is best, and I will force it” in a security plugin. Instead of giving options, or recommended settings, they go out and block what they think is wrong, regardless of the nuances. Sometimes they do it without a way to override, and that just isn’t cool.

    While the goal of perfect security is laudable, the reality is it’s impossible. There will never be a perfect solution for everyone, and if your security plugin doesn’t allow for the nuance of the real world, then I got nothing for you.

    Basically, Don’t

    This probably reads like “don’t bother with a security plugin.”

    There are some reasons you would want to use them. I use a lot of security checks on my sites, within WordPress, but for a specific purpose. See, I use them as tools to interact with services.

    For example, Akismet and spam. I have written bespoke plugins to stop a serial idiot from submitting a form so I don’t have to fire up my terminal and block IPs. I hate IP blocks. They always hurt the innocent.

    And yes, I am using the WAF from Jetpack right now on a large site! Warts and all, it’s been helpful.

    But for me? Having seen what I have with security plugins? They will always be a hard sell.

  • Plugins: When It Changed

    Plugins: When It Changed

    Many people have told me that I should write a book about plugins and name and shame the shitty ones.

    I’m not down with that.

    For the past fifteen years or there abouts, I’ve been reviewing plugins at WordPress.org. In 2015 I took over as the rep. I stepped down entirely in July 2023 for personal reasons that have nothing to do with my passion for WordPress, but is in fact “because” of WordPress.

    In fact, it’s really “because” of plugins. But to be specific, it’s because of developers.

    Book Him, Danno

    I really mean this. It didn’t used to be this bad at all. Sure we had some rough devs, many of whom have left the ecosystem, but overall the level of ashattery was tolerable. You could have an argument and things were kind of okay.

    I distinctly remember when that changed. Like, I can tell you exactly where I was standing, talking to a coworker, when it dawned on me what was happening and that this was probably a turning point.

    It was 2010 and we got the weirdest email from a company (fake name Booker Inc.) who explained their former employee (fake name Liam) had stolen a plugin.

    Stealing a plugin is a weird concept to many when you think of OpenSource. You can’t steal something that is free, and anyway WordPress’ license lets you fork (copy and alter). A lot of people despise me for saying they stole, likely becuase of that. But the reality here is if you take something, created by someone else, put your name on it and proclaim it was 100% your original work … ya done stole.

    An employee stealing from a company though, that was fascinating. I replied asking for some more details and what really was going on. As it transpired, Booker Inc. made a booking plugin that was behind a paywall, primarily built by an employee, Liam, who then was terminated, took the code, and put a copy up on WordPress.org.

    The Investigation

    Naturally the first thing I did was check the logs. Since Booker Inc’s was a paywall’d plugin, I asked for a copy to compare to as well. The logs I wanted to compare to their timeline claim. Liam was fired on X date, and a week later the plugin was submitted.

    That told me that it was extremely likely Booker Inc.’s plugin came first. I downloaded both plugins and ran a diff on them using DeltaWalker. What I saw was a line by line copy, where all copyright and credit was removed.

    The copyright is the reason, by the way, that I use the terms “theft” and “stealing” when I talk about this kind of thing. Copyrights and trademarks are, as I often say, “things with which one does not fuck around.” Copyright and Trademark laws are serious shit, and the GPL even says you need to include copyright! In fact…

    If you have copied code from other programs covered by the same license, copy their copyright notices too. Put all the copyright notices for a file together, right near the top of the file.

    How to Use GNU Licenses for Your Own Software

    Translation? Don’t remove people’s copyright!

    That means in this case, we had copyright infringement (the second plugin had removed the copyright), and a copy of a plugin that was line-to-line identical except the name.

    Oh and it was copied from a plugin … that wasn’t GPL.

    Conclusion Clue(do): Close the plugin.

    The End is the Beginning

    After the second plugin was closed, Liam was emailed something to the gist of “Your plugin is a copy of your old employers, Booker Inc., and you broke copyright. On top of that, the code isn’t GPL, so we can’t host it.”

    That’s pretty reasonable, I thought. It wasn’t until about 10 years later that we sat and formalized all those emails as you see today (mad thanks to Josepha for being my copy editor back in those days!). Back then, 2010? Nah, we were winging it. But the email in this story was serviceable.

    At the same time we did that, I emailed Booker Inc. and said the plugin was closed and we wouldn’t host it because of the GPL thing. Done, dusted, situation over.

    Liam replied that the code was legally his and he had the right to do this and change copyright as the owner.

    And you know what? That might have been the case.

    Above and Beyond

    One thing about plugins that pisses off OpenSource purists is that the guidelines are above and beyond the GPL. Meaning, you have to meet all the requirements and restrictions of the GPL, but you also have follow the WordPress.org guidelines!

    So what guidelines kick in when Booking Inc. reports a plugin is not GPL and Liam says since the plugin was 100% his, and he can re-assign the licence? Is that still theft? Is it violating the GPL requirement (one of the few we cannot give a ‘pass’ on)?

    At the time, the guidelines had a lot more wiggle room. Today, WordPress.org is patently clear that even if the premium plugin is GPL, we will not host it because it hurts the ecosystem. I readily agree that all plugins behind paywalls hurts the ecosystem as well, but taking someone’s work and giving it away (usually claiming it’s yours), is a dick thing to do. You took money out of their pockets and could be wrecking a small business. It’s a balancing act.

    I immediately asked Booking Inc. if they had a contract for the work that clearly spelled out ownership. They did, and agreed to share it with Plugins. It stated the work would be the property of Bookings Inc.

    Next I asked Liam if he had a copy of his contract so we could validate ownership rights. He did, he shared it with us, and lo the contracts matched.

    Now, regardless of my personal feelings on this, it was pretty clear. The contracts spelled out the code would belong to the company. It also actually said that the code wasn’t GPLv2, which I’d never seen in a contract before. The contract also stipulated that Liam would work with a team. They did the UX, he did the PHP.

    So. I emailed Liam back and said I was sorry, but the contract made it clear that he did not have legal ownership, and thus couldn’t change the license. In addition, even if he was the owner, the contract indicated he was not the sole developer, and would have to get permission from everyone who wrote so much as a line of code to change the license.

    Booking dot Hell

    At first, Liam seemed to understand. He didn’t like it, but he understood he’d signed this contract. I told him something I have told many people before, and it’s always get a contract that protects you. If someone hires you for work, get that damn contract to protect you. There’s a story I will share later about a reverse of this situation, but basically that contract exists to clarify who owns the code, who has the rights, and it wasn’t Liam.

    About a week or so later, Liam submits a new plugin. Also booking related. I eyeball it because while that contract implied an NDA existed to restrict Liam on working on booking code, I knew that wouldn’t hold up in court in their country. However, there is a fun legal concept known as “fruit from the poison tree.”

    If a single line of code in that plugin was taken from Booking Inc.’s plugin, the entirety of the new plugin was not permitted. Generally we advise people to not try and submit a similar/related plugin, mostly for that concern, but also because of bad-blood. There was no way on earth that Booking Inc. would be chill.

    As it happened, the code was about 75% the same. It was summarily rejected and Liam was told why. I distinctly remember telling him not to submit another booking plugin, because the wall for him was so high, he’d have to start from zero and not use anything from the original.

    Liam said he was mad, but understood. He said he wouldn’t resubmit a booking plugin.

    Liam Lied

    For the next three weeks, Liam made a new account every other day or so, and resubmitted variations on the plugin. I rejected them all and would email his first address, explaining he needed to stop.

    He didn’t. We ended up banning first his email domains, then his IP, and there was a time he couldn’t even visit .org. I hate doing that kind of ban, because it impacted others, but again, hard choices.

    Then it got weird.

    Someone with another booking plugin emailed plugins freaking out because they got an email, impersonating me, telling them that their plugin was closed! It was a mostly copy pasta of my email. And Liam had spoofed the plugin email address.

    I had the new person check the email headers, and we confirmed it was not official. But then more people with booking plugins contacted us! Worse, those emails had “me” attacking those people! The closest I get in plugin emails to insulting people is when I tell them they made a stupid choice, or they acted like a jerk.

    We fixed the spoofing issue, and that stopped, but it was that second email, the second one impersonating me, that told me this was bad. Real bad. This was changing the game bad.

    Abuse is Now Common

    It’s been 13 years, give or take, and people like Liam went from being a once in a decade occurrence to yearly to weekly, and finally to pretty much daily.

    People hear “no” and decide the correct thing is to be a complete and utter abusive asshole. They believe they have the right to do what they want, and damn everyone else. These days people call it being a “Karen.” Oh and yes, they ask if they can speak to my manager.

    A creepy smiling woman, who is about to break down an annoying customer.
    I AM the Manager (unknown source)

    By May 2023, if a day went by without someone, somewhere, deciding that the plugins team could fuck themselves, I was surprised and relieved. You’d get three in one day, move their emails to the auto-block system, and it would be tense for a couple days because most people made fake accounts to try again.

    And again.

    And again.

    The Toll

    While Liam pissed me off, personally, in retrospect what he did was tell me we needed to clean up the guidelines, organize our rules, and make it more clear that being abusive needed to stop. Impersonation should be an instant permaban.

    WordPress.org didn’t get a community guideline until 2022, and yes, I was one of many people who regularly complained that we needed it a hell of a lot sooner. It became up to each team to sort out how to handle infractions, and what in fact was an infraction.

    Each team has suffered rage quitting and burn out, due in part to the loosey goosey guidelines like that. It feels like you don’t have real support. If we did, that saga I refer to as “my idiot harasser” would have been a lot shorter. Or over.

    I don’t blame WordPress directly for this. The community has done their level best to help and protect each other. So has leadership, as much as they could. But I really do feel the absolute lack of overall guidelines for “don’t be a dick” would have short circuited a lot of the pain people have had to deal with.

    No, this was clearly not a thing WordPress did. This was a shift in the world, and honestly? It’s only gotten worse.

    Why Not Name?

    I have a lot of stories like this, and I absolutely will be sharing more. But I will not tell you exactly who people are.

    Oh Liam probably sees himself in this, and that’s fine. What’s he going to do? Leave a comment to complain I’m not telling the whole story, and out himself as a human who felt impersonation was the right way to prove his point? He crossed a line and there probably is no way back at this point.

    But naming him removes the “probably” from that. Naming him means that he is forever branded as the asshole. And I actually still firmly believe that nearly everyone can come back from crossing that line.

    Otto has often called me an optimist for that. He’s right. I am optimistic that the human condition lends itself to empathy. We’re all on this rock together. We aren’t getting to Mars if we can’t figure out how to exist respectfully with people we disagree with.

    And I feel that most people want to be in a group. Humans don’t want to be alone. Getting excluded from the group hurts, and people will do anything to get back in if that’s the only group. That’s reasonable, right? And when people have a bad day, getting kicked out, they lash out.

    Likely Liam and most people like him never think about me again. I recently was reminded that for an adult, making a joke about a kid being chubby doesn’t stick in the adult’s memory, it’s just another day. But that kid will remember the time and place their parent called them fat.

    I’m not the parent.

    I remember the days, probably all of them given a prompt, I’ve had to tell someone no and close the door on them. Because it remains my secret hope that everyone like Liam feels a little bad, and sorry. Not sorry because he got kicked out, though. Sorry that he hurt someone.

    And if that happens? If a Liam developed the empathy to understand how his actions harmed others and sincerely apologized? I would be the happiest woman in the world.

    I want to leave that door open for the Liams in the world.

    I hope you will too.