Tag: plugins

I Hate Your Framework
The plugin itself was one PHP file and three JS files.

The framework was over two megs.

The plugin added in a new setting to select which one of the three javascript files should be called.

The framework ‘made it pretty.’

I’m right up there telling people that the WordPress Settings API is a giant bag of wet hair. It’s confusing, it’s cryptic, it doesn’t always play well with everything, and sometimes it makes you feel like the point is to make us have decisions, not options, for our plugins. But I don’t think plugin frameworks are the answer. At least not the way most people seem to be going about them.

When I say frameworks, I don’t mean the libraries like the AWSSDK for PHP framework that you package up into your plugin and do a proper check for a function, calling yours if the the library isn’t there. No, I mean the plugins that are totally separate plugins but are meant to be called by yours in order to make development easier and more consistent.

That’s what I hate.

I love the idea of these frameworks, actually. I think that a boilerplate plugin, similar to _underscores, where I can put in my plugin name, my information, and press a button to have the basic plugin files generated for me is brilliant! But I think most of the libraries out there are doing it in a way that will annoy and upset most people.

The problem is less the framework and more the people using them as a ‘quick fix’ without properly thinking about what they want to do.

They’re Too Large

In the case of this plugin, one file with three settings could just be done with two functions (maybe three) and instead he’s made a download half the size of WordPress core. The zip is large, it makes things take just a little bit longer for people on slow servers to download and upgrade, and the larger you get, the worse you are for the really small shared hosts. I know a lot of people argue with me about this, but remember than a high number of hosts still default you to allow 7M in PHP upload size. That means when your plugin becomes the 30 meg behemoth with all your dev files, you’ve made things pretty bad for some users. But even when you’ve only made your plugin 2 or 3 megs, why would you do that when you have one file of actual code?

The logic escapes me.

They’ve Got Too Many Files

Not the same thing as too large! There are hundreds of files in a framework, and if you’re using only 4, that means you have 96+ files to review for security. You just increased your workload for not enough value. Which is really a major part of my next issue. The point here is you, the developer, are responsible for every single file in that framework. You are expected to know everything about it, where it installs, what it uses, why it uses it, and when to upgrade. This is a pain. It’s a chore. And it’s your job now.

You Don’t Know How to WordPress

This is also why I don’t like the idea of making Multisite too much easier. The further you take a developer from writing this code, the further they get from understanding how it all comes together and the harder it is for them to debug their own plugins. If you’re developing a plugin you plan to share with other people, even a teeny tiny one, you need to understand what you’re doing. You need to learn about the way the code interacts with the CMS tool, you need to understand why some things are secure and others are not.

You Use the Frameworks Wrong

I said before, I love the idea. And I do. They’re a brilliant idea and, when done right, work perfectly. The problem with them is, a bit, a problem with WordPress, which is we really don’t have a way to handle children plugins. You see, the best thing for a true framework plugin would be to have it be a separate plugin. But without plugin dependency support in core or the directory, it becomes another level of hassle for users.

For example… if you have the plugin as a separate plugin, these are the issues we’ve see for end-users (not developers):
- Not recognizing the framework plugin, and thus deleting it (causing the plugin(s) to break)
- Not recognizing the framework plugin and thinking they’ve been hacked
- Updating the framework plugin separately from the dependent plugins, possibly leading to breakage
- Updating a dependent plugin without updating the framework, possibly leading to breakage
- Different plugins requiring different versions of the framework
And bearing in mind that the framework and plugin developers are different people, that’s another level of coordination/compatibility issues. Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.

But I still think that’s wrong.

I still think the best framework plugin isn’t a plugin at all, it’s a tool to help you design and build a plugin via your editor of choice. Or maybe a Grunt Script that lets you build it out based on parameters. Time spend making a framework for making the plugin ‘interface’ better would be better spent making the Settings API better.
18 March, 2015
Mailbag: What Code Makes You Sigh?
When I was talking about ThemeForest, I mentioned we had code on WordPress.org that made me sigh. Or cry depending on the day.

Here it is:
```
if (!defined('WP_CONTENT_URL')) define('WP_CONTENT_URL', get_option('siteurl').'/wp-content');
if (!defined('WP_CONTENT_DIR')) define('WP_CONTENT_DIR', ABSPATH.'wp-content');
if (!defined('WP_PLUGIN_URL')) define('WP_PLUGIN_URL', WP_CONTENT_URL.'/plugins');
if (!defined('WP_PLUGIN_DIR')) define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/plugins');
```
Why do I sigh?

It’s not needed.

You can use functions to determine those directories and while I’m sure someone’s thinking “But WP_PLUGIN_DIR is shorter than plugins_url()!” it’s not.

That code block above was used so that one line of code could exist.
```
include(WP_PLUGIN_DIR.'/PLUGINNAME/settings.php');
```
Those four lines, plus the include, could be replaced with this:
```
include( plugins_url( 'settings.php' , __FILE__ ) );
```
So yes, I sigh. Because with just a little work, you could see that there’s a more efficient way to make your plugin smaller.
6 March, 2015
I’m Fine With Envato

