Migrate from Mantis 1.2.11 to Redmine 2.1.2

16. Oktober 2012

I managed to migrate from Mantis 1.2.11 to a clean Redmine installation today using these adjustments:

0.) Backup Databases (this should be obvious)

1.) Execute the following SQL Statement in your Mantis DB:

-- ALTER TABLE mantis_bug_table DROP COLUMN date_submitted_redmine;
-- ALTER TABLE mantis_bug_table DROP COLUMN last_updated_redmine;
-- ALTER TABLE mantis_bugnote_table DROP COLUMN date_submitted_redmine;
-- ALTER TABLE mantis_bug_file_table DROP COLUMN date_added_redmine;
-- ALTER TABLE mantis_news_table DROP COLUMN date_posted_redmine;
-- ALTER TABLE mantis_project_version_table DROP COLUMN date_order_redmine;

ALTER TABLE mantis_bug_table ADD date_submitted_redmine DATETIME;
ALTER TABLE mantis_bug_table ADD last_updated_redmine DATETIME;
ALTER TABLE mantis_bugnote_table ADD date_submitted_redmine DATETIME;
ALTER TABLE mantis_bug_file_table ADD date_added_redmine DATETIME;
ALTER TABLE mantis_news_table ADD date_posted_redmine DATETIME;
ALTER TABLE mantis_project_version_table ADD date_order_redmine DATETIME;

UPDATE mantis_bug_table SET date_submitted_redmine = FROM_UNIXTIME(date_submitted);
UPDATE mantis_bug_table SET last_updated_redmine = FROM_UNIXTIME(last_updated);
UPDATE mantis_bugnote_table SET date_submitted_redmine = FROM_UNIXTIME(date_submitted);
UPDATE mantis_bug_file_table SET date_added_redmine = FROM_UNIXTIME(date_added);
UPDATE mantis_news_table SET date_posted_redmine = FROM_UNIXTIME(date_posted);
UPDATE mantis_project_version_table SET date_order_redmine = FROM_UNIXTIME(date_order);

which adds some pre-formatted date-columns to some tables for the adjusted migration script.

2.) Replace (Backup original first) the migration script in redmine/ lib/tasks/migrate_from_mantis.rake by following Script: migrate_from_mantis.rake

3.) Execute the migration Script, fill in your Database connection values and you should be good to go.

Eigene Validatoren für Symfony Forms

04. November 2009

Symfony liefert von Haus aus eine Menge Validatoren mit, um Formulareingaben, die ein Nutzer tätigt, zu überprüfen, neudeutsch: zu validieren. Leider reichen diese sonst sehr mächtigen Validatoren nicht immer aus; so auch in einem aktuellen Projekt.
Für E-Mail-Templates gibt es eine ganze Reihe von vordefinierten Platzhaltern, die jeweils als regulärer Ausdruck vorliegen. So wird für die Anrede in einer E-Mail der Platzhalter {salutation} verwendet, der dann gemäß der ausgewählten Sprache ersetzt wird.

Diese Platzhalter sind zwingend notwendig und müssen deshalb nach dem Abschicken des Formular überprüft werden. Dazu haben wir die Validator-Klasse PlaceholderValidator erstellt.

1
2
3
4
5
6
7
8
9
10
11
12
<?php
class PlaceholderValidator extends sfValidatorBase
{
    public function configure($options = array(), $messages = array())
    {
    }
 
    public function doClean($value)
    {
        return $value;
    }
} ?>

Der Klassenrumpf ist einfach erklärt: Enthalten sind zwei Funktionen, configure und doClean. In der ersten Funktion haben wir die Möglichkeit, unserem Validator bestimmte Optionen und Nachrichten zu geben. Optionen werden benötigt, um den Validator bzw. dessen Überprüfungsroutine zu spezifizieren, und Nachrichten werden benötigt, um Fehlermeldungen vorzubereiten. Optionen gibt es bei einem Großteil der symfony-eigenen Validatoren. Mit ihnen können wir angeben, wieviele Zeichen ein String mindest haben muss, und ob ein Formularfeld ein Pflichtfeld ist oder nicht. Ein beispielhafter Funktionskörper könnte passend zum Beispiel des E-Mail-Template-Validators also wie folgt aussehen:

1
2
3
4
5
6
public function configure($options = array(), $messages = array())
{
    $this->addOption('patterns_required');
 
    $this->addMessage('patterns_required', 'Your template must contain the placeholder "%pattern%"');
}

Als nächstes implementieren wir das Herzstück unseres Validators: die doClean-Methode. Der eingegebene Wert im Formularfeld wird von Symfony an die doClean übergeben. Hier erfolgt nun die Validierung dieses Wertes. Um unser E-Mail-Template zu überprüfen, müssen wir mit Hilfe von regulären Ausdrücken prüfen, ob die benötigen Platzhalter im übergeben Wert vorkommen. Dies realisieren wir in einer Schleife und werfen, sofern der reguläre Ausdruck keine Übereinstimmungen findet, einen Fehler. Dieser enthält den Namen der Fehlermeldung, die wir in der configure-Funktion definiert haben, sowie Namen des Platzhalters, der für diesen Fehler verantwortlich ist. Somit erhält der Nutzer eine Fehlermeldung, in dem ihm mitgeteilt wird, welcher Parameter fehlt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public function doClean($value)
{
    $patterns = $this->getOption('patterns');
 
    if($this->hasOption('patterns_required') && $this->getOption('patterns_required') == true)
    {
        foreach($patterns as $pattern)
        {
            if(!preg_match("/".$pattern."/", $value))
            {
                throw new sfValidatorError($this, 'patterns_required', array('pattern' => $pattern));
            }
        }
    }
 
    return $value;
}

