Having your site hacked is not a fun thing, I can tell you that. You might think that no one would want to hack your site, why should they? You’re wrong! Bots and scripts attack randomly, and chances are they’ve been sniffing your site already. And you know what, one of the reason for this is the amount of publishing platforms, such as WordPress or Drupal, available out there. That makes it easy for hackers to analyze the code, and find vulnerabilities. Likewise, it makes it easy for would be online publishers to get things going quick and easy.

There are a lot of things you can do to at least make it harder for these nasty things. Here are some tips.

#1: You’re Not Done Just Because the Site is Up

make sure that you won’t miss a security release

Congratulations, you installed your content management system of choice! Good for you, now get cracking on that content, will you?

Wait! Before you get carried away and forget all about the code behind the system that powers your amazing site, you need to make sure you’ve got a solid upgrade policy. And by that I mean you need to sign up for newsletters, RSS feeds from development blogs, bookmark sites, and so on, to make sure that you won’t miss a security release.

Take WordPress for example. A lot of blogs are insecure because the operators aren’t upgrading to the latest version. This goes for all online code, be it forums or pretty simple scripts. If there’s a security issue, you need to fix it. Usually that means staying up to date with the latest software, so do that!

#2: The Plugins, Extensions, Addons…

It’s not just the actual content management system that needs to be updated whenever there’s a new version released, the same goes for plugins, extensions, addons, or whatever they’re calling the extra features for your particular poison. Think about it, you’ve got this plugin that does things with your database, probably somewhat regulated, but still a vulnerability enough to make things difficult for you should it be exploited.

As a rule, keep your plugins up to date, and don’t use more than you have to. Actually, it might be a good idea to delete the ones not in use.

#3: The Username and Password Thing

The importance of a good password should be pretty obvious to us all. Don’t use a word, use both letters and numbers, use some caps, add special characters, make it at least 8 characters long… Easy tips. Today, most web apps have analyzers that look at your password and tell you if it is a strong or weak one. You should probably take that to heart.

everyone knows that every install will create this master account

However, there’s another thing here. Your username is right there in the open, after some installs. When you installed your content management system, you probably got an admin account created. That account’s username might be admin, root, master, god, or something like that. Login, create a new account with full privileges, and delete the created admin account! Why? Because everyone knows that every install will create this master account, called admin, root, god etc. - and that means that anyone who wants to hack your site already know the username to an account with full access, now they just have to hack the password.

Don’t make it easier to hack than it already is. And make sure that the privileges of accounts match what they need to do. For instance, the user who writes all the blog posts is pretty public, so don’t give it full admin access, just what you need to write, publish, and edit posts. Sure, you’ll have to login with another account whenever you want to change settings, but it is worth it.

#4: Add Security Stuff

You need to find out if your content management system of choice have any particular brilliant security features that could make life harder for hackers. Like the secret key in wp-config.php for WordPress, for instance.

This will be different from system to system, so read up!

#5: Move the System Core from Public View

consider moving the core files outside the public folders

I’m surprised that not more online platforms doesn’t do this by default. Your content management system’s core files is the ones that power the whole shebang. Without them, the site just won’t work, and that also means that if someone hack them, you’re in trouble.

First of all, consider moving the core files outside the public folders on the server. You won’t be able to move the admin interface of course, you’ll need to access that online, publicly, but the other core files might not need to be in the public folder. This makes it a little harder to mess with them, which is a good thing.

However, not all systems allow this. One solution is to put the core files in a different folder than it usually is, which won’t make it invisible online or anything, but people just surfing known URL:s won’t find it without some hassle. Not too much hassle though, this is something that is pretty easy to figure out, so don’t rely on it too much.

I hope these tips will help you make your site a little more secure. Do you have some tips of your own, or perhaps experience gained by being hacked? Then by all means share them in the comments.

