Author: Ipstenu (Mika Epstein)

Why CDN Media Needs a Plugin
I wanted to write a blog post for work (something I try to do once a month) so I thought “I should write about using a CDN for images. I wonder if you can do this without a plugin…”

One hour later, and 1200 words, the answer is no. You cannot.

My initial goal was to move media files (and only the media) from http://example.com/wp-content/uploads/ to http://static.example.com/wordpress/ on DreamObjects. I’ve written a plugin that does that, but to my frustration, I found you cannot do this without a plugin for one incredibly simple reason.

But before the big reveal, let’s break down, in simple terms, what I would actually need to do in order to move the uploads. My two assumptions are that I already have a WordPress powered site (check) and I already have DreamObjects (check)
1. Setup a bucket on DreamObjects (or AWS whatever) to house my images, and give it a CDN alias.
2. Copy all the images to the bucket.
3. Change the Upload URL to http://static.example.com/wordpress/ (my CDN alias for the bucket).
4. Edit all posts and GUIDs to the new URL.
The thing is, I can actually do all of that!

Setup a Bucket on DreamObjects

Log in to your Panel, click on Cloud, go to DreamObjects, and create a new bucket in DreamObjects. I called my domain-static because that’s easy for me to remember. Static content lives here. Once you have your bucket, click on the “Change Settings” link and add an alias of “static” to the domain you’re hosting all this on (example.com in this example).

You can name your alias anything you want. I just picked static because I knew I wanted my URLs for images to be http://static.example.com/wordpress/2016/01/happynew.jpg and this makes it simple. I like to leave my CDN available for more than just WordPress, and doing this will let me have more folders like wiki or gallery.

Next, scroll down to “DreamSpeed CDN” and turn on CDN Support. You’ll notice that tells you a special URL for CDN:

Connect to the accelerated DreamSpeed CDN version of this bucket at: examplecom-uploads.objects-us-east-1.dream.io

Don’t worry! You can use your custom URL too. You don’t have to, but most of us want to, to feel special. In order to use your custom alias that we just made, scroll up a little and check the box for ‘CDN’ on your alias. Press save and you’re good to go!

Copy all the Images

Set the bucket public first!

Just trust me, here. Okay? Good. Set the bucket public and then upload all the images. I used Transmit. Cyberduck also works.

Change the Upload URL

This part was scary.

We need a moment of history first. Up until WordPress 3.5 this was actually pretty easy to do. You went to your media page and you changed things. As of 3.5, WordPress decided that this was more trouble than it was worth. Too many people were accidentally doing silly things, breaking their sites, and it was too dangerous. So they removed the part of the screen that let you change this.

I have issues with this, since for what I want to do, it makes it a hassle. But given the flaw in my great plan, I recognize the change as one that protects people who know less than I do.

Using a plugin to restore this missing setting would be the easiest on many levels. And there are a few plugins that do this but I like Upload Url and Path Enabler. It’s simple and to the point.

Of course, I love wp-cli and we have it on all our servers at DreamHost, so this command is similarly awesome:
```
wp option set upload_url_path http://static.example.com/wordpress
```
The last option for this is the secret WordPress page called “All Settings” — This is hands down the most powerful and dangerous page in all of WordPress. It lists all your options and settings that you have in the database. And yes, you can edit many of them in your browser at http://example.com/wp-admin/options.php

Go ahead. Take a look. It lists a lot of things, most of which you should never, ever, ever, touch. If you were going to use this, search for upload_url_path, change the value from empty to http://static.example.com/wordpress, and press save.

Edit All Your Posts

This is a sucky part. You have to edit all your posts now to move the existing images. This is because those changes you made are only for images going forward. Which is really cool and means you didn’t break anything so far. But WordPress hardcodes the paths to images in your posts (for many reasons) so you need to change all of them.

If you know how to use the command line, this is actually really easy:

wp search-replace http://example.com/wp-content/uploads/ http://static.example.com/wordpress/

