Author: Ipstenu (Mika Epstein)

The Passion of Change, Part 1
One of WordPress’ big claims is that it democratizing publishing. In recent years, it’s also begun democratizing the distribution and consumption of data via the Rest API, and it’s helped push the openness of data, which can be used by anyone to make the world a little better.

Change is born of many things but it always stems from a refusal to accept the norm. When Shay died on the TV show Chicago Fire, many of us were angry. When Lexa died on The 100, we became irate. And then we organized. Multiple groups, separate, all used WordPress and social media to power our desire to show the world what was wrong and what needed to change. We took our hobby of television and made it our passion, and we let our passion start to change the television landscape.

WordPress Enables Change

Having built many sites in many different CMS tools, ranging from Jekyll and Hugo to MediaWiki and Sharepoint, WordPress still makes it easiest to share the data in more ways than just plain old HTML. By allowing us to output our content in JSON with that API, we can create paths for people to transmute our data and display it in new ways we never dreamed of.

In the last two years, I’ve been able to take my simply hobby site from a list of information to a open API for people to get lost in like Wikipedia to an open-data resource for all people to generate dynamic results. Without data we cannot come to accurate conclusions about the world, and without OPEN data, we cannot work together to make the world better.

Taking a hobby as a vector for change didn’t happen overnight. It came with toil and hard work. It came with research of plugins and solutions. It came with hours and hours of watching TV just to come up with a reasonably accurate list of all the queer females on television, and if they were alive or dead. And with this data, we’ve been able to help news reporters and tv show writers visualize the impact on the world. We’ve started to change the world, just a little, with WordPress.

Bury Your Queers

Just telling people “Hey, WordPress helped me power a site that publicized the information of a hitherto uncollected dataset” would be a pretty short post.

I mentioned change was born of a refusal to accept the ‘norm’ in our lives. As it happens, being a queer female on television is more dangerous than being on the Titanic. In 2014, it was reflecting the darkest aspects of ourselves. In 2015, 33 queer females died on TV. Over 40 in 2017. Trans people are being murdered in record numbers today in the real world. All of this is related to the Dead Lesbian trope, AKA Bury Your Queers.

My theory is that the more we accept death in our media, the more we accept it in reality. The media is pervasive and colors our lenses to accept normal when it’s not. There are a lot of hills to stand on and make this point, but I picked the one that reflects me the most, and the one I felt I could tackle. My hope was that it would just be the start.

A Brief History
- December 13, 1971 – Julie Solkin / Executive Suite
- August 15, 1995 – Talia Winters / Babylon 5
- May 7, 2002 – Tara Maclay / Buffy The Vampire Slayer
- May 13, 2014 – Leslie Shay / Chicago Fire
- March 3, 2016 – Lexa / The 100
- June 4, 2017 – Barbara Keen / Gotham
It would take me a while to list all the deaths, so I’ve listed six of the more prominent deaths here. Julie was the first recorded death. Lexa set the world on fire. These deaths, out of well over 270 since 1971 by the way, shaped our perceptions. They told us it was okay to kill off the queers for shock value. But the thing is, with Lexa, last year, people lost their minds.

If you were in the LA area, you may have seen some surprising billboards in 2016. There were four all told, four separate billboards crowdfunded globally via Tumblr, Twitter, Facebook, and a WordPress site. They collected the money and put the billboards up and said that WE would not stop. That wasn’t the end of it. There’s been a convention, ClexaCon, and more activism.

Why WordPress?

One of the interesting things was we all sat down, in our various corners of the internet, and asked “How bad is this, exactly?” Sites like AutoStraddle made a straight up (heh) list of all the dead and all the happy-endings. Spoiler, very few have happy endings. Other sites, like LGBT Fans Deserve Better and LezWatchTV started to make lists of everyone we could find. And we all actually used WordPress.

