Opacity CSS Validation Using Javascript

I’ve always been annoyed by browser specific CSS properties. Not necessarily because of the purpose browser specific CSS properties serve, but more so the isolation of each property. For instance, applying opacity across multiple browsers requires something like the following:

#selector {

 filter:alpha(opacity=80); /* Internet Explorer */

 -moz-opacity:0.8; /* Mozilla Firefox (legacy) */

 -khtml-opacity: 0.8; /* Safari (legacy) */

 opacity: 0.8; /* CSS3 Standard */

}

Someday when CSS3 goes completely live, we won’t have to worry about opacity not validating; however, what about other browser specific styles that we need in order to support multiple browsers? If you don’t care about passing W3 CSS Validation, then this article is not for you. But for those of you whom require validation, or have a perfectionist nature, can workaround the validation engine using both JavaScript and CSS.

Although it may not be the best method out there, using JavaScript to implement impossible-to-validate CSS works the best for me.

Why does it work? Well its simple. Most bots/spiders don’t render JavaScript, which I imagine is for a number of reasons. Perhaps rendering JavaScript would slow down the bots’ very purpose of data mining (or with bad bots, the purpose of infiltrating). In fact, there usually isn’t anything valuable to a bot that would come from having to render JavaScript. (As a side note, this doesn’t mean that their aren’t bots that seek out sites that have vulnerabilities in their JavaScript markup, but reading JavaScript and rendering JavaScript are completely different).

So first, its a matter of migrating browser specific code to its own spreadsheet (so our JavaScript can include it).

/* invalidable.css */

#selector {

 /* random properties */

 zoom: 1;

 -moz-border-radius

 /* opacity properties */

 filter:alpha(opacity=80); /* Internet Explorer */

 -moz-opacity:0.8; /* Mozilla Firefox (legacy) */

 -khtml-opacity: 0.8; /* Safari (legacy) */

 opacity: 0.8; /* CSS3 Standard */

}

Once you have your browser specific properties on its own stylesheet, its just a matter of creating a JavaScript file that will “dynamically” insert the <link type=”text/css” rel=”stylesheet” href=”/assets/styles/invalidable.css” media=”screen”/> into your page (thus keeping with XHTML Strict standards).

// invalidable.js <-- note the extension

//

// Dynamically Inserts CSS Link Tag

var headTag = document.getElementsByTagName("head")[0];

var linkTag = document.createElement('link');

linkTag.type = 'text/css';

linkTag.rel = 'stylesheet';

linkTag.href = '/assets/styles/invalidable.css';

linkTag.media = 'screen';

headTag.appendChild(linkTag);

Now all you have to do is throw in an JavaScript include tag:

<script type="text/<span class="searchterm1">javascript</span>" src="/assets/js/invalidable.js"></script>

Your done! Bots will now only get this:

<script type="text/<span class="searchterm1">javascript</span>" src="/assets/js/invalidable.js"></script>

…while visitors will get this:

<script type="text/<span class="searchterm1">javascript</span>" src="/assets/js/invalidable.js"></script>

<link type="text/css" rel="stylesheet" href="/assets/styles/invalidable.css" media="screen"/>

NOTE: It’s important to mention that visitors who have JavaScript DISABLED will NOT have the CSS file included, simply because the JavaScript won’t process; however, I will go on to say that its incredibly rare for you to have visitors that have JavaScript disabled. The only cases you’ll probably run into is visitors who visit your site from a cheap mobile phone (iPhone supports JavaScript), or a visitor who knows what their doing and has a Firefox plugin like “NoScript” installed.

On another subject, its important to mention that Google now penalizes for showing “different” content to search engines than to visitors. Would I classify an extra line in the section as different? Probably not. It’s my opinion that Google’s algorithm would check for differences in content, and not necessarily markup. I also haven’t seen very many cases where practices such as using JavaScript to “show/hide” content, be penalized in anyway.

Querying a SQLite 3 database using PHP

Previously, I detailed a way of creating a database in A basic hit counter using PHP and SQLite 3 using PHP Data Objects and PHP 5. For most web sites, SQLite would be fine, but for very high volume (as in many hundreds of thousands of hits per day), there are better options - Appropriate Uses For SQLite (SQLite.org) has more details on when SQLite is a good option.

Here is an example of how to query the data and display it on a page (to see which pages are popular for example).

<?

$dbfolder = $_SERVER["DOCUMENT_ROOT"]."/data/";

$dbname = $_SERVER["HTTP_HOST"]."_log.sq3";

$logdb = new PDO("sqlite:".$dbfolder.$dbname);

$starttable = "<table>

<tr>

 <th>Page</th>

 <th>Counter</th>

</tr>";

