Author: Ipstenu (Mika Epstein)

A Case Sensitive Headache
Like most people, I pull my site down to develop locally. After all, it’s safer. But also like most people, my live machine is a linux box and my personal machine is not. In fact, it’s a Mac, running whatever the latest OS X is. But don’t worry, today’s drama happens on Windows as well.

You see, I downloaded my local data, imported my database, changed my URLs to local, and stared at a page that had the wrong data. Or rather, the right data and the wrong image. The page for “Sam” was showing me a photo for another character named “Sam.” But on my live site it was fine.

Commence the Debugging

The first thing I did was copy the image to a new folder to try and re-upload it. Only that didn’t work out the way I thought it would. You see, I knew the filename was Sam.jpg so I tried to copy that over:
```
cp ~/sites/example.com/wp-content/uploads/2018/05/Sam.jpg ~/Downloads
```
Only when I went to look, it was again the bad image. In fact, when I looked at all the files in the folder, there was only one file named ‘sam’ when there should be two

Local site is on the left, live is on the right

Things were starting to become clear. Next I copied it and renamed it sam.jpg and got an error:

I’ve got it now. Mac doesn’t understand the different between upper and lower case. It’s not case sensitive.

Bad News: No Easy Fix

I’m really sorry about this. There isn’t an easy fix.

First of all, if you wanted to fix your main hard drive, you would have to reformat it. That’s a pain in the ass. Second? Your Mac will not be happy and things will break. For example, the Steam app doesn’t like it if your Mac is case sensitive. Seriously, I have no idea why. But it’s what it expects.

This means the ‘fix’ is to partition your hard drive. Since I’m using AFPS, I opted to make a volume instead of a partition, which feels pretty much the same but it’s not. I opted for AFPS with case sensitive and encrypted because I’m generally a neurotic. Making a volume is very fast, and once I was done, I copied everything in my ~/Sites/ folder over to /Volumes/websites/ (where websites is the name of my new volume).

And now it looks great!

Except… I still only see one in terminal. I freaked out for a moment and then I realized that while the GUI is smart enough to know that Sam and sam are both S’s, terminal put the capital letters above the lowercase. So all the S’s came before all the s’s.

The last step was to move my copy of Chassis over to the new websites volume, spin it back up, and finally it was working properly.

The Moral?

Don’t use case-sensitive filenames. Or filenames with special characters like á or í because operating systems are stupid.

No seriously, that’s it. Haven’t you wondered why people advocate we all use all lower-case for filenames in our code repositories? Because different operating systems are stupid. They don’t always talk properly to each other, they have different ideas of right and wrong, and they’re never going to agree. If you work with multiple operating systems, aim at the lowest common denominator, pick a style, and stick the hell to it.

That’s your moral.
7 June, 2018
Data Deletion May Not Be What You Think
So you’re handling GDPR and you have a privacy doc and policy and a plan for people requesting data and, yes, deleting it.

Eventually someone is going to ask you to delete their content from your site. This is the scary part for most people. Remember, you get 30 days to reply, so don’t panic. Next, figure out what they’re asking for, and if you can say no.

This is the fun part. You can say no. Sometimes.

When You Can Say No

In general, yes, you should delete people’s information if they ask. But if your website stores complicated information this is not actually as black and white as all that. The right to erasure does not apply if retaining is necessary for one of the following reasons:
- exercising your right of freedom of expression and information
- meeting any legal obligations
- performing a task for and in the public interest or in your legal authority
- archiving information of public interest or for research where deletion would impair the work significantly
- related to and legal claims you have (or may have)
This helps you balance out the problem of being told to delete things you need to keep for tax reasons. It also keeps sites that may collect public data for the general public (like wikipedia or a website that tracks queer characters on TV) from losing everything. It won’t protect you from other lawsuits, of course.

It’s that last one I feel is really important to everyone. That’s the one that means if I block you, I may not have to delete your data, even if you ask, because I may need it for the establishment of legal claims. But that has to be a legit claim.

You can also just say no for any reason you feel is justified. Now again, do not use this flagrantly. You still have to turn around and tell someone that you’re not deleting their data, so you need to be serious about this.

Self Protection

