Tag: wordpress

Editing Content In Ghost Rocks
You may have noticed based on tweets that I’ve been using Ghost daily (mostly) for a little while now, trying to get a feel for it vs WordPress.

You know what? With the exception of wanting to kill people while I was installing it, I really, really, like it for simple blogging.

The editor is a delight, plain and simple. It’s fast. Super fast. There’s nothing dragging it down man. Which ironically is where it loses.

You see, there’s no extendability. It’s like the Old Days of WP, where I have to edit a theme to make widgets. Oh and no apps right now.

Not to mention the drama of installing. It sucks for self hosted. This continues down to installing themes (sucks) and apps (non-existent). You have to reboot the Ghost ‘node’ after every change too. This is not tenable for most people and highlights the need for apps. Oh. Yeah. Apps are a thing that Ghost needs, stat.

Right now, they’ve added in a way to add code to your header and footer without needing to edit themes, which means I was able to put in my Google Analytics code easily.

Ghost is Ghost. WordPress is WordPress. For what I do, WP is right. For plain, simple, blogging, Ghost is good except for the Markdown aspect. I’ve got the hang on it, but it’s been nine years and I doubt it’s ever going to be ‘the thing.’ HTML wins for many reasons.

So what do I want from Ghost into WordPress? That damn editor! Seriously.

The content on the left and preview on the right is great. It live updates and I can see what things look like in the Visual editor while having full code control like the HTML editor. In addition, there’s no place to put in the tags or featured images or anything other than content. Until I click on that gear.

That is slick. And it works great on mobile too. Compared to the fade out and off center DFW editor in WP, which is pretty great, it’s awesome.

Of course I looked at the available plugins for WordPress

Gust Plugin – This looked great, but it doesn’t work on Multisite. On WP 4.2 it threw this:
```
Fatal error: Cannot redeclare get_avatar_url()
(previously declared in
/wp-includes/link-template.php:3414) in
/wp-content/plugins/gust/gust.php on line 202
```
Then there’s Splitdown – Not updated in a year and also errors:
```
Parse error: syntax error, unexpected T_STATIC,
expecting &amp;#039;)&amp;#039; in
/wp-content/plugins/Splitdown-master/Splitdown.php
on line 19
```
Finally we get to PrettyPress – This isn’t a ‘Ghost’ plugin exactly but it makes a second ‘editor’ you can flip into. No save button there, but as an editor it’s rather nice.

At this point, I’m resigned to not having that kind of slick editor in WordPress. I do think it’s a nicer direction than ‘distraction free’ as it’s actually fewer distractions. All I see is my content and a preview.
20 May, 2015
Underscores (A Plugin We Need)
Look. I still hate Your frameworks.

I really do. They’re a decent idea with a terrible reality. The concept of ‘a plugin to build other plugins’ is nothing at all like a Parent Theme. A plugin that builds other plugins is synonymous with a theme framework or, perhaps you’ll understand this better, a starter theme.

Have you met _s?

_s (aka underscores) is a starter theme. Themes are built from it. In and of itself, it’s not a theme you’d see on WordPress.org because in and of itself, it’s useless. It’s not a parent theme, it’s not even a ready to use ‘drop this theme in and you have a site’ sort of thing. No, in fact if you installed it, it would look terrible.

Because the point is not to use it as a theme, but to use it to build your theme. No one in their right mind uses Underscores as a parent theme. No one uses it as a drop-in to their themes. It’s a, literal, framework where you say “This is my Theme Name, this is my slug.” And then it drops out the code for you to start plugging into.

What do the existing framework plugins do?

The problem isn’t what they do it’s how they do it. They’re not frameworks. They’re libraries. A library is like the AWS SDK library. It’s a vendor based addition to your code that enables it to do ‘a thing’ but, in and of itself, doesn’t do anything. A library is a great tool and lets you include code that you’re going to use but don’t want to reinvent the wheel. I love them. Another example would be that Font Awesome is a library.

But we don’t allow libraries, themselves, in the repo. That means if you write a Font Awesome plugin, it has to actually do something besides just include Font Awesome.

And the point here is that a plugin, like a theme, has to be usable. It has to stand up on it’s own and do something.

Is a library perfect?

Once you take your framework plugin out of the repo, how do you handle upgrades?

Obviously you can run your own upgrader (which we’d encourage) but if the plugin is folded into another plugin, you’re not able to just upgrade YOUR portion. So you have to wait (and trust) the plugin dev will update their plugin and include your latest version.

Mind you, this is an existing problem with plugins and libraries and, in a way, is related to why we don’t allow you to use your own copy of jquery. Conflicts! Yay!

How does _s handle updates?

This is something Konstantin’s thought about before. Funny thing, Underscores is versionless and it doesn’t update often.
Here is a list of reasons why you should not update your _s-based theme with our changes to _s:
- Most likely your theme code will have evolved to a degree where merging _s changes would lead to conflicts. They also won’t be applied to anything you created on top of it.
- We are in the unique situation to not having to worry about backwards compatibility when we commit changes. And we don’t!
- Once you release your theme, you’ve probably fixed all the things in _s that needed fixing for your case. Just because we push an update to _s, it does not necessarily mean it applies to your theme.
Basically there should be no updates to your framework.

