Recently in Programming Category

If you’re using JQuery, you’re likely concerned about the size and amount of data in your pages. With the average web page now over 300k (and 50 objects), if you can come in under the average your site appears more responsive than average (many people are still on dial-up as broadband isn’t frequently available outside densly populated areas). A good goal might be half the average, or 150k per page. JQuery itself only adds about 20k, but if you want to use some UI effects, JQuery’s UI can add 100k to your pages, making it impractical for use if good response time is a goal.

At the end of 2008, Microsoft abandoned their old search API. While older applications continue to work, new AppID’s only work with the new V2.0 API. If you’ve created a new AppID, and wonder why none of the code samples you find on the Web work with it, now you know. It’s not hard to update code to use the newer (still in beta) V2.0 API, and we’ll do exactly that by updating our previous API search code. If you’ve used the old code, it’s quite simple to update to the new code. Just copy the file, and change one line in your PHP page — the new code requires PHP5, so be sure your server has PHP5 installed.

If you’re interested in having a site search on your web site, you can create one yourself, use one of the free services, or better yet use one of the existing search engines. The big three (Google, MSN, Yahoo) each released API’s so you can query them, and then present the results any way you wish. This article presents a PHP class which queries MSN Search, and returns the result as an array.

In another article we discussed the MSN Search API, presenting a PHP class to allow easy use of MSN Search. But what if you want to use the Google API instead of MSN? One advantage of object-oriented programming is the class functions as a “black-box”; the user of the code unaware of how it does it’s job so MSN’s API can be swapped with Google’s, Yahoo’s, or any other. All you have to do is modify the search() function for Google, and then the previous code works for Google’s API.

In our previous article on PHP, XHTML and MIME type, we focused on using XHTML and sending the correct MIME type as application/xhtml+xml, as it was the future of the web. Additionally, we forced PHP to send the correct 304 Not Modified header for pages not modified to reduce bandwidth and increase your users’ experience.

Using PHP for your XHTML web site is great, but if you’re not considering possible effects you could be violating Internet standards and reducing the usability for your users. You might not know your validated and tested XHTML is treated as “tag soup” by browsers, or that without sending the proper headers your pages caching ability is severely reduced, or perhaps some browsers (due to bugs) won’t cache your page at all. When using PHP with XHTML, several issues need to be considered.

Previously, we wrote about getting the browser default language in PHP. But so what? What can you do with it? In this article, we’ll use the previous code, and expand on it to create a page which can be automatically translated into many languages — with the help of the Google translator.

If you’re doing international (i18n or Iñtërnâtiônàlizætiøn) work (or just want to make your site available in several languages), you’ll likely need to determine the users default language in your PHP code to determine which language to serve up. Searching the web yields one common code piece frequently; unfortunately as you’ll soon see it may not give you the results you need as it ignores parts of the HTTP spec which may or may not be critical to the accuracy of the results.

Most blog software allows the use of markdown syntax on posts. Markdown is a simple formatting language with an easy syntax which easily transforms into HTML and other formats (PDF,RTF,LaTeX). It’s designed to be a simple markup language (based on email formats) which is quite easily read in it’s native form. Here’s what the creator of Markdown says about the syntax:

One of the advantages of Movable Type over Wordpress comes from publishing static HTML files (fetching data from the database for each page request doesn't scale well). By creating static HTML files, round trips to the database are eliminated and your blog is more likely to handle sudden bursts of high traffic. How many times have you gone to a popular Wordpress blog and seen database errors like "too many database connections"?