And speaking of being serious, you can actually say no to protect yourself. You see, people can only ask for deletion if the data is no longer needed for the reason it was collected. So if they want to delete their account but keep shopping at your store, you can say no since the information is needed to keep shopping!

So remember why you track the data in the first place. When people leave a comment, for example, you track their username, email, and IP (and web address if they provide it) in order to know who they are and prevent spam, but also abuse.

Here’s an excerpt from one of my privacy policies:

Comments: When visitors leave comments on the website, the collected data shown in the comments form, as well as the visitor’s IP address and browser user agent string are saved in order to help spam detection and abuse.

Since I retain data to prevent abuse, that is serial internet harassers, you can ask me all you want for me to delete any data I save about you, but I can say no to protect myself.

When You Say No

If you decide to tell someone no to a deletion request, you must:
- provide the reason
- inform them of their rights to make a complaint
- inform them of their right to a ‘judicial remedy’
That last one means yes, they can sue you to delete the data. If they’re abusing you (harassing etc) and you’ve saved all that, you’ll probably win. Which is one reason you should actually save and document people’s actions. I hate having a whole folder on my laptop that documents a bunch of people hating on me, but I need it.

Basically if you’re going to say no, have a damn good reason, document it, and be prepared for a fight.

Say Yes If You Can

Most of the time, it’s no skin off your ear to delete a comment or edit a post. But sometimes it’s going to be a huge deal. And in fact, you can turn around and tell people “If I delete all your data, I will retain information required to identify you in order to prevent you from returning to this site. Deletion requests means you will not be welcome back.”

If that sounded harsh, well, it can be. Because for most small blogs, consider what they’re asking. When someone asks to delete the content of a personal blog, it’s most likely going to be for a pretty petty reason. Unless they’re asking you to remove information that shouldn’t be public (like their phone or email – and yes, someone’s asked me to delete that before), it’s probably going to be someone asking you to remove a comment that makes them look foolish. Or at least it has been in my experience.

Make Your Life Easier

Keep this in mind too. Make your life easier. If you don’t need comments on your site, don’t have them. Turn off that contact form too. But there’s no law that says you need to let people talk to you on your blog.

This won’t be true for all situations, but do as much as you can and save yourself that GDPR headache.
5 June, 2018
CMB2: Conditional Meta Fields
Even though Gutenberg is on the rise, and every day gets us closer to using a whole new editor, we still use the ‘classic’ editor and we’re still beholden to it’s space limitations. I have strong feelings about how to properly utilize space when using CMB2, but not included in that specific post is this.

Fields You Don’t (Always) Need

There are three types of fields for CMB2.
1. Fields you always need to use
2. Fields that are optional
3. Fields that are needed only in specific situations
Most of the time we use option 2. Option 3 is the tricky one, though, since most of the time we end up having things show based on actions. That is, I save a post, and new options show up. When it comes to CMB2, we really don’t want to have to save and then edit and save and edit.

Yuck!

Thankfully this is all possible.

Practical Example: Affiliates

Today we’re making a box to handle affiliate links. There are three types of links: Amazon, Genric, and ‘Unique.’

The Amazon one will link directly to a signup link and the generic one links to the same thing only on Click Junction. Both of those links will have affiliate details backed in so I don’t have to look them up later. This also means any partners I have on the site don’t need to know all the gory details. Bazinga.

The last one, though ‘Unique’ is tricky. You see, when someone picks that, I want them to be able to put in a specific URL that may be affiliate linking somewhere else. But let’s start out with how it normally works.

Make Your Fields
```
function my_site_cmb2_metaboxes() {
	// prefix for all custom fields
	$prefix = 'my_sites_';

	// Metabox Group: Must See
	$cmb_affiliate = new_cmb2_box( array(
		'id'           => 'affiliate_metabox',
		'title'        => __( 'Affiliate Details', 'my-domain' ),
		'object_types' => array( 'post_type_shows' ),
		'show_in_rest' => true,
	) );

	// Field Box: Affiliate Type
	$field_affiliatetype = $cmb_affiliate->add_field( array(
		'name'             => __( 'Type', 'my-domain' ),
		'id'               => $prefix . 'affiliate',
		'type'             => 'select',
		'options'          => array( 
			'amazon'  => 'Amazon',
			'generic' => 'Generic',
			'url'     => 'Unique Link',
		);
		'show_option_none' => true,
	) );
	// Field Box: Affiliate Links
	$field_affiliateurl = $cmb_affiliate->add_field( array(
		'name'    => __( 'Link', 'my-domain' ),
		'id'      => $prefix . 'affiliateurl',
		'type'    => 'text_url',
	) );
);
```
That’s pretty normal for CMB2 and looks like this:

Normal, but … I want to hide that Link field unless a specific option is selected. Enter javascript.

Hide That Field (Conditionally)

Make a file for your javascript. I’ve called mine cmb2.js and put it in the same folder as my file that will enqueue the scripts.
```
// Either create a new empty object, or work with the existing one.
window.MySite_CMB2 = window.MySite_CMB2 || {};

(function( window, document, $, app, undefined ) {
	'use strict';

	app.cache = function() {
		app.$ = {};
		app.$.select = $( document.getElementById( 'my_sites_affiliate' ) );
		app.$.field = $( document.getElementById( 'my_sites_affiliateurl' ) );
		app.$.field_container = app.$.field.closest( '.cmb-row');
	};

	app.init = function() {
		app.cache();
		app.$.select.on( 'change', function( event ) {
			if ( 'url' === $(this).val() ) {
				app.$.field_container.show();
			} else {
				app.$.field_container.hide();
			}
		} ).trigger( 'change' );
	};

	$( document ).ready( app.init );
})( window, document, jQuery, MySite_CMB2 );
```
And then call the enqueue, but only when appropriate (because we want to keep the load low):

add_action( ‘admin_enqueue_scripts’, ‘my_site_admin_enqueue_scripts’ );

function my_site_admin_enqueue_scripts( ) {
$screen = get_current_screen();
if ( ! isset( $screen->post_type ) || ‘post_type_shows’ !== $screen->post_type ) return;
```
wp_enqueue_script( 'custom-js', plugins_url( '/cmb2.js' , __FILE__ ), array( 'jquery' ) );
```
}

And that works like this:

A Word of Warning

While all this is great for the sighted people, hiding things is not actually all that great for those who use screen-readers. For that you’d want to toggle the field to be disabled.
31 May, 2018
Consent and Awareness
GDPR.

It’s the bane of many headaches for many web developers, web admins, and in general anyone who uses the internet. If you’re reading this, it’s probably a headache for you too. So let’s have a real, non-lawyer talk about what’s going on and why you need to care.

Notice: I’m not a lawyer. This post is not legal advice. Please read the EU GDPR Information Portal and research your specific situation.

Everyone Needs to Care

If you thought this only has to do with people who use eCommerce products, think again. The centre of the GDPR is data privacy. That is, the right to have your data removed from websites, when you want. The point to all this is if you have a website, and people visit, you need to care because the following reasons:
- You have ads on your site
- You allow comments
- You use custom avatars (Gravatar)
- You track visitors (Jetpack, Google, etc)
- You embed content (Twitter, YouTube, etc)
Does any of that sounds like you? It sounds like pretty much every public website in existence. And congratulations you need to care about GDPR.

What You Need

There are a lot of moving parts here, but the pared down version is this:
- Know what 3rd party services you use
- Know what your CMS tool tracks
- Have a privacy policy
- Have a way for people to request data deletion
The first two are surprisingly complicated because, in the case of WordPress, you might be tracking a lot more than you think. Remember all those things I mentioned above? They all are common situations where your CMS might be tracking people. But what if I told you that a lot of plugins you use also add on tracking? Or record more data than WordPress knows about?

Like. I wrote a plugin that adds in the IP address used to register an account to the user meta. This means WordPress now records more data. Thankfully that gets deleted when you delete a user account, and it’s generally covered under the broad disclosure that you track users IPs (which every website does). But I have to make sure people who use the plugin know that, and communicate to others.

That’s a very simple example. Take a plugin that logs user activity for, oh, let’s say security. Now you have to tell everyone about exactly what it tracks (browser information etc) and what you use it for. And you get to figure that out for every single plugin you use.

This won’t be easy. Unless you read every single plugin you use, you’re going to be at the behest of developers who may not be aware of exactly what they need to disclose.