Run that command and WP-CLI will magically fix all your posts.

If you don’t want to use the command line, I recommend Velvet Blues Update URLs.

Done!

And to be clear on things, this worked perfectly. My media library showed properly, all my images showed, and everything looked perfect. So I decided to run some basic tests and upload new images…. and that’s where my house of cards fell apart.

You cannot save files to another server.

Actually You Can… if you sudo

Now I have to tell you something. I lied. You totally can do this. The problem is that it’s hard and requires mounting your bucket as a local filesystem so that it would be available via the file-path of the server. You see, you could save files to /folder/location/wordpress/ anywhere on the server. I save mine to /home/user/public_html/static/ on one set up, and I have a static domain (domain-static.com) that runs from that folder.

What that means if I had a location I could access, I could tell WordPress to save there, making it ‘local’ enough to trick it. You can do this with tools like s3fs-fuse, however they’re incredibly complicated and weird for the layman. And that right there was my problem.

If you’re trying to present something as ‘Without a plugin’ then you don’t want to make the tradeoff be ‘..but with sudo access to a VPS.’ That’s unreasonable.

And it’s why, right now, if you want to use a CDN for your media in WordPress, use a plugin.
20 January, 2016
Circular Arguments Need Research

There’s something I hate about the fact that they charge for tampons and pads in bathrooms. I understand the financial outlay of providing a ‘service’ but at the same time, the collection method means that most of us never use them. After all, on those occasions when a woman needs a tampon or pad from those machines right bloody now, we probably don’t have our purses with us. Most women I know keep at least one in there for just such a moment, after all. If we don’t have our purses, guess what else we don’t have? A dime! In my experience, any time any woman has stared at that machine with a look of hopelessness and despair over their lack of a dime, another woman has brandished her personal emergency tampon and handed it over without a second thought.

So why do they charge? Well if they didn’t charge, then people would just take them and that would be a financial loss. I get that. Except, as my friend Mark Jaquith put it:

Financial outlay is an imprecise way of validating the intensity of a need.

The day I had my great-tampon-rant was the same day I’d argued with some folks about marketing. Someone who is a ‘known’ person in the WordPress community got a bog standard email from a hosting company. It was one of those emails that looked like it was meant to feel personal, but was really just a sales pitch about what the company was and how they worked.

The thing about that is I’m pretty damn sure the person who got the email knew all of that already. He may have known it better than the ‘person’ who sent the email. I say ‘person’ in quotes because I’m sure it was an automated campaign set to hit up people who’d emailed or used a contact form and asked a question.

And this bothered me.

If the email hadn’t made an attempt to be personal, and instead just said “Hey, you used our form/emailed our service address recently. Did you get all the help you needed? Do you need to talk?” I would have been just fine with it. And if he’d checked a box to say “Please contact me about stuff!” I’d similarly say “Well you deserved that one, B.”

The reality is that he filled in a form to get a ‘report’ that he wanted to read and got that personalized email within an hour. The company offered something for ‘free’ but the cost really was data collection. Furthermore, the penalization was immediate solicitation.

It doesn’t matter who the company is. This could be mine (it’s not) or yours (it might be). Pretty much every company known to humanity has done this at least once. And every company uses the justifications that the marketing strategy converts people into sales, and thus it’s fine. We all accept that marketing automation is hard, that identifying people we should be reaching out to and separating them from the ones who will just be annoyed by our hard sells is extremely difficult.

Remember what Mark said?

Financial outlay is an imprecise way of validating the intensity of a need.

Not enough women using the pay-for tampons and pads is (part of) why they’re never going to be free. Women don’t use them because they’re pay-for (and we rarely have the damned dime).

The ‘need’ of tampons is not being correctly measured.

With those marketing emails, I would say this:

Financial boons are an imprecise way of validating the effects of a campaign.

Yes, I’m aware I just said that “Making money doesn’t mean your campaign was successful.”

