A content disposition header can be used to tell web browsers to ask the user where they want to save the file (and download it) instead of actually opening the file in a browser tab/window. Very handy if you want to have a download button.
Content-Disposition: attachment; filename="filename.mp3"
Tested in: Firefox, Safari, IE, Opera, and Google Chrome
PHP supports sharing sessions among subdomains which can be very useful for sharing cookies and sessions among multiple web applications.
I wanted my users to remain logged in while navigating from www.example.com to site1.example.com. By default PHP will treat these domains as two separate sites and users would have to login to each subdomain.
All you have to do is to either set the following setting in your php.ini file:
session.cookie_domain = .example.com
Or, set it from within your code before you create your session:
ini_set("session.cookie_domain", ".example.com");
session_start();
Facebook takes security seriously and there are many many things a Facebook app cannot do. Sometimes it is necessary to create an iFrame and load the page in to work around Facebook's security model. This example shows how you can continue to use the $facebook->require_login() method while you are inside an iFrame.
Each Facebook request to your application contains a number of parameters that you can use to authenticate if the request really came from Facebook and if the user is actually logged in. These parameters looks like this:
Array
(
[fb_sig_in_canvas] => 1
[fb_sig_request_method] => GET
[fb_sig_friends] => 12345678,123456789,...
[fb_sig_locale] => en_US
[fb_sig_in_new_facebook] => 1
[fb_sig_time] => 1265247656.6432
[fb_sig_added] => 1
[fb_sig_profile_update_time] => 1261813927
[fb_sig_expires] => 1265248900
[fb_sig_user] => 1234567
[fb_sig_session_key] => 2.18zPq2sNPEE6sn0wpMLc5w__.3600.1265248800-1234567
[fb_sig_api_key] => ab6c2d2604ae9604be0efef88315c53e
[fb_sig_app_id] => 289424642699
[fb_sig] => 575ed0ccd0c9b3ea2d5d7c5417187de6
)
If you create an iFrame in your facebook page, the parameters will be passed to the iFrame but by will not automatically be passed from one request to the next. Once the user clicks on a link or you try to do an ajax request, you will not be able to validate the user. The simple trick to keep the authorization is to pass the fb_sig_* parameters to request. A handy PHP function like this will help:
If you append the result of that function to the query string of each request, the $facebook->require_login() call and the $facebook->validate_fb_params() can then successfully validate if your user is from Facebook.
Mozilla Firefox 3.5 and Firefox for Mobile 1.0 (Fennec) both have support for modifying a web applications look based on screen dimensions and current orientation. These abilities give web developers the power to build better web applications for mobile devices and the ability to optimize the browsing experience when screen space is constrained.
Web applications look and feel is defined by a CSS file, so therefore the Firefox developers made it super easy to tie current orientation and screen dimensions into which CSS file to load.
For examaple: If the browser is in portrait mode, a single CSS media parameter will specify which styles to use:
In the same way, you can create a custom CSS stylesheet for users who are browsing with a screen size between 500 and 700 pixels:
Firefox 3.6 adds support for orientation events in JavaScript, so you can get current updates of how the user is holding their mobile device:
Once you register the event handler, the handleOrientation function will receive an object specifying the x, y, and z value of the devices current position:
With those parameters and a game timer, you can probably build the Labyrinth game.
For those of your that are ready to start experimenting with this API right away, Mozilla Developer Center has the full Firefox orientation documentation.
As you've probably heard, both YouTube and Vimeo have released beta support to their massively popular websites to play videos using the HTML5 video tag instead of Flash. While I am glad the video sites are finally switching to the native HTML video tag, I am perplexed why they have gone with the non-free option.
Firefox, Safari, Google Chrome, and soon Opera all support the HTML5 video tag with the ability to play Ogg Theora encoded videos (except Safari). On the other hand, H.264 is only supported by Google Chrome and Safari. Both of these formats do the same thing, they specify a compression standard that allows for efficient playback at relatively small file sizes. There are a number of technical differences, but generally, they preform relatively the same. The big difference between the two is that Ogg Theora is royalty free and available for anybody to use, while H.264 is encumbered by patents held by the MPEG LA association. This same organization will charge anybody who uses it a hefty royalty fee starting in 2011.
If you have a personal blog and want to put a video on your website using H.264 this means you need to have to hire a lawyer to create a deal with the MPEG LA to allow you to use their codec. This will either cost you a lot of money, or they will not allow you to do it. They do have the right to simply deny you if they don't feel like it.
However, if you use the open Ogg Theora format, you are free to simply upload the video to your website to start using it, the same as uploading an image. Ogg Theora is not covered by any patents and is royalty free.
I don't understand why both YouTube and Vimeo are both going the non-free route. Is it simply because they have the money to pay MPEG LA? Whatever the case, endorsing H.264 encoded videos as the format for video on the web is an option for large companies with money to pay, but it's completely the wrong choice for blog writers and any small or medium sized organization.
