Tag: wordpress

Mailbag: What Plugins Do I Use?

This was actually a bit of a shill from someone I didn’t know, asking to help him with his own ’roundup’ of various experts. I didn’t reply, mostly because I was super busy and favors like this from random people are low on my list of things I’ll ever reply to. But the question is interesting.

Which WordPress plugins do you use most in the following categories: Seo, Social Media, Commenting, Performance, Captcha and Payments.

Answer to all: None.

Seriously, though. The only ‘Social Media’ plugin I use is Jetpack, and that’s just to push my content to Twitter and Facebook reliably. I don’t use any SEO plugins though when I do, I use WordPress SEO because I trust Yoast. Most of the time, my themes handle SEO for me just fine.

Captcha I never use. I won’t. I hate captcha. Captcha isn’t accessible, as I’ve been saying for four years. Similarly I don’t use commenting plugins because I don’t need them, and I like owning my content. When you put up barriers to comments, you get fewer comments.

Performance plugins are a weird area. Yes, I use plugins for that, but it’s got to do with what I installed on my server. I have memcached and ZendOptimizer, so I use a couple things for that. Zach Tollman’s memcached object-cache.php plugin and Batcache. But really most of the work is on the server already having the backend required for those. That’s the same reason I have Google Pagespeed on the server.

Payments… I don’t know how I could answer this. I use Easy Digital Downloads for sales, and I handle payments through Paypal and Stripe right now. But that isn’t so much a plugin question as a who do I trust with my money question. I’d be using them regardless of if I used EDD or not.

Asking me what I use ‘most’ is a very weird question since I use what’s right for the job I’m facing. If that answer is ‘Not WordPress’ then I don’t use WordPress. So with that in mind, I rarely blanket recommend any plugin out there. I listen to people, what they’re asking, what they mean, and how they sound, and I try to recommend based on all to those aspects. There’s rarely one perfect answer for everyone.

If you think I’m joking, read Chris Lema on the perfect WP shopping cart plugin. There are a lot of choices and decisions and options out there, but you’ve got to know what you really need before you make a choice.

Of course for me, when the choice is between two equally well written plugins, I pick the one where I’ve worked with the developers before hand.

26 December, 2014
Mailbag: Can I do it on WP (Legally?)

This one comes from Zara:

I’m about to create a website on wordpress. My website is an escort website. It is adult oriented. The new website would look exactly like my current website […] and I’m considering to build a new website on wp.

Since my friend’s website is built on wp and is escort oriented, plus it was banned by wp, now I’m worried about it all.

Is it allowed to build an escort website on wp?

Yes.

I’ve mentioned it before, that you can use WP for porn because the freedoms of the GPL allow it. More specifically, WordPress states that you can use it for anything you want.

So what’s Zara talking about when she says ‘it was banned by wp’ if that’s true? We’re talking about a couple things here, one is WordPress.org and the other is WordPress.com and yes, it’s a headache.

WordPress.org is the home of the software. WordPress.com is a hosting service that runs nothing but a locked down, managed, WordPress Multisite instance that you can use for free (or pay for add-ons). As a hosting company, WordPress.com has specific rules and bylaws that they restrict their users to. This is, in no way shape or form, a violation of your GPL permissions. They’re not restricting WordPress usage, they’re restricting your usage of their servers and their system.

So yes, Zara, you can use the WordPress software for your escort website, but you need to find a web host who will give you permission to host it. My advice to you is to make sure what you’re doing is legal where you live. Also, make sure it’s legal for your webhost. At DreamHost, I know we allow any website that’s legal in the state of California, which means we host a lot of sites I personally disagree with but will defend their right to publish with my dying breath. Not every website has the same rules, so just ask them if they allow escort sites. They should be able to answer, or pass you on to legal for confirmation.

Good luck!

19 December, 2014
You’re Not The Priority With Free Support

Once in a while, someone flies off the rails when they don’t get a fast enough answer for their question in a freely supported product. They don’t get the right answer, or they get what they feel is a run-around by a total stranger trying to understand the real problem, and basically they feel the service should be better.

