Safari: RSS Feed zeigt nur ein Element

19. September 2011 in Allgemein von Leo

Falls Safari im RSS Feed nur 1 Element Darstellt, liegt dies höchstwahrscheinlich daran, dass die anderen Elemente als Duplikate wahrgenommen werden. Dies geschieht z.B. wenn der Titel bei allen gleich verlinkt ist.
Um dies zu Lösen nutzt man am besten das Element. Im Element gibt man einen Link an, welcher aber keinen Einfluss sonst hat, ausser das er mitteilt das es sich hier um ein einmaliges Element handelt.
So könnte man z.B. dies so Lösen:

<guid>http://www.mywebsite.xy/news/#newsid_123</guid>

phpMyAdmin auf Debian Server installieren

5. September 2011 in Software, Tutorials von Leo

Hier eine kurze und simple Anleitung um phpMyAdmin auf dem eigenen Debian Server zu installieren. Vorausgesetzt ist das mySQL bereits installiert ist.

1. Verbinden mit dem Server (SSH)
2. apt-get install phpmyadmin ausführen. Nun wird alles installiert. Falls etwas gefragt wird einfach OK / Ja auswählen.
3. Nun folgende 2 Befehle nacheinander ausführen:

cp /etc/phpmyadmin/apache.conf /etc/apache2/sites-available/phpmyadmin

danach noch

a2ensite phpmyadmin

4. Server neu starten: /etc/init.d/apache2 restart

Nun ist phpmyadmin über den Browser erreichbar (/phpmyadmin)

TYPO3: Eigene Extension lokalisieren

16. August 2011 in TYPO3 von Leo

Um die eigene Extension Mehrsprachig zu machen und trotzdem so flexibel wie möglich zu halten, nutzt man die locallang. Früher handelte es sich hier um ein simples PHP-File mit einem Array, heute ist es ein XML-File mit einer besseren struktur und Übersicht, wo es auch keine Zeichensatz Probleme gibt.

Um für die eigene Extension eine locallang nutzen zu können, gehen wir folgendermassen vor:

Als erstes legen wir die locallang.xml an. Meist direkt im Extension Verzeichnis zu finden, sprich typo3conf/ext/meineExtension/locallang.xml. Falls wir jedoch mehrere pi’s in unserer Extension haben, können wir in jedem pi eine eigene locallang Anlegen welche dann jeweils genutzt wird.

In unsere so eben erstelle locallang.xml Datei kopieren wir nun folgenden XML-Code:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<meta type="array">
		<type>module</type>
		<description>language Labels</description>
	</meta>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="captchaErrorMessage">Captcha incorrect!</label>
		</languageKey>

		<languageKey index="de" type="array">
			<label index="captchaErrorMessage">Captcha nicht korrekt!</label>
		</languageKey>
	</data>
</T3locallang>

