TYPO3 interne Suche für Datensätze

In der Listen bzw. Seitenansicht gibt es ja ganz unten eine Suche um nach Elementen zu suchen. Bis zur Version 4.6 konnten alle Datensätze von Extensions damit gesucht und gefiltert werden. Jetzt muss in der Extension selbst jedoch eine Liste hinterlegt werden, welche Felder durchsucht werden sollen. Ansonsten verläfut die Suche ins Leere.
Da ich gerade über diesen Punkte gestolpert bin und die Suche in eigenenen Extensions nicht mehr nutzen konnte habe ich Google bemüht mir da mal einen Tipp zu geben. Gesucht, gefunden und nun lieber hier notieren bevor ich es wieder vergesse.
Fündig wurde ich bei Stackoverflow , ext_tables.php öffnen und das ‚ctrl‘ Array wie folgt anpassen, cache löschen und sich in hunderten von Datensätzen wieder zurecht finden.

$TCA['tx_yourext_table'] = array(
    'ctrl' => array(
        'title' => 'Title of your table',
        'label' => 'title',
        'tstamp' => 'tstamp',
        'crdate' => 'crdate',
         // etc...
        'searchFields' => 'title, other_field, yet_other_field',
    ),
);

git befehle

Eine kleine Zusammenfassung für mich an git Befehlen:


git clone - "erstmailges kopieren des Repos"
git push - "hochladen"
git push -u origin master - '-u git merkt sich die übergebenen Parameter'
git pull - "Änderungen runterladen"
git diff - 'Änderungen ansehen'
git diff --staged - 'Nur Änderungen aus dem Stage bereich'
git reset - 'staged filed entfernen, wird aber nicht gelöscht'
git checkout --[space] - 'Alle Änderungen seit dem letzten Commit verwerfen'
git rm - 'Files werden gelöscht und gleichzeitig dem Staging Bereich "mitgeteilt", das Dateien gelöscht wurden' -> danach noch commiten

Branch:
git branch - 'anlegen eines Branches'
git checkout - 'switch zu anderem Branch'
git merge - 'Um änderung aus einem anderen Branch zu übernehmen, bsp: bugfix integrieren'
git branch -d - 'branch löschen, bsp: nach erfolgreichem Bugfix'

Source
http://try.github.com/

Cygwin Aliase

Ich bin mittlerweile großer Fan von Cygwin unter Windows geworden denn damit kann ich auf viele kleine Tools aus der Linux Welt zurückgreifen.
Um direkt auf per Shell dann direkt auf meine Partitionen zugreifen zu können nutze ich immer das folgende Skript von Thomas Gern.

  #!/bin/bash
  ############################################################
  # alias 

  for drive in a b c d e f g h i j k l m n o p q r s t u v w x y z
  do
          alias ${drive}:="cd /cygdrive/${drive}"
  done

Quelle:
http://www.pro-linux.de/artikel/2/128/eine-cygwin-umgebung-unter-windows-einrichten.html

Fehler in Standard-Installation von Xampp + XDEBUG unter Windows

Die Fehler die einem begegnen sind meist die größte Quelle des Ansporns und wenn man Sie gelöst hat bleiben die Lösung am längsten in Erinnerung.
Ein solcher Fehler hat mich nun fast zum verzweifeln gebracht. Ich wollte eigentlich nur einmal Webgrind ausprobieren und testen. „Webgrind is an Xdebug profiling web frontend in PHP5.“ [1] Um es also zu testen habe ich meine Xampp Installation gestartet und habe XDEBUG aktviert. Jedoch schien XDEBUG nichts zu laufen, da ich keine Profiling Datei erhielt. Nachdem ich nun mehrere Stunden mit dem Suchen nach Lösungen zu dem Problem verbracht habe und verschiedene Versionen von XDEBUG und XAMPP ausprobiert hatte, stellte sich raus das der Dateiname nicht korrekt ist.
In der Standard php.ini in XAMPP wird folgender Eintrag für den Dateinamen gesetzt.

xdebug.profiler_output_name = „xdebug_profile.%R::%u“

Allerdings enthält dieser Dateiname zwei Doppelpunkte, die in Windows Dateinamen nicht erlaubt sind, eine Änderung zu
xdebug.profiler_output_name = „xdebug_profile.%R-%u“, reicht nun aus um endlich meine Profiling Dateien zu erhalten.

Ich denke mal in Zukunft werde ich jeden Ausgabenamen einer Log Datei oder irgendeiner anderen sonstigen Datei 3x prüfen um auch wirklich sicherzustellen, das nicht eine solche „Lappalie“ Grund für eine derartiges Rätselraten ist.

[1]
https://code.google.com/p/webgrind/

PHP Skripte auf der Commandline

Wieder mal ein kleines Projekt brachte mich dazu ein PHP Skript auf Commandline bzw im Terminal ausführen zu wollen.
Zum einen sollte es schnell gehen und keine WebOberfläche benötigten zum anderen wollte ich auch einfach mal wissen wie es funktioniert. Im Endeffekt gar nicht schwer, das Zauberwort heißt getopt(). Mit dieser PHP Methoden lassen sich übergebene Argumente auf Commandline ebene abfragen.

PHP Code:

<?php
    $arguments = getopt("f:t:");
    var_dump($options);
?>

CommandLine

php bsp.php -f -t

In diesem Fall werden die Parameter einfach übergeben, getopt gibt hier ein Array zurück mit der Hinterlegten Option und dem zugehörigen Wert. Wenn kein Wert übergeben wird, wird FALSE zurückgegeben.

Wenn wir den Aufruf nun ändern zu:

CommandLine

php bsp.php -f hello -t world

