Tag: wordpress

Fight For The Future: Battle for the Net

On July 12, 2017, we fight for the internet. Again.

I know. Didn’t we just do this? Well we did, and we have to do it again.

What Is Net Neutrality?

Net neutrality is the principle that Internet providers don’t get to control what we see and do online. Think of it like if your phone company got to decide what numbers you could call and when. Back in 2015, we managed to get fairly strong net neutrality laws from the FCC (the US Federal Communication Commission) which stopped Internet providers from blocking, throttling, and paid prioritization—”fast lanes” for sites that pay, and slow lanes for everyone else.

Isn’t that like TV?

Yes it is! On your TV, you can only watch the stations you pay for. Now imagine the Internet that way. The problem though is that we don’t just use the Internet to watch movies. We use it to work, to develop code like WordPress, and to communicate world wide with like minded people to do all of that.

What’s the battle for?

Comcast and Verizon want to end net neutrality so they can control what we see and do online. It’s that simple. They want it to look like TV so they can say that we can’t work with our fellow developers in Serbia or Iran. They want to monitor all our communication with those people as well (which in the case of WordPress isn’t really a hinderance but still…).

What can we do?

Fight back!

Change your websites so people see the damage being done. Inconvenience the hell out of them. Make everyone notice and get them aware. Even if they watch Fox News.

The Fight for the Future has started the Battle for Net Neutrality just like they did in 2014 with The Great Internet Slowdown and like they do today with Blackout Congress.

How do we fight back?

Add the Battle For The Net Widget to your website.

If you’re running WordPress, I made a Fight for the Future Alerts Plugin, which lets you decide which alerts you want to show. It currently only supports the upcoming Battle for the Net and the Blackout Congress, but I plan to add other on-going events as they occur.

You can also use the Cat Signal which dynamically loads the right alert for you at the right time. The reason this is different is that not everyone wants to run an extra javascript all the time on their websites. Page speed is important after all. Plus they may not want to show every single alert.

3 July, 2017
This Post Was Written on Gutenberg

I think … I like it and I don't like it. Yeah that was the worst review ever, so let me explain.
Overall, I like the direction
I'm a big text-editor person. I like the control, I'm comfortable in HTML, and I really only used the visual editor in the last 3 years because I felt to fully support people with WordPress, I needed to do so. Naturally this means I'm probably the least likely candidate to like Gutenberg. But I do.
I don’t like the animations
The transition animations feel 'off' to me. When I start typing, the icons for styles (bold and italic and so on) vanish, which is nice, but they reappear when I move my mouse. This is a problem if I want to go back and edit a previous block. Things are cut off.
I like that everything is a block
The simple idea "Everything is a block" is really nice. I can understand this easily, and it was no hard jump to think of my content as blocks. Moving blocks around is also nice. The idea of blocks and modular content suits me.
I don’t like that ‘tab’ doesn’t work
When I'm writing in sections, blocks, I can't use TAB to navigate back and forth. Yes, I want too. Since I can't use my arrow keys either, it's really annoying. Navigating by keyboard is a huge part of what I do daily, and I like to keep that. ## I like that I can use Markdown* The `*` is because I can kind of use markdown. And by kind of what I mean is in the above line, I used `##` to make the H2 block. On view, it works. In the editor though it looks like this: I'm not super fond of that. I expected it to magically transform. ## I don't like the meta-box experience Okay. This is the advanced user stuff. But I use meta boxes. I spend a lot of time making my meta boxes fix the screen space. I added content to the publish box. And I'm not the only one out there who customizes the heck of the sidebar and the below the post area and … Yeah. I'm seriously concerned about that. Right now, all I see on the sidebar is a 'drop cap' toggle, which I probably won't use. I'm watching the Advanced Drawer discussion very closely with that in mind, since I have a post type with, literally, a dozen meta boxes. And no, not all will fit on the sidebar. ## As a whole… Gutenberg is really neat. It has some serious quirks, but that's why it's in beta testing at the moment. So please. Test it. As Chris Lema said, the people working on this plugin need our feedback. If you're a hardcore WordPress user, be that a developer or an advanced user, please download the latest plugin and leave your comments over here. To that end, comments here are closed.

30 June, 2017
Plural URLs
URLs can be hard. When you have custom post types in WordPress it can be harder.

Take, for example, a custom post type for videos. Do you want your URLs to be http://example.com/videos/video-name/ or http://example.com/video/video-name/ ? And do you want the archive to be http://example.com/videos/ or http://example.com/video/ ? And what happens when you change your mind?

Thankfully, WordPress lets you do some weird things.

Pick Your Default

Let’s look at the video/videos idea for a moment. Individual posts should be video but the archive should be videos in order to grammatically make sense. When you make your custom post type there’s a parameter called has_archive – by default it’s false. If you make it true, then it’ll have the same ‘base’ as your custom post types.

But. If you make it a string then you can make it ‘videos’ or ‘photos’ and magically your archives will have those names. That makes it pretty easy to change, just remember to re-save your permalinks after. I personally recommend doing a redirect so that video goes to videos (and videos/postname go to video/postname) so that any random bad URLs would still be caught.