Except that’s not what I’m saying. What I’m saying is that the effects of your marketing are more than just financial. If you send out 1000 emails and get 1 sale, that sounds like ‘free money.’ Very little output and work nets you money. Everyone wants this. The problem is how many people did you chase away? What net negative are you creating? We’re not tracking the information in a way that lets us know this. We’re just thinking that any news, any discussion, and any income means it was good and effective.

Let me ask this differently. How many auto-play ads have you seen on a website that made you like a product less? How many websites have you quit visiting because you can’t stand their ad practices?

Not all press is good press. Forbes recently had a snafu where they asked you to turn off adblocking only to serve up ads with malware. They had a rather immediate and vocal negative impact. I doubt that level of embarrassment and pain will hit this company, but at the same time, we should be looking towards other, better ways of attracting new customers.

This Can Be Fixed

Looking at the situation that led to this in the first place, requiring an email to download a report is an obvious ploy to gain a list of people to contact. There was no attempt to opt in and no information that the email would be used for marketing. Step one is to disclose that. Step two is to actually make that opt-in. Step three is to provide some additional reward. “Do you like reports? Click here and we’ll send you our next one right away!” Then when you send those next reports, you can put a little footer for sales. “Interested in our stuff?”

Step four is the hardest. Curate the damned list. Remove all your customers. You already have their emails, you don’t need to email them about your services. Put them to the side. Next you want to remove people with emails like support or webmaster. In addition, you’ll want to check your list for people who already know about your product. WordPress is an incredibly small community. There are some people who just are not ever going to be your target audience, who aren’t going to need that sale, and you don’t need to bother them. They’re also the ones who will uncheck the marketing email, of course, but just in case…

Step five is handling your existing customers (the ones you removed in step four). Put them on separate list to target with different emails. “Hey, you’re already our customer and we noticed you liked X. Would you be interested in Y and Z?” Of course if your customers have checked that box to say “Don’t email me with marketing stuff” then you damn well better respect it.

For step six I want everyone to stop pretending these are personal emails. Shut up. Give up. We know, okay? We absolutely, 100%, without a doubt know that you automated this stuff. And that’s totally okay. But you cannot claim personal emails, from real people, while not vetting the people to whom you’re sending email in the first place. Okay? Good. Now go be quirky! “Hi Mika! I set up our robots to email people who downloaded X because I wanted to make sure they knew about Z and Y! Hate these emails? Click here and we’ll delete you from the database.”

But Can It Be Automated?

Not entirely. No. The real question is ‘Should it be automated?’

This goes back to Forbes. They automated their ads. They set it and let it run without review. Obviously the answer there is ‘No, that should not have been automated.’ It’s easier to ignore them and trust the ad company. That said, regularly I go through the ads on my site and delete them when I find them annoying or offensive. Yes, I curate my ads. And if someone tells me “Hey there was an ad for porn” I go look for it!

As much as we’d love to automate these things, we can’t. We just need a human taking a look now and then to go “Hang on…” Marketing cannot be set it and forget it. We have to look at the return on investment. We have to understand what impact, true impact, our campaigns have. We can’t just look at the net income, we have to be aware of the seemingly invisible loss.

And as for those tampons? We need a better metric than just “Well some people pay for them, but not enough to make us think a lot of women will use them if we give them away for free….” Maybe they could just have a nice box of tampons and pads in every stall, where you can press a lever and one item falls out every X minutes. Or maybe that idea of a drop of menstrual blood works in place of a dime… At any rate. The point is assuming things as successful because of a lack of response does not actually mean they are.

The circular arguments, that silence proves success, or at least an acceptable status quo, need to be thrown out on their ears.

18 January, 2016
Mailbag: How do plugins update?
From Ken the Web Mechanic comes this:

Hi! I wonder if you’d have any insight on this… I’ll mention Wordfence, though I imagine that it applies to any security plugin that compares plugin files with those in the WordPress repository… One of the most common things that Wordfence reports as a file “inconsistency” is the readme.txt of many plugins. Frequently, when using Wordfence’s compare feature, the readme of an installed and up-to-date plugin is shown as not the most current version and the repository shows the latest version – which is for the version that is installed!! If you delete the plugin and then download and install it anew from the repository, the readme is for the current, Wordfence has no complaint and all is right with the world… So I guess my question is… When a plugin is updated through WordPress, does the readme.txt file always get updated? It’s always been my understanding that during an update all of the old filed are deleted and then the new version is installed from the repository… It’s seeming like this may not be 100% of the case. It’s certainly only a minor irritation to me… but it makes me curious… Inquiring minds and all of that! 😉 Thanks!

I put the whole question in because while the crux is “How are these buggers updating?” the whole picture is interesting. I’ve talked about this once before, but it was a very long time ago. How the WordPress Upgrade Works was posted in 2011, and Why does the WordPress background auto-upgrade work? was back in 2013. So it’s about time for a revisit.

The short answer is “Actually, the readme.txt is deleted on plugin (and theme) upgrades.”

The longer answer means first we should understand what’s going on with upgrades! How plugins (and themes) update is pretty basic and you can check out /wp-admin/includes/class-wp-upgrader.php to see all this code:
1. Connect to the filesystem.
2. Download a package.
3. Unpack a compressed package file.
4. Clears the directory where this item is going to be installed into.
5. Install a package.
These are all great failsafes, making sure multiple times that we’re not about to leave a user in a bad state. We check to make sure we can download and use the file before deleting and replacing. We check to make sure WordPress can find all the folders it needs, like plugins and wp-content and so on. If it can’t connect to any of the ones it needs, it will fail. We make sure we can download and unzip the file. Even when we look at the complex fourth step, we’re all checking over and over to make sure that when we really do delete these files, we have something to replace them with.

The goal is that WordPress should never be able to leave you with a plugin deleted and not installed again, nor should it leave you with a half-deleted plugin. Obviously critical failures, like a server reboot mid-stream, will have some catastrophic effects. This is why WordPress tosses a .maintenance file down, mind you. Stops your site from looking like total poop while all this is going on.

When we look at the class Plugin_Upgrader itself (line 766 or so), we get into some nitty gritty things. The public function upgrade does some interesting things:
```
		add_filter('upgrader_pre_install', array($this, 'deactivate_plugin_before_upgrade'), 10, 2);
		add_filter('upgrader_clear_destination', array($this, 'delete_old_plugin'), 10, 4);
```
Here we are clearly deactivating and deleting safely before we upgrade. And at this point, I’m very confident that we’re deleting that readme.txt before we upgrade.

Okay! So why is WordFence being a dillweed?

I have a theory it’s related to the updates we do when WordPress core has a new version. You see, instead of updating the whole plugin, we update the readmes only to edit the “tested up to…” value. If there’s no code change, after all, why would we bother? No need to push an update! This means you no longer have a plugin that 100% matches what’s on Wordpress.org, you have a plugin where the code files match, but not the readme.txt files.

And then poor WordFence notices that the readme you have and the readme on .org’s servers is out of whack, and tosses an error.

I don’t know how WordFence would fix that, but I’m pretty sure this would hang ’em up.

WordFence folks, got any ideas?
15 January, 2016
Not Ditching ZenPhoto After All
When we last left our heros… We had taken a SQL database, converted it to JSON, split it into 885 separate JSON files, renamed and moved them based on the folder path previously assigned.

That took a while, but now we’re ready for the fun!

Convert them to MD

I already know how to do this one. Run grunt-mustache-render!

One problem. It didn’t like recursive folders. Pause for laughter. Thankfully I had done a cp and not an mv on my files with Mike’s script, so I just changed that to handle moving .md files instead of .json and it all went fine.

Turn on Hugo

I had a theme already so I copied it over and then started making my changes. I needed the layout to be a little different.