Hier haben wir 2 Sprachen. Die default Sprache (englisch) und “de” für Deutsch. Die Übersetzungen werden als Phrasen gemacht, welche jeweils in labels abgespeichert werden. Die labels erhalten einen namen (index=”") und werden im languageKey Array eingefügt. Oben anhand des Beispiels zu sehen.

In unserer PHP-Class der Extension (falls mehrere muss es in jeder gemacht werden), müssen noch folgende Variabeln angegeben werden, was falls ihr mit dem Extension Kickstarter arbeitet eigentlich erledigt sein sollte. Direkt in der Class gebt ihr folgendes an:

public $scriptRelPath = 'class.ux_tx_tipafriend.php'; // Path to this script relative to the extension dir.
public $extKey = 'x4etipafriendrecap'; // The extension key.

So kann TYPO3 die korrekte localconf holen. Wäre unsere Datei in einem pi Verzeichnis, wäre der $scriptRelPath demnach z.B. pi1/class.ux_tx_tipafriend.php.

Damit die Sprachen nun noch geladen werden, müssen in der Main-Funktion noch folgendes gemacht werden:
Zuerst muss die conf in $this->conf geschrieben werden:

$this->conf = $conf;

Danach (muss danach sein!) muss die locallang selbst noch geladen werden:

$this->pi_loadLL();

Fertig!

Um jetzt auf die Phrasen zuzugreifen, nutzen wir folgende Zeile:

$error = $this->pi_getLL('captchaErrorMessage');

Fluid: Select mit zusätzlicher Option

30. Juni 2011 in TYPO3 von Leo

Lange war ich auf der Suche nach einer einfachen Möglichkeit in einem Fluid Select eine default Option anzufügen, sprich eine Option wie “Produkt auswählen” oder ähnlich. Schlussendlich war die beste lösung einen ViewHelper für das Select zu erstellen.
Dabei bin ich erstmals auf folgenden Artikel gestossen: Fluid: Select in Formularen mit weiteren Optionen. Leider führte dies zu einer Fehlermeldung, und ausserdem waren in meinem Fall noch ein paar Anpassungen nötig.

Hier nun eine kurze Anleitung:
Als erstes erstellen wir einen neuen ViewHelper mit dem Namen SelectViewHelper.php unter typo3conf/ext/meineExt/Classes/ViewHelpers/. In diesen fügen wir nun folgenden Code ein:

class Tx_MeineExt_ViewHelpers_SelectViewHelper extends Tx_Fluid_ViewHelpers_Form_SelectViewHelper {

    public function initializeArguments() {
        parent::initializeArguments();
        $this->registerArgument('additionalOptions', 'array', 'Associative array with values to prepend', FALSE);
    }

    protected function getOptions() {
        $options = parent::getOptions();
        $additionalOptions = array();
        foreach ($this->arguments['additionalOptions'] as $key => $value) {
            $additionalOptions[$key] = $value;
        }
        $return = $additionalOptions + $options;
        return $return;
    }

}

Hierbei noch den Namen der Klasse abändern und “meineExt” durch den eigenen Extension namen ersetzen.

Nun bearbeiten wir unser Fluid Template wo das Custom Select hin soll. Dort fügen wir zuoberst folgende Zeile ein:

{namespace meineExt=Tx_meineExt_ViewHelpers}

Der namespace kann eigentlich beliebig heissen, wie man es halt gerne hätte.

Und fügen dann an einer beliebigen Stelle darunter unser Select ein:

<meineExt:select additionalOptions="{- : '-- Produkt wählen --'}" sortByOptionLabel="name" name="products" property="products" options="{allProducts}" optionValueField="uid" optionLabelField="name" />

Der Parameter additionalOptions ist also für unseres Zusätzliche Feld, dort kann ein beliebiger Wert angegeben werden.

Wichtig: In meinem Fall wurde in der getOptions Methode in unserer ViewHelper Klasse keine array_merge verwendet, wie im Original Code, da die Array-Keys noch gebraucht wurden.

TYPO3: Felder über PageTS entfernen

21. Juni 2011 in TYPO3 von Leo

Um für Kunden welche Backend-Zugriff für ihre TYPO3 Installation den Umgang mit TYPO3 möglichst einfach und Benutzerfreundlich zu gestalten, wird alles unnötige – was sie halt nicht benötigen – entfernt. So auch bei den Feldern. Verschiedene Plugins wie z.B. tt_news sind sehr Umfangreich und bieten Felder an die der Kunde nicht benötigt. Da es teilweise sehr viele Felder hat, könnte dies den Benutzer nur verwirren, als dass sie ihm was nutzen. Eine möglichkeit diese Felder zu entfernen, ist über die Zugriffsliste. Man bearbeitet eine Gruppe und kann dort bei den Rechten die Zugriffsliste einschränken, somit werden die ausgeschlossenen Felder ausgeblendet.
Was wenn jedoch einige Felder auf verschiedenen Seiten (oder z.B. SysFoldern mit Datensätzen für Plugins) benötigt werden und auf anderen wiederum nicht?

Eine simple Methode ist das auslagern des pageTS in eine oder mehrere Dateien. Diese Dateien können wir im pageTS einbinden.
Und so gehts:

Wir erstellen eine Datei im fileadmin Ordner, wo genau ist egal. Am besten nehmen wir die Endung .ts, auch wenn es sich eigentlich um eine Textdatei handelt, so wissen wir was es ist.
In dieser Datei können wir für jedes Feld das wir nicht haben wollen folgende Zeile einfügen:

TCEFORM.tt_news.author.disabled = 1

Somit wird das Autoren-Feld von tt_news nicht mehr angezeigt. Dies kann für alle Spalten in einer Tabelle gemacht werden, am besten öffnet man noch phpMyAdmin (oder ähnlich) und kopiert dort die Namen der Spalten.
Um ein Feld zu erlauben wird demnach einfach eine “0″ gesetzt.

Damit das ganze seine Wirkung zeigen kann, muss es noch im pageTS eingebunden werden:

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/ts/setup/tt_news-fields.ts">

Fertig! Um Felder je nach Ort zu erlauben / verbieten, erstellt man am besten 2 Dateien (für zum erlauben / verbieten) und bindet diese je nach dem ein wo halt die Felder erlaubt oder verboten werden sollen.

pageTS: Seiten TypoScript, zu finden beim bearbeiten einer Hauptseite unter dem Tab “Resources” (Ressourcen).

TYPO3: Problem mit Image-Links nach Update auf 4.5

in TYPO3 von Leo

Nach dem Update auf TYPO3 funktionierten die Image-Links nicht mehr, sofern mehrere Bilder in einem Inhaltselement waren, welche je Einzeln verlinkt werden sollten. Angegeben werden die Links undereinander (je eine Zeile) in einem Textfeld, und sollten dann gesplittet werden. Kurze Zeit später bin ich auf folgendes gestossen: [Klick], welches mich auf die richtige Spur brachte.
Jedoch war es in meinem Fall die Extension SlimBox die das Problem verursacht. Also bearbeitete ich kurz das TypoScript-Setup der genannten Extension, und fügte folgende 2 Zeilen ein:

tt_content.image.20.1.imageLinkWrap.enable.ifEmpty.typolink.parameter.listNum.splitChar = 10
tt_content.image.20.1.imageLinkWrap.typolink.parameter.override.listNum.splitChar = 10

Danach funktionierte alles wieder wunderbar.

Womöglich funktioniert es auch lediglich mit einem Update der SlimBox. Auf der Seite welche dieses Problem existierte war noch eine alte Version installiert (2.1.0), zurzeit ist Version 3.1.0 die aktuellste.

MAMP MySQL startet nicht mehr (trotz beenden des Prozesses)

14. Juni 2011 in Software von Leo

Seit ich ein Macbook habe nutze ich anstatt wie damals unter Windows XAMPP, nun MAMP. Teilweise gab es das Problem das der MySQL dienst nicht startete, das Problem war jedoch schnell gelöst nachdem der Prozess in der “Aktivitätsanzeige” (siehe Spotlight [cmd + Leertaste]) beendet wurde (mysql Prozess).

Als ich später ein neues Projekt erstellte und MAMP aufstartete, wollte der MySQL Dienst auch nach mehrmaligem Abschiessen immer noch nicht. Das Problem war das ich 2 Benutzeraccounts auf meinem Mac habe. Beim Anlegen einer Datenbank werden die Daten in /Applications/MAMP/db geschrieben. Da ich auf dem anderen Benutzeraccount arbeitete, hatte dieser keine Berechtigung für die anderen Datenbanken, wodurch MAMP anschienend nicht zu schlag kam. Kurz das Terminal geöffnet und folgendes eingegeben:

sudo chmod -R 0777 /Applications/MAMP/db

Fertig!

Git: Geänderte Dateien Zippen und Filestruktur beibehalten

10. März 2011 in Allgemein von Leo

Falls man für ein Projekt Git nutzt und nun die geänderten Dateien bündeln und als Zip haben möchte, kann dies ganz simpel mit ein paar Commands machen. Mit Git diff können wir einen Vergleich machen. Was hat sich geändert.

In unserem Zip welches in meinem Beispiel später wieder auf einen anderen Server gespielt wird und dort die Live Dateien überschreibt, muss natürlich die Filestruktur beibehalten werden.

Der Befehl der uns all diese Arbeit nun abnimmt sieht folgendermassen aus:

git archive --output=export.zip HEAD $(git diff --name-only --diff-filter=ACMR $(git rev-parse HEAD))

Kurz erklärt:

git archive --output=export.zip

Erstellt schlussendlich das Zip, also der Output.

git diff --name-only --diff-filter=ACMR

Dies würde einzeln ausgeführt eine Liste mit den geänderten Dateien anzeigen (diff).

git rev-parse HEAD

Dies ermittelt uns die ID des letzten Commits. Die ID ist hierbei ein Hash Wert.

Phing: Remote Tasks Loggen

25. Februar 2011 in Allgemein von Leo

Was in lokalen Phing Tasks abläuft wird bekanntlich in der Konsole angezeigt. So weiss man auch gleich den Grund falls ein Task scheitert.

Hat man nun aber einen Remote Task, läuft dieser auf dem Server ohne das wir etwas mitbekommen. Scheitert ein Task wüssten wir nicht gleich genau wieso. Um dies nun aber zu Loggen, bietet Phing hier einen Parameter der beim Aufrufen mitgegeben werden kann.
Nehmen wir an wir machen z.B. ein PHP exec():

exec("phing testTask -logfile log.txt");

Nun wird alles was auf dem Server passiert in das Logfile “log.txt” geschrieben. Dies geschieht natürlich auch auf dem Server.

Natürlich funktioniert dies auch mit dem Phing exec Task:

<exec dir="/home/" command="phing testTask -logfile LOG.txt"  />

Nachtrag:
Mittlerweile habe ich endlich herausgefunden wie Remote Logs geloggt werden können, welche jedoch nicht mit exec ausgeführt werden. D.h. Phing wird nur temporär auf dem Remote Server sein und per PHP gestartet.

So funktionierts:

// ...
Phing::startup();
Phing::fire(array('-logfile', 'LOG.txt'));
Phing::shutdown();
// ..

Dies ist nur ein kurzer Auszug aus dem Script welches wir aufrufen um Phing auf dem Remote Server zu starten. Wie man aber sehen kann, wird dem “fire” ein Array mitgegeben, in welchem man alle Anweisungen welche wir vom exec kennen mitgeben kann. Diese Optionen findet ihr hier.

Phing: Bedingungen nach Betriebssystem für Befehle

22. Februar 2011 in Coden von Leo

Um in Phing einen Befehl (Command) nur auf einem bestimmten Betriebssystem auszuführen, gibt es die Option OS. Wir können also in Befehlen in Phing die Option OS mitgeben und so nur ein bestimmtes Betriebssystem ansprechen.

Dies sieht dann z.B. so aus:

<exec command="mklink /d verzeichnis1 verzeichnis2" dir="C:\dev" os="WINNT" />

Dieser Befehl wird nur auf einem Windows System ausgeführt, da wie man hier sieht sowieso nur ein unter Windows bekannter Befehl ausgeführt wird.

Hier ausserdem eine Liste mit verschiedenen Möglichkeiten:

    * CYGWIN_NT-5.1
    * Darwin
    * FreeBSD
    * HP-UX
    * IRIX64
    * Linux
    * NetBSD
    * OpenBSD
    * SunOS
    * Unix
    * WIN32
    * WINNT
    * Windows