Monkey House

It was never intentional for me to advertise for Envato and their marketplace for so long (and for free!), but for some reason I never got around to removing the ads. Not that there’s anything wrong with Envato– on the contrary, it’s one of the best places on the web to get themes, graphics, audio files, etc… (there, one last final freebie for them. )

What I’m about to explain is hyper-obvious for anyone with web dev experience, but for those of you who are using the Androida Theme as users not as programmers, here’s how to get rid of the ads:

1. Log in as an administrator
2. Go to “Appearance” –> “Editor”
3. From the list of files to edit, select Sidebar (sidebar.php)
4. “Comment out” the line that loads the sponsors.

“Commenting out” means adding comment symbols (which are different from language to language to language) around a piece of code. These comment symbols tell the browser, “This is just a note… don’t do anything to render me.” The reason for using comments is so that you can easily reverse your changes later.

To add comments in HTML, you add “<!–” at the beginning of your comment and “–>” at the end. Now, I wasn’t sure if PHP would still get executed even from inside a comment (certain non-HTML code WILL get parsed, like the code in-between css style tags), but the first try of using the HTML comments showed that it in fact worked.

Here’s the change you need to make (note the comment symbols.. only one line is changed and the others are shown just for context):

That’s it! No more ads. And easy to undo if I decide to put some ads in there.

Alex says to me the other night, “Any way to fix the emoticons on the blog?” (this was after her first post in which I am assuming she wanted to use some emoticons).

Easy peasy! Says I.

The problems are that the emoticon is going off to the left and have spacing/border, as per this image:

First step: see what’s going on with the existing emoticons. Using FireFox, bust open a blog post with an emoticon, KABLAM, open up Firebug and focus on that image. Firebug tells me that the styles for the emoticon image are applied to “img” (images) within the class “entry”:

Well, if you know CSS, you already see the problems: the border, the float, the margin, and the paddings. So basically, the whole class is messing up the emoticons! Non-destructively inside Firebug, I modified those declarations just to prove concept, but the problem was so obvious that I probably needn’t have bothered.

Newbies to CSS or who just sort of learn by trial and error (and we all were at one time) might look up the “.entry img” class in the CSS and start making the changes. However, this would break the rest of the images inside the “entry” div. The example image of “what was wrong” above in this post would be affected along with the emoticons. And we probably don’t want that. What we want is to zero in on the smiley images and style them accordingly.

Back to Firebug.

Firebug tells me that although the styles are inherited from “.entry img” there is in fact another class that the smileys belong to which is even higher up in the hierarcy: “wp-smiley”. THAT is the class that needs to be either added or changed. I know not everyone goes all guerrilla style, so use whatever editing method you think is safest or best for your site. Me, I just went right over to WP’s built-in Appearance Editor and selected Stylesheet (“style.css”). Doing a search for “smiley” turns up the fact that although the post uses that class, there are no styles assigned to it. In other words, “.wp-smiley img” does not exist. No problem, just have to add it to any reasonable place in the CSS. The original author commented a few “categorized” blocks for CSS, so I’ll put it somewhere in the “Main Content” area:

Float is set to none. Margins are set to zero. Padding is set to zero. Border is set to none. Note: I don’t know why it has to be “img.wp-smiley” instead of “.wp-smiley img” but it does. Something to do with inheritance? Dunno.

All done. Update Stylesheet (“style.css”) and you should be ready to rock. If you apply this change to your own site, you MAY need to SHIFT+Refresh to grab a new non-cached version of the CSS. Here’s the end result:

It seems like a small thing, but if you’re a non-developer just trying to fix some niggling little things with this or any other theme, sometimes the small things count!

I’m pedantic. You know it’s true. Every time I tell you that you’ve used an apostrophe incorrectly (come on, people; it’s not that hard!) or that you probably meant “cornucopia” that time you used “plethora” (El Guapo knows the difference!), you’ve seen my pedantry in action.

But there’s a limit. I will start sentences with “but” or “and” in grammatically incorrect ways. I will let my writing “voice” be more important than absolute precision. And I don’t correct people all the time and for no good reason if they’re just doing the same.

Lately I’ve discovered that I’m only semi-pedantic when it comes to web development. It is starting to drive me absolutely nuts when the “markup police” comment in the blogs and forums I read. These are the people who say, “You have an extra div that serves no purpose except to hold an image. Images aren’t content,” for example.

