Tag: wordpress

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
Slow Site Troubleshooting: Database Edition
So your WordPress is slow and you’ve already done the needful. You’ve checked your plugins and themes, you’ve put caching in place, you’ve checked for hacks, but it’s still slow, especially on the back end of WordPress?

It may be your database.

More specifically it may be your wp_options table. When your options table gets very, very large, it gets very, very slow. WordPress regularly queries that when you’re logged in, and it’s not indexed. DB indexes are used to locate data fast, without searching every row in the tables. This sounds sensible in many ways, but we don’t

Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed. Indexes can be created using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records. We don’t use ’em in the options table for a variety of reasons, but mostly that it slows things down.

So in lieu of making indexes on your own, what can and should you do to debug things?

Optimize Your Database

Got WP-CLI?
```
wp db optimize
```
Otherwise you can use phpMyAdmin to check tables with overhead and clean ’em up. I don’t use a plugin, I think asking WP to optimize itself is a little weird, but you certainly can. The point here is to keep it clean.

Cache that Database!

Caching makes things better. Right? Kind of right. Mostly right. I use memcacheD (which I often typo as memecached) and that plus an object-cache.php file can cache your DB calls so they’re faster, which is great. Unless your wp_optimize table is too big.

Your cache has two major issues. First, there’s going to be data you don’t want to cache (like private, sensitive information), but also when your cache is too big, or it’s trying to save data bigger than it is, it can make things slower by trying to cache, crashing, and repeating that over and over. That gets worse when we talk about the temp data generated by _transient entries in your database.

Check The Size

Your options table really shouldn’t be large. My biggest, busiest, site is only using 142K. It’s a site that’s old (8+ years now), it’s had many iterations and themes and plugins. You’d think it would be filthy with leftover code, because we all know plugins don’t always clean up. Nope. I did rebuild the DB once, in 2009, when I rebuilt the entire site from scratch, but that was 5 years ago and a lot has changed since then with plugins and themes. The next biggest site, a Multisite Network, has a wp_options of 100k. The biggest I’ve had is one of 500kb and that’s on a test site where I install and delete plugins daily.

You get the point I trust. These things should be small. At most, I’m going to have a lot of _transient entries. But that’s actually issue here.

Clean The Transients

There’s a story here about why WordPress doesn’t really clean your transients. Why? Well as the name implies, transient data is meant to be transient. It should be temporary data, saved and used briefly, and then it should go away. A lot of developers, as it happens, were storing it for long term caches. Like checking when the last upgrade ran, or when a cron kicked off. So while for one, glorious, month we did nuke them all on upgrade, now we only delete expired transients, which doesn’t help as much as it could. As Nacin said:

This leaves much to be desired, but we don’t want a core update to be blamed for breaking a site that incorrectly assumes transients aren’t transient.

Basically people doing things wrong in a way we couldn’t adjust for.

There are plugins like Delete Expired Transients and Transient Cleaner (which has the cutest header image). Those can be used to clean out your old transients.

If you want to go whole hog, there’s a command to clean the whole thing out with SQL:
```
DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')
```
Of course you want to run a db optimize afterwards to actually flush out the rows.

As always WP-CLI has features like wp transient delete-expired and wp transient delete-all.

What if that doesn’t help?

Then you should check the Database to see exactly what the biggest value is. In this case, I ran wp db cli to leap into the database and then this:
```
mysql> SELECT option_name , length (option_value) AS blah FROM wp_options ORDER BY blah DESC LIMIT 5;
+--------------------------------------------------+----------+
| option_name                                      | blah     |
+--------------------------------------------------+----------+
| cron                                             | 12194468 |
| _transient_feed_d117b5738fbd35bd8c0391cda1f2b5d9 |   223838 |
| _transient_feed_ac0b00fe65abe10e0c5b588f3ed8c7ca |    98184 |
| _transient_is_cached_instagram_images_self       |    97315 |
| mytheme_storage                                  |    18354 |
+--------------------------------------------------+----------+
10 rows in set (0.02 sec)
```
CRON is 12 megs. That would be the problem. Of course the only way I know of to fix that would be to totally trash cron and let it start over.

Is That It?

When you see a ginormous wp_options table, what do you do?
23 March, 2015