This is an unofficial follow-up to my previous post, titled CSS: Fun With Floating in the Grid. We'll be using some of the same mentality to make floating elements in your design, like pullquotes and boxes containing interesting facts, something I tend to call infoboxes.

Why Would I Want to Do That?

The idea with floating elements containing information or content is simple: It eases up the design. Let's say you've got a mammoth bulk of text, a truly smashing article, but it's really a heavy piece with lots and lots of text. There might not be any obvious images or illustrations to ease it up either, what to do, what to do?

So essentially, the idea is to make the design more appealing.

Simple! Use pullquotes, something magazines are really good at. They're taking quotes from the text, and floats it to the left or right, to break the flow and add some much needed space.

Informational boxes, often containing interesting facts relevant to the content, is another way to do the same thing.

So essentially, the idea is to make the design more appealing. That's why you'd wanna do that!

Pullquotes

You've probably noticed that we use pullquotes here on Devlounge. You can make your own, and add to your site, without much hassle. I suggest that you base it on the blockquote tag, which seems fitting. However, should you be running a blog, then it might clash with your present blockquote styling.

We'll solve that by adding a class called pullquote. Here's the code:

So should you want to have a pullquote to the right, you'll use this code:

Simple, yeah? Naturally, if you want your pullquotes to be styled differently from your blockquotes, you'll have to edit that.

Infoboxes is Just More of the Same

As you might understand by now, infoboxes are just more of the same. We'll use a div with a particular class, to float a box to the left or right.

This is a very simple box, just a grey one with the same font etc. you're already using. Naturally, you'll want to complete this one with some styling that works well with your design. However, this is how you use it:

I recommend using a different font for the content of the infoboxes, as well as using a stronger color for h3 than the actual type (managed with the p of course).

Trimming Down the Code

A quick note to wrap this up! If you really are using the ideas from the previous CSS post, then you can trim down the code for these elements a bit. Since that post wants you to have global classes for floating elements to the left and right, then you can skip the float:left; and float: right; parts, of course.

Sometimes for bigger design projects that will need to be pretty flexible, I tend to use several CSS classes to make it easy to maintain from a design and layout perspective in the long run. If you're a fan of grid-like design, this is most certainly things for you to consider.

Flexible Floating

To make it easier to position elements in a design, from actual content areas (like columns and sidebars), to images and boxes, I employ a set of CSS classes that can be mixed together easily enough.

The core of these classes are:

This means that any element I've given the left class will float to the left. If I add the frame class, it will get a grey 1 pixel border, with some padding between the content and the actual border, to make it look better.

Now, to make sure that images get the necessary spacing to the left or right when being floated, I also add these additional classes:

This will make sure that images floated to the left will get a 15 pixel spacing to the wrapping text to the right, and below. The same goes for images floated right, but to the left and below of course.

So how would this work?

This image will float right, with a suitable spacing to the wrapping text. Well, let's add a border to it to make it look better:

I just add frame to the class attribute to make this happen, not hard at all. In fact, I have in the explanatory image to the right just here.

The really nifty thing, however, is that I can use the classes left and right anywhere, which can be convenient.

If you're a WordPress theme developer then you might want to add the classes alignright and alignleft to your CSS declarations. These are the default classes used by WordPress' image uploader/inserter, so it might be a good idea to support them.

Practical Layout Uses

Nothing fancy so far, right? Well, as I said, by doing it this way, I can easily arrange my layout as well. Let's say I have this 970 pixel wide design, following the grid with three columns of 310 pixels each. You might recognize the concept, it's the new Devlounge design. What I do is that I define the column, like this:

No float or anything. I can also add a wide column, spanning over two columns (310x2=620 pixels), and add the spacing I have between each column in the design, being 20 pixels, bringing it to a total of 640 pixels.

So let's have a wide (double) column to the left, and a single column to the right. Simple:

For clarity's sake, here's an overview of the Devlounge layout, with the columns marked:

It can be convenient to keep the float attributes free of the actual content containers. As you remember, the classes left and right are global stuff that I can pull out whenever I want.

The whole current Devlounge design is built like this, using columns and separate classes as much as I could. I could optimize it a lot more (and I am, whenever I have time), but this suited this build.

Do you use this technique, and if not, why not? Share your thoughts in the comments!

Gravatars are global recognizable avatars, being avatars hosted at Gravatar.com, a service run by Automattic, creators of WordPress and WordPress.com, these days. Since version 2.5 of WordPress there's built in support for Gravatars, using a template tag to display the appropriate avatar, or a placeholder. The default WordPress theme, being Kubrick renamed as default, uses it in comments, which is the common usage of gravatars.

However, with the recent redesign of Devlounge, I decided to use gravatars rather than theme-bound avatars for displaying the author's pretty face. You can't just pull the gravatar code from comments.php to do that, you need to work a bit with the template tag.

First, to display a gravatar you need to register an e-mail with the Gravatar.com service. There, you connect an avatar with the e-mail address. The key is the e-mail address, that's important to remember.

Displaying the Gravatar

The code used here on Devlounge, for the avatar on the top of the single post pages, is the following:

So what does it mean? The get_avatar() is the WordPress call the Gravatar functionality. As you can see, I'm using the template tag get_the_author_id() to fetch the singe post's author ID, which will tell get_avatar() what e-mail to use to look for. I could use other template tags to fetch the correct e-mail, but I went with the ID one.

40 is the width and height of the avatar in pixels. 16, 32, 48 or 64 are more common uses, but 40 pixels fits the design for me.

If you wanted to, you could add a path to the default avatar URL, so that not the default one from Gravatar.com is displayed for people not having registered an avatar. In this case, I'm going with the default one because people are used to it, and when they see that a gravatar can be used, they might be more inclined to get one.

For comparison, in the comments the gravatar code looks like this:

Here $comment calls the comment in question's author e-mail is used to fetch the appropriate avatar, and that one will be 32x32 pixels in size. As above, I could have added a path to a default avatar.

