Since I’ve started using the new bbPress plugin more, I find myself wanting the same thing there. I want to quickly see new topics and replies, the same as I can via the Recent Comments widget. So, I created the Dashboard Forum Activity plugin to do just that.

Dashboard Forum Activity

You can download Dashboard Forum Activity from the WordPress.org Plugin Directory. The plugin will add a widget to your Dashboard (only if you are an admin, or more specifically have the manage_options capability) showing newly created topics and replies on your bbPress-powered forum.

From the widget you can jump in and edit any topics or replies, as well as view them on the front end of the site. (Almost the) Same as the Recent Comments widget.

I have further plans for this plugin, but wanted to start simple and get it out. I’ve started using it today as well, and already enjoy it. I hope you will too!

This plugin slows down the dropdown so that it only opens up after a moment’s hesitation on the Admin Bar. It only effects logged in users, so shouldn’t add any overhead to your site.

You can download the Admin Bar Hover Intent plugin from the WordPress Plugin Directory.

That’s pretty much it, since this plugin is pretty straightforward. Hope you find it useful!

Now, first a little bit more detail might be necessary. The exact error I ran into was this:

Site error: the file (filename) requires the ionCube PHP Loader ioncube_loader_lin_5.2.so to be installed by the site administrator.

(If anyone cares, this happened when installing a Plugin called WP-Member to a blog I run called Frontending. More on the relevancy of adding in that Plugin before long .)

Nobody likes errors. When I saw this I did what any able minded person of the modern world would do. I Google’d it. Odds are that you might have discovered this very post by running a search like I did.

Walking through the solution

It should be said, although the post title says so, that this solution is only likely to work when you are hosted by Bluehost. As I am, this is how I figured it out.

So what is ionCube? Apparently it’s a PHP encoder of some sort, that certain applications use in order to run. In my research I was able to see a couple of examples, one where a Joomla plugin was the culprit, in other cases a WordPress Plugin called Fedafi. Basically the host is only set up with the basics of ionCube, and we need to supplement it. 

Open up your site in an FTP client and browse to the topmost level. This is the level that lists public_html as a folder. You should see a folder called ioncube. Crack that sucker open and you should see two files (at least), ioncube_loader_lin_ts.so and ioncube_loader_lin.so. You probably won’t see the ioncube_loader_lin_5.2.so file mentioned in the error message. That makes sense, right?

Run over to the ionCube site and grab the appropriate zip full of the loader you need. Now, in order to determine which of the files you should download, you’ll need to know your server’s OS and architecture. You can find this located in your Bluehost Cpanel along the left sidebar. Mine is running on Linux (OS) and x86_64 (architecture). Find your own and grab the corresponding zip file from the ionCube loaders page.

Unzip and throw the two files with 5.2 at the end into your site’s ioncube folder, the one we identified a minute ago. Now we should be good, right? Well, almost.

Traversing php.ini

Odds are that you’ve heard of php.ini at one point or another, most likely when editing it (or at times creating it) in order to increase the size of files you can upload to your site. Before stepping into this dunghole of a problem myself, I had only ever modified php.ini in order to do that. Now, it’s time for a bit more of an understanding of how php.ini works in cooperation with Bluehost’s Cpanel.

In your Bluehost Cpanel, jump into PHP Config. I usually just run a find/text search on the page to see where it’s located. You should see three options, like in the image below:

First, pay attention to the first three options regarding the PHP you are running.

You can see that, in my case, I’m now running PHP5 with FastCGI. There is a lot having to do with this decision that I won’t cover here, but one reason related to the issue at hand is that we want to be able to only have to deal with one instance of php.ini, and not copy it ourselves into every directory that will be using it. That would just be a pain in the ass. (Note that choosing FastCGI is not necessary for this to work, but it makes it a bit less painful, I think.)