First I needed a list of all the sections and files and I needed to grab all the items that were an ‘Index’ file and format them specially:
```
<div id="albums">
{{ range $section, $taxonomy := .Site.Sections }}{{ range $taxonomy.Pages }}{{if eq .Type "index" }}
		<div class="indexalbum">
			<div class="thumb"><a href="{{ .Permalink}}" title="View album: {{ replace $section "-" " " | title }}">IMAGE HERE</a></div>
			<div class="albumdesc"><h3><a href="{{ .Permalink}}" title="View album: {{ replace $section "-" " " | title }}">{{ replace $section "-" " " | title }}</a></h3>
            {{ with .Params.desc }} {{ . | safeHTML}} {{ end }}</div>
			<p style="clear: both; "></p>
		</div>
{{ end }}{{ end }}{{ end }}
</div>
```
I felt very pleased with myself at this point. Obviously I would need to replace “IMAGE HERE” with an image, but I had the basic idea down.

Inside each post, there was a shortcode mentioned before, {{< gallery >}}, and this is where my drama started. What I wanted I thought would be (fairly) easy. Get a list of all the folders where this index.md file was and list them similar to what I had done before. They were sub-sections (in Hugo Terms), but as it happens, Hugo doesn’t have a way to handle those! There are no templates for subsections. Now this in and of itself wasn’t a deal breaker. I could made do with that shortcode except…

Limitations

The thing I really do like about ZenPhoto is that I can drop my new media in a folder and magically knows what’s up. Add a new folder? It knows it’s there. With Hugo (or Jekyll) I found it was incredible hard to do something as ‘simple’ as getting a list of all the items in a folder. With Jekyll I’d need a plugin (which I am certainly not adverse to). Hugo has a readDir call, but it’s limited to the working directory and I wanted to read the images in a CDN folder (on the same server, but still).

Perhaps ironically, it’s easier to run a gallery with Hugo and Jekyll if you host the images off your own domain. It goes against my goal of having a self-hosted site, though. But for now, it’s not possibly to do what I wanted.

Do I feel like I wasted time?

No! In fact, I’ve learned a lot of things that tell me where the foibles are in my plans.

ustwo actually did make a React powered site and in looking at their source code I see they did it by making the site ‘all one page.’ This is something I can understand today and wrap my head around. Because the alternative would be something like this:
1. Write a post
2. Run a script to grab all the pages via the JSON API as individual .json files
3. Run a script to convert them into .md
4. Build static site (test and then deploy)
It’s not actually that horrible when I put it that way. It means everyone could write on WordPress and, when they’re ready to deploy, I just run my script, push to my dev site, validate, and push to live.

But. That loses a lot of what makes WordPress cool. Editing posts on the fly, pushing live updates, and scheduling posts all becomes a nightmare. For my Gallery idea, it means that WordPress remains a viable option except for the fact that I can’t easily move from ZenPhoto to WordPress and WordPress behaves like a blog when I don’t want it to be one.

I’m all about using WordPress for things other than blogging but the sad truth is it’s still structured like a blog. Custom Post Types are doing a great job, and a lot of what I do on my estore site is similar to how I’d want to handle a gallery. I could do posts as posts and organize them as categories, for example, and structure the whole theme to handle that…

Or I could just stay on ZenPhoto, which does all that out of the box.

And yes. That’s what I’m doing.
13 January, 2016
Ditching ZenPhoto for Hugo?
This started out as a 230 word bullet point list of how to do things. It’s now two entire posts!

(Almost) Leaving ZenPhoto

I have to preface this by telling you that I didn’t in the end. Yeah. I know. I planned to. And here’s why:

I like ZenPhoto a lot. It’s a great Gallery tool, and after Gallery2 went to Gallery3 and I hated it, I was quite in love with them. But. They’ve started to inch towards being a general CMS and the whole ZenPhoto/ZenPhoto20 split left a weird taste in my mouth.