Welcome to the new version of Devlounge. I have revamped the design to make things easier for the people involved in running this site. The previous version, being a nice piece of work for sure (I doubt Splashpress would've bought it otherwise!), had been around for a while, and it's always good to redefine oneself every now and then.

So here we are, with a new version of Devlounge, for all the right reasons, I hope.

More importantly, it was necessary for us to redesign so that Devlounge would fit better in the Splashpress network (which isn't fully integrated yet), as well as find its new voice. You have probably noticed that we have experimented a bit with various types of content during the past month or so, and spoken directly to some of you to make sure that we're reading things right. It's always hard to butt in as the poor bloke in charge of a recently acquired site, especially when you haven't bought it yourself.

So here we are, with a new version of Devlounge, for all the right reasons, I hope.

So What's New?

Besides a visual overhaul, still pretty true to the Devlounge look and feel I'd say, the big news is the way the content is categorized. In the backend, a lot of old things and choices still lingered, which is fairly common for sites in constant evolution actually. The key is to focus it so that you can have actual use of things like categories, tags and so on. It's only natural that things are piling up, so this week will involve me re-categorizing a lot of content to fit our main categories. These have been described earlier, in the sneak peak post, but here they are again:

• Code focusing on PHP, CSS, XHTML and similar, tutorials and snippets
• Design on trends, web 2.0, inspiration, critique and praise
• Opinion being commentary on the web from the staff, will probably delay this one for focusing reasons
• Publishing blog platforms, forum systems, open source applications as well as paid ones, things you need to publish a website, basically
• Strategy for launch and relaunch, monetization and SEO, things to help you succeed
• Webapps is about online tools, necessities, desktop replacements, cool apps, things like that

The reason is of course to make it easier for the readers to find what they're looking for. I have chosen to put the menu to the right, in favor of the descriptive type, otherwise I'm a fan of horizontal menus.

So category listings with relevant content will be coming along during the week, as will a dedicated archive page, an author archives at that.

The front page is new as well. It's not the version I showed in a concept mockup way back, but a more straight forward one, displaying the latest articles straight up, but having space for more visual pushes at the top. I expect to tweak this a bit, to find the way to manage it and use it. It'll be one of those elements where you have to find your way.

What About the Content, People?!

Yes, I'm getting to that. The whole purpose with a redesign is to elevate the content, and I've had the feeling that we needed to do that all along. There's a lot of cool features planned, including my promised ones on bbPress, and I've got some promising writers on the way in as well. The idea is to up the publishing schedule, and offer a solid mix of articles and posts in the topics described above.

The whole purpose with a redesign is to elevate the content

I'm also hoping to be able to look through and update the WordPress themes offered here on Devlounge, with better support. Still working on how to solve that.

And yes, the previous Devlounge design will be released for free! Just don't expect it right away, there's probably a lot of hacking and customization to do to get it download-worthy. After all, it was made for Devlounge, and not general use.

We'll offer more downloadable content as well, as we get back into our groove. Expect cool stuff coming out of the article series planned for this Summer... Tease, tease indeed!

This Week Might Be Rocky

Finally, I'd like to warn you all that this week might be rocky, as I take the time to manage the content as well as clean up a few things. I wanted to get this version out in the open, for feedback (the comments are wide open for you!) and reflection. The idea is to make Devlounge great, and that will take some effort for sure.

Expect a follow-up post on the progress late this week, or (probably) early the next.

Spam is the bane of blogs, ugly links trying to nest its way into your blog comments section to trick your readers to buy their products, download spyware, or just build links. We don't want it, none of us do, and luckily there are ways to stop it.

Solutions in the Blog Platform

You can do it manually, which will work perfectly fine to start with. Just moderate every comment, no problem right? Wrong. That will take time, and the more readers and Google juice your blog gets, the more spam will hit you. It is just not humanly possible to manage spam on a larger blog, it will get out of hand really quick.

Enter the anti-spam measures taken by the blogging platforms. In WordPress you can set up a blacklist and stop all comments with more than two links, for instance, which will help out a bit. Similar solutions are available for Movable Type. Problem is, spammers are sometimes very bright, which means that they alter their spam comments to trick you, so you'll end up with a bunch of spam comments getting by your line of defence.

Enter the Spam Fighting Plugins

The real way to tackle blog spam is using plugins.

Akismet is something of an industry leader, developed by Automattic and shipped with WordPress. The plugin is free for personal use, but there are problogger licenses. Akismet started as a WordPress plugin, but nowadays it is available for other platforms as well, including Movable Type, various forum software, and more.

Defensio is a fairly new anti-spam solution similar to Akismet. It is available for both WordPress and Movable Type, as well as other platforms, which is a good thing. The plugin is free for personal use, but commercial adopters will have to pay.

TypePad AntiSpam is Six Apart's brand new anti-spam plugin built on the TypePad platform's spam protection. It's in beta and totally free at the moment, and available for both Movable Type and WordPress, with more platforms coming soon. The plugin got a very good testimonial from TechCrunch's Michael Arrington, who puts it in the same level of effectiveness as Akismet, which is a great start. TypePad AntiSpam is a plugin that learns from what you mark as spam, which means that you need to work a bit to get the plugin to be really effective. It will be very interesting to follow this one.

Other options are of course available, mostly for WordPress. Spam Karma 2 used to be a lifesaver for me, until Akismet got really effective, and I've had clients being happy with Bad Behaviour. I'd also like to flag for Mollom, an anti-spam plugin for Drupal that is available for WordPress and apparently is looking go the same way as Akismet and TypePad AntiSpam, with wider platform support.

My Weapons of Choice in the Spam War

I used to have a combination of Akismet and Spam Karma 2 on my WordPress blogs, which means most of my sites, and it's been working really well. However, the last 6 months or so I've settled for Akismet, and actually haven't had the need to utilize any other anti-spam plugin. Defensio is yet to impress me, although I wouldn't rule it out. I am waiting for more users to report on how it is working for them, should it get a lot of positive press I'll probably give it a serious go on one of the larger public sites.

Six Apart's TypePad AntiSpam plugin is the most interesting one, however, and I'll be using it on an upcoming project to see how it turns out.

How do you battle comment spam on your blog, and how is the war coming along? Share your experiences in the comments.

It's been a bit quiet on the Devlounge redesign front for some time now. Juggling a lot of project can do that to a man. However, things are rolling again, so expect a relaunch soon enough. No, I won't make an estimate yet, those always break anyway, right? Maybe I shouldn't have said that...

I will, however, give a sneak peak as to what you can expect from Devlounge once the redesign is rolled out. I'm talking about the new categorization of our content.

Brand New Categories

Today's categories doesn't really work well with how Devlounge have evolved. I'm sure the plan behind the current layout is both cunning and brilliant, but things change over time, no matter how well you plan them. A good and logical categorization of content for such an editorial site as Devlounge is crucial. I repeat: it's crucial!

That's why these will be our new main categories, replacing the old ones.

• Code focusing on PHP, CSS, XHTML and similar, tutorials and snippets
• Design on trends, web 2.0, inspiration, critique and praise
• Opinion being commentary on the web from the staff, will probably delay this one for focusing reasons
• Publishing blog platforms, forum systems, open source applications as well as paid ones, things you need to publish a website, basically
• Strategy for launch and relaunch, monetization and SEO, things to help you succeed
• Webapps is about online tools, necessities, desktop replacements, cool apps, things like that

There might or there might not be room for sub-categories. With tags, I personally think that pinpointing a post's topic is better left to the tags, the fewer categories you can get away with, the better.

I'd say that the categories Code and Design are the most important ones, the primaries, with Publishing being secondary, and the rest being less frequent on the site. How does that sound to you? Let me know in the comments.

I need a forum for an upcoming project, and I need to decide which one. I should've done this a long time ago, or at least a last week, but I'm having a hard time making up my mind.

This is where you come in, dear reader! I'm asking you, which forum should I choose: Vanilla or bbPress?

I came to the conclusion that it would be one of these two forums after contemplating these criterias:

1. It has to be opensource and free. Lots of good commercial solutions are out, like vBulletin. Not a money issue, more like a principle...
2. I want a PHP forum running MySQL (or similar). This is because this is something I know something about, and most hosts provide decent service.
3. I want the forum to be pretty lightweight. Basically, I'd rather add plugins for special features, than have everything crammed in there at once.
4. The forum needs to be pretty easily customized. So phpBB is out, and so is PunBB. Not that these are necessarily bad forums but phpBB is pretty clunky, and PunBB won't commit to CSS full-time until the next version.

After much consideration, I went with Vanilla or bbPress. Both are opensource, lightweight, and cool new players. Also, I like the tag support.

So which one?

Pros & Cons: Vanilla

Let's start with the good:

• Seems to have decent support and a fair amount of extensions.
• Easily integrated with X, including WordPress, which I'll be doing for a client soon enough.
• Nice "new" forum layout to build from, always a good thing.
• Good reputation online.

Then the bad:

• Nobody I know have styled nor run it, so I only have second-hand opinions.
• Documentation could perhaps be better?
• The nice "new" forum layout could mean that I have to reshape everything whenever I want a more customary approach.
• Not sure about the theming...

Pros & Cons: bbPress

Starting with the good things again:

• Automattic, makers of WordPress, is backing bbPress, which feels safe.
• I have run several bbPress forums for editorial groups and such. Small, but they're working OK.
• Very fast and lightweight!
• Akismet spam protection, thank you very much!
• Theming to be close to WordPress, which is familiar to me.

And the bad things:

• It's not in 1.0 yet. Who knows what will happen? Is it really ready for a public site? (Probably.)
• Maybe too lightweight? Everything besides writing forum posts is a plugin, not even support for private forums. That's not good.
• I've had issues with upgrades when using the Swedish language. This is a problem that should be fixed, but it could theoretically be an issue until 1.0.
• The admin interface is poor at best.

Help Me Pick: Vanilla or bbPress?

I'd like to hear what you guys think, since I'll be spending some time playing with whichever it'll be, and that means possible tutorials and more for Devlounge. Might even release a theme or two, we'll see...

Which one and why? And remember, it's either Vanilla or bbPress, nothing else I'm afraid.

I've never been shy of throwing stones in glass houses, hoping that they should bounce away and not make it all come down on me. It's more fun that way. With the Devlounge redesign around the corner (the theme's core is more or less done - yes, there'll be more previews before launch), and after that a similar treatment for The Blog Herald, talking common mistakes in redesign seems like a good idea.

Now, this is by no means a complete list or anything, every site and design has its own needs and do's and dont's. See as something to think about before redesigning.

1. Launching before the new design is cross-browser tested. Seriously, sometimes you'll stumble onto a redesign by a what you thought was a serious website, and it breaks in Safari, isn't tested in IE7, or whatever.
2. Launching without giving your readers a heads up. You should definitely inform your readership that a new design is coming, or have a really good explanation ready when you've launched. Chock-launching can work, but in today's very open and transparent web I think you really should let people know that they might see another design next time they pop by.
3. Removing all key recognition elements in one swipe. Don't just null out your previous visual identity, make sure there are some elements left, updated perhaps but recognizable, so that your readers can tell that they're visiting the correct site.
4. Making everything harder to find. Let's face it, you might want to move around elements in your design and that's fine. Just don't change everything at once, or if you do, make sure that everything is in the second most obvious place (the first being your old design's locations of course).
5. Jumping onto the popular style bandwagon. It's easy to get caught up in the flavor of the day, being rounded corners or pastels. By all means, take the parts you like into your designs, but remember what you're redesigning, maybe the style doesn't fit at all, or maybe it just doesn't benefit the site. If you really want to do the design of the day, then by all means do, but consider carefully where you use it.
6. Launching too early. I know, I know, it's very easy to launch early and say "I'll fix the rest later". Well, if you're gonna do a beta launch, be sure you don't pull a Google and stay in beta forever. Make sure you've got a list of features and additions ready, and plan them, so that your premature launch won't come back and haunt you. Ideally, your design is done when you'll launch, or at least appear done, then you can add to it and make it look like tasty bonuses!
7. Redesigning too often. A new design, again? You should commit to your designs, give them time to exist. Maybe they turn out to be "bad" for your site, then fine, go ahead and fine-tune, but watch out for getting caught in the redesign loop.
8. Removing features without an explanation. Some features and functions should never disappear of course, like the search box on most sites, but some might not seem necessary anymore. Well, that might be true for you, but you should make sure that it goes for your readership as well. I like to ask the readers, or at least post about why something was removed, with alternate (better) functionality for them to use instead. That way, they'll complain if I've been stupid and ignorant in my feature-slashing, and the site benefits.
9. Too drastic monetizing changes. This is a tricky one. On the one hand, you need to make money on your site, but on the other you don't want to make the ads too obtrusive. Every change in advertising on your site, be it contextual text links, image ads, or whatever, should be made with caution. This is one point where the chock treatment will not work.
10. Pushing too much new stuff. This goes for design in general of course, but adding too many things to a page makes it cluttered and that's ugly. Since a lot of redesigns are pushed because of the urge to add new functionality, nifty new stuff you have to push out there, this is a common mistake. Don't clutter it, prioritize, and be wary of what you remove to make room for the new things.

Want to add to the list? Post in the comments.