Here’s a cold hard truth.

When it comes to free support on free products, you aren’t the priority.

Usually when people get shirty about the ‘lack of quality support’ I point out that (on WordPress.org) support is handled predominantly by unpaid volunteers who are offering sage advice and help out of the kindness of their hearts. This is mostly true. Some of us are paid by our companies to volunteer, others are doing it to master skills (not much teaches you how a product works faster than helping someone else debug it), and others do it because they enjoy it. But as far as WordPress goes, it doesn’t directly pay anyone to do support.

Sidebar: Automattic isn’t WordPress and doesn’t own WordPress. Automattic is a company who pays for some of their employees to help out in the forums. And it’s making my point. Some of us get paid by our companies.

When I tell people that they need to scale down their expectations, what I don’t mean is they should expect worse help, but that they should expect slower help. Because they’re not the priority.

What’s my priority? Number one is my family (hello). But after that you get my paying job. Keeping abreast of everything WP related that impacts us, keeping on top of server changes, looking for patterns in tickets to see if we missed something, and generally knowing everything I possibly can about WordPress at DreamHost. After that my priority becomes the websites I run (like this one) and other hobbies I have.

That begs the question of when is WordPress public support my priority? When I have the time. I try to carve out at least a couple hours a day to check in. These need to be consecutive hours, a nice block of time to catch up and read and help. I don’t always get it. Sometimes I get thirty minutes. And when I am helping out, I prioritize my time.

If there’s an alpha/beta of WP out, I check there first. If we just released a new version, I’m over in the general troubleshooting. Then I hit Multisite, because we have a very small amount of people there. If I still have time, I’ll get the ‘Requests and Feedback’ and ‘Misc.’ forums. Next I hit up the dread Ideas forum, clean out the spam, and sort things that are dupes or solved or in the wrong place.

And then I’ve hit how much free time I have, so I go over to plugins for reviewing those. Anyone who was closed for a security issue comes first. After that, it’s anyone who replied to our emails. Then I close out anyone who didn’t reply in 7 days, check for people with bad plugin names, and finally I can start in on the queue.

It’s a lot to do on top of a day job. So sometimes you will get a reply from me at 8am and then nothing again for 24 hours, because all of those things are important to people and they all need to be taken care of and you, personally, aren’t my number one priority. It’s the same reason why you may not get immediate replies from anyone volunteering, and its why I tell you to lower your expectations.

Free support isn’t better or worse, but it does run at it’s pace and that may not be yours.

17 December, 2014
Hide Your Site on Multisite
Sometimes when you’re building a network, you don’t want all your sites to be available just yet. While you can install a ‘Coming Soon’ plugin, there are also built in ways to handle this.

First you’ll want to take advantage of two of the Network’s least loved features: Deactivate and Archive. When you go to the Sites page on the Network Admin and hover over the items, you have new options appear:

Should you click on Deactivate, you’ll be asked to confirm and then you get this:

Don’t panic!!

I know it says Deleted. It’s not. A deleted site is 100% deleted, the DB tables dropped and the images nuked. So while it ‘says’ deleted, it’s not. If you press Archive it’s a little more realistic:

What’s the difference? In both cases, this is what a non-logged in user sees:

This site is no longer available.

And in both cases, you can’t log in, because this is what you see for wp-admin and wp-login.php.

It’s weird, but it pretty much ‘archived’ the sites. You can, as a Super Admin, see it, but you can’t even change user roles from the network dashboard. (I spent about an hour trying to debug why I, as a Super Admin, couldn’t get to the dashboard at all, and it turned out I needed to flush my cache, so remember folks, caching is wonderful until you shoot your foot.) Still this presents a predicament.