Assuming that you don’t have any major modifications done to your php.ini file, go ahead and hit the “Install php.ini Master File” button, after selecting IonCube from the options above it. Keep in mind that if you do have any worthwhile modifications done to php.ini, you can just copy them and paste them into your new php.ini file when it’s there.

Take a look into your public_html folder. There should now be a php.ini.default file. Kill the file ending so it is just php.ini. Now download it and open it up so that we can make the modification we need to.

Toward the bottom of your php.ini file you should see the references to the basic ionCube loaders. It should look something like this:

Note that the path referencing the ioncube files may be slightly different for you.

At line 118 and 119, we see the references to the two files that were originally in use at our site. But we want to add two more, two references to the two 5.2 files that we added.

The key here is to maintain the nomenclature of line 118, but duplicate it for the two new files. So we’re going to add two lines that look like this: zend_extension=/home/sitename/ioncube/filename. We’re also going to add them directly after the [Zend] at line 1123.

Use this image as a reference:

Again, note that the path to the two files you add will need to be adjusted from what's displayed here.

Once you have those two lines (in the above, the lines added to 1124 and 1125) in your php.ini file, save that puppy.

Given a minute or two for your cache to clear (force a reload if necessary) you should be good to go with whatever problem you’re facing. In my case, I was immediately able to successfully activate WP-Member. So I’m a happy camper.

It should be mentioned that I found a good deal of help with this issue at these following sites.

• The FAQ page I started with regarding this error, at WP-Member’s support site
• This thread at the Bluehost forums with a couple of people trying to figure this problem out

I appreciate their help, and only put this together so that there is one consistent tutorial on the issue. Hope it helps someone!

Today I would like to talk about style, and some of the ways I go about writing CSS. There are lots of methods and tips to find out there, but hopefully I can share something unique that might help you in your writing habits.

Importing Stylesheets

One of the first things I will do in a style sheet is drop in a few imported style sheets, like this:


@import url('css/typography.css');
@import url('css/layout.css');


Importing style sheets keeps CSS trimmed and clean. I also tend to use certain styles over and over again like typography or layout styles. Usually these style sheets can be modified to a small extent to make them usable for a new site design, without having to re-do all of the same code as before.

Reset.css

A style sheet to reset styles initially is crucial to have. By not resetting all of the default styles on the page, you are allowing the browser to decide for itself how it should display certain elements. I tend to agree with the great CSS giant Eric Meyer, who has said:

Elements are nothing alone. They act the way they are told…And I don’t want anything acting like anything unless I tell it to.

Meyer’s reset.css is the best, which is why I use it.

Ems and Pixels

If it were up to me everything on the web would be sized in ems. Unfortunately, it isn’t always possible to build (what I think of as) a vector web just yet. Right now we’re stuck with raster. But while there is an excuse when it comes to sizing elements and their spacing/alignment, there is no excuse for anything but ems for typography.

I start by defining the font size in the body element to 62.5%. This sets the base font size (1em) to 10 pixels, which is pretty easy to scale and keep track of as you go. Then, if I want 12 pixel text, I set the font size to 1.2 ems. You get the picture.

Clean Code

When it comes to the literal act of laying out code things can get pretty messy fast. I’ve gone back and forth about the best way to do this. I used to write in this common way:


div.style {
  font-size: 1.2em;
  line-height: 1.8em;
  margin-bottom: 1.8em;
}


And that works really well. Recently, though, I’ve been doing it this way:


div.style { font-size: 1.2em; line-height: 1.8em; margin-bottom: 1.8em; }


Using this method, I find I don’t have to scroll nearly as much, and to my eyes it looks very clean.

Commenting

Commenting the styles as I write them is integral and serves two distinct purposes: organizing code into appropriate sections and describing styles/decisions/hacks/anything for the purpose of being able to understand it all later.

I use comments to break up my code pretty simply, usually something like:


/* Header */

/* Footer */


