Category: PHP

Posted on

Schau auf die Error_Log

Man sollte sich tatsächlich angewöhnen beim Entwickeln immer eine Console offen zu haben und die error_log zu beobachten.

tail -f /var/log/apache2/error_log

Bekommt man nämlich so einen Fehler in der error_log:

ALERT - configured POST variable limit exceeded - dropped variable ...

… bleibt die Seite meistens ohne Fehlerausgabe trotz E_ALL und es passieren komische Dinge.
Dann kann man schonmal eine ganze Weile damit verbringen ganz woanders zu suchen.
Mit offenem error_log wäre das nicht passiert ;).

Continue reading “Schau auf die Error_Log”

Posted on

Symfony 2 PR3: doctrine:schema:create liefert “No Metadata Classes to process.”

Die Doku stellt in Aussicht, dass man den “normalen” Doctrine-Namespace-Shortcut benutzen kann, also bspw. @Entity anstelle von @DoctrineOrmMappingEntity. Funktioniert aber nicht, weil in irgend einer Service-Configuration dieser Namespace auf einen Alias gemapped wird, der da lautet “orm”. Die Syntax lautet aber nun auch nicht @ormEntity, sondern @orm:Entity. Schreibt man sein Model also bspw. so:

<?php

namespace ApplicationHelloBundleEntity;

/**
 * ApplicationHelloBundleEntityUser
 *
 * @orm:Table(name="users")
 * @orm:Entity
 */
class User
{
  /**
   * @var integer $id
   *
   * @orm:Column(name="id", type="integer")
   * @orm:Id
   * @orm:GeneratedValue(strategy="AUTO")
   */
  protected $id;

sollten alle CLI-Tasks auch wunderbar funktionieren. Es bleibt zu hoffen, dass die DI-Services eine reichhaltige Parameter-Dokumentation spendiert kriegen und das ganze Bundle-System eine transparente, dokumentierte API erhalten (wo zum Teufel liegt in der Sandbox bitte der versprochene Doctrine-Controller?)

Die Einstellung findet sich übrigens in der Service-Configuration unter src/vendor/symfony/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml:

<service id="doctrine.orm.metadata_driver.annotation.reader" class="%doctrine.orm.metadata.annotation_reader_class%">
            <call method="setAnnotationNamespaceAlias">
              <argument>DoctrineORMMapping</argument>
              <argument>orm</argument>
            </call>
        </service>

Ist leicht zu finden, wenn man weiß, wonach man suchen muss. Ich denke, es ist am einfachsten, die Service-Definition des DI-Containers an entsprechender Stelle an seine eigenen Bedürfnisse anzupassen. Wie das zuverlässig und projektübergreifend funktioniert, erkläre ich vielleicht mal, wenn ich’s selbst gerafft hab.

Achso, hier noch der Nebensatz (etwas herunter scrollen), in dem gesagt wird, das Jonathan irgendwann mal das “orm:” Präfix einführt. Symfony 2 ist definitiv noch nicht ready for production (was aber auch niemand behauptet).

Posted on

Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen

Unter Dependency Injection versteht man heute nicht nur ein einfaches Entwurfsmuster, sondern vor allem Framework-gestützte Mechanismen, die den konkreten Implementierungsaufwand verringern (Entwicklungszeitoptimierung), dem Entwickler bessere Übersicht über Abhängigkeiten zu schaffen (Applicationdesignoptimierung) und die Anzahl der Instanzen gleichen Prototyps zu minimieren (Performanceoptimierung).

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.
Continue reading “Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen”

Posted on

Persistente Objekte in PHP und redirects

Achtung Falle!
Benutzt man persistente Objekte in PHP, die ungefähr so aufgebaut sind, wie hier beschrieben.

class User
{
public function __construct(){}

// save object to session variable
public function __destruct()
{
   $_SESSION['user'] = serialize($this);
} 
// factory method
public static function factory()
{
   session_start();
   if(isset($_SESSION['user']) === TRUE)
   {
      return unserialize($_SESSION['user']);
   }
   return new User();
} 
}

Continue reading “Persistente Objekte in PHP und redirects”

Posted on

Datei-Endungen im Vork Framework

Von Haus aus kommen im Vork Framework alle MVC Dateien ohne Endung daher.
Wer das ändern möchte kann folgende Dinge tun:

in der Klasse config in der Datei .config folgendes einfügen:

public $fileExtension = '.php';

dann erwartet vork im MVC Ordner Dateien mit der Endung .php.
Um alle Dateien umzubenennen braucht man eigentlich nur Windows Vista, eine präzise Maus und etwas Geduld.
oder folgende Zeile:

find /myVorkFolder/mvc -type f -exec mv '{}' '{}'.php ;

Continue reading “Datei-Endungen im Vork Framework”

Posted on

Zend_Log pseudo logrotate

Manchmal wachsen einem die Logfiles ja über den Kopf und drohen den Server zu sprengen.
Dann muss man aufräumen, weithin als logrotation bekannt. Unter Linux gibt es ja das praktische logrotate Programm, welches man für seine zwecke vielfältig konfigurieren kann.

Es gibt dann aber auch Fälle wo man dies nicht benutzen will/kann, zB weil man auf shared hosting ist oder man eine Tool ausliefern will, welches selbst aufräumen soll.

Zend_Log bietet zZt leider keine Log Rotation mit an, also muss man es selber machen:

In meinem Fall will ich die Logfiles ca eine Woche vorhalten, das sollte reichen um Problemen auf die Spur zu kommen.
Zudem werde ich die tagesweise stückeln, da diese in einem Backend angezeigt werden sollen.
Dafür nenne ich die Logfiles so:

define('SYNC_LOG','sync.'.date('N').'.log.txt');

Also mit numerischem Wochentag im Namen.

Continue reading “Zend_Log pseudo logrotate”