Devlounge

Design, Develop, and Grow

Search Results for: wordpress

Using WordPress MU to Power Multiple Blogs

By

WordPress MU, short for Multi-User, is a WordPress version that you probably have used without really knowing it. Automattic’s hosted blog service, WordPress.com, uses WordPress MU, although what you get when signing up with WordPress.com is pretty far from your basic WordPress MU install.

In other words, like most blog installs before plugins and nifty theming’s been added.

Choosing MU

I choose to build this on WordPress MU for one simple reason: I wanted to be able to create a beta blog in a few seconds, and MU let’s me do that.

Lately I’ve been doing a lot of WordPress MU work for a national blog network that I’ve founded. All is not done, but it’s launched over at pakten.se, if anyone’s up for some Swedish. The front page is one of the things on my todo-list by the way, so don’t judge me too hard now, eh? Links to the seven (as I’m writing this) blogs within the network is available in the top right, in the bar, if you want to click around.

I choose to build this on WordPress MU for one simple reason: I wanted to be able to create a beta blog in a few seconds, and MU let’s me do that.

A Whole New WordPress World?

Nope, it’s not. More or less every theme will work, and most of the plugins available. If you’re running a hosted WordPress installation, you can probably just move every extra little feature you’ve incorporated there, into a WordPress MU blog.

However, MU doesn’t have the ease that WordPress offers. Installation is still simple, permalinks a breeze, but there are a few things to consider. One being the fact that the MU community is small (or very silent), and documentation is poor at best. If you run into problems you’ll soon find yourself in the MU forums, and that’s far from the best way to find information.

Maybe I’m spoiled with the WordPress Codex wiki, a place that’s still valid since MU is basically WordPress for more users, but I thought twice before going with MU at all. Yes, I know, it’s opensource and everyone’s participating for free, yadayada – I can relate to that, and understand it. However, you won’t be having any users unless you offer decent documentation. I most certainly know my way around WordPress, but if I hadn’t I’d never dared to give MU a shot on a public project.

Pros and Cons with Using MU

Remember, this is assuming we’re using WordPress MU to power multiple blogs. If you want to offer your visitors a free blog, then MU really is your only WordPress option, since installing a WordPress blog for each person that wants to blog is tedious and slow.

WordPress MU supports most themes and plugins, as I stated above. It gets better, however. You can put plugins in a mu-plugin directory (much like you do with regular WordPress plugins in wp-content/plugins), and that means that they are automatically available and activated for all blogs.

Time saved for the multiple blogger. Nice.

That’s the good part. The bad part is that it doesn’t work with a lot of plugins, since no admin interface will show up, and if the plugin is manipulating the database, then forget about it. You can still put plugins in wp-content/plugins, however, and activate them manually for each blog. Just like you would if it was traditional stand-alone WordPress installs.

Themes are the same as with original WordPress, with the lone exception that you’ll have to activate them for usage in MU Admin, a new tab for administrators in WordPress MU’s admin interface.

So far so good, right? Sure, not every plugin can be activated in one place, but that’s a small price to pay for just having to update the blogging software on one place, and the same goes for plugins and themes of course.

Time saved for the multiple blogger. Nice.

Problems with MU

Yes, time saved indeed. There are, however, quite a few problems that you’ll have to overcome. Like editing core files for allowing certain tags to be used in the Post and Page writing fields in admin. Per default, you can’t even publish a YouTube video, since some of the tags the embed code uses get stripped away. I found quite a few things that I wanted to allow, since I’m in control of my own blogs – which was the whole purpose here.

Naturally, the not allowed tags are meant to protect the MU administrators when offering blogs for free, to anyone who wants ’em. Still, editing wp-includes/kses.php (where you’ll set allowed tags and so on) isn’t a small thing for someone not used to hacking som PHP. Not very user friendly.

Another problem I’ve had with MU is pinging, still unresolved. Per default, MU pings pingomatic.com, which is fine. I’d like to add more services though, which isn’t possible in admin – I can just add that one. As you might know, you can add just about how many you want in regular WordPress.

I have yet to find out how to add more ping services. Unfortunately, the small MU community haven’t been very helpful yet – and this is a problem I’d reckon could arise to quite a lot of people. What little documentation there is doesn’t help either. In fact, with all the “MU is just like WordPress so read the Codex” references that are out there, I could see users get pretty confused about these things, since pinging several services is a standard feature in WordPress.

(Do you know where I should look or what I should do to ping multiple services in WordPress MU? Get in touch, please!)

Final Verdict for Using MU to Power Multiple Blogs