And that terrifies a lot of people. Because the extant framework plugins update a lot. In fact, some of them want to be in the .org repository specifically because they update a lot.

They shouldn’t. And that’s why I think they’re doing it wrong.

Be a Starter Plugin

Stop trying to be a framework. They don’t work, they’re not sustainable, and they’re problematic.

Be a starter plugin. Be a plugin that I can download. Use that underscores form so I can download everything set up for ‘me’ right away, no search and replace needed. Have a template settings page that creates basic options, just like a theme. Except that plugins are not themes. And there’s the real issue. A theme is ‘easier’ (and this is subjective) because it only has one interface: The customizer.

Plugins can add a menu section, they can add an option to an existing area like discussion, they can be silent and have no information and just work. Plugins can do anything and in any way. There’s not a ‘standard’ because there really can’t be.

Is There An Answer?

I think the starter plugin would work, if it came with options. It would more likely be a workflow. Where do you want your menu? Will you connect to an API? Will you need settings?

If someone can boil that down, it would all be better.
18 May, 2015
Mailbag: What’s The Diff?

How do you compare two plugins to see if one’s a fork or stolen? What’s the difference between a fork and a clone?

Sometimes people like to ‘steal’ plugins. This normally happens when someone takes a premium (purchase only behind a firewall) plugin and attempts to give it away for free on WordPress.org. They tend to violate copyright when they do that, but also it’s just not a cool thing to do and I find it distasteful.

Often we catch these since people who steal like that aren’t always very smart and we recognize code that is generally well known and popular. But more often we don’t catch it because CodeCanyon has 3400+ plugins and WordPress.org has 37k+ and that’s a lot to compare and remember. And that’s when we get an email from a plugin developer who says “So and so stole my work!”

What do we do? We ask them for a copy of their code, in a zip, and say we’ll compare. Most developers are happy to do that. We’re a trustworthy lot, otherwise we wouldn’t be on the plugin team (yes, being a good, moral, and ethical person is very important). Once I have the zip, I download the claimed-clone and compare them line by line.

Well. Not really.

My toy is DeltaWalker.

With DeltaWalker I can compare two zip files without having to open the zips and look at each line. In the below example, I’ve got Akismet 3.0 vs 3.1.1 and I can see every single change just by tossing the zips in as files to compare:

DeltaWalker is so good, it helps me compare the readmes so I can easily see that someone has just fiddled with the original and not written their own.

What I look for is code style, formatting, and naming conventions. Rarely do two separate individuals use the same code formatting (tabs vs spaces vs tabs+space etc), so seeing their additions will jump out. Similarly, the code style, their internal logic, is often wildly different. Same with naming conventions.

When you look at it, it will jump out at you that generally all anyone does is rename functions or classes. They remove credit and copyright information too, and sometimes they mess with the help docs. Rarely do they add anything of substance. If they do then it’s a legit fork and we’ll push them to restore credit and copyright information.

But since it’s generally not, we will quickly see that the plugin is a direct, no feature added, copy, and remove it.

If this happens to you, if your plugin is ‘taken’ and duplicated without any code being added, email pluginsATwordpress.org with a copy of your original plugin (and a link to perhaps prove it’s you) and we’ll look at it. If you get an email where we tell you that your plugin is a copy, take a moment to review your code and feel free to talk with us about it. A ‘one line’ change actually MAY be acceptable as a fork, but it’s rare unless it’s adding in a massive feature, or totally changing functionality.

Above all, remember this:

Despite the fact that all plugins in our directory are licensed under the GPL or compatible licenses, we do not allow direct copies of other plugins to be re-listed under somebody else’s name. “Forking” is acceptable only when the resulting fork is of a substantial nature, or when the original plugin is no longer updated or supported.

Always try to contribute back to the original plugin’s authors if you wish to make improvements to the original plugin, instead of creating an entirely new version and thus creating incompatibilities and duplicated code in the repository.

Alternatively, write your own plugin to perform the functionality you want to have, drawing on ideas from the original. Ideas can always be copied.

1 May, 2015
Mailbag: Homogenous websites?

I have a site for my business that has multiple physical locations that have online booking for each location. Right now we basically have separate websites that look very similar for each location (except for some content) with separate domains [URLs redacted]. Is this what you meant by homogenous websites? If WPMU ins’t a good option, can you steer me in the right direction for how you would design this type of site?

Yes. That’s pretty much exactly what I mean when I call a site “homogenous.”

You can’t see it, but each URL I removed had identical design. Same layout, pretty much the same splash page.

When I talk about ‘sameness’ with websites, I really do mean exactly this. Each site on the network has the same information, the same about page, and actually pretty much the same everything except for the booking page.

