Installation
Place the code below at the end of your Posted By line, replacing whatever is listed between the <MTEntryIfAllowPings> and </MTEntryIfAllowPings>. Use the code in your Main Index, Date, Category, and Individual Archive templates. Note that the lastn="15" can be changed to whatever you like.

<MTEntryIfAllowPings>
| <a
href="<$MTCGIPath$><$MTTrackbackScript$>?__mode=view&entry_i
d=<$MTEntryID$>"
onclick="OpenTrackback(this.href); return false">Trackbacks</a>
(<$MTEntryTrackbackCount$>)
<MTPings lastn="15">
<br><$MTPingBlogName$> linked with <a href="<$MTPingURL$>"><$MTPingTitle$></a>
</MTPings>
</MTEntryIfAllowPings>

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

How to create a Sideblog in MT
A Sideblog is basically a new weblog that gets included in your original blog. The steps are very painless. The creation steps are universal. The include steps presume you are using php. Anders has an SSI version of these instructions as well.

1. Create a new blog in MT's main menu. I've called mine "Sideblog".
2. Create a basic index template that shows just the html that you want to include in your main blog. I strongly suggest that you implement some type of limit on the number of entries displayed. For example:
   

   <MTEntries lastn="15"> <MTDateHeader> <br /> <$MTEntryDate format="%Y-%m-%d"$>: <br /> </MTDateHeader> <$MTEntryBody$><br /> </MTEntries>

3. Exit the Sideblog and edit the main index template for your existing main blog. We want to include the index page from the Sideblog, so we'll use a php include. For example:
   

   <?php include("http://www.to-be-simple-just-use-full-web-path.com/sideblog/index.php");
   ?>

That's it! Now you can post to your Sideblog and (if you use the template I've shown) the 15 most recent posts will show up in your main blog.

How to use the Sideblog

There are a lot of variations on using the sideblog. Some people post the interesting link in the excerpt and use the extended entry to include a brief little message about it. I suggest posting the interesting link in the entry body and then any other comments I have on the link in the extended entry. That works for me in my testing. Your mileage may vary.

Variations
There are a lot of ways to "spice up" the sideblog. Since we just included the index template from the Sideblog into the main blog, all of our template tags are available to us. For example, Christine's Crumbs show the number of comments for each Sideblog post as a link to the Sideblog entry itself. This is a great way to allow your visitors to interact with your Sideblog. If we modify the template in #2 above as follows to mimic Christine's Crumbs:

<MTEntries lastn="15">
<$MTEntryBody convert_breaks="0"$> (<a
href="<$MTEntryLink$>"><$MTEntryCommentCount$></a>)<br />
</MTEntries>

You can additional spaces to separate the interesting link from the comment count or modify the code to include any detail you like. I like the way Christine's works, so I plan to use the comment count on my own Sideblog.

That's all there is to it. Again, we just include the MT tags directly from the index template of the Sideblog. There are other ways to accomplish this, but I think this is the simplest of them all!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. swfobject – flash doesn't load in Firefox Ran into a bizarre problem today using swfobject. A lot...

Related posts brought to you by Yet Another Related Posts Plugin.

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

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

I've bolded the sections where you'll have to make changes. You can download this section of the tutorial here (right-click and save) if you're having problems copying & pasting from the site.

Other parts – these are all New Index Templates:

1) cookiecheck.php – This is the workhorse that points people to the right skin (if they are new and don't have a cookie or if they have a cookie already). This gets added to the top of index.php (and any other pages you want to match your skin). Note: I've used 10 here as the limit for the number of skins I have, but you can set it to either the exact number of skins you have or some other number.

<?
if (isset($newskin)) {
$newskin=(int)$newskin;
if ($newskin<1) $newskin=1;
if ($newskin>10) $newskin=1;
} elseif (isset($skin)) {
$newskin=(int)$skin;
if ($skin<1) $newskin=1;
if ($skin>10) $newskin=1;
} else {
$newskin=1;
}
$skin=$newskin;

$headervar = "/path/to/directory/where/your/skin/pieces/live/header";
$footervar = "/path/to/directory/where/your/skin/pieces/live/footer";
$extension = ".php";
?>

2) skins/index.php – This is your skin selector page. It basically has links to /skins/index2.php?newskin=N for each of your skins. It lets people see what skins you have to offer. cookiecheck.php goes at the top of this page too.