Remember that you can leave it false and make a page to be a placeholder page, or you use archive-{post_type}.php to customize it further.

When You Need Both

But… What if you need both?

This is probably a bad idea, but let’s pretend you want to have both video and videos work for all cases. That’s when you’ll need something like this:
```
$plural_types = array( 
	'videos' => 'post_type_videos', 
	'photos' => 'post_type_photos' 
);

foreach( $plural_types as $slug => $type ) {
	add_rewrite_rule(
		'^'.$slug.'/?$',
		'index.php?post_type='.$type,
		'top'
	);
	add_rewrite_rule(
		'^'.$slug.'/page/([0-9]+)?/?$',
		'index.php?post_type='.$type.'&paged=$matches[1]',
		'top'
	);
}
```
In that example, I have the slug for my custom post types set to the singular, and then the $plural_types array has the correct plural and the associated custom post type. This is tossed into a for-loop that creates a custom rewrite rule that will redirect.
28 June, 2017
Expect the Unexpected
The other day, while reviewing a plugin, I told someone that their code was okay, but it could be better.

They had this:
```
if ( $_POST['value'] == 1 ) {
    $variable = yes;
}
if ( $_POST['value'] == -1 ) {
    $variable = no;
}
```
And I said they should do this:
```
$variable = ( $_POST['value'] == 1 )? 'yes' : 'no';
```
They asked why, since the only possible input were 1 and -1.

Users Are Weird

It’s hard to explain why users are so weird, but they are. Any time you have post data that a user can input, a user will find a way to intentionally or accidentally put in bad data. I think perhaps the best way to explain it is that users are like toddlers. You can baby proof your house, but they’ll figure out how to get into the flour and suddenly your kitchen looks like an episode of Cutthroat Kitchen and good luck cleaning it up.

The point is this. Even if your data is only meant to be a 1 or a -1, you have to think beyond what the code should be and assume it will, one day, be what it’s it.

Broaden Your Mind

The basic rule of any input screen is that users will do what they do. They just will. They use code in ways you didn’t imagine, and that’s okay. And even if you have a check box, which logically cannot be altered beyond checked or un-checked, someone will do something outside your expectations.

The easiest way to understand it is to think about hackers. The whole reason we sanitize checkbox data is not that we expect a user to make a phenomenal mistake, but we expect a hacker to show up and try to back-door our work. We cannot trust that every user has good intentions. This is even more common in WordPress, since anyone can download your code, examine in for weaknesses, and then attack.

Angry People Do Bad Things

If I had a nickel for every time I heard “But an admin would never…” I’d be rich.

A good admin would never, intentionally, break their own system, this is true. But an admin who was just fired, and hasn’t had their credentials revoked yet? Oh gosh, can they ever be evil. When a person was fired at a job I once had, they went into the test lab, took all the diskettes, and tossed them in the dumpster. The protocol for handling people being fired was changed that day, but all it took was one angry admin, and we had to go dumpster diving for 3.5″ floppy disks.

No, it wasn’t fun.

Trust No Data

I never trust data. Not even on code only I use. I always assume I can be tricked into doing something dangerous, or that I’ll make a mistake while using a system. Humans make mistakes. You can’t trust them to be right all the time, and you can’t trust them to be good all the time.

That means it becomes our responsibility, as developers, to do the following:
1. Make sure the data entered is sanity-checked
2. If it’s not sane, fallback to a safe default or throw a good error
But never, ever, trust anyone to be right all the time. Especially you.
26 June, 2017
Chassis – When VVV is Too Much
When I need to do WordPress core development, I use VVV. It’s great for multiple versions of WordPress, a copy of WordPress Meta, and it’s all done in one go.

But when I’m developing my own code, I want something a little lighter and simpler. I’ve been using Local for that for a while now. It involved a few weird tweaks but I was quite fond of it until the 2.0 upgrade. That’s because they broke the tool I needed most: Addon Volumes.

The current status is that it’s broken and the developer misjudged how many people used it. These things happen, but for me this was the primary reason I used it. So that meant it was time to look at my options again!

Chassis

Made by the quirky and original Human Made, Chassis is a cross between VVV and Local.

Like VVV, it’s Open Source. Like Local, it’s fast. Like VVV, it’s command line. Like Local, you can map to your hard drive. And that last reason was why I wanted to use it.

Look. There are a lot of reasons to use Chassis. The fact that it’s a server, so you can test out things like Memcached and PHP versions and upgrades is a big one. The fact that it’s fast to install and setup is another. But at the end of the day, I need my dev environment to do the following things.
1. Be ‘easy’ to rebuild
2. Have access to WP-CLI
3. Boot fast
4. Have a GUI SQL editor
5. Use my dev code, where I want it used from
My Development, My Way

The thing I hate about most dev environments is that they want you to put your code in their locations. MAMP, VVV, Local, and DesktopServer all prefer you to put your dev code in the folder for your dev site.