There are pros and cons for every platform. There was never a doubt in Tracy’s mind that we were going to use WordPress, but I always think about pros and cons. MediaWiki is amazing when you want anyone contributing becuase it allows anonymous edits. But there was too much possibility for abuse so MediaWiki was out. Static site generators like Hugo or Jekyll are fast and secure (go on, hack my html please. Knock yourself OUT). But they’re not very flexible and can be difficult to manage with multiple contributors or non-technical ones. WordPress, though, is flexible, allows for multiple editors, processes images easily, and is incredibly extendable.

What Next?

Obviously I haven’t even begun to touch on the code part, of how you build out the data and make it beneficial to people via tools like plugins or Amazon Alexa, and not even how you build the data so you can do those things.
26 July, 2017
Date, Time, and PHP
I had a case where I needed to convert time from the format of the US centric dd/MM/YYYY to something a little more sane.

A Very Bad (and Stupid) Way

Since I was starting from a set position of 18/07/2017 (for example), the first idea I had was to use explode to do this:
```
$date = "18/07/2017";
$datearray = explode("/", $date);
$newdate = $date[1].'-'.$date[0].'-'.$date[2]
```
I did say this was stupid, right? The reason I’d want to do that, though, is that gets it into a DD-MM-YYYY format, which can be parsed a little more easily. Unless you’re an American. Which means this idea is useless.

A Less Bad, But Still Bad, Way

What about making it unix timestamp?
```
$date = "18/07/2017";
$date_parse = date_parse_from_format( 'm/d/Y' , $date);
$date_echo = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
```
Now I have a unix timestamp, which I can output any which way I want! At this point, if I’m not sure what version of PHP people are using, as long as it’s above 5.2, my code will work. Awesome.

But we can do better.

A Clever Way

Instead of all that, I could use date_parse_from_format:
```
$date = "18/07/2017";
$date_parse = date_create_from_format('m/j/Y', $date );
$date_echo[] = date_format($date_parse, 'F d, Y');
```
And this will convert “18/07/2017” into “18 July, 2017”

Which is far, far more understandable.

So Which Is Best?

If it’s your own code on your own server, I’d use date_create_from_format to control the output as you want.

If this is code you want to run on any server, like in a WordPress plugin, use the unix timestamp, and then use date_i18n to localize:
```
date_i18n( get_option( 'date_format' ), $date_echo );
```
24 July, 2017
Hello Trello

Organizing my life is usually done on the Apple Reminders app. I shove my to-dos in there and it alerts me when I forget about scheduled, repeated, events. Like mailing in a rent check.

But when you have a group of people, it can be trickier, especially if you all use different devices and have different workflows.

Enter Trello

There are a lot of options out there, but Trello is free for the small scale. It’s easy to set up and my friend Tracy uses it a lot. When I realized we needed something better than my list to keep track of everything, I popped over to Trello to make it work.

I’ve used it before, and I use Jira — which is owned by Trello’s Atlassian — so I’m familiar with the basic style of Kanban boards for tracking work. Every project has a ‘board’ and on the board you have ‘lists.’ In each list you have your ‘tasks’ which you drag from list to list to list. The general concept is you have a list of ‘backlog’ where you store everything. Tasks move from there to ‘in progress’ and then to ‘done’ (or they get archived).

There are some things about the flow I find annoying. Like there isn’t a way to mark something as ‘done’ unless it’s scheduled, it just gets archived, but it can work. And you can integrate it with Slack so that’s nifty.

What About WordPress?

I’m going to shoot your hopes and dreams. There isn’t a WordPress plugin for Trello.

Oh fine, there’s WP Trello but that actually is meant to display your boards as widgets or shortcodes. For the life of me, I can’t figure out why anyone would want to do that. No, what I mean is there’s no back-end WordPress plugin where I can go to, say, the dashboard and check out what boards and tasks are being worked on.

I suppose that’s much the point, though. You shouldn’t be managing those things in WordPress. In fact, if you look into it, embedding Trello anywhere is kind of a mess. They clearly don’t want you to miss out on their API and their apps. Their experience matters.

