This server has a dual stack configuration; it supports both IPv4 and IPv6. I don't have many IPv4 addresses, however; because of this, I can't use HTTPS on v4 for all sites. Still, since our home network also uses a dual stack (and, to be honest, because I can), I've added HTTPS over v6 support for all sites.
In addition, I use a secondary "test" server whenever I'm modifying the site itself. While the database is different between both sites, I sometimes synchronize content between both servers. That secondary server has a different host name, and is only available through HTTPS over IPv6 (OK, that's not completely true, but that's how I use it anyway).
When using WordPress' editor, it inserts full URLs for all links and images. This behaviour is quite understandable, and fine in most cases. However, because of the server's configuration, it causes a few rather nasty problems:
- if we are editing content from the main site through HTTPS, links and images will end up using that as well, and for an IPv4 user, this will lead to another server (and therefore a 404 error),
- worse, if we are editing content on the test site, it will either fail completely for an IPv4 user or request authentication from an IPv6 user.
I had a quick look at the WordPress plug-in repository but couldn't find something that did exactly what I needed, so I wrote the following piece of code. It will remove both the protocol and host name from HTML attributes.
* @package Fix my URLs
* @author E. Benoît
* @version 1.0.0
Plugin Name: Fix my URLs
Plugin URI: http://www.nocternity.net/
Description: Strip protocol and host name from URLs in HTML tags
Author: E. Benoît
Author URI: http://www.ebenoit.info/
function noct_fix_my_urls( $data )
$server = 'http' . ( $_SERVER[ 'HTTPS' ] ? 's' : '' )
. '://' . $_SERVER['HTTP_HOST'];
$input = array(
"=\\\"$server\\\"" , "=\\'$server\\'" ,
"=\\\"$server/" , "=\\'$server/"
$output = array(
"=\\\"/\\\"" , "=\\'/\\'" ,
"=\\\"/" , "=\\'/"
return str_replace( $input , $output , $data );
It's ugly, probably somewhat unsafe, a little too specific, but it does what I want it to.
For the record, I have been using PHP for years. Almost every web project I worked on ended up being written in PHP, and the same applies to the project I'm currently working on. Some may have noticed that this website, which had been rewritten in PHP recently, had suddenly switched to Python a few days ago.
This is the reason. Not that this fact, taken on its own, has a major bearing over how bad PHP is as a language. It's just the latest in a very long series of bad design decisions and, as far as I'm concerned, the drop that caused the ocean to yell, "Screw it guys, I'm going home".
A few years back, I was using PHP4, and I was quite annoyed with the (completely borked) OO system. Then PHP5 came along. A lot of improvement in there - objects were finally passed by reference automatically, and some new features had potential. Still, many of them were either borked or, which is probably worse, ill-designed from the start. "Oh well," I said, "I'll wait, it will improve over time."
And I was SO wrong.