<?php include('/path/to/docroot/directory/cookiecheck.php'); ?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<? include($headervar.$skin.$extension); ?>

<table>
<tr>
<td valign="top" class="tableText">1: Description goes here <a href="/skins/index2.php?newskin=1">Make this one your skin</a>.</td>
</tr>
<tr>
<td valign="top" class="tableText">2: Description goes here <a href="/skins/index2.php?newskin=2">Make this one your skin</a>.</td>
</tr>
</table>

<? include($footervar.$skin.$extension); ?>

</body>
</html>

3) skins/index2.php – This is where people can test drive the skin they've selected. This has the same code at the top of the file as in cookiecheck.php. It also sets your cookie.

<?
if (isset($newskin)) {
$newskin=(int)$newskin;
if ($newskin<1) $newskin=1;
if ($newskin>10) $newskin=1;
} elseif (isset($skin)) {
$newskin=(int)$skin;
if ($skin<1) $newskin=1;
if ($skin>10) $newskin=1;
} else {
$newskin=1;
}
$skin=$newskin;
setcookie ('skin', "", time() – 3600);
setcookie('skin',$newskin,time()+(86400*365),'/');
setcookie('skin',$newskin,time()+(86400*365),'/','.your_domain.com');
$skin=$newskin;

$headervar = "/path/to/directory/where/your/skin/pieces/live/header";
$footervar = "/path/to/directory/where/your/skin/pieces/live/footer";
$extension = ".php";
?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<? include($headervar.$skin.$extension); ?>

<b>Like it?</b><br /><br />

Your skin number has been reset to '<?= $skin ?>.'<br /><br />

If you like it, journey on to the <a href="http://your_url.com/">main page</a> of this site and play with it a bit. If it's not quite what you want, you can always <a href="/skins/index.php">go back</a> and select another.

If you run into problems with any of the skins, <a href="contact_info_here">drop me a note</a>.

<? include($footervar.$skin.$extension); ?>
</body>
</html>

4) Example index.php (when I'm setting up skins for the first time, I like to name this test.php until I get all of the kicks worked out):

<?php
include('/path/to/docroot/directory/cookiecheck.php');
?>

<?
$headervar = "/path/to/directory/where/your/skin/pieces/live/header";
$footervar = "/path/to/directory/where/your/skin/pieces/live/footer";
$extension = '.php';
include('$headervar.$skin.$extension);
?>

<MTEntries>
blah blah blah
</MTEntries>

<? include('$footervar.$skin.$extension); ?>

</body>
</html>

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. Anchor Links in WordPress Posts – another shortcode solution I was recently asked by a client how they could...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

To make your .htm or .html pages process like they were .php, just add this line to your .htaccess file:

AddType application/x-httpd-php .html .php .htm

Related posts:

1. Adding a block of HTML to a WordPress post One problem with the WYSIWYG editor in WordPress is that...

Related posts brought to you by Yet Another Related Posts Plugin.

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

• Like with so many other things, Netscape 4 really screws up gzip encoding in a lot of ways, but you can avoid 99% of its problems simply by making sure that you don't gzip any linked JS or CSS files and you should be alright. On a more technical level, early versions of Netscape 4 try to use the browser cache to store compressed content before decompressing it, which works unless you have your browser's cache turned off, and then it will do something crazy. Note that this behavior even varies from version to version of Netscape 4, so overall I wouldn't worry about it.
• If you're doing things over SSL and you want to use mod_gzip as well, you have a little hacking to do.
• PHP.net documentation on ob_gzhandler and zlib output compression (they recommend using zlib).
• Things like images, zip files, and Florida ballots are already highly compressed so trying to compress them again might actually make them bigger. And then you have to recount.
• Avoid compressing PDF files as well because sometimes Internet Explorer on Windows (the 900-pound gorilla) forgets to decompress them before the Acrobat plugin takes over.
• According to the RFC, technically compressed content should be sent using transfer encoding rather than content encoding, since technically that's what is going on. One browser engine supports this, can you guess which one?
• Internet Explorer on Mac doesn't support any sort of content compression like the methods described above, but that's okay because all of the above methods intelligently look for the HTTP header that signals the client can accept gzip encoding, and if it isn't there—like in IE Mac, handheld browsers, whatever—they just sit idly by.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.