$endtable = "</table>";

$tablecontents = "";

foreach ($logdb->query("SELECT * FROM hits ORDER BY counter DESC") as $row)

{

 $tablecontents .= "

 <tr>

  <td>{$row['page']}</td>

  <td>{$row['counter']}</td>

 </tr>";

}

echo $starttable.$tablecontents.$endtable;

// close connection

$logdb = null;

?>

Pixie – small, simple, website maker

Recently, I have been looking at Pixie, to see how it works as a simple system for managing websites. It is open source (GPL v3), written to web standards (XHTML Strict, Microformats) and powered by jQuery and PHP/MySQL. 

It consists of several page types – dynamic (blog, news), static or module (e.g. contact form, events, links etc). Plugins add additional functionality to modules (like allowing comments on blog posts). Blocks allow you to add content alongside your content (e.g. display RSS content from BBC News). 

Easy enough to extend, with detailed guides for module development (so you can create additional ones to those that are bundled with Pixie) block development and theme development. 

A few additional blocks I have created: News (latest content from a page named ‘news’) and Google Maps. These can then be shown on any page (so you can see news on your home page for example).

Optimizing Page Load Time: Fixing Your HTTP Pipeline Problem

Defined here by Wikipedia.org, “HTTP pipelining is a technique in which multiple HTTP requests are written out to a single socket without waiting for the corresponding responses.”

Mozilla talks a bit more about the topic: “Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.”

I have accepted the fact that HTTP pipelining is pretty much disabled in all modern browsers, but that doesn’t mean I have to like it!

I have a widget in Firefox that allow me to bypass this missing “feature” and it sure seems to speed up my browsing quite a bit. However, why can’t everyone get together and work this problem out so we don’t need extensions/widgets/hacks to get around the limitations?

I attempted to harass Microsoft about it and never received an answer (I didn’t really harass them per say). Firefox isn’t mum on the subject (here), but it seems to come down to compatibility issues with certain servers, routers, et cetera in some specific cases (even if the HTTP/1.1 spec allows it).

So what does a web developer do (programmatically)?

Do we just accept the fact and move on or is there something we can do about it? How can we speed up our page loads to a world that can’t use pipelining?

It turns out there is a relatively simple way to “fake HTTP pipelining”. When I read through the article “Optimizing Page Load Time“�, I had a very revealing moment of self-inflicted-disrespect. The solution is so obvious, but it never dawned on me previously. Why not simply source content on the page from different locations? It doesn’t even have to be different servers, just different domains. Pretty simple right?

For example, we could do something like this for a single web page:

- Static Images: images.ashishlakhotia.com
- Javascript Includes: includes.ashishlakhotia.com
- CSS: css.ashishlakhotia.com
- Static Content: static.ashishlakhotia.com
- Dynamic Content: dynamic.ashishlakhotia.com

Now this is a pretty extreme example that I wouldn’t recommend for production (except in very specific cases), but let me explain what happens in simple terms. Instead of your browser making a request to one domain for all the content, data, files, and everything for a page; it splits up the requests amongst the various sub domains (of which could be hosted separately or together).

What does splitting up the content get us?

The advantage is that the browser isn’t sitting around waiting on previous requests to complete before moving on to the next item. It really only makes sense for larger pages. In fact there is a drawback, according to Aaron, “Beware that each additional hostname adds the overhead of an extra DNS lookup and an extra TCP three-way handshake. If your users have pipelining enabled or a given page loads fewer than around a dozen objects, they will see no benefit from the increased concurrency and the site may actually load more slowly. The benefits only become apparent on pages with larger numbers of objects. Be sure to measure the difference seen by your users if you implement this.”

Perhaps now you can consider playing around with this idea a bit on your own. Given plenty of tinkering time and careful examination, it could help decrease page load times noticeably.

If you’d like some more tips on this subject, check out Optimizing Page Load Time.

PHP Security - Ensuring A Safe PHP Setup

One of the inherent flaws with any popular web language like PHP is the serious potential of security vulnerabilities from improperly set up installations and servers. Although ensuring a secure server installation (whether Apache or IIS) is extremely important, that process is outside the scope of this article.

Instead, I’d like to recommend one simple tool that will should enable you to pro actively plug most “holes” in your PHP setup.

The ironic part about this article is that just a short while ago I thought I had everything “plugged” myself. I had done my reading up on PHP security and felt confident that I had a secure setup. Unfortunately, in an upgrade to a more recent PHP version, I accidentally overwrote my “secure” php.ini from the previous install. This caused one particular web site to be infiltrated by a nefarious ‘hacker’. Fortunately, there was no serious damage and I quickly found the problem.

However, if I had dropped PhpSecInfo onto the server and checked it out before going live, I would’ve immediately known there was a problem.

