Eclipse kann Update-Sites nicht erreichen

Wer – wie ich und viele andere – auf Eclipse als Entwicklungs-IDE setzt, wird früher oder später auch auf die Tücken und kleinen Stolperfallen der Freeware-Lösung stoßen.

Eine davon – wenn man Google und verschiedenen Foren glaub darf – ist schon mehrfach aufgetreten, auf die richtige Lösung zu stoßen ist jedoch Glückssache. Es geht darum, über Eclipse weitere Plugins wie bspw. Subversion oder auch die PHP Development-Tools nachzuinstallieren. Gerade bei DualStack-Arbeitsrechnern – also denen, die sowohl via IPv4 als auch IPv6 angebunden sind – funktioniert das nicht ohne weiteres. Eclipse wird den Dienst mit der Fehlermeldung

Unable to read repository at http://subclipse.tigris.org/update_1.8.x/content.xml.
Unable to read repository at http://subclipse.tigris.org/update_1.8.x/content.xml.
Connection reset

verweigern. Ganz offensichtlich hat Eclipse und/oder Java hier ein Problem, eine stabile Verbindung hinzubekommen. Die Lösung ist einfach – wenn man sie kennt, nämlich des festlegen der Verbindung über IPv4. Dies realisiert man über einen Eintrag in der eclipse.ini im Eclipse-Verzeichnis:

-Djava.net.preferIPv4Stack=true

Wichtig: Es gibt Quellen, die diesen Eintrag als „-Djava.net.preferIPv4Stack = true“ angeben. Das ist FALSCH, die Leerzeichen vor und/oder nach dem Gleichheitszeichen machen diesen Parameter ungültig und damit wirkungslos. Es ist EIN EINZIGER Parameter, der als ein kompletter String weitergegeben werden muss.

Danach einen gegebenenfalls vorhandenen Cache in

<Eclipse-Pfad>\p2\org.eclipse.equinox.p2.repository\

löschen und Eclipse neustarten. Über „Help“ -> „Install New Software“ kann man nun wie gewohnt Eclipse-Repositories und Update Sites pflegen und abrufen.

mySQL und die Zeit

Oft wurstelt man bei der Entwicklung mit UNIX-Timestamps für Zeitangaben herum. Das ist kein Hexenwerk, aber direkt das Gelbe vom Ei ist es auch nicht. Speziell zur Implementierung von Zeit- und Datums-Filtern benötigt dieser Lösungsansatz eine Menge Logik, die in PHP gegossen werden muss (Schaltjahre, Schaltsekunden, …). Das Herumrechnen damit ist mühsam und sorgt oft für Knöten im Hirn.

Dies kann man wesentlich einfacher haben. mySQL kommt mit einer großen Vielfalt von Datums- und Zeitfunktionen daher, derer man sich wunderbar bedienen kann. Wenn man sich zum Beispiel die Funktion

TIMESTAMPADD()

ansieht, wird man schnell merken, dass diese Funktionen das Entwicklerleben erheblich vereinfachen können. Musste man früher mühsam herumrechnen, um bspw. ein Jahr zu einem gegebenen Datum hinzuzuaddieren, funktioniert das mit

SELECT TIMESTAMPADD(YEAR,1,'2012-01-03')

völlig problemlos – und das Beste: Schaltjahre, -Sekunden und dergleichen sind schon drin. Ein anderes Beispiel: Oft sollen Daten im Monatsraster dargestellt werden. Mit PHP mühsam, mit mySQL eine etwas ausführlichere WHERE-Klausel:

[...] WHERE `date`>SELECT TIMESTAMPADD(day,1,LAST_DAY(TIMESTAMPADD(month, -1, NOW()))) AND `date`<=LAST_DAY(NOW()) [...]

Dieser Where-Klausel liefert alle Datensätze, die im aktuellen Monat liegen, mit einigen Handgriffen kann man sie so erweitern, dass allein ein übergebener Parameter wie bspw. die Angabe, der wievielte Monat vor dem aktuelle angezeigt werden soll, die Filterung schon komplett macht.

Sollte doch einmal – aus welchen Gründen auch immer – der UNIX-Timestamp nötig sein, kann man sich diesen für ein beliebiges Datum mittels der Funktion

UNIX_TIMESTAMP()

zurückgeben lassen. Will man auch so nette Gimmicks wie bspw.

DATE_FORMAT()

nutzen, ist es sinnvoll, vorher die Systemvariable für die Darstellung von Monats- und Tagnamen über