I almost regret going with MU. It lacks the polish of regular WordPress, and the community is a lot smaller. I feel a lot more left out on my own here, than I did when I first ventured into WordPress.

However, the ease of which I can create blogs – allowing public creation or not – makes up for it. Just having to update on blog system, on set of plugins, that also saves me time.

While I wouldn’t pick MovableType over original WordPress, the lack of support and help for MU makes me wonder if there’s something better out there.

If you know your way around WordPress, and know a little about PHP, then WordPress MU is a good choice for powering multiple blogs. Otherwise you’ll have a hard time, or harder at least – MU isn’t as user friendly as original WordPress.

And by all means don’t expect your fresh WordPress MU install to look and feel like sleek WordPress.com. Then you’ll cry…

Finally, they say MovableType OpenSource will support multiple blogs in one install. It’s just available as a nightly build still, and I haven’t had the time to check it out, but if that’s true then WordPress MU is in for some serious competition. While I wouldn’t pick MovableType over original WordPress, the lack of support and help for MU makes me wonder if there’s something better out there.

Competition is good. Users will be the great gainers here.

Client Friendly WordPress Themes: Header.php

By

So today I wanted to take some time to talk about how you can make a WordPress theme more friendly for your clients, friends and general distribution by taking advantage of the template system built in to WordPress.

We are going to start with the header, an often misunderstood part of the WordPress theme. The part of the theme that can do a fair bit of the heavy lifting in a theme.

Here is the full text of the code I am going to dissect for you today:
[php]

<?php if ( is_home() ) { ?><? bloginfo('name'); ?> <?php bloginfo('description'); } else { wp_title(' '); ?> by <? bloginfo('name'); } ?>

” rel=”stylesheet” type=”text/css” />

[/php]

The first thing that is relevant to WordPress theme authors is the title tag. Most people, by default just put the name of their blog, and a catch phrase as their title and while this is all well and good, for search engine optimization purposes, you might want to go another route. Sure, there are WordPress plugins that can help you add more optimizations to your blog, but I don’t like to have to rely on plugins, unless I have to, especially when I am going to be giving a theme to someone else.

[php]<?php if ( is_home() ) { ?><? bloginfo('name'); ?> <?php bloginfo('description'); } else { wp_title(' '); ?> by <? bloginfo('name'); } ?>[/php]

What I have done here is to basically say, “if we are on the home page, show the blog’s name, and description, otherwise show the title of the current article and then the title of the blog.” While this is not perfect, it is a huge step up from just showing the blog’s name, and description on every page, and every article.

The bloginfo(‘name’) and bloginfo(‘description’) come from the WordPress administration under, the Options -> General panel in the sections that say, Blog Title and Tag line.

The next line of note includes another reference to bloginfo, but this time asking for the template URL.
[php] /images/coolgraphic.jpg” />
[/php]

The next relevant line is dealing with the stylesheet. WordPress looks for style.css when using their templating code, so make sure your style sheet is appropriately named.

To reference it, just use the following code:
[php] WordPress Codex.

[php]

[/php]

If you want your theme to work with plugins that exist, then adding in the wp_head call is very important. This little function allows a vast number of WordPress plugins to add all sorts of code to the top of the theme. I have seen far too many of them not include it, and thus a huge number of users complained.

[php]

WordPress Codex, you too can start to make your WordPress theme work well, no matter who uploads it.

Idea for this post by Chris Garrett of the449.

WordPress Blogs: Changing Hosts the Easy Way

By

Have you been putting off the need to change hosting companies because of dreading the move of your WordPress database? For a static website a hosting change is no big deal, but things can be a little bit more involved for a database-driven site like a WordPress blog. Fortunately, WordPress has an easy solution that can make it a fast, painless process.

When I started my WordPress blog I had no intentions or thoughts of large spikes of traffic from sites like Digg. While our inexpensive hosting held up just fine under normal conditions, it wasn’t sufficient for days with high traffic. The obvious solution is to switch to a host that can handle higher volumes of traffic, but I wasn’t very eager to move the blog.

Within the WordPress dashboard there is an import/export feature that makes this situation pretty routine. The feature was created to help WordPress users migrate a blog from other platforms such as Blogger, Movable Type and TypePad, as well as to allow for moving from one WordPress blog to another. (And even if you’re not considering a move, it serves as a great backup option).

