Here’s a nice Movable Type template trick originally posted at Wizbang. Show your posts’ trackbacks inline with your posts. Why do this? Well it shows readers who is linking to your post, plus it provides Ecosystem and Technorati links to the sites that send you trackbacks.
(more…)
Having seen some great “sideblogs” across the internet (Christine’s Crumbs, Movablog’s Asides, and many others) I’m inspired to add a Sideblog to my own MT-powered blog. Anders created a short “how-to” for those who are not using php and it has inspired me to create a php version here.
(more…)
Mark Pilgrim’s recent post (why we won’t help you) about using HTML validation as a way to troubleshoot layout problems (among other things) got me wondering if I could validate my own HTML. So I did - here are some tips on how you can too:
Validation means you’re bringing your markup into compliance with the standards set by the World Wide Web Consortium; because I was a novice and because my main goal was cross-browser viewing compatibility, I chose to validate to the standards for HTML 4.01 Transitional. HTML is being supplanted by XHTML or eXtensible Hypertext Markup Language; if you want to validate to the most cutting-edge standards, you’ll want to read more about it. Among other benefits, validation acts as the ultimate proofreader; it catches mistakes you might not find (and might not even know were mistakes) that cause your site to behave strangely in differnet browsers. If you’re considering embarking upon a big site overhaul like skinning, this kind of effort is worth it, because you’ll move forward with cleaner code.
The nuts and bolts of validating involve checking for and correcting errors; to do this most effectively while my main site was still live, I moved a copy of my index page to a test blog - no risk of ruining the template because my main site could serve as a backup copy. Another reason to use a test blog? You will always want to validate the source code of a live page; that’s what people will see when they view your site. If you try to validate a blogging template before any PHP scripts or template tags have been processed when the page loads, the validator will give you error messages because it won’t recognize the tags. When I first ran my page through the W3C HTML Validator, I discovered 103 errors. Let that sink in for a moment. Then I realized that the validator was picking up two kinds of mistakes: 1. errors in the code used for the templates, and 2. errors in the code in the entry text. Every time I corrected an error in the template code, it removed multiple instances of that error on the index page - the number of errors I found started dropping sharply after I figured that out.
In addition to the W3C validator, I used this excellent HTML resource from Ian Graham; which helped me understand what tags could be used where, and what tags were deprecated, or out-of-date. I used HTML Validator Lite to help me interpret the more obscure messages I got from the W3C validator. I didn’t know which standard HTMLValidator Lite was using, so I doublechecked the changes it suggested on another test page before implementing them in the final corrected template. Many people recommend using HTML Tidy; my page was so far from valid when I started that Tidy had trouble processing it.
Other good things to be aware of (or “let my mistakes save you time”): Many of the errors I encountered were as a result of the improper handling of special characters in Javascript (like the “Blogroll Me!” link) or HTML (like a link to an item on Amazon.com) in my templates. I used the Hiveware URLCleaner and the CleanURL bookmarklet to give me the ASCII equivalents to characters like the dreaded ampersand. I made sure that each and every page had a DOCTYPE at the top; it’s the validator’s way of recognizing what kind of text you’re about to feed it. I was under the mistaken impression that tables don’t validate (this comes from hanging out with people who use and love cascading stylesheets); table tags must appear in the proper order (be properly nested) to ensure that designs with tables validate. Finally, if you do want to skin your website and you want it to be valid, you can; each skin you implement needs to be checked against the output of the validator.
Sound complicated? It’s not nearly as complex as trying to ask for help when you’re not sure what the problem is (”My site doesn’t look like I thought it would in Browser X. Why?”) Being able to say “My site validates, and I’m still having problem X” puts you a lot closer to a solution because more people will have an idea of what you’re talking about. Don’t be intimidated - give it a try. If I can do it without pulling my hair out, anyone can.
Guest authored by:
Donna - deliriouscool.org
If you’re working with scripts, the time will come when you need to work with a Unix archive. Generally, these are .tar files or .tar.gz (zipped). These .tar files are commonly called “tarballs”. These are no different than any other archive/backup/zipped files, they just take a little getting used to.
How to decompress a .tar or .tar.gz archive in Windows:
Winzip is my windows-based zip file manager of choice. There are several versions available, included a free “evaluation” version. Winzip can decompress .tar and .tar.gz files locally to your hard drive. Make sure you use the wizard or select “Use Folder Names” from the Classic interface so the file structure will be maintained.
How to decompress a .tar or .tar.gz archive on your webserver:
You need shell access (telnet or ssh). If you don’t have shell access, you’ll just have to decompress the tarball local (see Windows directions above) and upload via ftp.
1) Assuming you have shell access, upload the tarball to your webserver in binary mode via ftp. (Note: Choose binary mode, not ascii or automatic detect - binary). Most of the time, you’ll want to place the tarball one level above where you want the files installed, as the structure of most tarballs begins with a folder.
2) Once the tarball is on your server, log into your shell account (ask your host for directions).
3) Use the following commands to decompress:
.tar files: tar -xvfz filename.tar
.tar.gz files: tar -xvfz filename.tar.gz
4) The files will decompress into it’s original uncompressed structure. You can browse the structure using your ftp program or other tools that are more familiar to you.
While we’re at it, let’s just round out this topic.
How to zip a folder in Unix:
To create an archive from the Unix shell (telnet/ssh), use the following command:
tar -cvzf filename.tar.gz folder-name
So, if I want to create a tarball to backup my “images” folder, I’d use the following command:
tar -cvzf images.tar.gz images
Note the space between the “z” and the name of the folder I am compressing. You can create archives of individual files as well, just replace the “folder-name” in the example with a file name (i.e. “image.jpg”).
If you need a good telnet/ssh client for windows, I recommend Putty. For more information on unix shell commands, google “unix shell commands”. There are 1,000s of good resources.
Guest authored by:
Kevin Donahue - blog.kevindonahue.com
This is specific to MT, but the concent should be applicable to other blogging software.
Back when Statia and I were first skinning her site, Robyn used the sandwich anology(*) to explain how you “piece” out index.php for skinning.
1) the code at the top, up to but not including MTEntries [bread]
2) the MTEntries stuff [the all important sandwich filler]
3) the code after MTEntries to the end [bread]
Section 2 is the code that stays in index.php.
Section 1 is headerN.php (where N is the skin #).
Section 3 is footerN.php (where N is the skin #).
You can get more complicated and leave the javascript and the other code that is global to all of your skins in index.php. Then your header & footer would just contain the code that actually changes per skin, but it’s not necessary.
(*) The sandwich analogy has been around for a while. Christine used it to explain skins to Robyn. And it’s quite possible that Amy used it to explain it to Christine.
(more…)
This is not Jennifer’s feed. This feed was put together by Brad, .NET Guy.
This feed contains your 10 most recent posts as well as your 20 most recent comments. The difference between this and Jennifer’s feed is that if someone comes by and comments on a post that’s not one of your 10 most recent, your readers will still get to see the comment.
Please read more on my site. I have 2 variations of this feed available there for download.
This is a variation of Girlie’s Comment Leaderboard. I’ve seen other people who show the comment leaders for the last 30 days, but I decided I’d rather show the leaders for the current month.
Here’s the code. The items bolded and underlined need to be changed to reflect your blog settings.
<? include (”/path/to/your/connection/file/connect.php“);
$leaders = mysql_query(”SELECT comment_email, comment_url, comment_author, COUNT(*) as comment_count FROM mt_comment WHERE (comment_blog_id=1) AND (comment_email!=’you@yourdomain.com‘) AND MONTH(comment_created_on) = MONTH(CURDATE()) AND YEAR(comment_created_on) = YEAR(CURDATE()) GROUP BY comment_author, comment_email ORDER BY comment_count DESC LIMIT 10“);
while($row = mysql_fetch_array($leaders)) {
while (list($key,$val) = each($row)) {$$key = $val;}
if (!empty($comment_url)) {
$authorlink = “<a href=\”$comment_url\”>$comment_author</a>”;
} elseif(!empty($comment_email)) {
$authorlink = “<a href=\”mailto:$comment_email\”>$comment_author</a>”;
} else {$authorlink = $comment_author;}
echo “$authorlink ($comment_count)<br />\n”;
}
?>
/path/to/your/connection/file/connect.php = location of your connect.php file
1 = your blog ID
you@yourdomain.com = your email address (so that your comments aren’t counted)
10 = number of leaders to show
Update: I added “, comment_email” to the “GROUP BY” section so that it will group by name and email address and not lump people who leave comments with the same name together.
I was going to post this here, but it seemed less appropriate the more I wrote.
You can read the whole post on my site.
Here’s a summary of what I wrote on my blog:
Now that you’ve gotten your RSS feed(s) set up, it’s a good time to check out your site from the viewpoint of someone entering your site via an RSS reader.
1. Figure out where your RSS feed is sending your readers. Look at the <link> tag for your entries. I find that linking to the individual post is the best/easiest place to send your readers.
2. Once you know where you’re readers are being sent, look over this page. Does it have links for next and previous? Can your reader get back to your front page easily?
3. Are the comments easily readable? If you link to the individual post, it’s really handy to just display the comments there (I like oldest comments at the top). A link to the comments works as well, but it’s more clicks for your reader.
4. Is it easy for your reader to leave you a new comment? Because that’s probably why they left their cozy newsreader.
5. Now, look at that page. Should you add some of the lnks that you have on your front page to these other pages? Again, it depends. When I go to a blog from my newsreader, I don’t usually hit the front page. Just the pages with posts that caught my eye.
If you have any questions, please let me know.
I’ve had to look this up more times than I can count. I think I’ve made a post to link to it, but it’d be easier for me if this was just here. I got this code from Christine who posted it on the Blogomania support forums ages ago. (side note: Those forums are mostly for people who are hosted on Blogomania - but obviously you’re free to peruse the info there)
To make your .htm or .html pages process like they were .php, just add this line to your .htaccess file:
(Written by the Guest Goddess, Photo Matt. Please note: You need to have PHP on your server to do this. No PHP? Won’t work.)
So your page is now totally pimped out. You have gads of content on your sidebar, you’ve used ScriptyGoddess know-how to have comments and extended entries pop out like magic, and you even have some entries to take up some space between all the gadgets. The problem? The code on your page is now weighing in at half a meg and you can actually hear people cry when they load your site with a modem. You start to think about what features you could take out, maybe cutting out entries on the front page, but what if I told you that you can third your content easily with no work on your part whatsoever? It sounds like a pitch I might get in a lovely unsolicited email. The secret lies in the fact that every major browser of the past 5 years supports transparently decompressing content on the fly. There are three ways to do it—easy, right, and weird—and we’ll cover all three here. Before we even get started you should check for compression of your pages, because if it’s already happy it’s probably best to not fix what ain’t broken.
Easy
<?php ob_start("ob_gzhandler"); ?>
I hate to be anti-climatic, but that’s it. Put that at the very top of your PHP-parsed page that you want to compress and that’s it. The only thing to watch for is it really does have to be at the top, or the sky will fall. Actually before you call me Chicken Little, you’ll probably just get a cryptic “headers already sent” error, but you can never be too careful. Basically what this magical line of code does is start an output buffer which takes all your content, checks if the client can receive compressed content, and if it can it zips up the buffer and sends it on its merry way. This can be a great technique to curb your bandwidth usage to; I’ve seen it save gigabytes on content-heavy sites.
Right
While the overhead associated with the above is minimal, if you’d like to see the benefits of compressed content on a larger scale, mod_gzip is the way to go. Mod_gzip is an Apache module which will compress files whether they are CGI scripts, processed by PHP, static HTML or text files, whatever it can. It is completely transparent to both the user and client, and it supports sophisticated configuration to allow it to be tweaked to your heart’s content. However if you don’t have permissions on your box to compile modules and modify httpd.conf, this option is unavailable, but don’t let that stop you from bugging your host to include it, as there is really no good reason to not include it. It’s always faster to send a smaller file. If you’re interested in writing your own Apache module, studying mod_gzip is a great way to learn as it has extremely informatative debug code.
Alternative
There are certain circumstances where output buffering, which by definition has to wait for everything to process before it sends anything to the browser, can cause a perceivable delay in viewing scripts that take a while to run. With mod_gzip this isn’t a problem because it streams content as it comes to it, and using PHP it doesn’t have to be a problem either because it offers an alternative method of compressing and sending content, called zlib output compression. It’s a little trickier to enable though, because there is no good way enable or disable it with straight PHP code, so the way we’re going to do here is use .htaccess to modify the php.ini configuration. Instead of waiting until everything is finished, zlib output compression can take the content as chunks and send them as it comes to it. Here’s what you need to put in your .htaccess file:
<FilesMatch "\.(php|html?)$">
php_value zlib.output_compression 4096
</FilesMatch>
Basically what this code says is if the file ends in php, htm, or html turn zlib output compression on and stream it out every 4 kilobytes. It’s common to see a 2K buffer suggested on the web but I’ve found the overhead with that is higher, and this is a nice balance. You should know that this is the slowest of the three methods, but by slow I mean it adds .003 seconds instead of .001, so it’s not really that big of a deal.
So now you have a faster site that’s more fun to visit, and you’re saving money on bandwidth. You can sit back now and wait for the love letters to pour in from your readers saying how much faster everything is loading. Enjoy!
Geek Notes