How To Turn Off Comments in WordPress

Over the last year I’ve been asked a number of times how to turn off comments in WordPress after friends’ blogs have got full of spam. It’s not that difficult to do once you understand that it involves two parts: turning off comments in existing posts, and doing it for future ones.

Turning off comments and pingbacks in existing posts

You can turn comments on and off for existing posts using the Discussion section of the Edit Page settings. If you can’t see it, go to Screen Options and turn on Discussion.

Screen Options

Screen Options

From there, you can turn comments and pingbacks on or off.

Turn Comments Off

Turn Comments Off

However, if you’ve got a lot of posts that’s a lot of effort to do. There are plugins available for bulk editing, but I find that using the Bulk Edit section to do posts 20 at a time is fine in most circumstances. To do this, you go to the All Posts page of your Posts, select all the posts you want comments turned off on, go to Edit and on the screen that pops up change All Comments and Pingbacks to show “no comments”. Then click Apply.

Bulk Edit Comments

Bulk Edit Comments

Turn off comments and pingbacks in future posts

To stop future posts from having comments, go to Settings > Discussion and deselect “Allow Users to Add Comments”. This will stop all future posts from allowing them. Alternatively, you may want to make them auto-turn off after a few days.

Discussion Settings

Discussion Settings

if you have too much spam, you may want to try out using a commenting system like Disqus (which I use on this site and has cut out all but spam). If comments are really important to you, you can also use the WordPress endorsed Askimet (free for personal blogs but paid for non-business ones, thanks for the tip as I assumed it was pay only. Cheers Steven Jones and Caroline Murphy for the heads-up).

Moving from Drupal to WordPress

This website began as a blog. And probably a badly made one as well. Hey, it was 2008, and I was trying to get my head around Drupal 6! Since then, I’ve moved half-way across the world, become a better Drupal and WordPress developer, and generally got into the habit of blogging a lot more.

Which is why it was time to move away from blogging on Drupal. After some consideration, I decided to migrate from Drupal to WordPress.

Why the Move?

Drupal is great for many things. Blogging isn’t one of them. I got sick of the extra time it took to upload images (WSYWIG and IMCE, sigh) and the horrible options for formatting in general. Ever since I’d been using WordPress as part of Johnny Holland, I’d been jealous. The final straw was setting up another domain on WP and live-blogging an event on it as the thought of doing it in Drupal terrified me.

Why WordPress?

There are a lot of options out there these days for writing. A lot of devs like file based systems such as Jekyll and Octopress. However, for me, the importance was ease of writing and adding media. WordPress is obviously streets ahead in this respect. While I’m really getting into Markdown, I can do without it for now as a payoff for easy media integration.

Migrating from Drupal to WordPress

A few points on the setup. I’m on Drupal 7 and migrating to WordPress 3.6.

Content

Not surprisingly, there’s a lot of ways to move content from WordPress to Drupal, but not much the other way around. After getting freaked out reading a number of posts which involved editing databases, I realised the easiest option was just to suck in the content on RSS.

I created a RSS file using the Feed view on Drupal. I then used the Multi-importer to link this to a post.

Note: in hindsight, I’d try to download the file, run bulk changes on image locations etc, and then upload it using the importer.

Images 

Images involved a bit of cleaning up on the Drupal server, as imagecache created multiple versions. To play it safe, I copied all the original size files into one folder which I then moved into WordPress. I then used the Add from Server plugin to make them all be picked up in the Media Library.

But there’s a problem! Of course, the old images have the wrong links. I went into PHPMyAdmin and search replaced all old links.

SEO

As this was a slow transition, I moved the blog site from a folder to a subdomain. Once the site was working I used .htaccess redirects to match all old urls with the new ones (the mapping is pretty close anyhow).

Comments