I just don’t use ThemeForest.

Look. I think Envato is actually pretty awesome. They’ve made a way to help people monetize development within WordPress. I’m all about that! I want to see people making a living from WordPress and I want people to be able to succeed and make WordPress even better. A number of people I know who are currently successfully running their own WordPress related business got started over there.

So why don’t I use their products? I haven’t had a need to. I don’t use WooCommerce either, or their themes. There’s nothing wrong with that. But there is a ‘problem’ with Envato, or rather there’s one with ThemeForest, and it’s the same problem as we have on the WordPress.org plugin repository.

The last (and possibly only) time I mentioned them, I said I had an issue with their lack of upgradability. If I buy a theme or a plugin, I can’t easily get updates. I’m stuck on the old way of download when I get an email. There’s no way to do it easily from inside my dashboard. This is a problem of our own creation. Ten years ago, that was normal. Today, we have a reasonable expectation to easily upgrade WordPress, it’s themes and plugins.

I happen to know Envato’s working on it, so I still look forward to their solution.

But they have the exact same problem as we have with the WordPress.org plugin repository: crap code.

You see, there’s only no practical difference between the WPORG repository and ThemeForest and how it handles reviews except they actually may be checking on every upgrade. If you didn’t know, ThemeForest does review things. But they do it exactly like we do! They read the code, they test it, they look for evil things, and they approve or not.

Theme review on WPORG is a tighter ship than plugin, for a few reasons, but frankly I doubt the overall quality of code on WPORG (plugins) or ThemeForest is all that different. We’ve had some pretty insane vulnerabilities in plugins, after all, and the WPORG repository doesn’t have a great way of dealing with them. But to say that you don’t trust ThemeForest because the code quality is bad while simultaneously using any free plugin from ORG is naive at best.

The constant problem we have with plugins, and one they have with ThemeForest themes, is that we allow a lot of different types of code. In being liberal like we are, we can allow for a lot more creativity and expression and, well, art. The downside is that there’s a practical limit to what a human being will be able to catch. We’re like the TSA. We try, but we’re fighting a loosing battle and that’s why we’re always going to miss things and we’re always going to be running behind and cleaning up.

And worse they have the same problem with any code they yank. How do you upgrade everyone? When is it right and safe? When is it an overstep? Weighing security risks with information with compatibility is complex. For the WordPress.org repository, we have a long way to go before we’ll be able to push minor security updates like core can… at least not without a lot of fear and consideration. We’re on the road there, though, so one day you may wake up to a plugin magically secured on your site.

Oh and as a reminder? If you see a WordPress.org plugin hosted that is insecure or doing evil things, email plugins@wordpress.org with the plugin URL and all the possible information about how it’s insecure. If you know how to hack it, please tell us exactly what you did. You make it faster for us to sort things out.

For Envato, you can report these things via their Helpful Hacker program.

2 March, 2015
Stop Using Copy Protection
I’ve seen a million features out there to ‘prevent people from stealing your content.’ The idea is that by preventing people from (easily) copying your work, you stop them from stealing it and profiting off your efforts. You may even think that you’re saving your images from being stolen. In general, they use javascript to prevent things like right-click, view source, copying text, and disabling keyboard short cuts. In general, they suck and here’s why.

User Experience

Anyone who uses a screenreader or an alternative mouse tool now, officially, hates you. You’ve made your site look like absolute crap. Some screen readers can no longer read your content at all. Also not everything handles javascript very well (which is by far the ‘most popular’ way to block out content) and that makes for a pretty lousy experience for your visitors.

Support

If you have a problem with your website and ask the world at large for help, they will take one look and hate you. No one can easily help you with your CSS or your layouts or your design now, because you’re protecting content. When customers ask for help, the first thing I do is turn those plugins off so I can use my normal debugging methods and not worry about cruft interference.

It Doesn’t Work

If you disable right-click, you make it harder for me to bring up Chrome’s dev tools, but not impossible. You can’t make it impossible. This is, in part, because there are so many different browsers to account for, but also because developers really don’t want you to be able to kill dev tools. We need them to fix the web, and if I were to leave the dev tools open and then visit your site I would be able to have it open on your site.

Once I have dev tools open, I can view the resources loaded by your page. Take Instagram, who doesn’t let you right-click on an image to download. I can instead right-click, chose ‘Inspect Element’ and I get this:
```
element.style {
    background-image: url(http://photos-g.ak.instagram.com/hphotos-ak-xaf1/t51.2885-11/10912600_6619567248918_1818171895_n.jpg);
}
```
Guess what I can do now? Load that URL in another window, download, done. If that’s not available, I’ll go over to the Resources tab, open up the Instagram folder, then Images, and find the image I want. Again, done.

There’s Only One Way

There is but one foolproof way to prevent your content from being stolen: Don’t publish it.

But of course no one wants to hear that. So what’s the other way? Well give up on not having your words stolen. Even if you make it difficult, people will get at it. People type up books and scripts today, they’ll do it for your website if they’re properly motivated. Images, on the other hand, are a different issue. If you’re a photographer, don’t put your full-sized images online unless you’re selling them. And if you are selling photographs, put them on a cloud host like Amazon. Large files and PHP aren’t the best of friends anyway. Your website, unless it’s a store, doesn’t need the 10meg image file.

