scriptygoddess

This was an item cooked up by Lynda of digitalwoe.com but her original entry appears to be lost and this hack is so handy, I wanted to make sure it was readily available to anyone who wants it. You need to be using PHP to use this - just insert the code in your MT index template after inserting your IP iformation:

<?
$ip = $REMOTE_ADDR;
if ($ip == “IP #1” || $ip == “IP #2“) {
print “<a href=\”<$MTCGIPath$>mt.cgi?__mode=view&_type=entry&id=<$MTEntryID$>&blog_id=<$MTBlogID$>\” target=\”edit\” title=\”For me, not you\”>[edit]</a>”;
}
?>

(replace “IP #1″ and “IP #2″ with your IP address(s) that you want to be able to edit posts from)

Guest authored by:
Donna - deliriouscool.org

I was recently frustrated by Movable Type’s basic support of time zones. You can select a time zone as a number of hour plus or minus UTC, but there’s no adjustment for Daylight Savings Time, and entry dates and times are saved in whatever localtime was at the time. The default RSS 1.0 template just tacks on the +/- hours, a global setting. If you ware exporting a year’s worth of entries, there’s no way to get the correct time for both summer and winter entries.

I then remembered some perl functions that can convert times from local time to UTC and then to whatever timezone you want. A Unix system can keep track of DST, even from the past, so the new UTC times will be correct. With Brad Choate’s PerlScript plugin, you can put perl code right in your template. With 4 lines of code, I was able to print out a UTC date and time suitable for RSS.

<dc:date><MTPerlScript>
use Time::Local;
my $mytime = timelocal(<$MTEntryDate format=
“(’%S’, ‘%M’, ‘%H’, ‘%e’, ‘%m’-1, ‘%Y’-1900)”$>);
my ($sec,$min,$hour,$mday,$mon,$year,
$wday,$yday,$isdst)=gmtime($mytime);
printf(’%d-%02d-%02dT%02d:%02d:%02dZ’,
$year+1900,$mon+1,$mday,$hour,$min,$sec);
</MTPerlScript></dc:date>

A couple of notes. The arguments to timelocal are in quotes, since the values may have a leading 0 that will confuse perl. If your time zone is different from your server, you’ll have to adjust the %H parameter by the difference. Also, in perl months are numbered 0 to 11, and years are numbered from 1900, so we have to adjust accordingly. We then have a Unix timestamp in $mytime, and can obtain the individual components in UTC. I’m using printf for the output since the format for dc:date in RSS is so strict. Each %02d formats the output of an integer to two places padded with a 0 if necessary.

(This code was originally posted www.papascott.de/2003/05/17/2256.php)

Guest authored by:
Scott Hanson - papascott.de

Found this on Jennifer’s etc. blog this morning: Quick Code Text Filter plugin for MT.

This is one that would be useful here - If/when I get the time to do it, I’ll let you know how the install goes.

If you’re looking for a simple photo gallery script, Photopal may be right up your alley. It’s not completely template driven. The latest version is completely template driven. Confetti Falling is a good example of Photopal in action.

Guest authored by:
Carla - andshesaid.com

A simple little ASP snippet. If you want to see what’s coming over from your method=”POST” form - here’s a bit of code that will loop through everything, show you the variable name and it’s value:

for each x in request.form()
response.write(x & “: ” & request.form(x) & “<br>” )
next

if you’re using method=”GET” then it would be:

for each x in request.querystring()
response.write(x & “: ” & request.querystring(x) & “<br>” )
next

“How we really use the Web” is a sample chapter from Don’t Make Me Think that is chock full of good information. Even if you’ve been designing websites for years, it is always a good idea to step back and remember to consider how people will be using the site. (The challenge after that is getting your boss or the client to understand!)

Ever want your readers to be able to print your pages cleanly without having to suffer through all your sidebars and graphics? Here’s a way to do just that. You need to create a new stylesheet and point your pages to it. Here’s how I did it:

First, you need to define the two stylesheets in your document’s HEAD:

<link rel=”stylesheet” type=”text/css” href=”<$MTBlogURL$>print.css” media=”print” />
<link rel=”stylesheet” href=”<$MTBlogURL$>styles-site.css” type=”text/css” media=”screen” />

Your print.css stylesheet should not contain any extraneous items, such as banners or sidebars. Your readers will probably only want to print your posts. Therefore, any element that should not be printed should be dealt with as follows:

.element-name {
display: none;
}

You must define the original stylesheet as media=”screen” and the print.css stylesheet as media=”print” so that when your page is viewed on the Web, the browser will serve up the screen-based stylesheet. But when the browser’s Print or Print Preview button is pressed, the browser will use the print.css stylesheet.

If you have a separate division for your copyright information, as I do, it might be a good idea to leave that in the print stylesheet as well.

There is one “gotcha” involved in printing, and it doesn’t matter whether there’s a special stylesheet for printing or not. When you are printing pages, such as MT blog pages, that have the “More” (extended text) link (like the “But wait! There’s more!” link on these pages), the text in that link is not going to print. If you want the extended text to print, you’ll need to go to the individual archive page and expand the link and then print the page(s).

Guest authored by:
Joni Mueller - jonielectric.com

I wrote this script to password-protect a page of mine. This has some disadvantages in that you need to implement this on every page you want to password protect, though you can throw it into a header/footer file to cover a set of pages. I use this in MT to password protect a private journal of mine.

First, post this on the VERY FIRST LINE of the code… it has to come before any <HTML> or header tags… It MUST start on the very first line, or it won’t work. Change the URLs to the page you want it to go to when you log in, and change USERNAME and PASSWORD to whatever you choose.

<?php
// Set a cookie that expires in one year
if($submitcookie){
if($loginname==”USERNAME” && $loginpassword==”PASSWORD”){
setcookie(”login”, $loginname, time()+31536000);
header(”Location: http://YOURDOMAIN.COM/PATH/TO/PAGE/”);
exit;
} else {
$incorrectlogin = true;
}
}
if($deletecookie){
setcookie(”login”, $loginname, time()-31536000);
header(”Location: http://YOURDOMAIN.COM/PATH/TO/PAGE/”);
}
?>

Next, paste this right after your BODY tag, before anything you want protected.

<?php
// if LOGGED IN
if (isset($login)){
?>

Somewhere in the page include this link to let you log out. This can be placed anywhere in your design. =)

<a href=”<?php echo $PHP_SELF ?>?deletecookie=true”>Log Out</a>

And lastly at the very end of the page, before the BODY tag and after everything you want protected, paste this chunk of code. You can format it so it looks nice and fits in with your design, as long as you don’t change the mechanics (field names, etc).

<?
// if not logged in
} else {
?>
<table border=0 cellpadding=0 cellspacing=0 align=center>
<tr>
<td>
<?php if($incorrectlogin){ ?>
<div id=”entry” align=center style=”text-align: center;”>
Username/password incorrect.
</div>
<?php } ?>
<form action=”<?php echo $PHP_SELF; ?>” name=”login”>
<div style=”font-weight: bold;”>Please Log In</div>
<div align=center style=”text-align: center; margin-top:8px;”>
<table border=0 cellpadding=0 cellspacing=2>
<tr><td> User Name</td>
<td><input type=text size=20 name=”loginname” class=”forms”></td> </tr>
<tr><td>Password</td>
<td><input type=password size=20 name=”loginpassword” class=”forms”></td> </tr>
<tr><td colspan=2 align=center>
<input type=submit name=”submitcookie” value=”Login” class=”forms2″> </td></tr>
</table>
</div>
</form>
</td></tr>
</table>
<?php
} // end if/else logged in
?>

So you’re basically making a sandwich of your page contents. And that’s it!

Guest Authored by:
Natalie - lunardreams.net

I do not have an eye for color. An online tool that helps tremendously is The Color Schemer. Each color selected will show 15 other web-safe colors that correspond with it.

There is also a shareware version of the program, with more options than the web site, including a non-web-safe color spectrum.

Guest Authored by:
Jennifer - confettifalling.com

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