You know when you you’re working on a project and get stuck on something, so you scour the Web for solutions only to find that everyone else seems to be experiencing the exact same thing. Then, after many hours trying everything possible, you finally stumble onto something that seems to work. This time, the project was setting up a secure downloads area for Digging into WordPress. And when I finally discovered a solution, I told myself that it was definitely something I had to share here at Perishable Press.
Apparently, there is much to be desired when it comes to sending proper HTTP headers for file downloads. Different browsers (and not just IE) require different headers, and will error if not present exactly the way they expected. Confounding that equation is the fact that different file types also require specific headers. Then there are issues with sending an accurate (or should I say “acceptable”?) Content-Length headers when file compression is involved. Needless to say, finding a set of headers that works for all file types in all browsers is next to impossible. And I won’t even get into the issues involved with readfile() and large-download file-sizes.
When designing a website, it’s always a good idea to test on as many different platforms, devices, and browsers as possible. These days, pimping your websites for the iPhone and iPad is an important step in the design process. Especially on the iPad, sites tend to look about 20% cooler than on desktop browsers, so you definitely want to take the time to fine-tune the details. And when dealing with iDevices, it’s often necessary to deliver some custom CSS to make everything just right.
Want to apply CSS styles to the iPad and iPhone? Here is the plug-n-play, copy-&-paste code that actually works.
As you may have heard, I’ve been super-busy behind the scenes building an Angry-Birds fan site, of all things. The site is looking great so far, but needed some tweaking to appear slick on the iPad and iPhone. After testing a number of different solutions, here is what I found that actually works..
To wrap long URLs, strings of text, and other content, just apply this carefully crafted chunk of CSS code to any block-level element (e.g., perfect for <pre> tags):
pre {
white-space: pre; /* CSS 2.0 */
white-space: pre-wrap; /* CSS 2.1 */
white-space: pre-line; /* CSS 3.0 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: -moz-pre-wrap; /* Mozilla */
white-space: -hp-pre-wrap; /* HP Printers */
word-wrap: break-word; /* IE 5+ */
}
By default, the white-space property is set to normal. So you might see something like this when trying to force long URLs and other continuous strings of text to wrap:
Redirecting visitors to a maintenance page or other temporary page is an essential tool to have in your tool belt. Using HTAccess, redirecting visitors to a temporary maintenance page is simple and effective. All you need to redirect your visitors is the following code placed in your site’s root HTAccess:
That is the official copy-&-paste goodness right there. Just grab, gulp and go. Of course, there are a few more details for those who may be unfamiliar with the process. Let’s look at all the gory details..
An excellent way to simplify and streamline your Cascading Style Sheets (CSS) is to take advantage of the many different shorthand properties available to you. Working with a lot of CSS, you eventually memorize these different shortcuts, but every now and then, I find myself needing a quick, straightforward reference for some of the more elaborate property combinations. In this post, I’ll show you the shorthand rules for the following properties:
These are the top 5 on my list of most complicated and frequently used shorthand properties. There are others as well, even in CSS3, but I’ll save those for another post. Alright enough of my narcissistic ramblings – let’s do this thing!
Styling fonts involves a number of individual properties. You can save quite a bit of space using shorthand notation, but be careful to include at leastfont-size and font-family (in that order). Here are all 6 of the font properties along with their default values:
/* font properties with default values */
font-variant: normal
line-height: normal
font-family: varies
font-weight: normal
font-style: normal
font-size: medium
These 6 declaration blocks can be combined into a single shorthand rule, ordered according to W3C specifications:
As you can see, a single line of code is used to replace an entire block. Far more elegant, if not slightly awkward looking. The more I use this syntax, the more I like it.
In my previous post on Quick and Easy CSS @font-face Code, I provide a choice set of CSS rules for embedding custom fonts into your web pages. It’s a solid, cross-browser technique that works great, but as Marty Thornleypointed out, it would be useful to have a more thorough explanation of how the code actually works. So, rather than going back and adding a bunch of additional information to the original post, I’m following up with a visual walkthrough of the @font-face code.
In step-by-step visual format, this article will show you what the code is doing and how to use it with your own custom fonts.
Yes, it’s a hideous-looking chunk of CSS, but that’s not going to stop us from using it to embed our own custom fonts. Let’s break it down and see how the different parts fit together..
I’ve been using custom fonts in my designs for quite a few sites now, and have refined what seems to be an ideal chunk of CSS code for implementing the @font-face rules. Some of the sites that include these rules include Perishable Press and Digging into WordPress, which look more stylish and refined with the custom fonts in effect. I’ve tested this code on quite a few browsers, including the following:
Safari 3.1+
Opera 10+
Firefox 3.5+
Chrome 4.0+
Internet Explorer 6+
This technique delivers your custom fonts quite consistently to all of these browsers, and degrades gracefully for those that don’t support it. Of course, there are always weird exceptions contingent in particular scenarios, but overall it’s a solid chunk of code put together from much research, experimentation, and testing. I share it here hoping it will help others implement custom @font-face fonts quickly and easily. Let’s step to it..
Whenever I find myself working with PHP or messing around with server settings, I nearly always create a phpinfo.php file and place it in the root directory of whatever domain I happen to be working on. These types of informational files employ PHP’s handy phpinfo() function to display a concise summary of all of your server’s variables, which may then be referenced for debugging purposes, bragging rights, and so on.
While this sort of thing is normally okay, I frequently forget to remove the file and just leave it sitting there for the entire world to look at. This of course is a big “no-no” for site security, because the phpinfo.php file contains a hefty amount of information about my server, including stuff like:
The web server version
The IP address of the host
The version of the operating system
The root directory of the web server
Configuration information about the remote PHP installation
The username of the user who installed php and if they are a SUDO user
Progressive enhancement is a good thing, and CSS3 is even better. Combined, they enable designers to create lighter, cleaner websites faster and easier than ever before..
CSS3 can do some pretty amazing stuff: text shadows, rgba transparency, multiple background images, embedded fonts, and tons more. It’s awesome, but not all browsers are up to snuff. As designers, it’s up to us to decide which browsers to support for our projects. While everyone has their own particular strategy, there seem to be three general approaches:
Support all browsers with perfect fidelity – not realistic for most budgets, requires many elaborate workarounds, hacks, etc., also difficult to maintain, upgrade, and extend.
Support all browsers to some degree – focus first on the latest and greatest browsers, and then go back and make sure that older browsers look and work reasonably well.
Support newer browsers, forget about the older stuff – make your sites look pixel-perfect on the newest versions of modern browsers and don’t worry about anything else.
Among these generalized strategies, the second approach comes closest to the concept of progressive enhancement. In practice, progressive enhancement enables designers to design websites according to some predetermined support baseline and then gradually improve and optimize appearance and functionality to accommodate the most advanced browsers. Closely related to this idea is the principle of graceful degradation, which is what should happen when newer design methods aren’t understood or supported by certain browsers. Consider the following example..
I recently added to my growing library of image-preloading methods with a few new-&-improved techniques. After posting that recent preloading article, an even better way of preloading images using pure CSS3 hit me:
Using CSS3’s new support for multiple background images, we can use a single, existing element to preload all of the required images. Compare this method with the old way of using CSS to preload images:
Preloading images is a great way to improve the user experience. When images are preloaded in the browser, the visitor can surf around your site and enjoy extremely faster loading times. This is especially beneficial for photo galleries and other image-heavy sites where you want to deliver the goods as quickly and seamlessly as possible. Preloading images definitely helps users without broadband enjoy a better experience when viewing your content. In this article, we’ll explore three different preloading techniques to enhance the performance and usability of your site.
Method 1: Preloading with CSS and JavaScript
There are many ways to preload images, including methods that rely on CSS, JavaScript, and various combinations thereof. As one of my favorite topics here at Perishable Press, I have covered image preloading numerous times:
One of the most popular articles here at Perishable Press is my January 2005 post, Stupid htaccess Tricks. In that article, I bring together an extensive collection of awesome copy-&-paste HTAccess code snippets. Four years later, people continue to tell me how much they enjoy and use the content as a bookmarked reference for many of their HTAccess needs. The article was even published in a book on Joomla! Security.
This is very inspiring to me, so I have decided to create a similar post for all of the useful WordPress code snippets, tips and tricks that I have collected while working on Digging into WordPress, the new book by co-author Chris Coyier and myself that really “digs in” to all of the awesome ways to get the most out of WordPress. While writing the DiW book, I collected hundreds of incredibly useful WordPress tips and tricks. After packing the book with as many of these techniques as possible, I decided to share the “best of the rest” here at Perishable Press.
If you are one of the millions of people who use WordPress, this article will help you improve the appearance, functionality, and performance of your WordPress-powered websites. Each of these “stupid WordPress tricks” is presented as clearly and succinctly as possible, including as many notes, instructions, and pointers as needed for successful implementation. Of course, keep in mind that we are only scratching the surface here. For a much more complete resource that is packed with tons of tasty techniques, you need to get Digging into WordPress.
I have been wanting to write about 404 error pages for quite awhile now. They have always been very important to me, with customized error pages playing a integral part of every well-rounded web-design strategy. Rather than try to re-invent the wheel with this, I think I will just go through and discuss some thoughts about 404 error pages, share some useful code snippets, and highlight some suggested resources along the way. In a sense, this post is nothing more than a giant “brain-dump” of all things 404 for future reference. Hopefully you will find it useful in pimping your own 404.
When requested page is not found by server, error message is returned; this is the essence of the 404 — Ancient Chinese proverb
Might as well face it, Twitter is here to stay. Not that it’s all that bad, just used to be a lot more laid-back and enjoyable. These days it seems to have been taken over by the lowest common-denominator, mostly high-school twits or useless commercial propaganda. Even so, I still enjoy tweeting the occasional profound thought once in awhile, and even like to play around with various types of “advanced” Twitter functionality. You know, cool stuff like including “Tweet This!” links with short URLs, showing off my number of Twitter followers, displaying the number of tweets for each post, and even backing up my marvelous tweets quickly and easily. As you might have guessed, these are the kind of stupid Twitter tricks that you will find in this article. So kick back, relax, and enjoy these twitterific techniques that will make you go tweet.
“Tweet This!” short links for posts
I like to include an easy way for readers to “tweet” my posts, but the URLs are generally way over Twitter’s 140-character limit. Fortunately, we can use PHP’s handy file_get_contents function to grab short versions of our URLs from a free minifying service like TinyURL.
Running a private site is all about preventing unwanted visitors. Here is a quick and easy way to allow access to multiple IP addresses while redirecting everyone else to a custom message page.
To do this, all you need is an HTAccess file and a list of IPs for which you would like to allow access.
Edit the following code according to the proceeding instructions and place into the root HTAccess file of your domain:
# ALLOW ONLY MULTIPLE IPs
<Limit GET POST PUT>
Order Deny,Allow
Deny from all
Allow from 123.456.789
Allow from 456.789.123
Allow from 789.123.456
</Limit>
ErrorDocument 403 path/custom-message.html
<Files path/custom-message.html>
Order Allow,Deny
Allow from all
</Files>
To prepare this code for use on your site, do these three things:
Edit the three IP addresses to suit your needs. Feel free to add more IPs or remove any that aren’t needed.
Edit both instances of “path/custom-message.html” to match the path and file name of the file that will contain your custom message. This may be anything, anywhere, with any functionality you desire.
That’s it. Copy/paste into your site’s root htaccess file, upload, test, and get out!
While browsing the internet these days, I see a lot of this:
<body>
...
<a name="top"></a>
...
<a href="#top">- Back to Top -</a>
...
</body>
There’s an easier, better and prettier way. CSS Signatures are all the rage these days. If you’re not familiar with a CSS Signature, it’s basically nothing more than an ID on your body tag, like this:
<body id="www-domain-tld">
The fundamental purpose of the CSS Signature is to allow a user to specify style adjustments to your site in their own user style sheets. Whether or not users are actually capitalizing on this is a discussion for another day, but doing this has other benefits like having an extra id to use when dealing with CSS specificity.
Additionally, we can use this to capitalize on a little known fact about HTML and anchors: you can use anchors to jump to any element on your page with an ID attribute.
The shared server on which I host Perishable Press was recently scanned by security software that revealed a significant security risk. Namely, the HTTP request methods TRACE and TRACK were found to be enabled on my webserver. The TRACE and TRACK protocols are HTTP methods used in the debugging of webserver connections.
Although these methods are useful for legitimate purposes, they may compromise the security of your server by enabling cross-site scripting attacks (XST). By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE and TRACK methods to intercept your visitors’ sensitive data. The solution, of course, is disable these methods on your webserver.
Behold the ubiquitous list elements, <ul> and <ol>! These two sexy elements help millions of websites display lists of information in clean, semantic fashion. Without them, we’d be crawling around like filthy cavemen, eating dirt and howling at the moon.
But these list elements aren’t just sexy, they are also extremely flexible, enabling us humble designers to create robust list configurations that are semantically versatile and highly customizable. We all know how to throw down a basic list:
When developing the colorful Quintessential Theme (opens in new tab), I initially planned on displaying five random posts from each of my most popular tags and categories in the super-slick sliding-panel sidebar. Because I am running an older version of WordPress, however, this task proved to be quite the educational experience.
In newer versions (from 2.5 I think) of WordPress, the query_posts() function enables users to display posts in random order using the orderby=rand parameter. This would have made my life easy, as I could have included the following code for each of my random post lists:
Recently a reader asked about how to password-protect a directory for every specified IP while allowing open access to everyone else. In my article, Stupid htaccess Tricks, I show how to password-protect a directory for every IP except the one specified, but not for the reverse case. In this article, I will demonstrate this technique along with a wide variety of other useful password-protection tricks, including a few from my Stupid htaccess Tricks article. Before getting into the juicy stuff, we’ll review a few basics of HTAccess password protection.
In my article, Associate Extensionless Files with Notepad, I explain how to navigate the labyrinthine maze of Windows dialogue menus to assign Microsoft’s Notepad text editor as the opening application for files without extensions. In this post, I’ll show you how to associate any file type with any program (including Notepad) in less than five seconds.
Ready? Don’t blink, you’ll miss it.. ;)
Modify any file extension association in five seconds
In my recent guest post at The Nexus, I discuss Google’s new nofollow policy and suggest several ways to deal with it. In that article, I explain how Google allegedly has changed the way it deals with nofollow links. Instead of transferring leftover nofollow juice to remaining dofollow links as they always have, Google now pours all that wonderful nofollow juice right down the drain. This shift in policy comes as a terrible surprise to many webmasters and SEO gurus, especially those who have invested vast amounts of time, effort and money engaging in supposedly lucrative PR-sculpting pursuits.
Of course, this new policy leaves many of us wondering how to deal with it. If (and it remains a big “if” until Google clarifies their position) — if nofollow link equity simply vanishes into the ether, the repercussions may be significant. For example, webmasters who now rely on nofollow to salvage link juice otherwise leaked through lengthy comment threads will need to devise another strategy or suffer an inevitable loss of valuable PageRank. There are many good strategies available, including everything from long-term reorganization of site structure to short-term fixes involving much-despised tricks such as iframes and JavaScript links. Personally, I wouldn’t touch iframes with a ten-foot pole, but in the case of an emergency, I certainly would take a look at using external JavaScript to get the job done.
Let’s face it. There’s just as much scum on the Internet as there is out there in the “real world.” Maybe even more, who knows. From scammers and spammers to scrapers and crackers, the Web is just crawling with all sorts of pathetic scumbags. As predictably random as much of the malicious activity happens to be, it is virtually guaranteed that you will be hounded by at least a few persistent IP addresses that, for whatever reason, have latched on and just won’t let go. Like satanic parasites, they plague you night and day, haunting you and making your online life a living hell. Perhaps they leave endless spam comments; perhaps they are just mindless trolls giving you grief; or perhaps they continue to take flying stabs at the security of your website. Whatever the behavior, once you have determined that you need to block a collection of evil IPs, you have manychoices. Here is a simple way to blacklist multiple IP addresses with a little PHP magic..
Normally, when visitors post a comment to your site, specific types of client data are associated with the request. Commonly, a client will provide a user agent, a referrer, and a host header. When any of these variables is absent, there is good reason to suspect foul play. For example, virtually all browsers provide some sort of user-agent name to identify themselves. Conversely, malicious scripts directly posting spam and other payloads to your site frequently operate without specifying a user agent. In the Ultimate User-Agent Blacklist, we account for the “no-user-agent” case in the very first directive, preventing a host of anonymous visitors from hitting the site.
In addition to empty user-agent strings, malicious requests for site content frequently fail to provide any referrer information. Unless special privacy software is being used, the web page from which a visitor has arrived at your site will be specified in the header information for that request. Likewise, when a visitor posts a comment at your site, the referrer string for that post request will be the URL of that particular page. Thus, as with blank user-agent requests, no-referrer requests are frequently indicative of spam and other malicious behavior.
Another important piece of information provided by all legitimate clients is the host request header. The host header specifies the Internet host and port number of the requested resource. This information is required for all clients making HTTP/1.1 requests. Thus, requiring the host request-header field for all posts to your site safely eliminates illicit requests from hitting your server.
Taking screenshots of DVD, MPEG, AVI, and other video on Windows machines requires a couple of extra steps. A normal screenshot is easy enough to capture by pressing the “Print Screen” button on your keyboard. To capture a screenshot of video display, however, you need to disable hardware acceleration to make it work. To do this on Windows machines, go to your Desktop properties and click on the Settings tab. Click on the Advanced button and then on the Troubleshooting tab. Slide the Hardware Acceleration to “None” and then capture and process your screenshot as normal. Once you are finished taking your screenshot, don’t forget to switch your Hardware acceleration back to its original settings (e.g., “Full”).
![[ CSS3 @font-face ]](http://perishablepress.com/press/wp-content/images/2010/misc-chunks/font-face.png)
I’ve been using custom fonts in my designs for quite a few sites now, and have refined what seems to be an ideal chunk of CSS code for implementing the ![[ Enjoying the Evening ]](http://perishablepress.com/press/wp-content/images/2010/misc-chunks/secure-phpinfo.jpg)
Whenever I find myself working with ![[ CSS3 ]](http://perishablepress.com/press/wp-content/images/2010/misc-chunks/css3-chunk.png)
CSS3 can do some pretty amazing stuff: ![[ WordPress ]](http://perishablepress.com/press/wp-content/images/2009/misc-chunks/wordpress-tricks.jpg)
One of the most popular articles here at ![[ Twitter ]](http://perishablepress.com/press/wp-content/images/2009/twitter-tricks/twitter-tricks_00.jpg)
Might as well face it, Twitter is here to stay. Not that it’s all that bad, just used to be a lot more ![[ Dynamic Flow ]](http://perishablepress.com/press/wp-content/images/2009/misc-chunks/dynamic-linkage.jpg)
In my recent guest post at ![[ Screenshot: The Legion of Doom ]](http://perishablepress.com/press/wp-content/images/2009/misc-chunks/multiple-addresses.jpg)
Let’s face it. There’s just as much scum on the Internet as there is out there in the “real world.” Maybe even more, who knows. From scammers and spammers to scrapers and crackers, the Web is just crawling with all sorts of ![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2009/misc-chunks/secure-posting.gif)
Normally, when visitors post a comment to your site, specific types of client data are associated with the request. Commonly, a client will provide a user agent, a referrer, and a host header. When any of these variables is absent, there is good reason to suspect foul play. For example, virtually all browsers provide some sort of user-agent name to identify themselves. Conversely, malicious scripts directly posting spam and other payloads to your site frequently operate without specifying a user agent. In the