And that works pretty well. I also use it to describe certain stylistic decisions and explain some code to myself, for the sake of my sanity later. Every once and a while I think: But I understand how this works. It isn’t really complicated. Ah, but once I walk away from it, three months later, it will be complicated. The best advice I’ve ever heard, when it comes to commenting code, is to think of yourself looking at this three months from now: that is how someone else will look at it, and that’s, in the end, why you want to comment (for yourself and others).

What I Want to Begin to Do

I am pretty good about listing my contact information, version information, etc. in each style sheet, but I am not very good about leaving notes about when the last edit was made. I think that would really be helpful information, especially considering how it seems I am always updating and re-editing code across many different sites/themes/blogs.

Speak up

Was any of this helpful? And even if it wasn’t, point out where you disagree. And finally, what are you not doing that you want to be sure and start doing in your code?

Credit

I was inspired to write this post after reading Creating Sexy Stylesheets over at Think Vitamin. Tim Wall at Element Fusion was kind enough to point my attention there.

• Where, grammatically, should this content go?
• What markup is available that would correctly show this?
• If necessary, how can I style this so that it appears like it seems it should?

From these questions I try to find the best way to mark up content. In this way I want to look at images, most particularly images in blog posts, and see what the best way to mark them up might be.

Where, grammatically, should this content go?

An image is a unique form of content. There seem to be two uses for images, and I’ll attempt to define them below.

Decorative images

Used to decorate the design of a website, usually not critical to the consumption of content

Content images

Used as a substantial source of content within the site, and usually is critical to the consumption of content

A couple of examples of what I’m talking about:

The above screen is taken from Church Marketing Sucks, an offshoot of the Center for Church Communication, something I’m pretty passionate about. As you can see, the background image on the site is for decoration, as is the header sweeper design. I consider these decorative because they could be stripped away without the content of the site going away.

The above screen was taken from an article via A List Apart, which you can see by clicking either the image or this link. Actually it’s not a bad article—it talks about using Javascript to help with image placement, which is yet another technique. Anyway, the point of this page is that the image within the content is intended to work cooperatively with the content, and would detract from the message if it went away.

I use a different technique, depending on whether the image is intended to contribute to content vs. decoration. If something is intended for decoration, I will do my best to make the image the background of a div. Only if the image is intended to contribute to the content (such as the ALA example) will I use an <img> tag.

What markup is available that would correctly show this?

One of my pet peeves is when designers use class titles like alignleft and alignright when styling content images. The issue I have with this is the same I would have if these class names were used to name divs being floated to the right or the left. The problem is simple: the purpose of class names is to identify the purpose of the element, and not describe them according to how you will style them. This way, if you change the style of these elements later, they aren’t classified incorrectly.

This same principle applies to content images. If content images are styled with alignright or alignleft, either by the user or a WYSIWYG editor, their positions can’t be changed later without having awkwardly classified images.

I suggest three classes for content images.

1. main
2. major
3. minor

With this system, I analyzed how images could be aligned and matched them up with appropriate semantic classifications. A main image, for instance, is centered horizontally and text doesn’t wrap around it. A major image floats to the right and wraps text to the left. A minor image floats to the left and wraps text to the right.

The CSS for the images would look like the following.


img.main {
margin: 0 auto 1em auto;
display: block;
}
img.major {
float: right;
margin: 0 0 1em 1.5em;
}
img.minor {
float: left;
margin: 0 1.5em 1em 0;
}


Then all you have to do is add class=“main” or other classes to the img tag and there you have it. Images with proper classifications and correct alignment that could later be changed to fit a new hierarchy or site layout.

Benefits to Proper Image Classification

• Uses classes correctly
• Makes content forward–compatible
• It’s proper semantics

Negatives to Proper Image Classification

• Won’t work well with WYSIWYG editors
• Requires more work/case by the user

These are techniques with kinks which I’m still working out. For instance, I still want to figure out a solid way to use this technique in conjunction with captions. I’m addicted to Arun Kale’s technique in The Morning After theme which I’ve been using at Theme Playground. I’ll post once I perfect this technique.