I don’t work that way. All my code for all my WP sites live in ~/Development/repositories/NAME or ~/Development/github/NAME or ~/Development/wordpress/plugins/NAME and this is a system that works for me. I have all my dev code in the Development folder, and I’m consistent about it.

Furthermore, when I use a local host install to test, I may use the same plugin on multiple sites. I try to reuse as much code as possible, after all.

This means my headache is always trying to some how symlink my development folders to my development site. With MAMP and Desktop Server I used rsync (and I was sad). With Local I used the broken add-on. With Chassis, it’s actually built in!

Build The House

Chassis touts that it wants to be invisible. In order to do that, they separate WordPress and your code, recommending you put your code in the /content/ folder. This is great, but as we mentioned, I want to have my code in another spot, so I need to map folders.

This can be done in the “Synced Folders” of the config.yaml file. I’ve added this:
```
# Synced Folders
#
# You can sync as many folders as you like. We sync the nginx and php log folders by default.
synced_folders:
    logs/nginx: /var/log/nginx
    logs/php: /var/log/php
    /Users/ipstenu/Development/repositories/site1-genesis: /vagrant/content/themes/site1-genesis
    /Users/ipstenu/Development/repositories/site2-genesis: /vagrant/content/themes/site2-genesis
    /Users/ipstenu/Development/repositories/site2-underscores: /vagrant/content/themes/site2-underscores
    /Users/ipstenu/Development/repositories/site1-plugin: /vagrant/content/plugins/site1-plugin
    /Users/ipstenu/Development/repositories/site2-plugin: /vagrant/content/plugins/site2-plugin
    #/Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/content/mu-plugins
    /Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/wp/wp-content/mu-plugins
```
Run a reload and a provision of vagrant and it all worked. That’s right, it was all silently symlinked and had full access to all my code in all the right places… Except…

Mostly Ugly Plugins

You may notice this:
```
    #/Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/content/mu-plugins
    /Users/ipstenu/Development/repositories/site-mu-plugins: /vagrant/wp/wp-content/mu-plugins
```
The first one didn’t work. The second one did, but only when I added this to my local-config.php file:
```
define( 'WPMU_PLUGIN_DIR', '/vagrant/wp/wp-content/mu-plugins' );
define( 'WPMU_PLUGIN_URL', $_SERVER['HTTP_HOST'] . '/wp-content/mu-plugins' );
```
I’m still not sure if I broke it or if they did. What I do know is that I can rather easily build out my dev server, point it to my dev code, and everything’s working.

Conclusion: Should you use Chassis?

I firmly hold that all developers should be familiar with the shell. Maybe they’re not all golden goddesses, but they should know how to get around, list files, and Google the basic commands like links, rsync, move, copy, and delete. With that in mind, if you’re a developer (be it a code developer, a design developer, or anyone else who peeks under the cover at the code), you should give Chassis a try.

It’s open source, so you can learn from it if you’re so inclined. It’s command line, so you can script it if you’re so inclined. You can separate your plugins from the plugins of the extensions, like debugging, and you can write your own if you want.

Basically yes, you should use Chassis. It won’t be everything to everyone, but it can be something for most people.
23 June, 2017
Secure Mindsets in Plugins
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.

Past You

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.

This Morning’s You

That said, when we do work in that way, we get ourselves into trouble when we ignore security. We assume people will only use the code in the right way, because it’s obvious what is right and what is wrong. I try not to say ‘obvious’ or ‘simple’ when talking about code or interfaces, because they are absolutely never, not once, obvious or simple. When I got my Apple Watch, the UX of Force Touch wasn’t obvious to me. It’s not simple now, since it can be a bit touchy, but it’s not difficult.

In the same vein, we all know that users do weird shit. Really weird shit. They put text in fields that should only gen numbers. They put numbers in for email. They copy paste without thinking. And you know that. You’ve seen it.

The Right Now You

Having read that, you’re hopefully thinking “how can I make my code secure?”

When we talk about basic security, we mean four things:
1. Validate your data
2. Sanitize what you save
3. Escape what you output
4. Verify a human meant to do it
That’s it. Make sure a date is a date and an email is an email. Make sure you save the data in a way that doesn’t put other data at risk. Remove any possibly dangerous characters from what you show to users. Always make sure someone meant to do the action. WordPress has over a dozen Sanitize and Escape functions to help make sure you save the right data and it has nonces to help make sure you save when you should.

They’re very complex, but at their heart, they do those four things.

Future You

The you of tomorrow will appreciate the you of today, if you remember to never trust your data. People typo. People make mistakes. People do bad things on purpose. All of that just happens. And if today, you learn how stop those bad things, tomorrow’s you will look back on you with love and thanks. Your users will thank you. Your next future will love you even more.

Security isn’t just https and good passwords. It’s a mindset to remember that anything passed to your code might be attacked. It’s a mindset that good users do bad and dumb things. It’s a mindset that mistakes happen. And it’s a mindset that being aware of the whole of your code, how it all comes together, must always include validation, sanitization, escaping, and nonces.
21 June, 2017