Plus the DB I have is already 65 megs, which has started to behave a little oddly. Now I have 38,534 images in 885 albums, and to a degree that makes sense. If you think about it in WordPress terms, I have 885 taxonomies (tags and categories), and 38,534 posts. Given that each post in this example would be a sentence at most (describing the image), the WordPress DB would be around 15megs based on some napkin math I did. Validating this, there’s a WordPress Joke DB with 40k Jokes and it’s only 14 megs.

Oh and did I mention that ZenPhoto has no export feature? I guess there’s a reason the first PHP script I wrote was a simple Gallery. All I really want is to display images in a structured format.

But. As I said before, I did not leave ZenPhoto! Why not? Because I was unable to do what I wanted to in pure Hugo, and because porting everything over to WordPress is incredibly hard and complex.

Why Not WordPress?

WordPress has a lot of awesome advantages. It auto generates thumbnails for one, which Hugo does not, so porting the gallery over would save me one level of complication. But I have 38,534 images to import. No matter how you slice that, I’d have to import them and associate them with the right post. Probably manually.

With a static generator, I can very easily assign a variable for each album to say ‘get images from this folder and display them.’ And if there are folders, list each folder as a link to another page. By contrast, I would have to use a plugin like NextGen gallery to do this in WordPress, and while I do like the plugin, it’s got the same issue that ZenPhoto has for me. It’s doing too much. And, to be honest, part of this process is to limit my potential security issues. Adding in really big, really complex plugins is the opposite of that, no matter how rigorously reviewed they are.

Besides, if I hated it, I knew I could import MD files into WordPress. Someone already did it with Jekyll after all.

Get and Grep the Data

No matter what I needed the data. Thankfully I knew how to do this with phpMyAdmin already. I dropped the _albums table in JSON format. Why JSON? Well as I’d already learned, I could generate a Markdown file from a JSON pretty easily. Of course, I got stumped on having it loop through the JSON file, but I have a plan for this.

On export, albums.json was 643 KB while images.json was 61.4 MB. And they were all one line. I’m not using images.json just yet.

I tossed it into BBedit and scrubbed the data, removing everything I didn’t need. This did not change the file size at first, since I also made the JSON human readable. There was a lot of gripping here, but I took each entry from 16-22 items down to six: tags, categories, folder path, title, description, date. And the file went down to 143 KB. One-sixth, more or less.

Finally I had to split each entry because, as I’d learned, trying to loop through a nested JSON array in grunt is complicated. So fine, I’ll do it manually. But how? Answer: By loving linux. You can split files!
```
$ split -a 6 -l 8 ../albums.json album-
```
There’s also csplit, which is contextual split. Either way, I now have 885 album-xxx.json files. Whew.

Rename and Move the Files

I messed around with linux commands to move files based on their folder paths and rename them based on the last variable. I dreaded having to just move them and then going to mess with the renames. So after two days, I asked Twitter and was saved by Mike Little and Kailey Lampert. Between them I learned that there was a jq tool for messing with JSON (homebrew install it) and that a shell script is a godsend.
```
#! /bin/sh

# awk script:
# set field seperator to :
# strip comma from field 2
# strip quotes from field 2
# strip lead space from field 2
# strip trail space from field 2
# print field 2

for FILE in `ls *.json` ; do
    NAME=`cat $FILE | grep folder | awk 'BEGIN { FS= ":" } { 
        gsub( ",", "", $2 );   \
        gsub( "\"", "", $2 );  \
        gsub(/^[ \t]+/,"",$2); \
        gsub(/[ \t]+$/,"",$2); \
        print $2 
    }'`
    
    mkdir -p $NAME;
    cp "$FILE" "$NAME/index.json"