So here’s how it works: PhpSecInfo is just a single script and a small library that does the work. You simply drop the PHP files onto your server and execute index.php in your browser. You’ll be treated with a nice looking, clean, and easy-to-understand table of security information about your current PHP setup.

There are a mighty large number of security tests performed and all you have to do is analyze the results. Using the highly familiar red, yellow, green color schemes (from stop lights)… you know which tests have failed miserably, which ones you should probably check on, and which ones you can safely ignore. I realize that it’s not the end-all security check-up for a PHP installation, but I think it’s truly helpful to anyone operating a public facing PHP web server.

So, if you’re interested, check out PhpSecInfo from the PHP Security Consortium.

Whether or not you make any changes to your setup, it’s always good to be aware of your vulnerabilities. Oh yeah, it’s also totally free!

JQuery: The Best Javascript Library?

After stumbling across this article, I was in awe to see what has recently transpired in the world of Javascript libraries/frameworks. I had recently fell in love with Yahoo UI, but I was truly surprised to see that jQuery has gained remarkable traction in the market.

According to This Google Trend, it has leaped far ahead of even script.aculo.us in raw search volume. This is a particulary good sign for jQuery. As search volume increases, so will the number of pages related to jQuery obviously and vice versa.

In my experience, rapidly growing popularity is usually a pretty good sign of success for an open-source project. If problems exist with the project, usually the overwhelming interest helps to spur on solutions and increase the capability of the product because of the massive interest. I’ve seen this same trend previously with with CakePHP, an excellent framework alternative for PHP based loosely off of Ruby on Rails.

Regardless, it appears that I will start learning jQuery. Even if it turns out to lose the “battle”, it can’t help to learn more about advanced javascript without being forced to climb a steep learning curve.

Any truthfully, if this popularity trend continues, I think it’s safe to say jQuery is here to stay.

jQuery.com if interested.

Did you know that PHP has some pretty powerful type casting functionality built-in? It’s no surprise if you comprehend the roots of PHP (since it’s written in C), but I can’t help but think that casting is an often-missed tool when a PHP developer is trying to ensure data integrity.

Just for a moment, let me define type casting in case you weren’t “in the know”:

According to Wikipedia, “in computer science, type conversion or typecasting refers to changing an entity of one data type into another. “

So, in laymen terms, casting is an easy way to turn one type of data into another type. For example: converting a “string” variable filled with essentially text into an integer variable containing the same numbers but now representing a value. This makes it easy to do math with the value of what once was just a random string of characters.

The following cast types are allow in PHP:

• String - (string)
  
• Boolean - (bool), (boolean)
  
• Integer - (int), (integer)
  
• Binary - (binary) [PHP 6]
  
• Floating Point - (float), (double), (real)
  
• Array - (array)
  
• Object - (object)
  

So, in the real world, when does casting actually come in handy?

Normally, PHP handles all this stuff automatically behind the scenes. But, as is normal, dealing with MySQL database interaction is something to always take seriously — and type casting can help you out!

We’re going to assume your aren’t using the PDO Prepare statement (though you should be). As a PHP developer, a major part of your job is containing the inherent security risks of user input. It’s especially important when these inputs interact directly with the database.

So, your simplified (e.g. - don’t complain) database interaction code might look something like this:

$id = mysql_real_escape_string($_POST['input']);

$SQL = 'SELECT * FROM table WHERE id = ' . $id;

Call me an overly nervous Ned, but I’d prefer to use the following code:

$id = mysql_real_escape_string($_POST['input']);
$SQL = 'SELECT * FROM table WHERE id = ' . (int)$id;

Did you notice the subtle change? See the ‘int’ cast of the $id in the SQL statement?

This should certainly help to ensure that I haven’t missed any security holes for this query. Some might say it’s overkill, but I just wanted a simple explanation for using casting, so get off your almighty soapbox already.

Anyways, as you can see, type casting in PHP has real-world uses. Delve into type casting a little more and you’ll find a huge number of cases where it can make your code that much more bullet-proof.

So seriously, try out PHP Type Casting.

Open-Source vs. Home-Brewed PHP CMS

I’ve had a slew of requests lately from clients needing small web sites they can manage themselves (mostly small businesses).

Truthfully though, I simply prefer the client to manage their content themselves; so essentially we are looking at content management systems (CMS). I’ve had some mild success with CakePHP using my own “home-brewed” CMS for a few sites (thanks for the help Arthur). It works pretty well, but I keep wondering if I’m just reinventing the wheel by building a CMS myself.

So, after weighing the options, here’s my general winner/loser comparison:

Admin Interface Flexibility