Frankly, I don’t want people to know a site doesn’t exist. That can be easily done with a filter and a redirect:
```
// Archived sites only I can see
function helf_redirect_hidden_sites() {

	// Super Admins always get in
	if ( is_super_admin() || current_user_can( 'manage_options' ) ) {
		return true;
	} else {
		// Defines
		if ( defined( 'NOBLOGREDIRECT' ) ) {
			$goto = NOBLOGREDIRECT;
		} else {
			$goto = network_site_url();
		}

		$blog = get_blog_details();

		if( '1' == $blog-&gt;deleted || '2' == $blog-&gt;deleted || '1' == $blog-&gt;archived || '1' == $blog-&gt;spam ) {
			wp_redirect( $goto );
	        die();
		}
	}
}
add_filter('ms_site_check','helf_redirect_hidden_sites');
```
I wanted to allow my site admins and my super admin to view it, but if you don’t, edit if ( is_super_admin() || current_user_can( 'manage_options' ) ) to only allow what you want. And because I’m using a subdomain site, this makes it look like an archived/deleted site is just another non-existent site, by redirecting to NOBLOGREDIRECT.

But this doesn’t work around the problem that my whole wp-admin is blocked off to non logged in users. I mean, how can I log in? The only workaround is that if the site is a subdomain (test.halfelf.org) or a subfolder (halfelf.org/test), then I can log in at halfelf.org/wp-admin and then visit over. If this was a mapped domain, I’d be in trouble. So it’s clearly not a perfect solution for everyone.

By the way, you can customize the various messages for suspended or deleted sites by creating the following files in wp-content:
```
blog-suspended.php
blog-deleted.php
blog-inactive.php
```
So if you just want it to be pretty, that’s easy.
10 December, 2014
Whose Responsibility Is It?

When WordPress 4.0.1 came out, a small number of sites broke.

For a while, we’ve been touting that minor releases to WordPress core, the ones we auto-upgrade for you, are very safe, very tested, and very important. While all this is true, it has brought a few people complaining to me that obviously I was wrong.

It’s true that the 4.0.1 release broke people. It was an object lesson in why I tell people not to reinvent the wheel. But this upgrade situation does not mean the upgrades aren’t safe, secure or smart. It does bring thoughts to mind, like what my friend David talks about when he considers WordPress at the enterprise level. I know people who are using this failed upgrade scenario as a reason to tout that WordPress isn’t ready for big business, but I think they’re looking at it from the wrong perspective.

Let’s step back.

I used to work for The Man. I’m well aware of the machinations you go through to upgrade anything at a massive enterprise. One of the things they do is a code review. Every single upgrade is checked and tested and a dry-run of the upgrade is run to ensure everything works the way they think it should. By allowing WordPress auto-upgrades, you remove that ability. For a massive corporation? I would turn off the auto-update.

But at the same time, this mythical major company running WordPress would have at least one person who knew WordPress. They would have someone who’s job it was to review every single bit of code that went into their WordPress site. Each plugin would be checked, tested, evaluated for security, and only installed if that WordPress Checker said it was good. Because that’s exactly what you must do in any and all enterprise situations.

David’s viewpoint is that the vetting of a site should be delegated.

My gut reaction to say that they should know better has to be tempered with the fact that no, they should not have to. It’s the job of every site owner to vet their system, but to make a platform that is truly global, that vetting should be delegated. Web hosts and security analysts should vet code for collisions and bugs. Theme and plugin shops should ensure that their products adhere to best practices. Putting accountability for the full stack on each site owner is not only inefficient, but impractical. Inherent trust should exist that code in the official repository maintains a baseline level of code, trust that is eroded when the problems that occurred with a subset of sites on this update occur.

And here, he and I disagree somewhat.

It’s the job of everyone who uses software to be aware of what they’re doing. Vetting the software before it goes in to your system has to be someone’s job. WordPress core does an amazing job of this for you. WordPress core is safe. The 45k plugins and themes in the world don’t always meet the same level of robust checking. Which means when you introduce WordPress to your environment, you absolutely have to seriously review those third party odds and sods you want to use because they’re so shiny and cool.

Web hosts vet code for collisions, sure. We do at DreamHost. That’s part of my and Mike’s jobs! We know what’s going into WordPress and if it’s going to blow things up at DreamHost for our customers. But like the site owner who found her site down one morning because we’d upgraded her from PHP 5.2 to 5.4 and it broke her WordPress 2.5 site, we cannot account for everything.