done
```
I ended up changing it to reduce future broken URLs. But basically everything except the mkdir comes from Mike. He’s my hero.

To Be Continued

Once I had all the files, it was time to change them all to Markdown files and whip out my templates!

But you’ll need to wait for that because this post got really long.
11 January, 2016
Mailbag: Access and Security
In the midst of a longer set of forum posts about how to not have a plugin updated because you’ve made edits to the plugin, someone said that their issue was that the people on the site updated.

Now please don’t say that we should give them minimum privileges …

Actually. That’s precisely what I’m going to say.

1) Do not make anyone an admin whom you do not explicitly trust.

2) As the admin, test all plugins before updating.

3) If a plugin is constantly releasing unstable updates, stop using the plugin and look for alternatives.

3a) But make sure it’s not your theme or a conflict with another plugin first. It may be something else’s fault.

4) Stop editing plugins directly.

5) Treat every upgrade as a serious thing.

Now. I know why the guy doesn’t want to hear “You’re doing it wrong.” But the truth is this. If you give people who are irresponsible enough to update things the ability to update things, they’re gonna update things!

True story? On one of our company sites, one of the guys has access to update all the things. He did and broke the site. I jumped in, told him “Don’t do that, please, ask me next time.” and I fixed it. And then I went through everyone who had admin access and locked their accounts down to Editors. The exceptions were the people who legitimently needed that access.

And yes, WordPress needs more granular user roles/controls. I want that user to have access to administer all posts and add new users. I don’t want him anywhere near the plugins and themes. But I evaluated the risk vs reward of his access, and since he’s educatable, I felt it was safe to leave him there. Plus he knows right away to call me if he breaks things.

That goes back to the trust aspect, though. I trust him.

Trusting people to have access to aspects of your site reflect your understanding of what that access means. Making everyone and their brother an admin is reckless, not to sugar coat the situation. Only people who must be admins should have admin access. It’s really that simple. And if you insist there’s no other way around it, then you’re not paying attention closely enough.

Make a list of what your users need to do. Not what they want, what they need. And be serious here. Do they need to update plugins or do you do it for them in a reasonable timeframe? Do they really need to be able to add users? Remember though, we’re asking what they need, not you. Go to WordPress’ list of Roles and Capabilities and take note of what they actually can do.

Now I said before, the roles and controls and capabilities of WordPress leave a lot to be desired. But thankfully WordPress has add_cap and you can adjust roles.

Here’s how Isabel Castillo did it:
```
function isa_editor_manage_users() {
 
    if ( get_option( 'isa_add_cap_editor_once' ) != 'done' ) {
     
        // let editor manage users
 
        $edit_editor = get_role('editor'); // Get the user role
        $edit_editor->add_cap('edit_users');
        $edit_editor->add_cap('list_users');
        $edit_editor->add_cap('promote_users');
        $edit_editor->add_cap('create_users');
        $edit_editor->add_cap('add_users');
        $edit_editor->add_cap('delete_users');
 
        update_option( 'isa_add_cap_editor_once', 'done' );
    }
 
}
add_action( 'init', 'isa_editor_manage_users' );
```
You only need to do that once since the roles and caps are locked into the database (see above, the controls need to be better). Still. Now your editors can edit users. Brilliant.

So yes. I will tell you you’re doing it wrong, especially when you’re doing it in a way that is dangerous and risky in the long run.

Don’t let the toddlers try to drive the car.
8 January, 2016

Author: Ipstenu (Mika Epstein)

Why CDN Media Needs a Plugin

Setup a Bucket on DreamObjects

Copy all the Images

Change the Upload URL

Edit All Your Posts

Done!

Actually You Can… if you sudo

Circular Arguments Need Research

This Can Be Fixed

But Can It Be Automated?

Mailbag: How do plugins update?

Not Ditching ZenPhoto After All

Convert them to MD

Turn on Hugo

Limitations

Do I feel like I wasted time?

Ditching ZenPhoto for Hugo?

(Almost) Leaving ZenPhoto

Why Not WordPress?

Get and Grep the Data

Rename and Move the Files

To Be Continued

Mailbag: Access and Security