Um diesen Validator nun in Formularen zu verwenden, genügt es, dem Validator-Schema mitzuteilen, dass wir unseren Placeholder-Validator nutzen möchten.

1
$this->setValidator('template', new PlaceholderValidator(array('patterns_required' => true, 'patterns' => $patterns)));

Mit den Validatoren gibt Symfony dem Entwickler ein mächtiges Werkzeug in die Hand, welches einfach zu verwenden ist und in allen Formularen zum Einsatz kommen kann.

Runde Ecken und Schatten mit CSS 3.0

18. September 2009

Das leidige Thema der runden Ecken und Schatten hat so manchen Webdesigner oder auch Programmierer schlaflose Nächte bereitet. Gerade wenn man den Anspruch hat, den Code möglichst schlank zu halten, musste man hier ungewollte Kompromisse eingehen. Früher musste man mit Bildern und diversen Blockelementen komplexe Verschachtelungen aufbauen, dies gehört nun der Vergangenheit an. CSS 3.0 kann mit einfach anzuwendenden CSS Befehlen Schatten und runde Ecken realisieren. Auch wenn CSS 3.0 noch nicht der Standard ist, können die meisten fortschrittlichen Browser ( Firefox, Safari also Webkit und Geckos, etc.) dies bereits jetzt umsetzen. Leider ist der Internet Explorer 8.0 wie gewohnt seinen Konkurrenten hinterher und kann diese CSS-Deklarationen nicht unterstützen. Er ignoriert sie einfach. Wenn man dies in sein Design einbezieht kann man für die meisten anderen Browser runde Ecken und Schatten aber bereits jetzt einsetzen.

Und so sehen die CSS-Deklarationen aus:
.meine_box {

/* Für die Webkitbrowser */
-webkit-border-radius: 5px;

/* Für die Geckobrowser */
-moz-border-radius: 5px;;

/* Für die KHTML-Browser */
-khtml-border-radius: 5px;

/* Die zukünftige CSS 3.0 Deklaration */
border-radius: 5px;

/* Und hier sind die Deklarationen für die Schatten.
Der erste PX-Wert steht für die Y-Achse, der zweite Wert für die X-Achse und der dritte Wert für die Weichzeichnung des Schattens. Und der letzte Wert ist die Schattenfarbe. */

-webkit-box-shadow: 5px 5px 10px #MeinFarbwert;
-moz-box-shadow: 5px 5px 10px #MeinFarbwert;
box-shadow: 5px 5px 10px #MeinFarbwert;
}

Natürlich ist es auch möglich nur einzelne Ecken anzusprechen, da man ja nicht unbedingt immer überall runde Ecken haben möchte.

Der reguläre Ausdruck, wie er unter CSS 3.0 verwendet wird baut sich wie folgt auf:
border-top-left-radius für die linke obere Ecke
border-top-right-radius für die rechte obere Ecke
border-bottom-left-radius für die linke untere Ecke
border-bottom-right-radius für die rechte untere Ecke

Webkit und KHTML spezifisch setzt man die jeweiligen Bezeichnungen -webkit- oder -khtml- vorweg.

Hier unterscheiden sich die Geckobrowser.
Die -moz- Browser verlangen die Schreibweise wie folgt:

-moz-border-radius-topleft

Und dies kann wie folgt aussehen voodoo-media.de.
Dort haben wir mit runden Ecken und dezenten Schatten gearbeitet.

URLs mit .html-Suffix

17. September 2009

Standardmäßig bereitet Symfony die URLs in dem Format /module/action/parameter auf. Dies kann zum Beispiel in einem Blog die URL /article/read/1 sein. Um nun einer Suchmaschine eine statische HTML-Seite zu suggerieren, genügt es, in der Datei settings.yml im Konfigurationsordner einer Applikation folgende Zeilen hinzuzufügen:

1
2
3
prod:
.settings:
suffix:         .html

Symfony erweitert dann selbstständig die URLs, sodass sie aussehen, als läge dort eine statische HTML-Datei. Die Endung wird nur für die produktive Umgebung aktiviert. Damit alle Umgebungen mit Suffixen arbeiten, genügt es, das ‘prod’ durch ‘all’ zu ersetzen.

Symfony, Propel, PHP und die weite Welt

26. August 2009

Dies ist der voodoo-media-Firmen-Blog! Yehaww!

In Zukunft werden hier von Mitarbeitern der Firma voodoo-media relevante Inhalte zum Thema Programmierung mit den verschiedensten Werkzeugen und Sprachen gepostet.

Derzeit befindet sich ein großes Projekt bei dem wir auf das Symfony-Framework zurückgreifen in Arbeit. Daher wird sich ein großer Teil dieses Blogs sich zunächst mit Symfony und Propel auseinander setzen. Aber auch andere PHP-Themen werden nicht zu Kurz kommen. Das Thema Flex und Flash wird genauso Erwähnung finden, wie CSS, JavaScript und andere eher das Erscheinungsbild einer Site betreffende Themen.