Privacy Policies Are a Must

Every site should have a privacy policy. While for most smaller blogs, the odds are low that anything will happen, you should have one anyway. The problem is that no one can tell you exactly what yours needs to have. I try to cover the four basics:
- Terms of Use: all the things you agree to by using this site
- Data Collection: what situations result in my tracking your data, including details on 3rd party services regularly used
- Data Usage: what I do with data and how long I keep it – also how to request it
- Policy Changes: a CYA that they’ll likely change
There are a lot of details in those four sections, especially the Terms, which exculpate me if I get information wrong, allow me time to handle a DMCA, and a whole lot of things. And yes, it’s super daunting, I know. I mean, the privacy policy here isn’t half as robust as some of my other sites.

The Bottom Line

You can distill all this into consent and awareness. People need to know what they’re getting into on your site (or at least be able to know – you can’t help people who refuse to read). And you need to understand exactly what your site does. You need to be aware, as a website owner and a user.

All those terms you ignored when signing up for Google Adsense and Analytics? Now is the time to knuckle down and read, because you need to cover that. All those extensions (plugins and themes) you added? Read up on them too. If they don’t explain what they do with data, ask the developers.

Developers? Step up. Document exactly what data you save. If you allow for the saving of different kinds of data, based on what the user picks, explain that. But you have to tell people what’s being saved and how to delete it. Most CMS apps now have tools to hook into to aid deletion, so research.

GDPR kicked in four days ago, but it’s not to late to fix things.
29 May, 2018
Customizing Login Pages
Most of the time, the default WordPress login page is fine. The vast majority of the time it’s fine. Once in a while, you want it to look a little more custom. So let’s talk about what you can do.

Change the Login Logo

This involves three things:
1. Making a logo of the appropriate size
2. Uploading it
3. Pointing your code to it
The default size of the logo is 80×80, which I’m using below. You can make it as wide as 312px, and as tall as you want, but I recommend not going too tall. I like mine to match my Site Icon, personally.

The path to the file is going to depend on where you put it, obviously. Remember it should be the URL, so you can’t use relative paths here.
```
add_action( 'login_enqueue_scripts', 'helf_my_login_logos' );

function helf_my_login_logos() {
	$logo_image = 'http://my-domain.com/path/to/my/image.png';
	?>
	<style type="text/css">
		#login h1 a, .login h1 a { background-image: url(<?php echo $logo_image; ?>);
			height:80px;
			width:80px;
			background-size: 80px 80px;
		}
	</style>
	<?php
}
```
Don’t want to code? Try using the Login Logo plugin.

Change the URL (and Alt Text)

Now that we’ve changed changed the logo, we should change the link and the alt text. After all, if the logo is your site, why should the URL be to WordPress?
```
add_filter( 'login_headerurl', 'helf_my_login_headerurl' );
add_filter( 'login_headertitle', 'helf_my_login_headertitle' );

function helf_my_login_headerurl() {
	return home_url();
}

function helf_my_login_headertitle() {
	return get_bloginfo( 'name' );
}
```
You can change the URL and text however you want, but I find it easier to just link to the site itself.

Bonus! Change the Errors

Okay this is rarely going to matter to anyone. But Tracy has a new favorite GIF:

And me, I wanted a nice, sneaky place to have it show up appropriately. So I decided to have it pop up when someone put in the wrong credentials while logging in. And I did that like so:
```
add_filter( 'login_errors', 'helf_my_login_errors' );

function helf_my_login_errors( $error ) {
	$diane = '<br /><img src="' . content_url( 'uploads/diane.gif' ) . '" alt="Access DENIED" />';
	$error = $error . $diane;
	return $error;
}
```
Now this doesn’t actually do anything other than be amusing. Let’s have a more practical example of wanting to change the invalid username/password messages to not tell people what they got wrong and not offer a password reset.

