I want to recommend this post by Joel Spolski about differences in font rendering philosophy between Mac OS & Windows.
I never really understood why Apple failed to render sharp fonts on screen. Now I understand the purpose. I'm still not sure which is best though... ;)
It's been 3 years since PHP 5 has been released. Yet PHP 4 still rules on the vast majority of web hosting platforms.
This is annoying for PHP open source developers who cannot leverage the potential of PHP 5 as long as they need to support PHP 4. This is also annoying for the PHP development group since they still need to support PHP 4 instead of focusing on PHP 6.
In a way it is also annoying for the web hosts themselves, since they too need to deal with clients who want PHP4 compatibility and others who want PHP5 features.
What strikes me is that the solution seems obvious, and yet the PHP team fails to recognize it.
The only reason webhosting providers haven't massively upgraded to PHP 5 yet is because it would break applications running on their current client's site. It may also prevent new clients from installing well known applications (phpBB...) which may fail on PHP5.
Of course, that would not have been such an issue if PHP5 was indeed upward compatible with PHP4. But it isn't! (object references,
clone keyword, etc.) So what do we do now?
Web hosts install PHP5 next to PHP4, but you need to rename your scripts to script.php5 instead of script.php ... which breaks existing URLs... so no-one uses that either.
The real simple solution would be for the PHP team to release some PHP 5.x version which would actually behave like PHP 4 (completely!) with a simple config switch. It could then be installed in place of PHP 4 without breaking anything.
Once that is done, any PHP application that is PHP5 aware would just include something like this:
and everything would be fine.
Maybe PHP5 should have 2 separate php.ini files. Maybe that
ini_set() call should be required to come at the very top of the script. Maybe it should be a different function. But all in all, the solution seems so simple you have to wonder why anyone would want to support the older version for 3 years instead...
Besides the basics, there's three simple things I'd expect from an FTP client:
- Symetrically navigate in subfolders locally and remotely with single clicks;
- Upload files and overwrite the server side only if the local file is newer;
- Search the server for old files that no longer exist locally (with an option to ignore folders that contain user uploaded content).
I have never ever found a Windows tool doing all 3 ! :'(
- CuteFTP 8 Pro does #1 and that's about it (Its folder sync tools are basically a joke : it compares dates without comparing times!)
- FileZilla 2.32 does #2 but that's about it.
- My old DreamWeaver MX does #3 but is so painfully slow that it's barely bearable!
I'm so impatient to see FileZilla 3 as well as the new DreamWeaver CS3... but I fear I'm gonna be disappointed again... :-/
Maybe I should start to figure out how to run
rsync on Windows right now... |-|
“People don’t recognize how important URIs are. The notion that you have a huge, world-scale, information space, and that everything in it has an name and they’re all just short strings that you can paint on the side of a bus; that’s a new thing and a good thing.”
– Tim Bray
This is good for the users who can choose whether or not to type in the "www." part. However, it is not good for search engines which will tend to see a lot of duplicate contents.
If you are on an Apache webserver, you can use mod_rewrite in order to redirect all traffic that goes to the www.domain to the "non www" domain. (If you want it the other way round, see below)
Try adding this to a file named ".htaccess" at the root of your site (create that file if it doesn't exist):
Note: More advanced users will prefer to add this to the httpd.conf / apache2.conf instead in order to gain a little efficiency and also to not interfere with tests on development/staging servers.
RewriteEngine on activates mod_rewrite.
The first RewriteCond makes sure we have a non(!) empty(^$) hostname to work with.
The second RewriteCond detects that the host name is not(!) the one we want (e-g: it has an extra www. part in it).
The RewriteRule sends out a permanent(301) redirection to the right domain name followed by the currently requested path/page ($1).
Handling multiple domains at once
Below is more elegant (yet complex to read) solution that can handle multiple domains at once (if you have "ServerAlias"es) and that doesn't require to type-in your domain (just copy/paste):
The trick here is to use %1 which matches the canonical part of the domain name in the second RewriteCond (.+) .
By popular demand, here is how to redirect from somedomain.com to www.somedomain.com