Category Archives: PHP

Configure the symfony-mailer (swiftmailer) during runtime

One of my current projects is a multi-client environment. Each client has its own smtp-settings for the mailings that are done within that application.

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();
      $options["class"] = "Swift_MailTransport";
      // 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.

    class: myDynamicMailer
    # Rest follows here

Fixing TYPOlight-error #145 – Table ‘./tl_search’ is marked as crashed and should be repaired

Today a website of a customer running with TYPOlight stopped working. The friendly “there is an error”-message appeared. Even the administration-backend was not working anymore.

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
$con = mysql_connect($GLOBALS['TL_CONFIG']['dbHost'],
mysql_select_db($GLOBALS['TL_CONFIG']['dbDatabase'], $con);
// Repair table
$result = mysql_query("REPAIR TABLE tl_search", $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.


Its time to change the orm

I attended the great symfony day 09 in cologne yesterday. It was an awesome conference with nice people, interesting talks and discussions.

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.

Solving SOAP-ERROR: Parsing WSDL in PHP

Consuming web services is nothing special nor exciting. In one of my current projects I just did this. Using the web service on my development-system and on the test-system works just fine.

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…


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.

Solving utf-8-encoding-issues when connecting to oracle with php and oci8

In a recent project of mine a web-application is developed. This application consumes “some data” from an enterprise Oracle database. The development environment has the latest oracle drivers installed. Everything works as expected. Even the connection-speed is very good.
But then comes the deployment of that application. The production environment already runs for a while and hosts a certain amount of applications. Oracle driver had been installed a while ago.

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.


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.