Right now, each site has a locationdomain.com/book-now URL. Without looking at the code, I’m going to guess that the book-now pages are inserts. Either templates or shortcodes, but something that doesn’t need to be on the domain URL to be unique. Just some content in the page.

And I would have maindomain.com/book-location Or better still maindomain.com/location/LOCATION/book

That second example looks weird, I know. You see, I’d do it with Custom Post Types for each location. My CPTs would be pages and their slug would be /location/. Then each page would be LOCATION, giving me URL formats like /location/lexington/ and so on.

My thought process is that if the majority of the content of each site is the same, and the design of all sites are the same, then I don’t need a multisite unless there’s a specific need to silo data.

There are very few cases, in a homogenous network, where you need to silo data. Exceptions are pretty much all based on legal requirements.

And if you have a song in your head, here it is:

24 April, 2015
Mailbag: A Case Against (Part Of) Jetpack

You told me to try Photon, but I noticed you’re not using it on all your sites. What gives?

When people ask me how to speed up their sites for images, I often recommend Jetpack for the CDN boost. It’s a double edged sword, though. While Photon does two things amazingly well (resize images and put them up on a CDN), it’s hosted on wp.com which means I can’t use it.

What? Why not? No, it’s not that I have something against wordpress.com, it’s that other people do. Like China, Pakistan, and Turkey.

The list is probably longer. But those places, among others, block WordPress.com which means every module of Jetpack that phones home (stats, photon, tiled galleries, LaTeX, related posts, etc) cannot be active on my sites that have a large enough user-base in those places. When I leave those Jetpack features on, the site grinds to a halt for them, which is a terrible experience for my (often non-technical users).

Now that said, I do still use the stats plugins on all my sites with Jetpack. It’s a pretty safe loader to run, and it doesn’t slow the site down terribly (see Issue #566 for the code magic). Photon on the other hand I had to disable entirely because my poor users in China were complaining they could see nothing. I can live with a little delay for loading. I can’t live with an image heavy site not working.

So should you use Photon? Yes! Unless your visitors are blocked by WordPress.com.

17 April, 2015
Defines, Variables, and Plugin Dirs
If you’ve spent any time looking at PHP code, then you’ve seen defines and variables

Defines

A define looks like this:
```
define('SOMETHING', true);
```
This makes a global constant that can be used anywhere. In the case of WordPress, it means they can be used across multiple plugins or themes. This is very useful if you make a suite of plugins that all have the possibility of using the same API key. Then you can tell a user to put define('MY_PLUGIN_API', '123456'); in their wp-config.php file, and tell your code to check for the define.

A define also cannot be redefined. If you call it twice, you get errors, so you should be as unique as possible when creating yours.

Variables

A variable, meanwhile, looks like this:
```
$SOMETHING = true;
```
Variables only exist where they are, so if I have one in one function, I may not be able to call it in another. You can make global variables if needed, and in fact if you don’t, the variable won’t be available to all functions.

Which Should I Use?

Keeping in mind that defines are constants and variables are, well, variables, the idea is that a constant should be used for things that should not change in the running of the code. It also makes your code easier to maintain if the things that must be constant are explicitly so.

So what’s a good define? Actually not really this:
```
define('MY_PLUGIN_VERSION', '1.0');
```
This is a constant, it’s something you should be setting and it shouldn’t be overwritten, but actually I’d want to make it a database field to check on before upgrading. Remember, you should be changing that define on upgrade, so having it be a declared constant is a little odd. Now that said, it is a good one when you consider you don’t want someone to willy-nilly override it. Except … what if you do? What if you want someone to be able to change it back to re-run an upgrade?

So then really not this either:
```
define( 'MY_PLUGIN_PATH', plugin_dir_path( __FILE__ ) );
define( 'MY_PLUGIN_URL', plugin_dir_url( __FILE__ ) );
include( MY_PLUGIN_PATH . 'lib/asset.php') ;
```
Someone’s probably thinking that their plugin directory is a constant and, thus, should be defined like that. Maybe, but it’s a pointless define in WordPress. You already have plugins_url() (which this example isn’t using) but it’s really where people use that code that makes no sense. That’s why I included the second line there. That’s what they use it for, and it means two lines of code for one function call.

This actually magically becomes a good define when you have a complex plugin with multiple files and you need to grab the main plugin directory in sub-files. But if your plugin is one file (and yes, that’s where I see it the most), it’s overkill.

This is a good define:
```
define('MY_PLUGIN_APIKEY', '123456');
```
But that should never be in your code itself. Not for WordPress at least. That should be in the wp-config.php, like I mentioned before.

Basically … there aren’t great reasons to use defines unless you want things that never change. define('MY_PLUGIN_SUPPORT_HOME','http://help.example.com'); would make sense to me, as would other contact info you want to make sure is never subverted.

What do you think define is best for?

I’m interested to hear what you guys like to use defines for. I’m certainly guilty of using them for some pretty silly reason.
1 April, 2015