SET SESSION lc_time_names=de_DE

entsprechend zu definieren. Auf diese Weise kann man sich den Unwägbarkeiten der PHP-Datumsfunktionen einfach und nachhaltig entziehen.

Viele weitere Funktionen und genauere Infos kann man der mySQL-Dokumentation entnehmen.

TYPO3 – Suche erweitern

Wer des öfteren mal die Funktionalität von TYPO3 mit eigenen Extensions erweitert, wird des Öfteren auf das Problem stoßen, dass bei der Erweiterung von Tabellen oder beim anlegen von Extension-spezifischen Datenbanktabellen bei der hauseigenen Suche außen vor bleiben.
Hier ist es sinnvoll, der Suche mitzuteilen, es möge doch bei der Suche auch zusätzliche Felder berücksichtigen. Dies lässt sich einfach und – im Gegensatz zu IF-Abfragen – einfach über TypoScript lösen.

Um der Suche die neuen Datenbank-Tabellen und/oder Felder mitzuteilen, geht man folgendermaßen vor.

Standard-Wert für "Überschriften und Schlagwörter": 
tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description
Standard-Wert für "Seiteninhalt": 
tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description : tt_content.header-bodytext-imagecaption

Zur neuen Definition leert man diese zuerst:

tt_content.search.30.dataArray.20.valueArray.10.value >
tt_content.search.30.dataArray.20.valueArray.20.value >

Danach definiert man den Wert neu indem man dem Standard die jeweiligen Felder anhängt:

tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description-[zusätzliche Werte in der Tabelle "pages"]:[eine zusätzliche Tabelle]-[zusätzliche Felder dieser Tabelle]
tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description:tt_content.header-bodytext-imagecaption-[zusätzliche Werte in der Tabelle "pages"] : [eine zusätzliche Tabelle]-[zusätzliche Felder dieser Tabelle]

Damit wird auch der Mechanismus klar, wie die zu durchsuchenden Felder definiert werden. Tabellen werden mit Doppelpunkt getrennt, die in der jeweiligen Tabelle zu durchsuchenden Spalten werden mit Dashes („-„) angehängt.

Abschließend muss man die Felder noch als zulässige Suchfelder definieren:

tt_content.search.20.allowedCols = [sämtliche Felder, die als Suchfelder definiert wurden, müssen hier im selben Schema eingetragen werden]

Zusätzlich zur Erweiterung der vorhandenen Filter („Überschriften und Schlagwörter“ und „Seiteninhalt“) ist es ebenso möglich, zusätzliche Filter einzufügen. Dazu fügt man dem Array

tt_content.search.30.dataArray.20.valueArray

einfach ein neues Element hinzu:

tt_content.search.30.dataArray.20.valueArray.30{
    label = Eine neue Option im Selectfeld
    value = [die mit dieser Option zu durchsuchenden Datenbank-Tabellen und Felder, Schema identisch]
}

Natürlich kann man analog auch Optionen entfernen.

Umgang mit CSS/JS während der Entwicklung

Seit TYPO3 v4.4 werden Javascript- und CSS-Dateien standardmäßig komprimiert und konkateniert. Ein sehr praktisches Feature – außer für manchen Entwickler. Beispielsweise der CSSedit ermöglicht es, CSS-Dateien zu überschreiben, scheitert jedoch an den Versionnummern in den von TYPO3 erzeugten, neuen Dateinamen.

Eine Lösung hierfür:

$TYPO3_CONF_VARS['FE']['versionNumberInFilename'] = 0;

In der TSref leider noch nicht dokumentiert, aber es existieren wohl Schalter und Möglichkeiten:

1. Im Debug-Mode wird nichts concateniert und nichts kompremiert
2. Es sollte folgende Schalter im PAGE-Objekt geben, wenn ich class.t3lib_pagerenderer.php richtig verstehe:

compressJavascript = 0
compressCss = 0
concatenateFiles = 0
removeLineBreaksFromTemplate = 0

TYPO3 Systemextension Extbase und diverse Codebeschleuniger…

Die TYPO3 Systemerweiterung Extbase liest zur Laufzeit PHPDoc Kommentare aus. Was auch immer die Entwickler geritten hat selbst-parsenden Code zu schreiben, es ist auf jedenfall nicht kompatibel zu den ueblichen Beschleunigern und Code-Optimierern.

eAccelerator kann dazu neu kompiliert werden:

./configure --with-eaccelerator-doc-comment-inclusion [...]