Posts tagged php
Horde on Webspace (no shell) Part2
Dec 14th
After uploading the (now smaller) Horde with our FTP client we can continue with
Part 2 The Database
Since without shell access we can’t use Horde’s setup (./scripts/setup.php) to do this for us we have to manually set up the database for Horde.
This step depends on your webhosters so i’ll just make it quick:
First create a database with your webhost, then find: hostname (often locahost), username, password, type (often tcp) and databasename for that database.
Now your webhoster probably offers some kind of management frontend (mostly phpmyadmin). There you navigate to your database and select the “SQL” tab.
In the editbox you will find there you have to paste some of the lines from the .sql file provided with Horde that matches your database. I use mysql so i used ./scripts/sql/create.mysql.sql.
Out host already created the database, the user etc. so we only need lines that create tables. In my file this would be lines 52 -> end (look for the first CREATE TABLE statement). Copy&Paste and press Submit. This should have given you no errors and created ~18 tables in your database.
In the next step we will create a basic configuration that allows Horde to run so we can do the rest of the setup from within it.
Horde on Webspace (no shell) Part1
Dec 14th
Because i don’t like the webmailer my host has chosen for me (roundcube) i decided to try installing Horde on the webspace that came with it.
This experiment will most likely fail because i don’t have shell access and the php installation is probably missing vital modules .. but what else is there to do on a saturday evening
Part1: Horde is f***ing huge!
du -sch .
108M total
I’ll start by making horde a little slimer…
This will give me all the folders with locales other than german or english (cd to horde first)
find -iname ??_?? -type d | grep -v de_DE | grep -v en_US | grep -v en_GB
and this will delete them
find -iname ??_?? -type d | grep -v de_DE | grep -v en_US | grep -v en_GB | xargs rm -r
The same for the “.po” files:
find -iname ??_??.po -type f | grep -v de_DE | grep -v en_US | grep -v en_GB | xargs rm -r
du -sch .
51M total
Half the size, nice 
PHP DateTime bugs: i hate i18n
Mar 11th
Handling different dates and timezones in an application is – like most aspects of i18n – very annoying (to put it mildly)… Recently we discovered the following behaviour at work…
If you create a DateTime object like this (in the current stable version of php, 5.2.3):
<?php
$oDateTest = new DateTime("@0", new DateTimeZone(date_default_timezone_get()));
echo "tz: ".$oDateTest->getTimezone()->getName()."\n";
echo "date: ". $oDateTest->format("Y-m-d H:i:s")."\n";
?>
It will be in the default timezone (‘Europe/Berlin’ in my case) but say the date is 1970-01-01 00:00. This is wrong. The Unix timestamp “0″ stands for that exact date, but in another timezone: UTC. It should be 01:00 in Berlin.
This bug was reported multiple times, but with sometimes confusing bug reports. But someone had managed to submit a clear bug report with code to reproduce the behaviour (PHP Bug 43003) and the php developers acknowledged the bug and issued a fix that i verified to be (at least) in the following snapshots: php5.2-200803111530 and php5.3-200803111530.
Sadly, this fix is at best “unintuitive”, maybe it even qualifies as “still broken”. The above code gives the following output in these snapshots:
tz: +00:00
date: 1970-01-01 00:00:00
So, the DateTime object now knows that UNIX timestamps always are given in UTC and sets it’s timezone accordingly. But is this what it should do in this case? I – the programmer – clearly stated i wanted the DateTime object to be in my default timezone! Even if i explicitly give the timezone as ‘Europe/Berlin’ during construction, the object’s timezone still is UTC afterwards.
So instead of knowing that i have to manually set the DateTime to UTC, then back to my desired timezone when working with an UNIX timestamp i now have to know that a DateTime will be in UTC after setting it up with a UNIX timestamp. Personally i hate having to know things, IMHO it’s a sign of weak design. The API has to be clear, i don’t give a rat’s backside about the inner workings and struggles of the objects i use.
We went from this:
// FIXME: DateTime issue... needs the conversion to and from UTC...
$oDateTest = new DateTime("@0", new DateTimeZone('UTC'));
$oDateTest->setTimezone(new DateTimeZone("Europe/Berlin"));
To this:
// FIXME: DateTime issue... will always be UTC afterwards...
$oDateTest = new DateTime("@0", new DateTimeZone('Europe/Berlin')); // or UTC, or what/ever....
$oDateTest->setTimezone(new DateTimeZone("Europe/Berlin"));
Is this better or worse?