That would look like this:
```
function helf_my_login_errors( $error ) {
	global $errors;
	$error_codes = $errors->get_error_codes();

	if ( in_array( 'invalid_username', $error_codes ) || in_array( 'incorrect_password', $error_codes ) ) {
		$error = '<strong>ERROR</strong>: Incorrect login credentials.';
	}

	return $error;
}
```
There is not a good list of all the errors you may want to filter, I’m afraid.
24 May, 2018
FUD: The Sky Is Not Falling
Every day it seems like there’s a new Zero Day vulnerability about our websites. SSL is being deprecated, PHP is out of date, the CMS we use has a critical vulnerability, security isn’t all that safe, and OMG we’re all going to get our identities stolen and our lives hacked.

Making matters worse are those myriad security tools we use to keep ourselves from getting hacked or attacked, and they alert us to horrible things. I say worse because they terrify people without actually explaining and educating them, so the uninformed users come running to complain the sky is falling. And when those people are told an answer by other experts, they don’t know who to believe.

Can you blame them?

Responsible Disclosure

It’s four years now, and Nacin’s post about how security is nuanced is still required reading.

The problem we face is that telling the world about a security issue is complicated. We definitely need to tell people who are responsible for fixing it, and in a perfect world we should trust that they’ll push out that fix in a reasonable time frame. We also should be able to trust they’ll tell the appropriate people.

But who, exactly, is the appropriate person to tell about a Drupal patch? Not the hack, the patch. In a different light, who are the right people to tell that a new security fix for an operating system has been released?

There are millions of users. How do you get to all of them quickly, with the right amount of information so they can understand how important this patch is to them, and how quickly they should apply it?

Enter Security Companies

Many companies make their milk and meat off being the people who monitor and announce security releases. There’s nothing wrong with this. In fact, I laud them for being a much needed service. With so much data flowing, it’s important to have a service that can help users winnow down what’s critical to them and their setups.

But… That’s not what’s happening.

Security companies face the same problem we do. There’s just too much data, and it’s being updated all the damn time, and there’s no way to keep up with all of it. Which means that they do what I tend to do when I’m trying to explain things to a wide variety of people. They simplify as much as possible.

The problem with simplification is that you have to skip over things and leave out the nuances that help people understand what’s actually going on. They have no idea what they actually need to worry about. And we’re back to zero.

To Know When To Worry …

You have to actually understand context to know what to worry about.

There’s literally no other way around it. There’s no shortcut, there’s no cheat sheet, there’s just knowing what your site is doing.

Let’s taken OpenSSL as an example. Back in 2014, a serious issue called HeartBleed was discovered. The bug was phenomenal in that it allowed people to steal and read secure data. If you ran a website, this was a massive issue. For your webhost.

Was it a huge issue to you? Well. Maybe.

A lot of people sounded the alarm and declared this a crisis, and we should all grab our web hosts and asks what they were doing and when would we be fixed. And the rest of us said “Hang on. Webhosts are aware. See if they have an announcement, which most will, and if they say they’re working on it, trust them.”

Sounds like I’m passing the buck, but the reality is that unless I’m using my site for privileged data (like a private blog, or a store), then the odds are for my individual site … I don’t need to panic. Especially if I use unique passwords and take regular backups.

This doesn’t mean Heartbleed wasn’t a huge problem, and that I didn’t want to see my host putting this as their number one priority, but it means that I’m aware of the risk (private data being stolen) and the likelihood of it happening (moderate to high) and the level of risk. That last one is the most important.

What’s the worst that could happen, today, on this site if someone stole private data? Well. They’d see my password maybe, and some draft posts, and have access to my API keys for a couple services. Nothing I can’t fix relatively quickly. They can’t log in to those API services and they can’t destroy my life.

If I was still running a store (like I was at the time of the initial vulnerability), I paid close attention to the fixes being released and the moment one was out for my system, applied it. But there was no need to panic or rush about. I understood what was going on.

If You Don’t Know …

If, however, you have no idea how it all works and what it means, then I recommend the following checklist:
1. Do I have good passwords?
2. Do I have good backups?
3. Does my web host have a reliable track record for fixing this stuff?
4. Do I run any private/privileged data on my site that could be dangerous to release to the public?
If that last item is 4, then I better be paying my host (or an expert) a lot to protect me ASAP. If you’re still on budget web hosting, it’s time to move up to something managed, or hire someone to manage for you.

Otherwise, if the first three are all ‘yes’ then I’m not going to panic. I’m going to trust in the experts to do their job.
22 May, 2018