I found another doozy while researching a way to make blockquotes look spiffy. The tutorial used the blockquote tag AND a div (tsk, tsk, you should have only used the blockquote… the div serves no purpose) because 2 images of quotation marks were needed. The comment that drove me nuts was, “You shouldn’t need an image at all; just use large typography.” … You… idiot…. Using images presents design options not available with pure typography or the limited palette of visual enhancements (eg. borders) that we have available with pure markup. In this case, a browser-rendered quotation mark would have required the typeface to be installed on virtually all end-user machines, would require consistent anti-aliasing between browsers, and STILL would have required a stupid amount of markup to pull off properly.

To these people, I say, “get a life.” On one of the sites I maintain, I still use an old CSS trick for rounded box corners. It’s semantically horrific. Have a look:

1
2
3
4
5
6
7
<div class="graybox" style="width:100%;">

  <b class="xtop"><b class="xb1"></b><b class="xb2"></b><b class="xb3"></b><b class="xb4"></b></b>

    <div class="xboxcontent">

      <p>Here's a bunch of content</p>

    </div>

  <b class="xbottom"><b class="xb4"></b><b class="xb3"></b><b class="xb2"></b><b class="xb1"></b></b>

</div>

It’s theoretically awful. For starters, I put an inline style (the width:100% on the graybox) which is a no-no for the pedants. But you know? In 99% of the site, I have a specific width I’m using, which is set in the CSS. I could have added an additional class to the CSS instead, but meh… this worked and took 5 seconds, and nobody who might take over maintenance of the site would have a problem seeing what the extra inline style does. Next, it re-purposes the deprecated bold tag to style a bunch of smaller elements that essentially form the rounded corners. The CSS has a class for each of the sub-components of the rounded corners, the end result of which is simply that the “borders” property is being used 1 or 2 pixels at a time to “draw” a rounded corner. This mish-mash of styled “b” tags has absolutely no semantic meaning.

The whole thing is in theory—and for the pedants—awful. But it works. It looks pretty good. It works across all browsers including IE6.

Sometime soon, now that CSS3 is gaining more acceptance, I will substitute the above code with pure CSS rules using proprietary styling (moz and webkit) plus CSS 3 (border-radius property)… until then, I couldn’t care less if my markup isn’t perfectly “semantic”. This may seem like blasphemy to some, but there’s a time when design is more important than purity of markup. I’m much happier to not have boring rectangles everywhere all over the sites I maintain and develop, and I don’t mind “over-using” images or “mis-using” either HTML or CSS to do it.

Update: it was so yucky-looking that I dropped it before it even saw the light of day

So, in the event that the front page presents any confusion for readers (and I’m sure it might), I decided to reveal exactly which category each of the 4 featured areas (slider plus the 3 sub-features) belonged to…

This turned out to be a bit of a visual disaster.

I am definitely going to revisit this at some point in time… soon. The sooner the better. Because it’s looking mediocre at best. In the meantime, the code itself was simple enough that even a child could do it.

Looking again at the business.php page, I saw the following:

This is the code that tells the server side which category the content should come from. The important bit was “get_option(‘andro_gldcat’);”, which I took immediately to mean, “grab the category set by the user in the Androida theme options”. All I had to do to use that code was recycle the variable name that’s already being set to that function, namely &glidecat.

Putting $glidecat a bit higher up and as a separate declaration, I can now use it twice. Once in an “introduction” phrase and once again to build the slider contents. The new code looks like this:

line 1 is the important one; 3 and 4 were already there; 5 is the new div with my “intro” line. Since most font treatments (resizing, positioning via margin/padding) was breaking the existing CSS, I just made the new div absolute. Here’s the CSS:

And I used whatever the defaults are for h3 except for changing the colour. Not sure if the colour change was worth it… still looks wacky.

Moving on, since we’ve already declared the variable $glidecat, we don’t need to do it again. Just remove that line of code from the glider’s PHP function so that it now looks like:

That’s it.

Since you already get the concept of using Androida’s pre-existing variables, you can use this for the mini-categories as well. Just add a line like this:

Wherever you see fit. The variable names set by the Androida theme are quite obviously $minicat1, $minicat2, $minicat3.

Reclaiming the Front Page of the Androida Wordpress Theme

