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..
There are many ways to optimize your web pages. In addition to reducing HTTP requests and deliveringcompressedfiles, we can also minify code content. The easiest way to minify your CSS is to run it through an online code minifier, which automatically eliminates extraneous characters to reduce file size. Minification shrinks file size significantly, by as much as 30% or more (depending on input code). This size-reduction is the net result of numerous micro-optimization techniques applied to your stylesheet. By learning these techniques and integrating them into your coding practice, you’ll create better-optimized CSS during the development process. Sharper skills, cleaner code, faster downloads – it’s a “win-win” for everyone.
In this Perishable Press article, you’ll learn how to write leaner, cleaner CSS using 10+ micro-optimization techniques..
The basic idea behind micro-optimizing your CSS involves writing clean code, eliminating extraneous characters, and reducing overall file size. And you don’t have to rely on an automated script to do everything for you. Instead of writing lazy, sloppy, bloated code and then just dumping your hideous CSS into an automated minifier, it’s better to understand and practice as many micro-optimization tips as possible, given your particular coding style and specific project requirements.
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:
Say goodbye to the age-old clearfix hack and hello to the new and improved clearfix method..
The clearfix hack, or “easy-clearing” hack, is a useful method of clearing floats. I have written about the original method and even suggested a few improvements. The original clearfix hack works great, but the browsers that it targets are either obsolete or well on their way. Specifically, Internet Explorer 5 for Mac is now history, so there is no reason to bother with it when using the clearfix method of clearing floats.
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!
Stolen content is the bane of every blogger who provides a publicly available RSS feed. By delivering your content via feed, you make it easy for scrapers to assimilate and re-purpose your material on their crap Adsense sites. It’s bad enough that someone would re-post your entire feed without credit, but to use it for cheap money-making schemes is about as pathetic as it gets. If you’re lucky, the bastards may leave all the links intact, so at least you will get a few back-links (if you have been linking internally) and get notified of the stolen content as well (via pingback or Google Alert). Lately, however, many of the scraper sites that I have seen are completely removing all links within the stolen content. Incidentally, there are some tell-tale signs that the site you are visiting is a scraper site:
No RSS feed available
Many quality posts that contain no links
Many quality posts but very low subscriber count
Great content but with zero comments on any posts
Lots of good content but with lots of Adsense or other ads
No “About” page or business information
And the number one brain-dead giveaway: no contact form or email address
If you pay attention as you surf around, you may want to keep an eye out for some of these dead giveaways. If it looks like the site is profiting from stolen content, it is advisable to leave immediately and locate an original source of information (you could even be cool and report the scraper site to the original author). I.e., help strengthen the legit blogging community and don’t support scrapers in any way. But avoiding scraper sites is merely an afterthought. The real challenge is to have a solid strategy in place that will help you identify, eliminate and prevent stolen content. Unfortunately, there is no “magic cure” that will stop the scrapers from stealing your hard work — apart from running a private site or not providing a feed — but there are many great tools that have proven quite effective in fighting the war against stolen content. While not completely exhaustive, here are some powerful tips and tricks that have served me well over the years:
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.
..and so on. These directives all function in different ways, but they all serve the same basic purpose: control how Google crawls the various pages on your site. For example, you can use meta noindex to instruct Google not to index your sitemap, RSS feed, or any other page you wish. This level of control over which pages are crawled and indexed is helpful, but what if you need to control how Google crawls the contents of a specific page? Easy. Google enables us to do this with a set of googleon/googleoff tags.
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:
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.