On the other hand they’re very hip on integration, letting people stick in one tool and access everything. I suspect the brunt of the lack of a WordPress tool is due to the fact that there’s no one recommended PHP API. If you go to their community page, you’ll see a lot of python and Ruby, but no PHP.

What Can You Do With WordPress?

Thankfully, you can integrate WordPress and Trello. There are extensions for Ninja Forms and Gravity Forms which let you integrate your form submissions and make them into Trello Tasks. If you use those plugins to allow visitors to post submissions, it’s a near perfect idea. They submit a post, you make a to-do, and your life remains organized instead of wondering who handled which submission.

But if you’re looking for more, you need to consider a 3rd party integration via Zapier or IFTTT. There isn’t even a Jetpack contact form to Trello plugin.

Yet.

21 July, 2017
Yes, You Can Use Enqueues
One of the battles I face with plugins is explaining to people that they really do need to use wp_enqueue_scripts() for their code. And often I get an argument back that they can’t because they need to include parameters.

Hold on to your hats. You totally can.

The Misconception

It’s easy to get confused with code. There are so many different ways to solve the same problem, we get twisted around. Let’s say that you wanted to include the following script in your website:
```
<script src="https://mycoolsite.com/widget.js" async></script>
```
That’s pretty straightforward in WordPress:
```
wp_enqueue_script( 'my-widget', 'https://mycoolsite.com/widget.js', array( 'jquery' ), 1.0.0 );<
```
But. What if you wanted to add this as well:
```
<script type="text/javascript">
    var _widget_options = {
        theme: 'slow' // Choose from 'fast', 'stop', and 'slow'. Remove this property to get the default theme.
};
</script>
```
Now you clearly have to hand-code this into WordPress. Right?

Wrong!

Use Inline Scripts!

You may have heard about wp_add_inline_script before. If not, don’t feel bad. What this does is add extra, inline, code to an already enqueued script.

Which means that to add the extra code, you do this:
```
wp_add_inline_script( 'my-widget', 'var _widget_options = { theme: "slow" }', 'before' );
```
Which will echo out exactly what you need.

The cool thing about this, is what if you want your plugin to have a lot of options? Like you want to use the value for an option to determine what your script should do?
```
$my-widget-inline = 'var _widget_options = { theme: "' . get_option( 'my-widget-theme' ) . '" }';
wp_add_inline_script( 'my-widget', $my-widget-inline, 'before' );
```
And now you’ve got flexibility.

Keep In Mind…

First, the name of the script matters. If you enqueue it as ‘my-widget’ then you call it as ‘my-widget’ as the first parameter in your inline script.

Second, you can change ‘before’ to ‘after’ if you need it to be after the script.

Third, as with all things, make sure you only load your javascript when you must. No one likes a slow site because you’re loading your javascript on every page when it only needs to be on a specific custom post type.
19 July, 2017
Git Attributes: Control Your Vendor Folders
When you’re developing code, a lot of the time you have vendor or bower_component folders that you don’t need. That is, you don’t need them for the code, but you do for the development.

A year ago I explained how I handle my vendor folders. Essentially, I use SVN to ignore things so they don’t get uploaded to WordPress. And that’s great but…

What about Git?

Enter Git Attributes

The .gitattributes file lets you define attributes for paths. What that means is you can assign an attribute to a file which will then impact how various Git operations occur.

Operations are things like checking your code out or pushing a release (something familiar to Githubbers). Basically an operation is when Git does a ‘thing.’ Whatever that thing will be. And the Attributes file allows you to specify what happens to specific files (or folders) when that thing happens.

How Do You Use It?

There’s a lot more to it than this, but if your goal is to exclude vendor folders and .git files from your zips to send them off to people, then you’ll want to have your .gitattributes file look like this:
```
/vendor/ export-ignore
.gitattributes export-ignore  
.gitignore export-ignore
```
This results in when you use GitHub and tell someone to download the zip from it, it will exclude those files.