Users of the Androida theme already know about this. Readers of my blog may have thought I was doing something intentional. Basically, the content in the slider and the 3 “featured categories” area was always getting smooshed up. Line breaks/paragraphs just weren’t being respected.

The Short Version

I ramble. I mean, I REALLY ramble. So, to get the short version, jump right to the last heading in the article.

The Long Version: the Problem

One thing that immediately bothered me a bit about the otherwise spiffy^‡ Androida theme is that using the Business layout resulted in front-page content that has all its HTML/XHTML tags stripped out. The implication is that you cannot have paragraphs (<p>), links (<a>), additional images (<img>), or ANYTHING. Just pure pure text.

An example of why this sucked: since rendered HTML allows for line breaks, this means that no matter how many times you hit “enter” in your post, you will never be able to put spaces between your paragraphs. I didn’t quite realize why at first, but I knew that all tags were being stripped out. Not even ugly old <br/> line-breaks were doing it. AAAARGH!! I NEED line breaks for the sake of readability and sanity!

I headed over to the Web2Feel forum to see if anyone else had ever encountered this. Someone HAD, but the forum admin himself thought that the post was just not formatted. I’m not sure if he’s the original coder, but even if he was, there’s no way he could be held responsible for every single plug-in and its idiosyncracies for a FREE theme. As I stated in their forum, it was clear that some sort of “sanitization” was happening. It was just a matter of figuring out where.

The Long Version: Finding The Culprit

No matter how you slice it, the santization was being called from the “meat” of the front page. The front page consists of header.php, layouts/business.php, and footer.php.

I figured it COULD be a script of some sort being called in the header, so I looked there first. No scripts with obvious names jumped out, so I didn’t bother looking any further. A growing trend is to include scripts in the footer instead, but I didn’t think that seemed likely, so I didn’t even bother. I jumped right over to business.php.

Now, anyone who has ever looked into Wordpress code knows that content is retrieved/displayed via a function called the_content(). I figured I’d look at the code surrounding this function and see if anything shook loose in my brain. As it turns out, I found this (actually, a bunch of these, but it only took one):

“That’s curious,” thinks I. I thinks, “Wonder if that’s a standard function that comes with Wordpress….” So after I thinks, I Googles for “the_content_limit” (keeping the underscores of course) and soon discover that it’s part of a plug-in. Closer inspection of my plug-ins reveals what I really should have known all along… when I installed Androida, one of the required plug-ins was “limit-post.php”, which as you can guess, is supposed to limit posts.

I look at the above code, and I think, obviously the number being passed to the function represents its length, presumably in characters. What does that have to do with stripped tags?

Only one thing to do… open an editor (I just used the one built into Wordpress) and inspect the Limit Posts plug-in (limit-post.php). The culprit stood out like a sore thumb. See if you can spot the baddie (hehe, I know you will, even if you’ve never touched a line of code in your life):

Didja see that? Yup, you did.

The Long Version: The Solution

Here was the offending line inside the Limit Posts plug-in (limit-post.php):

I didn’t bother tracing through everything that went into creating $content up to that point in time… it was obviously going to be the content (duh!) of the post. And it was now about to be updated by a function called “strip_tags()”. Didn’t take a rocket surgeon to know that something called “strip tags” being applied to something called “$content” was going to be the problem!

Couldn’t have been easier to find the solution. First hit in Google (search term: “php strip_tags”) brought me to this page describing the function: PHP.net strip_tags

In short, if you do not pass an array to the function, it will just strip all tags. But if you pass a non-delimited (I assume the braces automatically delimit) array of permissible tags, you can retain the power of the function while permitting tags that you want to be considered safe. For example, if you want to allow paragraph tags (my biggest one!) and anchor tags (ie. links), you would update the line to look like this:

Images are still stripped out, which is usually going to be the best idea anyhow. If you are modifying an Androida theme, you will probably also want to add back in the <em> and <strong> tags as a minimum… I would go on to add back any HTML

Voila!

‡(yes, I will always put that disclaimer… no matter how much I complain during the next several weeks, I chose this theme because it was cool)

Addendum: Turns out I don’t like there to be links on the front page… at least not without being properly styled. Also, header links aren’t stripped out by the function, so they’ll need to be styled in order to keep the front page looking smooth-ish. Alternatively, I could start using Excerpts and include those instead!