bekommen wir durch optget() ein Array mit den Optionen f -> hello und t -> world zurückgeliefert.

jQuery resize

Kleines (quick and dirty) Beispiel für die jQuery Resize Funktion
In einem Projekt musste ich ein genau hinter einem Logo ein Hintergrund-Bild starten lassen, welche dann dann horizontal den Rest des Bildschirms ausfüllen sollte… Wie ein Strahl der aus dem Logo kommt.
Auf Grund der bestehenden CSS/HTML Struktur und natürlich zu wenig Zeit ist diese kleine Javascritp Lösung entstanden.

bgposition = function(){
    var left = $('a.logo').position().left;
    left = Math.ceil(left);
    $('.containerMitCSSBackgroundImage').css('background-position', left+'px 0');
  }
    bgposition()
  $(window).resize(function(){
    bgposition();
  });

Die Funktion bgposition() wird beim Start der Seite aufgerufen und die Position des Logos abgefragt, dieser Wert wird gerundet und dann dem Container mit dem background-image als Hortizontale „Start“ Position mitgegeben.

Wenn das Fenster nun verkleinert oder vergrößert wird, greift die die resize() Funktion von jQuery und die Funktion wird erneut ausgeführt. Schnell, klein, praktisch das mag ich an jQuery.

Sqlite3 und PDO

Ich habe heute für ein kleines Projekt eine Datenbank benötigt und habe mich dann recht schnell für Sqlite entschieden.
Da ich damit allerdings noch nie gearbeitet habe hier ein paar Punkte zur Erinnerung:

Sqlite DB erstellen bzw öffnen
// bei PDO anfragen zumindestens den Connect immer in einen try catch Block setzen
// wenn DBs mit Benutzer und Passwort abgefragt werden, da bei einem Fehlgeschlagenen
// Versuch sonst alles inklusive User und PWs als Fehler ausgegeben werden

try{
	$dbh = new PDO("sqlite:mydatabase.sdb");	
}
catch (PDOException $e)
{
	echo $e->getMessage();
}

Sqlite Datentypen:
Die sind hier relative einfach gehalten, da Sqlite dynamic typing nutzt.

SQLite uses dynamic typing. Content can be stored as INTEGER, REAL, TEXT, BLOB, or as NULL.

Quelle: sqilte.org

wie erstelle ich ein Auto Increment Feld

Short answer: A column declared INTEGER PRIMARY KEY will autoincrement.

Quelle:
sqilte.org

ErrorMode setzen:

//direkt nach dem öffnen der DB
	/*** set the error reporting attribute ***/
   $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

simple Abfrage und Ausgabe

/*** The SQL SELECT statement ***/
    $sql = "SELECT * FROM entries";

    /*** fetch into an PDOStatement object ***/
    $stmt = $dbh->query($sql);

    /*** echo number of columns ***/
	foreach ($stmt as $row){
		echo $row['uid'] . '<br>';
		echo $row['header']  . '<br>';
		echo $row['bodytext']  . '<br>';
	}

Sonstige Quellen:
http://henryranch.net/software/ease-into-sqlite-3-with-php-and-pdo/
http://www.phpro.org/tutorials/Introduction-to-PHP-PDO.html und weil alle guten Dinge 3 sind sqlite.org

Symlinks für Windows am Beispiel TYPO3

Wenn ich eine neue TYPO3 Installation aufsetze nutze ich immer die Möglichkeit der Symlink Nutzung.
hat einfach den großen Vorteil, wenn eine neue TYPO3 Version rauskommt, reicht es auch einen Symlink zu ändern und die Installation ist mit einer Frischen Version versorgt… danach natürlich noch die üblichen Update Schritte durchlaufen.
Den noch größeren Vorteil sehe allerdings darin, schnell wieder zurück zu wechseln. Bei einer größeren Seite musste ich die Möglichkeit auch schon mal in Anspruch nehmen, nach dem Switch gab es einfach eine weiße Seite und vom Frontend keine Spur mehr, schnell sysmlink wieder auf die alten TYPO3 core Dateien geändert und alles wieder da.

Bisher nutze ich immer die empfohlene Kombination

source/ <---- typo3_src-4.x/
www/   <--- Installation

www/typo3_src <--> ../source/typo3_src-4.x/
www/typo3 <--> typo3_src/typo3/
www/t3lib <--> typo3_src/t3lib
www/index.php <--> typo3_src/index.php

Bei Unix wird es umgesetzt mit folgendem Befehl

// immer das Ziel und dann den Symlink Namen
ln -s ../source/typo3_src-4.x/ typo3_src
ln -s typo3_src/typo3 typo3
ln -s typo3_src/t3lib t3lib

Also als erstes wird ein Symlink typo3_src gesetzt, dieser weißt als einziger Link auf den aktuellen Source-Ordner, die andern Symlinks bauen dann auf diesen Link auf. Bei einem Update muss dann nur dieser eine Symlink angepasst werden.

In Windows (an Vista) sieht es dann so aus:
Start -> in der suche CMD eintippen und dann auf dem Ergebniss mit Rechtsklick „Als Administrator ausführen“
dann folgendes eingeben

// hier ist es genau umgekehrt zu Unix, erst den Symlink Namen dann das Ziel
// wenn Ordner auf diese Weise geschriee
mklink /J typo3_src ..\source\typo3_src-4.x\
mklink /J typo3 typo3_src\typo3\
mklink /J t3lib typo3_src\t3lib\

// Dateien
mklink index.php typo3_src\index.php

Damit ist auch ein Testen mit XAMPP oder ähnlich auch gut zu bewerkstelligen

Genutzte Quelle:
http://www.windows7home.net/use-mklink-command-in-windows-7/