I think there’s a need for security specialists to review plugins, in a public forum, and point out who’s not doing things in the best way. I also think that there’s a need for developers to remember there’s a reason why we do things a certain way, and while it’s fine not to, you have to keep in mind that it’s now your responsibility to keep a close eye on anything that changes in core that might cause your code not to work as well.

For example. If I wrote a plugin that worked around the shortcode API for whatever reason, I would have a custom query on trac for any ticket related to Shortcodes and have it as an RSS feed to monitor. Or I might even subscribe to the trac firehose and use a filter to pull out anything that so much as mentioned the word. Because I’ve now made a change that I know might be a problem someday.

Every business owner should know the risks of all the software they use, be it website or desktop. This responsibility is the cost of doing business. The size of the business and the importance of the software will change what resources you can afford to allocate to that part of your business, but you absolutely cannot ignore it.

While I really want to say that because WordPress core does due diligence you don’t have to, I would be a lying liar who lies. Even if we do as David suggests and have everyone in the world making sure things are vetted and checked and stamped, it still requires the owners of a site listen to that information and not use the code that’s less optimal. Enforcing that would be impossible unless you wanted to suggest that WordPress outright deactivate code that doesn’t use the proper APIs. That would put a lot of weight on WordPress and slow it down and be pretty annoying for people who are legitimately using non-standard methods of development and implementation.

No matter what, at the end of the day, the person who is responsible for the code quality is the person who wrote and maintains it. But the person responsible for their site is the person using the code. You have to know what code you’re putting into the site and be aware of the risks you’re introducing to your environment by doing so. If your website is your entire business, you cannot afford to be cavalier about these things.

Disasters happen. Understanding the risks will prepare you for dealing with them when they do.

5 December, 2014
Switching The Main Blog on Multisite
Previously I’d only ever posted this in my ebook, WordPress Multisite 110.

What people mean by this is the site they originally set to be seen at domain.com is no longer the one they want to use, but the one at (say) domain.com/temp or temp.domain.com. If this is what you’re wanting to due, it’s not impossible, but it is annoying and a little tricky. If you’re using the trick to give WP it’s own directory, these are not the directions you’re looking for. I haven’t written those out yet.

First you have to go to Network Dashboard > Sites and edit the site you want to be the main site.

This you want to to look like this:

~~Make certain you leave ‘Update siteurl and home as well’ checked! If you forget that, you’ll be sad.~~ You no longer need to check the box (it’s gone in newer versions of WP), but if you DO have it, check it.

Now you’d think you go to edit the main site and change it, but you can’t.

By default, the main site is not editable. This makes sense when you think about how messy this might be, so in order to edit it you have to go to your wp-config.php file and look for this line:

define('BLOG_ID_CURRENT_SITE', 1);

Change it to the site ID you want to use as your main site. In this example, I want site #2, aka, two, to become my main site.

define('BLOG_ID_CURRENT_SITE', 2);

Save the file and then you have to go back to your Sites and edit the old main site.

Give its path a new name and press save, making sure you keep that checkbox checked if it’s there.

In this example, I’ve picked a new URL for my formerly main site becuase I don’t want any conflicts, but there’s nothing stopping me from picking ‘two’ again and just totally swapping things.

The last step is to change your post content. Using a plugin like Velvet Blues Update URLs, you will need to search each site separately and replace the URLs. If you have wp-cli, you can do that too like this:
```
wp search-replace 'example.com' 'example.com/new' wp_posts wp_postmeta --dry-run
wp search-replace 'example.com/two' 'example.com' wp_2_posts wp_2_postmeta --dry-run
```
If those look good, rerun without dry run and call it a day!

An interesting quirk is that you may need to edit the Fileupload URL if you’re using blogs.dir for your images. I noticed that on one site it was set to http://example/two/files which clearly is wrong. To fix that, go to Network Admin, click on Sites, and click on edit for the site. From there, click on the dangerous “Settings” tab and look for “Fileupload URL” and edit as needed to match things.

Cool tricks like this can be found in WordPress Multisite 110.
3 December, 2014