From static …

Symfony allows the configuration of the mailer in its factories.yml. There smtp-settings can be definied. But in this case this is impossible as every client has different smtp-settings (every client can use its own smtp-settings to handle mailings).

As I did not want to create an instance of the Swift_Mailer (and Swift_SmtpTransport) myself I decided to create my own mailer-class which is derived from the symfony one. So I get the full benefits of logging.

… to dynamic

class myDynamicMailer extends sfMailer
{
  public function __construct(sfEventDispatcher $dispatcher, $options)
  {
    // Load client based configuration
    $cfg = EmailConfiguration::getCurrent();
 
    if(!$cfg->isSmtpConfigured())
    {
      $options["class"] = "Swift_MailTransport";
    }
    else
    {
      // Update settings for the current client
      $options["transport"]["param"]["host"]      = $cfg->getHostname();
      $options["transport"]["param"]["port"]      = $cfg->getPort();
      $options["transport"]["param"]["username"]  = $cfg->getUsername();
      $options["transport"]["param"]["password"]  = $cfg->getDecryptedPassword();
    }
 
    parent::__construct($dispatcher, $options);
  }
}

Simply update factories.yml with the new class and the dynamic configuration is applied.

all:
  mailer:
    class: myDynamicMailer
    # Rest follows here

Enabling the “display-error” setting revealed that there was a database-problem (perhaps due to a crash of mysql).

#145 - TABLE './tl_search' IS marked AS crashed AND should be repaired

The problem was that I have no shell-access to the server of the hosting provider and no administrative-console for the database. So I built a little “repair-script” to fix this issue.

// Typolight table repair script
define('TL_ROOT', dirname(__FILE__));
 
// Load the configuration
require_once('system/config/localconfig.php');
 
$con = mysql_connect($GLOBALS['TL_CONFIG']['dbHost'],
  $GLOBALS['TL_CONFIG']['dbUser'],
  $GLOBALS['TL_CONFIG']['dbPass']);
mysql_select_db($GLOBALS['TL_CONFIG']['dbDatabase'], $con);
 
// Repair table
$result = mysql_query("REPAIR TABLE tl_search", $con);
var_dump(mysql_fetch_array($result));
 
mysql_close($con);

Its placed where the “front-controller” (index.php) resides and after executing it via browser the problem is gone and the website is up and running again.

Propel is dead

One thing got crystal clear during the talks. Propel is dead! In the next version 1.3 of symfony Doctrine will be the default orm. If thats not a hint … In symfony 2.0 Propel will be deprecated. Additionally the “leader of Propel” stated out that he is no longer leading Propel.

So its time to move to Doctrine. The new features in Doctrine 1.2 described by Jonathan Wage are quite nice. And Doctrine 2.0 will be even more impressive.

Sadly it will require a lot of work rewriting Propel “criteria queries” with Doctrine’s DQL-queries. But I’m certain that this step makes my applications future prove.

However when deploying the module to the production-system and using it an exception is thrown containing the following error:

SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://my-webservice-provider/service.wsdl'

This exception was thrown during the initialization of my custom soap client (which derives from SoapClient). So what is the problem here? Two systems worked perfectly. One system is causing troubles. The issue is probably not caused by the code itself…

Conclusion

The error message given by the SoapClient is misleading and should be more precise! The openssl extension for PHP (php5-openssl) simply was not installed on the production system. Because the service is consumed via https openssl is a requirement.

I would asume an error message like: “Cannot load openssl extension” or something like that… But as TDD tells you: Don’t asume anything.

Here comes trouble…

Both environments (production and dev/test-system) connect to the same Oracle database. Inside the production environment all data received from the Oracle database is corrupt due to wrong encoding. A simple mb_detect_encoding shows ‘UTF8′ which cannot be. The whole web-application “is” utf-8. There is no implicit or explicit conversion of encodings performed. So the problem must be caused by the Oracle drivers themselves.

Fixme

setlocale did not work. The encoding option in the dsn (connection string) did not work. What did work was setting the NLS_LANG in the registry. The key can be found inside HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\{SomeInstance}. In this case the NLS_LANG was set to GERMAN_GERMANY.UTF8.

// Some static command here
$cmd = '/path/to/fop -c config.yml -fo input.fo -pdf outfile.pdf';
exec($cmd);

So quiet

This doesn’t work! There is no pdf-file. exec gives no output, no warning, no error … Simply nothing. If I run the command inside the shell the pdf files gets created as expected.

Use-Cache = true

The cause of the problem is the config-option use-cache which is set to true on default.
FOP wants to create a cache-file to speed up the font-embedding-process which fails in my case.
Running the fop-command as the user apache runs with gives an error. The creation of the cache-file fails due to missing filesystem permissions. I really have no idea why this output isn’t catched by exec. Some java-related behavior? Perhaps stdout is redirected somewhere else?

Use-Cache = false

I’m not using the “auto-detection”-feature for font-embedding as I clearly define where my fonts reside. So I added the option into my fop-config-file.

false

Finally everything works as expected.

Redirection

In order to get information of what fop does use the following command:

$ouput = array();
$ret = 0;
echo exec('/path/to/fop -fo test.fo -pdf test.pdf > /path/to/logfile.log 2>&1', $ouput, $ret);

I’m using Propel 1.2 (an upgrade will be done soon) but for other people out there …

Consider the following declaration-fragment for the “Foo-entity”. Nothing special here.

<column name="name" type="VARCHAR" size="32" required="true" />
<column name="culture" type="CHAR" size="5" required="true" default="de_DE" />

Now if we create the new object and show the state (var_dump) of the object the culture-field is set to ‘de_DE’ which is correct.

$inst = new Foo();
$inst->setName('Foobar');
$inst->save();

But if you look in your (debug-)logfiles you will see that the insert-query will be generated as:

INSERT INTO foo (NAME) VALUES ('Foobar')

Where is the value for the culture column?

Propel keeps track of the modified columns to reduce the size of the update/insert-queries. The default values for the object will not be set through the generated class-methods. Instead the default values are directly assgined in the member-variable of the generated class. So Propel is unaware that the values has changed.

protected $culture = 'de_DE';

Conclusion

I don’t know if this bug is fixed in Propel 1.3. Soon I will know …

As I will continue working with Propel 1.2 in the current project the “workaround” is to manually set the culture. This is best done in the constructor of your derived class. So Propel knows that the column is modified.

class Foo extends BaseFoo
{
  public function __construct()
  {
     // Note: The generated base-class does not have a constructor
     // so parent::__construct will fail!
     $this->setCulture($this->getCulture());
  }
}

The plugin ships with XLIFF-files for interface translation. In order to get gettext working simply create the required directories inside the plugin-directory (plugins/sfAssetLibraryPlugin/modules/sfAsset/i18n) and create a new catalog for each language (de, en, fr, ...).

The important thing here is to take care of the “translation-namespace” the plugin uses (sfAsset in this case).

echo __('Description', null, 'sfAsset');

Directory layout of the sfAssetLibraryPlugin

Propels (Creole) “criteria infrastructure” is a great speed-up for the development process and makes it easy to “write” queries. However if you are forced to create a SQL-Join which requires multiple join-conditions the criteria-api is not a helper anymore.

In order to make use of the criteria-api even in this case a “hack” can be used. Someone else described it in a blog-post.

$c = new Criteria();
$c->addJoin(Object1Peer::ID, Object2Peer::ID .
  ' AND ' . Object1Peer::LOCALE . ' = ' . Object2Peer::LOCALE .
  ' AND ' . Object1Peer::WHATEVER . ' = ' . Object2Peer::WHATEVER,
  Criteria::JOIN);

Its a “hack” but you are not required to write the whole sql-query on your own and can rely on the criteria-api.

As I found out the Propel-developers are aware of this problem and a solution is planned for the (hopefully soon) next Propel release 1.4.

Der Google-Maps-Service ermöglicht Geocoding mittels HTTP-Anfragen. Eine feine Sache und dank JSON als Rückgabeformat und json_decode sehr einfach zu nutzen.

Problem mit dem Encoding und json_decode

Der folgende Code liefert nicht das erwartete Ergebnis. Die Funktion json_decode liefert für die Antwort ein “leeres Ergebnis”.

Eine Analyse von $reponse zeigt einen fehlerhaft codierten String. Das ß ist falsch codiert, obwohl der Reponse in UTF-8 vorliegt (vorliegen sollte).

// Hinweis: Fehlerauswertung fehlt hier gänzlich,
// was in produktivem Code nicht sein darf!
$handle = curl_init ();
$url    = "http://maps.google.de/maps/geo?key=myKey&output=json";
$url   .= "&q=Vollmerhauser Straße 115, 51645 Gummersbach, Deutschland";
 
// Set curl options
curl_setopt ($handle, CURLOPT_URL, $url);
curl_setopt ($handle, CURLOPT_RETURNTRANSFER, 1);
 
// Get code and parse json
$response = curl_exec ($handle);
$json     = json_decode ($response);
 
curl_close ($handle);

Fügt man jedoch einen User-Agent als curl-option (CURLOPT_USERAGENT) hinzu, ist das Ergebnis korrekt und json_decode verrichtet seinen Dienst, wie erwartet. Ein sehr seltsames Verhalten…

// ... Code siehe oben
curl_setopt ($handle, CURLOPT_USERAGENT, 
    'Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050309 Firefox/1.0.1');
// ... Code siehe oben

StatusCode 620 (G_GEO_TOO_MANY_QUERIES)

Der Geocoder liefert eigene Response-Codes (GGeoStatusCode) um den Status der Geocodierung anzuzeigen. Bei vielen Anfragen tritt häufig der Response-Code 620 (G_GEO_TOO_MANY_QUERIES) auf.

Google beschränkt also die Anzahl der Geocoding-Operation pro Sekunde. Deshalb müssen die Anfragen limitiert werden.

// Warte 100ms
usleep (100000);

Nun sinkt natürlich der Datendurchsatz, aber damit kann man leben, denn die Anfragen werden richtig beantwortet.