This post was initiated, in part, by Sarah over at BlueJar with her post How to Position Your Photos and Images Using CSS. I’m kind of a semantics dork, so this topic caught my attention. Overall, I look forward to seeing these things develop, especially as far as valid, semantic blogging is concerned.

I use WordPress for every web project I’m a part of, and I believe each project is that much better for it. Church websites, personal websites, even company websites — all benefit by using WordPress. In this case, however, WordPress was not allowing me to upload or place this particular image for my church website.

I began searching the WordPress.org help forums for some, well, help. The only related advice I could find was that some others had experienced similar problems when they had tried hotlinking an image from another server — or when, somehow, the server didnn’t believe the poster had the right to link it. I had never heard of this before, but then again this had never happened to me before either. Since there had been some mix-ups with our domain and hosting server lately, I decided that must be the problem.

So I wiped everything and had the server admin check over and make sure we were clean. Then I re-uploaded everything. I re-installed WordPress and synced all of the databases again. It took around three hours.

Jumped back in to post the image, and guess what?

It didn’t work. No difference from earlier.

It turns out that the problem wasn’t the server at all. It wasn’t even WordPress. The problem was that the image was called banner.gif. And apparently my ad protection (either my browser or otherwise) automatically blocks things called banner.gif.

Imagine my surprise.

So, take this as a word to the wise (as well as a word to anyone wanting to potentially save three hours of their time): never name an image banner.

I hope I’m the only one to suffer through this. So I hesitate to ask: anyone else have a problem like this one?

I’m looking forward to the event. Things like this always get me inspired. I’m sure I will have lots to say when I return.

Does this strike anyone else as odd?

My first question: Why prove it’s yours? What’s the point?

We’d like you to create a beautiful, functional and user-friendly 404 error page for your own web-site. We’ll collect the most creative, usable and elegant solutions and review them in one of our next posts.

I don’t understand why there is a necessity for the website to be your own. I’m trying to think of a reason that this would be necessary, but I can’t. Whatever the site is will get the credit, not the person who made it. And I’m sure no one would be upset if someone other than themselves submitted their 404 page to some sort of awesome directory.

Why Smashing? Why?

So the next question is: Why would they want people to put “Smashing Magazine” on their 404 page?

Anyone?

Now, I’m not a SEO expert by any means, but I imagine it couldn’t hurt your search engine listing if you were named on lots (and lots) of 404 pages. Would it improve your ranking? I don’t know. Without a link, it’s probably hard to say.

But maybe that’s the reason they’re doing it. Maybe they want to find out what will happen if they get a lot of responses and “Smashing Magazine” is written everywhere, like graffiti on bathroom walls. Then there’s the number of people who will forget to take it off. Already a simple search for 404 pages on Google sets them on the first page.

I’m not sure whether to be mad at Smashing or congratulate them on a clever ploy. What do you think?

body {
font-size: 12px;
}
p {
font-size: 1em;
}

and

< id="wrapper" >
< id="content" >
< id="maincontent" >
< p >This is where text would go. < / p >

Everything after “maincontent” was the size I wanted in Firefox but not the size I wanted in IE. More specifically, everything (anything sized in ems, which meant the widths of columns, margins, and font sizes) was around 10× the size I wanted it to be. Needless to say it caught my eye.

After about an hour of struggling with it I discovered that IE assigns its own base font size unless something is specified in the parent container. So in Firefox (the correct browser) when no specification is found in the parent element it checks the next highest, the next highest, and finally the body defined font size. Firefox uses the 12px size I specified. To correct for IE, though, I had to duplicate my font specification in the direct container of “p” — that is, “maincontent.”

Everything is working well right now. I’d love to talk about the project this is for (a fairly personal one) but I would rather wait until its ready for release. I hope this post helps someone else with the same problem somewhere down the line — I know it really pissed me off last night.