For moving from one host to another the process works like this:

  • When you are ready to make the switch, login to your current blog and go to Manage, Export (see the 1st picture below).
  • Click on Download Export File and WordPress will create an XML file that they call eXtended RSS (or WXR) that serves as your backup. Save this file somewhere on your hard drive.
  • Once your hosting has been switched and your site is on the new server, install WordPress in the same location as on your old server.
  • Login to WordPress and go to Manage, Import and choose WordPress. Then click on Browse and find the XML file that you exported (see the 2nd picture below).
  • Of course, you’ll also have to upload whatever theme and plugins you were using on the old server (and don’t forget to set your permalinks to the same setting used on the old blog).

Export:

Export screenshot

Import:

Import screenshot

The whole process for my recent switch took about 5 minutes. One additional step was needed with my new hosting company. I had to edit the php.ini file to allow for an import of this size, but this will vary from host to host. If you are having issues with this, the new hosting company should be able to help, although most hosts will provide little help for actually moving a database.

Another thing to consider is that the process is easier if you move to a host that offers a one-click WordPress installation. Most hosts now offer this, some of them through services like Fantastico. Otherwise the installation of WordPress will take a little bit more effort, but is still very feasible.

WordPress Tip: Disable and Remove Unused Plugins

By

As WordPress continues to evolve and change, and your blogs grow as well, you may no longer use certain plugins, but forget to deactivate them and this could lead to a huge security issue down the road.

WordPress 2.3 and above has been great about letting you know when there are updates to certain plugins, but if you ignore this update message, or if there is no update notification, and you leave a plugin active, you could be opening your WordPress blog to being compromised.

Plugin authors don’t always think of everything when creating their plugin, and I would hate to see anyone have their blog be hacked due to a vulnerability in a plugin, so please, if you aren’t actively using and updating your plugins, remove them, as you will be closing potential security risks.

I know it is something not widely talked about in the community, but there is no reason to have four or five dozen plugins on your WordPress blog if you are only using three or four. I try to stay away from using extra plugins as much as possible, and I also steer away from any plugin that isn’t actively developed.

If you follow my advice, you will have taken another step to protect your blog, and in this day and age, that is never a bad thing.

I also highly recommend updating your blog to WordPress 2.3.1 if you haven’t already, and making sure you back up your blog both before and after the upgrade. If your blog is compromised, a working data backup can reduce the data loss.

Protect Your WordPress WP-Config So You Don’t Get Hacked

By

Today while at work I was browsing my feeds when I stumbled across a very odd headline: You got h4ck3d!

I thought it was a joke. So I went to the website.

Hacked Website Message

As you can see from the image, the hack is legit. The author promptly removed the post within a few hours and it was like nothing ever had happened.

The way the hacker got in was through the “wp-config.php” when it was readable as plain text. From that, the hacker can get your database name, and your database username and password. This could’ve have easily been prevented, even if the hacker could read the “wp-config” file.

Protect it the .htaccess Way

Josiah Cole wrote a nice htaccess tutorial on modifying your .htaccess to protect the wp-config.

Here’s the code he used:
[php]
# protect wpconfig.php

order allow,deny
deny from all

[/php]

Protect the WP-Config by Moving the File

Now one can move the wp-config to an unpredictable location and change the code in the source, but that would be a pain to do with every WordPress upgrade.

How about creating a separate PHP file in a non-WWW accessible location and use the WP-Config to include that file.

Say for example that your web include path for your server was /home/yourname/public_html/. You can actually save a file in the /home/yourname/ area and it won’t be web accessible. Meaning that even if somebody were able to read your wp-config, they wouldn’t get anything valuable.

Here are the steps that I took.

Create a “config.php”

Within this config.php file I included the following:
[php]

[/php]

I uploaded this file to a non-WWW readable location. Normally this should be the directory before “public_html” or “www”.

Modify the WP-Config

I then modified the “wp-config.php” file to include the file. If somebody were to somehow read the contents of my WP-Config, all they would see is this:
[php]

[/php]

Please note that the include paths change from server to server, but hopefully you get the idea. Save your sensitive information in a non-WWW location, and have the WP-Config file read it in. This way you won’t have to change anything if you have to upgrade WordPress.

Conclusion

If a person with malicious intent finds your WP-Config file and can actually read the contents, your website is exposed. Devlounge wrote an article earlier today that revealed how easy it is for a hacker to change your password (and get admin access to your blog) using phpMyAdmin.

You can never be too careful about these things, so protect your WP-Config and make sure you have a recent database backup.

If there are any more ways to protect the WP-Config that I didn’t already mention, please feel free to add them in the comments.

About Devlounge

Want to read more about Devlounge, or maybe you want to contact us, or even advertise? Oh, and don't forget to subscribe to updates!

The Best of Devlounge