As much as it pains me to say it, DRM is also a solution. So is watermarking your images. The way people like Getty protect their images is to lock it down to purchased users only. You can (fairly easily) download the smaller, sample images, but the awesome big ones are locked down.

But that’s how you protect your content. Not with those plugins.
23 February, 2015
Mailbag: Tools To Keep Consistent

Meg from Ohio (go Ohio!) asks the following:

You blog three times a week about tech. How do you keep doing that?

I schedule posts.

Chris Lema doesn’t, bless him. I started with about 10 posts I had in mind, sat down one day and made myself a buffer, and thought that it would be better to space them out to every other day. It actually started as twice a week, but then I bumped it to M-W-F, and since I’m kind of wordy, I’ve been able to keep up with it. Sometimes I write a post because I solved a problem, which happens pretty much every day, and sometimes I toss out a remark on twitter that people want to hear more about.

Much of it comes from listening and reading a lot. But I don’t just schedule posts. I use the plugin Editorial Calendar to keep tabs on what my schedule is, when things are being posts, and at what time, because I actually really hate the posts lists.

Here’s your default posts list:

It’s pretty bare bones and functional, but one of the things that’s always bothered me about the whole post list is how useless it is. Don’t get me wrong, it’s a list of posts, and it does that really well. But with the moving target that is what we use WordPress for, it’s become rather frustratingly bare bones for me and it really does impact my ability to get work done when I have to bounce back and forth between multiple screens just to see what the status is, verify I updated everything, and by the way, where are all my posts.

So, in the grand WordPress Tradition, I enhance it with plugins.

Admin Featured Image shows the featured image in the posts list, which is really good for one site to make sure I did too set an image and what it is.

UI Labs I’ve actually forked. I need to remember to ping John about this, because I took his (great) plugin and modernized it. If you’re interested, that code is up on my github UI-Labs repo. It’s slowly being improved to make things a little easier for me and to work on WP 4.0 and up.

Editorial Calendar, as mentioned before, gives me a great view for what’s scheduled and when:

The drag and drop interface lets me reschedule on a whim.

Speaking of… Schedule Posts Calendar fills a void that has pissed me off for years. Just look at the comparison:

First, there’s the calendar by the month, then there’s the date, and finally the epic button ‘today’ to let me fast fix posts messed up by the WP iOS app.

So how do I keep posting so often? You ask questions, I answer them, and I have some tools to make it simpler for me.

6 February, 2015
Subdomains and Subfolders, One Network
For the longest time, if someone wanted to have example.com, foo.example.com and example.com/bar for their Network on Multisite, I’d tell them to use a Multinetwork Plugin like Networks+ (which you can buy from e-Books by Ron and Andrea) or WP Multi Network (free from JJJ).

But sometimes you don’t need multiple networks and the multiple admin sections. Sometimes you just want to have options. Thanks to the work that started with the roadmap you can have your cake and eat it too.

If you’ll recall, I detailed how you can map a domain without a plugin on Multisite these days. Guess what? You can also do this with subfolders and subdomains.

I did this with a subdomain install, since it made more sense to go that way.

WordPress is installed at multisite.dev and I have subsites of foo.multisite.dev and bar.multisite.dev

I then made a new site called baz.multisite.dev:

Then I edited that from this:

To this:

Be careful here! If you don’t put the trailing slash on the folder name, this will not work. And does this work? Yes it does. Of course there is the small issue of how this looks on my list of domains:

I have two sites as ‘multisite.dev’ and I have two ‘foo’ sites (because you can also make foo.multisite.dev/zot if you want to). The problem is that the Sites page in the Network Admin has a check:
```
$blogname_columns = ( is_subdomain_install() ) ? __( 'Domain' ) : __( 'Path' );
```
This means the ‘domain’ of foo.multisite.dev/zot and foo.multisite.dev are (correctly) foo. I couldn’t see how to filter, so I made a quick MU Plugin:
```
class Add_Blog_Blogname {
	
	public function __construct() {
        add_filter( 'wpmu_blogs_columns', array( $this, 'blogname' ) );
        add_action('manage_sites_custom_column',  array( $this, 'blogname_columns' ) , 10, 3);
        add_action('manage_blogs_custom_column', array( $this, 'blogname_columns' ) , 10, 3);
    }

	function blogname_columns($column, $blog_id) {
	        global $wpdb;
	        
	        $blog_details = get_blog_details($blog_id);
	        
	        if ( $column == 'my_blogname' ) {
	                echo $blog_details->blogname;
	        }
	        return $value;
	}
	
	// Add in a column header
	function blogname($columns) {
	    $columns['my_blogname'] = __('True BlogName');
	    return $columns;
	}
}

new Add_Blog_Blogname();
```
This tosses the True Blog Name to the end of the sites list. It’s not perfect, but it gets the job done.
21 January, 2015