What Else Can I Do With It?

Have a problem with line endings because one person on your dev team uses Windows? gitattributes can help.

Need to make a change like that for everyone on a system? Or maybe you want to make sure you never include those vendor and documentation folders? The Pro Git Book says this:

Attributes for all users on a system should be placed in the $(prefix)/etc/gitattributes file.

Before you ask, unless you changed it, $(prefix) is nothing for pretty much everyone. You may have a /usr/local/git/etc/ location though.
17 July, 2017
The Unbearable Uniqueness of Functions
PHP 7.2 is on the horizon and one of the battles that we’re still facing is how to name our functions and classes. In WordPress, this is especially hard because we have to consider how our plugins and themes will be used in the global landscape.

Everything Must Be Unique

If you’ve written a self-contained PHP app, you know that you can’t give two functions the same name. So you have function enqueue_scripts and function enqueue_styles and function embed_content but you can’t declare them twice. Names must be unique within an app.

When you consider the fact that all plugins and themes are third-party add-ons to WordPress, the naming situation gets messier. You can’t, for example, use function get_the_excerpt() because WordPress is using it. So you have to introduce prefixes to your plugin (let’s call it “Caffeinated”) like this: function caff_get_the_excerpt()

That works well until someone creates an add-on to your plugin, call it “Decaffeinated”, and they need to use function decaff_get_the_excerpt() which isn’t so bad, but “Tea Caffeinated” has to either use a prefix of tea_caff_ or caff_tea_ and the more you travel down the road, the messier it gets.

Prevent Collisions

The whole point of this exercise in naming is, you see, to prevent collisions between your code and the parent projects you’re working with. You can’t use __ as a function prefix, for example, because that’s magical in PHP land. You can’t use wp_ or wordpress_ in WordPress, because … well. You’re not WordPress.

But preventing collisions gets long and messy and convoluted and you end up with prefixes like edd_stbe_ which is unique but can be difficult to remember what it’s for. That’s why, thankfully, we have the option of a little more selective naming.

Selective Uniqueness

Back in PHP 5, the object model was rewritten to allow for better performance and more features. And this allows us to make Classes which contain our functions, named whatever we want:
```
class Caffeinated {
    function get_the_excerpt() { ... }
}
new Caffeinated();
```
This is extended to the add-on plugins, So we could have class Decaffeinated and class Caffeinated_Tea but within the classes, our functions are more simply named. Also we can call functions from one class into another, like Tea could call Caffeinated::get_the_excerpt() and easily filter that function.

Why is this good? Well it lets you keep the function names simple, but the class name distinctive and thus easier to remember.

Simple Names are Better

One of the cardinal rules about domain names is that shorter is better. The same goes for functions and classes, to a degree. As Otto likes to say, a well named function doesn’t really need documentation. And one of the ways you can get a well named function is by putting it in a well named class. You can also use Namespaces.

Namespaces are magical. By adding namespace Caffeinated; to your plugin file, for example, you can then have a classname of class Settings and not have to worry about collisions, because your class name is prefixed automatically by the namespace. This extends to functions, as you can us function admin for admin settings in the Settings class, in the Caffeinated namespace. And to call that? Use Caffeinated\Settings::admin();

There’s a lot more you can do with Namespaces, of course, but using them to stop your code from crashing into other people’s, while still keeping names obvious, unique, and memorable? Well they’re pretty nifty.

Remember: What’s Your Global?

At the end of the day, the big thing to remember is what your globals are.
- Outside of a class or namespace, a function is a global.
- Outside of a namespace, a class is a global.
- Outside of a namespace, a namespace is global.
Yes, you can have sub-namespaces. But the point is that top-level whatever you pick, be it a function, class, or namespace, must be named uniquely and distinctly and, in my opinion, relative to the code it’s in. Naming things generically ends in tears as they’ll probably conflict.
14 July, 2017