• Home-Brewed CMS
  
  • I can create an extremely simple administrative side, one that is logical for the client. This allows me to create a dynamic and powerful site, but still allow the client to manage it. I think this aspect is extremely important and often-overlooked in most CMS’s.
  
  
• Open-Source CMS
  
  • Most of the good ones have too many features for the average client I see. They tend to allow extreme flexibility on the public side of the site (obviously important), but there is little or no flexibility on what admin functions are available. Basically, I need something that is simple to administrate, but has “advanced” options hidden away somewhere. It’s great to have a lot of complex configuration settings for design and administration, but not if that means the client will be calling me every day for help adding a new employee.
    

    Winner: Home-Brewed CMS
    

Relative Costs

• Home-Brewed CMS
  
  • It will certainly take some time to develop this product fully on my own. Calling this time “free” isn’t particularly accurate when my time could be spent making money in other ways. However, doing it on my own does guarantee I won’t ever run into any licensing or “upgrade pricing” issues in the future.
    


• Open-Source CMS
  
  • Free (mostly GPL) and generally easy to resell. There might be some issues with licensing in the future, but for the most part, pretty doubtful.
    

    Winner: Open-Source CMS
    

Learning Curve

• Home-Brewed CMS
  
  • Obviously becoming a relative expert of my own software is a fairly easy goal. However, the other consideration is the effort required for my graphic designer to adapt to my CMS. In general, it probably wouldn’t be much of a concern in a home-brewed situation (because I can be flexible).
    


• Open-Source CMS
  
  • Certainly a learning curve involved in becoming an expert. Knowing how to install & configure the CMS properly is one aspect, but I’m much more concerned about digging into the code. If I have an issue and I REALLY need it solved, it might be nearly impossible for me to figure out how to solve it quickly. On top of that, it’s likely the templating system the CMS uses would have a bit of a learning curve for my graphic designer.
    

    Winner: Home-Brewed CMS
    

Testing, Security, And Debugging

• Home-Brewed CMS
  
  • It’s extremely important to plan for and spend a considerable amount of time testing and debugging. In fact, on most projects, I spend a majority of my time testing. With that being said, the amount of time it would take me to fully test, debug, and check for holes in my own CMS… well, it would consume my life for a very long time. Even after that, there’s very little certainty that I would’ve done a good enough job. It’s just tough to compete with the experienced developers out there who have real-world ideas on things I haven’t thought of yet.
    


• Open-Source CMS
  
  • A single programmer simply cannot compete with open-source testing and debugging of a project. Multiple configurations, multiple types of hardware, multiple security situations… the combinations are mind-boggling. Plus, these projects are frequented by people who are insanely talented experts in areas such as database design, Javascript, XML, and even PHP. I have a good basis on all this stuff, but these people use their hords of pent-up knowledge to help the project achieve much more than I could have on my own… especially in the testing & debugging arena.
    

    Winner: Open-Source CMS
    

Future Growth (Extensibility)

• Home-Brewed CMS
  
  • I just have to face it: my own CMS will require constant maintenance and changes as it grows and evolves over the years. I will be rebuilding it constantly and reworking it to solve bugs, issues, and new features.
    


• Open-Source CMS
  
  • The growth and expansion factor is built-in. New versions will be coming out consistantly and will require little or no work on my part (except for dealing with upgrade bugs).
    

    Winner: Open-Source CMS
    

Extendability

• Home-Brewed CMS
  
  • Not quite as easy as it could be with an open-source system. With the except of JS scripts and PHP frameworks, cool new features are going to require blood, sweat, and tears on my part.
    


• Open-Source CMS
  
  • The clear winner. It doesn’t take long exploring any of the major CMS extension pages to realize the immense number of plugins available to achieve almost any goal. In fact, I was almost overwhelmed with the number of choices.
    

    Winner: Open-Source CMS
    

Monetary Viability

• Home-Brewed CMS
  
  • This is an awkward issue to discuss, but essentially, I am more valuable and can charge more to develop/use my own CMS. It comes down to billable hours and it just takes more to go with the home-brewed route.
    


• Open-Source CMS
  
  • Yes I know I can still charge the same amount for an open-source CMS, but somehow I just don’t think it will work out that way. Just call it a hunch I suppose, but using a pre-existing system just isn’t as valuable (though I realize that for the most part most clients wouldn’t know or care about the difference). Maybe it’s just my consciense?
    

    Winner: Home-Brewed CMS

So, by adding up the wins and losses, it appears that the open-source content management system has won the battle, but by just a hair.

Stay tuned for further articles as I delve into reviewing the major open-source PHP-based content management systems available right currently. I might be proven completely wrong once I really start delving into them again, but I hope that’s just my pessimistic nature.