I'm just putting Mika's post here as a way we can remind ourselves to treat others with respect - even if we don't agree with them.
I’ve had an interesting week with WordPress. It’s been bad enough that I have to preface this post with a note. I have no plans to quit WordPress at this time.
This morning, I woke up thinking about a statement I picked up from Wikipedia. Assume good faith. I like that. I try to do it. The concept is simple and direct. Don’t assume everyone’s evil, instead assume they do mean well, but sometimes they may have trouble expressing it properly.
And while I do believe that most people don’t mean to be evil (there are exceptions…), I think that more people remain concerned about themselves over anything else. And this self-involved nature causes problems like happened recently, with choices certain companies made to self-promote in ways that other people found offensive and harmful.
So when I think about ‘good faith’ I do it with a look back to the previous actions someone (an individual or a company) has taken. How have they behaved before? Have they constantly shown poor choices? Is this a first? What happened the last time I tried to talk to them about it? Did we have a discussion? Did I get 15 emails in a row, alternately being called names
This post isn’t about the reasons why someone might need to disable the automatic updates. No, this is about the argument I saw stem from the vulnerability, whereby people said it was proof the REST API should be disabled by default.
WordPress 4.7.1 and 4.7 were vulnerable via the REST API. Any unauthenticated user could modify the content of any post or page on a site. Since the release of the information, a surprisingly large number of users failed to update to 4.7.2 and, thus, were hacked. I say surprisingly because WordPress enabled automatic updates quite a while ago (WordPress 3.7), which will automatically secure your WordPress install. There have been 18 automated releases since then (which is why we have 3.7.18) and the vast majority have addressed security in one way, shape, or form.
But this post isn’t about the reasons why someone might need to disable the automatic updates. No, this is about the argument I saw stem from the vulnerability, whereby people said it was proof the REST API should be disabled by default.
And to them I say “No.”
The REST API Probably Has More Vulnerabilities
Look, I’m not going to lie to you. The odds are high that the REST API, which is a very new feature, probably has some serious issues still. But, as my friend Helen pointed out to those arguing for it to be disabled by default.
Why should this be treated differently from XML-RPC? Have you gone through
Mika Epstein goes through all the things she deals with (and so many others). We hear lot about the joys and great people, but not so much about the bad days. Excellent read.
I wear a lot of hats in the Open Source World. I help teams. I represent and direct others. I herd the cats of software. I allow my name to be known. People talk about how we’re doing a good job, working hard, working together trying to make things better. They talk to you about the wonderful feeling of success that comes with releasing a product. They tell you about the joy, the friendships, and the community. Well. Here’s what they don’t tell you.
They don’t tell you about the bad days.
They don’t tell you about the week you will spend being blamed and slandered and lied about in blog posts and on Social Media because people know half of thing.
They don’t tell you about the fact that you can’t speak up and defend your actions because it’ll make things worse.
They don’t tell you about the subtle misogyny that makes you wonder if it’s there at all.
They don’t tell you about the gut churning nausea you’ll feel about turning on your email and watching wave upon wave of hate-mails come in.
They don’t tell you about the dick pics and come ons.
They don’t tell you that even when you can explain yourself to
An interesting look into the mind of a creator and the things they have to go through when building things for others.
I get painted as a bad guy a lot. I’ve been called names, everything you can think up. I’ve had my gender, sexuality, appearance, and ability all mocked and derided. And most of this has happened since I took up the role of a volunteer in WordPress. Creation, Editing, Fitting In
As a writer, which is how I’ve always seen myself first, I’m used to the ruthlessness of the editing process. I’ve seen papers torn apart and painted red with corrections and commentary. Why this? What are you saying here? I understand the reason for ripping apart creativity to find it’s heart and crux and meaning. Art for the sake of art is different than art for the sake of consumption, after all.
But instead of a career in the arts, or journalism, I had a different path. Out of college I went to work for a bank and quickly learned how to fit myself into the cog of a machine. I had a role and a life that did not encourage innovation and uniqueness, but that of interchangeability. And in that work, I began to understand the reason for patterns and the similarity.
I’ve always been fascinated by patterns. I liked to see how the number went from 09 to 18 and 27 and obviously
Bottom line: when you uninstall a plugin, if it was well written, it removes the files and the data.
Someone asked me why WordPress always says it’s going to delete files and data when it only removes the files and not the database options. There are two parts of the answer to this, one being a little historical and the other being a bit unhelpful. The Message: Delete Files and Data
Once upon a time, when you uninstalled a WordPress plugin, it looked something like this:
That was a very simple screen. You were asked to delete the plugin files, you clicked that you were, done.
Now you see this thanks to Shiny Updates:
It’s a different message, telling you it’s deleting data!
What Is The Data?
The part you don’t see is that WordPress would also remove all the data as well as those files.
Any time WordPress showed you that message to delete files and data, it was saying that it found a file called uninstall.php which would, presumably, delete the data set by the plugin. By this I mean the options and settings you chose for your plugin. Some plugins have data and others don’t. For example, Hello Dolly has no data, just files. It doesn’t need an uninstall file. On the other hand, a plugin like Jetpack has a lot of settings it should remove from the database
HalfElf takes on when to use PHP constants in plugins: nowhere.
If you’ve spent any time looking at PHP code, then you’ve seen defines and variables A define looks like this:
This makes a global constant that can be used anywhere. In the case of WordPress, it means they can be used across multiple plugins or themes. This is very useful if you make a suite of plugins that all have the possibility of using the same API key. Then you can tell a user to put define('MY_PLUGIN_API', '123456'); in their wp-config.php file, and tell your code to check for the define.
A define also cannot be redefined. If you call it twice, you get errors, so you should be as unique as possible when creating yours.
A variable, meanwhile, looks like this:
$SOMETHING = true;
Variables only exist where they are, so if I have one in one function, I may not be able to call it in another. You can make global variables if needed, and in fact if you don’t, the variable won’t be available to all functions.
Which Should I Use?
Keeping in mind that defines are constants and variables are, well, variables, the idea is that a constant should be used for things that should not change in the running of the code. It also makes your code easier to maintain
Mika Epstein wrote a nice article about naming a personal project to something that will be shared in the wild. This post goes deep about naming function name and check if function_exists(). Must read.
When you’re making your own project for small things, it’s not a huge deal when you try to think up a name. As soon as you realize your project is going to be shared with the world, however, the game changes. Project Names
A project can be as massive as a new release of an operating system (Longhorn anyone?) or as small as a new plugin for WordPress. If could be a library for PHP or JS, or maybe a simple NPM add on. In all cases, the name you pick should be unique.
This gets hard when you want to name a tool something like “Foo for Bar” like “Color Coding for Quickbooks.” Wy is that hard? Well while your name is certainly descriptive, it’s not unique. Because someone else can make the same tool. “Joe’s Color Coding for Quickbooks.” Or worse… “Color Coding 4 Quickbooks.” And the problem here is that neither of you really have the right to the name, do you? You’re both leveraging ‘Quickbooks’ and their brand, so where do you have a leg to stand on when someone uses a similar name?
A unique name, though, like “Color Me Quickly,” would be so much better. Think of displaying it like
Some great points like review is a reflection of an experience and not yours.
The following is the original notes on my WCEU talk about WordPress reviews. It’s more or less what I said, though the video will no doubt be up soon. 30 Months In Jail Over a One Star Review
This is a true story. In late 2014, a man violently assaulted a woman who left a bad review on his self published ebook. He stalked her, sorting out her pseudonym, finding her real name, address, and work location. He traveled 500 miles, found her at work in Scotland and hit her over the head with a full bottle of wine. He received 30 months in jail for the assault and stalking.
An Extreme? Not So Much
Every day people leave hundreds of reviews on WordPress themes and plugins. They talk about how much they love or hate a plugin, there is rarely any middle ground here, and they are as passionate as the developers themselves. This passion leads to a large amount of confrontation on the WordPress Review Systems.
Your Code Is Bad< And You Should Feel Bad<
We are all going to get the bad reviews, and while you might want to dismiss the idea of being a stalker or a violent offender, because YOU would never do it, I promise you this. You will react badly to a poor review. It’s human
We all know about Child Theme, here Mika sharing about Grandchildren Theme, or to be exact its actually Grandchildren Plugin. It will let you stay sync with Child Theme changes.
I’m a fan of Genesis themes. They look nice, they’re secure, and they’re well coded. A lot of things I have to reinvent in other themes are done out of the box in Genesis. But they’re not perfect.
Frameworks Beget Children Themes
The problem with Genesis themes is that if you use them, you’ll end up using a Child Theme and not Genesis. Unlike boilerplate themes like Underscores, you’re not meant to edit the theme itself but make a child theme.
For the most part, this doesn’t bother me. I don’t generally edit the child themes, except in two cases. Both of my fan sites run highly modified versions of the default themes, and one of them uses the amazing Utility Pro theme by Carrie Dils.
And that was my problem. I knew Carrie was working on a new version which would have some amazing updates. And I? I had forked her theme.
Merging my fork to her new theme had, generally, not been an issue. I’ve updated it a dozen times already and I just run a tool to find the diff between the files. I’m a Coda fan, and I use Comparator to check out the differences between files. Doing this is time consuming and annoying, however,
Renaming things, or rebranding has a cost. Sometimes that cost can be years or even decades of brand equity. Sometimes it can be losing a piece of history, even if that history is insensitive or flat-out wrong. Mike Epstein looks at the things you may lose when you rebrand.
If you caught my talk in Seattle last week, I talked about names, versions, and SVN. One of the things I touched on with names was their problematic nature. And believe me, I know about that. You see, I’m a Cleveland Indians fan.
And yes, I think the name (and the logo) are racist.
You can’t rename things, but you can rebrand
When I said this, I meant that you can’t rename a plugin slug. Yoast SEO will forever have the URL of wordpress-seo because we do not have a way to rename the slug and properly redirect everyone. We just don’t. And even if we did, the old URL would need to remain in perpetuity in order for everyone who upgraded super late to still get the new code.
Names are really important. Your name is (often) your brand, and your brand is how people know you and how to find you. When you consider a name like the Cleveland Indians, today we can see the problems with it. Racism. But in 1914, we were a little simpler, a little more naive…. A little stupider. Okay a lot stupider.
The problems that Cleveland faces with renaming are related to the problems you would face in renaming your product.
Rebranding has a cost, and it could be everything
Here is Mika (the person who accept most plugins in WordPress.org) talking about premium plugin update and what possibly could be better way to communicate. She also talks about premium theme and bundle product, nice read.
I am a massive proponent of people making money off of plugins. I think they can and should find a way to create a business in this ecosystem we’ve created. There’s a problem with the approach of some of these products, and in a way we created it ourself, and it hit WordPress 4.5.
There is a plugin, it doesn’t matter which one, that’s a premium plugin. It’s not available for free on WordPress.org. You have to buy it, get a license, enter the license into the plugin, and in that way get updates. That’s fine. But there’s a complication. Actually a couple.
Licenses Expire and People Aren’t Informed
That’s a big ‘no kidding’ moment, but they do expire. And people don’t always notice that their license expired. Even if you post a big sign on the dashboard and email them.
Worse, people don’t know they have license. One of the major problems with software, when purchased for a company, is ownership. If I buy an app on the company dime, it’s their app. But when I buy an app for someone I’m building a site, and I pay for it myself, even if I charge them for it, who owns it? Who keeps the license? Who has the information for running a site?
This is an aspect of WebDevelopment where we collapse,
Mika explains why it's natural to NOT write secure code and why It's time to get into a clear mindset of security when coding.
At WordCamp Europe last week, I talked about the basics of plugin development. Since I had a mixed bag of experiences, I decided not to actually write a plugin in the class, but instead I took Hello Dolly and edited it. I discussed how the plugin worked, that an action called a function, which returned a value, and showed the interconnectivity. In this way, the attendees could understand the big picture of how code comes together. But at the end, with five minutes, I touched on an important aspect of plugins that Hello Dolly doesn’t do much with, because it doesn’t have to.
I talked about security.
In the past, you probably done insecure things. Have you ever left your car unlocked in the driveway while you ran the groceries inside? We all do things that are insecure or unsafe. This is normal. Similarly, we have done insecure code. In the past, all of us, when we begin, we write code to perform actions without thinking about how it will be used globally. We don’t worry about safe, we worry about functions.
There’s nothing wrong with this. We are often focus driven designers, fueled by passion and desire, so we want to do and not worry about the details.
If you’re a WordPress developer encountering a CMB->CMB2 migration, read this @Ipstenu post.
Migrating from CMB to CMB2 I didn’t plan to, the first time. I’d inherited a site that I offered to help someone clean up and they had . They didn’t actually. They had CMB, the original. This was a while ago. Looking at their site, I realized they had one (yes, one) custom meta box, so I removed CMB and coded in that one meta box and called it a day.
Flash forward a while. A long while. I have a site that was mostly built out by someone else, and it worked great except on mobile. After trying to update content on the site on my iPad and getting frustrated to the point of angor, I re-did the theme as Metro Pro (yes, it’s that site), and folded in a lot of the meta boxes into mu-plugins, so we could keep them no matter what the theme.
But again, he’d used CMB. Not CMB2. And since I know CMB2 has a lot more features, I decided to upgrade. Three hours later, I had it done and had it done rather nicely.
Decide how to install CMB2
I did it as an mu-plugin – Look. It’s a library. I have my font library (aaah!) in there as well. This is how I organize things. I don’t want people disabling it on accident, so by having it in my Must Use folder, only people with SSH or Git access can screw with
Adding support for premium plugin upgrades is no rocket science. Mika does a good job explaining the options available.
When your plugin is hosted on WordPress.org, this isn’t a problem at all. But if you’re selling your own work, or hosting it on a non WPORG resource, there are other concerns. You see, if you host a plugin on WordPress.org, your plugin can’t have it’s own updater script. You have to use the default .org updater. This is just fine, except when you have an add on that you want to be pay-only. Then what? Take a look at Easy Digital Downloads. You can get the main plugin from WordPress.org, and if you buy add ons from their site, they get magical updates too! How did they do that? They put an updater script in the main plugin which is then called by the paid extensions. You can even use their Software Licensing add ons to run your own updates on your server! If you want to sell on their site, they’ll help you take care of that too.
Todd Lahman also has an WooCommerce API manager, so if you’re using WooThemes, you’ve got that covered too.
Speaking of self hosting, if you’re hosting your own code on Github, then you want to use Andy’s Github Updater. While it’s not allowed on .org (sorry Andy), this will let you push updates from your GitHub or Bitbucket hosted WordPress plugins and themes.
And the shirt is kind of cool :)
Way back in the stone ages I wrote an explanation as to why the WordPress Upgrade didn’t work all the time . In that post, I pointed out that servers and your installs are special snowflakes and not all the same, and that’s why an upgrade doesn’t work all the time. I’m amused that no one pointed out to me that stance (one which I still maintain by the way) seems contradictory to my proclamation that we should love the built-in updater as of WordPress 3.7. Allow me to challenge myself.
Your server, with your install and your plugins and theme and tweaks, is still a special snowflake .
The background updates for WordPress keep this in mind.
Oh, I have to go further into this? Fine. The reason the updates are restricted to just minor, security/maintenance, updates is that, in general, they do not cause the problems people experienced 2010. It’s been three years. We’re smarter, we learned a lot, and most importantly, if the problem in 2010 showed up again, WordPress would not to install . I heard the sounds of brakes screeching. Let me explain. We want WordPress to not install itself if it can’t. We’re not defining that as a ‘failure’ because while your install did fail to upgrade, your