Lambda the Ultimate

Really!!

I've been hosting LtU on a rented dedicated server that I also use to host various services for consulting clients. As such, hosting was essentially "free", since the server was paid for and had spare capacity.

However, the server that LtU was on had become outdated and unreliable, and for the most part moving services off it was easier than trying to upgrade and repair it. LtU was an exception - moving it proved challenging, because it currently depends on old software versions, particularly PHP 5.2. PHP 5.2 can't reasonably be installed on a modern Linux system via the standard package repositories, since its dependencies conflict. Even if it could be installed, it would result in a rather dubious configuration.

That could of course be addressed by installing it on its own server with the necessary software versions, although that would have started incurring a direct cost. It could also be addressed by upgrading Drupal, but that's a bigger project (one which will now be a bit easier to undertake, with the new setup.)

What I ended up doing instead was to deploy LtU in a set of Docker containers. That worked very well, allowing the software versions that LtU depends on to be deployed to containers which can then be deployed to any server running Docker, without interfering with anything else on the host server.

LtU now runs in four Docker containers: one running Apache with PHP 5.2 and the Drupal code, one running MySQL, and two data containers, one for Apache logs and one for the MySQL database data. This provides a great deal of flexibility for migrating the site between servers in future, and allows it to continue to enjoy "free" hosting.

Many thanks.

Thanks. I believe that's related to known issue #1. It seems the old system had Latin1 as the encoding specified for its database tables, but the front end was rendering with, and accepting, UTF-8. The new config is being a bit more strict about such things. I hope to have that resolved soon.

(P.S. When one googles such things related to Drupal, the posts and comments about it are all about 8 years old. I interpret this to mean that the solutions are mature!)

See e.g. http://lambda-the-ultimate.org/node/5038 (and comments) — my original post contained Unicode characters. For instance, lambda is λ and the em-dash (UTF8: E2 80 94) is —. That's what you'd get if you read the UTF-8 stream as Windows-1252 (the Windows variant of Latin1) — the whole post seems to match quite precisely; by now the stream is probably in UTF-8, but you can still try some variant of:
$res = mb_convert_encoding($field, "Windows-1252", "utf8"); (no warranty!).

It happened to me once in the past (and I used the above for a fix), and while I didn't get to a complete diagnosis, I've learned that since PHP strings are arrays of bytes, PHP is only too happy to store a the bytestream for a UTF-8 string into a Latin1 database field. In that case, converting the database to UTF-8 will decode the UTF-8 bytestream using Windows-1252 and encode it *again* with UTF-8. (Not sure how Latin1 ended up being Windows-1252, but that seems quite common, since Win-1252 is a superset — https://en.wikipedia.org/wiki/Windows-1252#Details). IIRC, the used encoding depends on what the client browser used (which maybe was set by the page encoding), since PHP does no character conversion on its own, but I hope I misremember this detail.

Just to be sure, I'm not asking anybody to fix this. It would be great, and I hope that my tip makes this easy, but given the potential mess, I wouldn't ask dealing with this to my worst enemy!

for all the hard work.