I’d got annoyed with spam a while back on the Drupal blog so had already moved my comments to Disqus. Luckily, there are fairly easy ways to migrate the content over. Once I installed the Disqus plugin, it was a matter of choosing the best means to migrate. As my top level mapping system had changed slightly (from http://vickyteinaki.com/blog to http://blog.vickyteinaki.com), I could use auto-mapping, but as I’d attempted to map all old URLs to new ones, I could use the option of letting Disqus sniff out the 301 redirects.

Gotchas

URL mapping

I assumed that my simple naming system would mean that the URLs would easily map. I didn’t account for one thing. Drupal’s auto-naming URL system strips out a number of small words (‘the’, ‘of’), which WordPress leaves in. This unfortunately meant that I had to go through all of the posts and check for changes. I suspect that for a large amount of posts you would just have to do bulk changes or accept a drop in SEO.

Cleaning up the WSYWIG cruft

The only real disadvantage of pulling from RSS is that you get all the formatting that comes with it. For me that was the original Disqus scripts, and numerous divs from the original feed (though this probably could have been avoided if I checked my Drupal templates).

Linking it all Back

My original all-in-Drupal site included the latest blog posts on the home page as a View. How to do that now? Again, RSS. The Drupal 7 core Aggregator module includes a block for showing feeds (though I had to add a template extra, and suspect I’ll need to make a new view so as not to end up with content duplication/SEO issues).

Theming With WordPress Multisite

I was recently asked to do some WordPress development on a set of two sub-sites that would nest under a main site. It seemed like a good chance to try out WordPress multi-site. However, as per everything, there are gotchas that you find out when actually implementing a new feature.

Why use Multisite?

There are a lot of good reasons why not to use WordPress Multisite, mainly if the functionality is going to change a lot between sites, or there aren’t many common users. However, these sites were a good opportunity to do it: shared domain (though you can map to different domains if need be), a custom theme that would only change in colours any minor imagery between the sites (though this wasn’t quite as simple as I assumed), and a combination of people working on only one site, or needing access across the board.

Range of sites

 

Setting it all up

The Multisite installation is well documented and relatively painless (once you’ve enabled wp-config.php to allow for multisite, you can even make new sites from the WordPress Dashboard!) . The main difference is that when logging in, you become the Super Administrator able to switch between sites and able to activate plugins and themes (see below).

Multisite

However, there are some annoying quirks of the system probably stemming from the functionality originally being a plug-in.

Uploads don’t Share Across Sites

This is probably to be expected, but I mention it anyway. While it does mean in some cases you may have to upload a media asset several times, it also means that administrators on each site can delete files without fear of it breaking one of the other sites.

Custom Upload Paths? Er, No.

I was ecstatic when I found out earlier this year how to get uploads out of that obviously ‘made with wordpress’ wp-content file folder. (Yes, I get excited about strange things). However, if you try and do anything like this with Multisite, you’ll just end up with errors, as far as I can tell. (The files will save, but the media library won’t accept them). So, you’re stuck with paths looking like /wp-content/uploads/site-1/IMAGE.JPG. It’s not ideal for people who’d rather play down the WP aspect or try and safeguard file hacking by moving the folders out of the obvious places, but I guess that this is one of the teething issues for a website becoming a CMS.

Mapping Sub-sites: All Or Nothing

Similarly, the WP folder rewrites are pernickety. As far as I can tell, you can’t have a non-Wordpress top level along with non-WP subfolders.
I was hoping to have the multisite work as subdomains, but couldn’t due to hosting constraints. So, it came down to using subfolders. They actually work reasonably well (you just need to set them in network settings). However, my original plan to have two subfolder sites and a top level static page were quickly scuttled. In short: if you want a top level site and subfolder ones, make them all run as WP sites, even if the top level one is a single page.

The multi-site setup

Plugins and Themes Don’t Have to Be Network Activated to Be Available

Another weird thing to get your head around is the Network Activation settings. From what I can see, Multisite strips administrators of individual sites of the ability to add themes and plugins. However, from the Sites Settings as a super-administrator, you can allow these to be specifically available to a site. This is different from Network activate which makes a plugin/theme available to all sites.
Another interesting point is that you don’t have to activate a parent theme when you activate a child one (useful if you’re worried about people messing with the parent theme and causing all end of trouble).

Themes and Plugins

Theming

Child Theme or Roll Your Own?

In the past, I was inclined to use my own defaults when it came to theming. However, now, I’m more inclined to use child themes, particularly when it comes to WordPress. This is because WordPress changes incredibly quickly, so I assume that their themes should be more likely to make the most of new developments. (Also, to be honest, WordPress has always had great themes, far more so than Drupal, which could often be overkill).

Cancelling things out in functions.php

However, there are some gotchas involved with using these themes. One of the nefarious ones I noticed was the “powered by wordpress” footer appearing as an overlay on the page. These things are easily rectified in functions.php however.

No Grandchildren Allowed

Unfortunately, you can’t have a child theme of a child theme (which you can do in Drupal and is incredibly useful). So, if you want ways to get around this, you have one of three options:

  1. Duplicate themes and activate for each site only. This would be the most painless way, but obviously involves duplication, particularly if you’re making global changes to how the theme appears on both sites.
  2. Use the theme options for each site. To be honest, this is probably the official WordPress way, but I would rather not do it, as it means that your admins can change the colours (thanks to another annoying WP default, anyone who you need permission to be able to change widgets also gets permission to change themes and theme options). In this situation the sites were also highly designed down to the colours, so it made sense to be able to hard code the options.
  3. Use body classes to target specific sites. I preferred the idea in this case of being able to target different sites with CSS overrides and thereby use the single theme as a master theme. However, perhaps unsurprisingly, there is nothing in the body tags that lets you target a specific site on a multi-install. I ended up adding in a class through functions.php. function add_slug_body_class( $classes ) {
    global $post;
    if ( isset( $post ) ) {
    $classes[] = $post->post_type . ‘-’ . $post->post_name;
    }
    return $classes;
    }
    add_filter( ‘body_class’, ‘add_slug_body_class’ );

On hindsight, I’d probably change this to be ‘site-1′ etc as this is less likely to change than the site title (which is what I hacked it from at present).

Other thoughts

The risk of editing themes and other administrator power. As I mentioned earlier, it’s irritating that by default editing widgets also means that you can edit the theme. However, I’ve been helped out by an unexpected benefit: the hosting we use has strict settings when it comes to editing files on the server in that it has to be manually unlocked.

All up, it is pretty cool to see a single theme used in different ways on a multi-install site. And it’s handy to be able to tell clients that they can delete whatever they want on their subsite without worry of ruining everyone else’s. Still, I think it still is early days in regards to WordPress Multisite, and would be happy to see them both improve their upload file system, and allow grandchild themes.