Kategorie: PHP

XAMPP PHPUnit 3.5.13 Installation Howto

Sollte Ihnen dieser Fehler bekannt sein:
Could not open input file: .\pear\PHPUnit2\TextUI\TestRunner.php
dann gibts hier die Lösung.

Nachdem wir mehrere Server auf PHP 5.3 und MySQL auf 5.1 hochgezogen hatten,
war es an der Zeit auch meine lokale Umgebung (ältere XAMPP-Instanz) einem Upgrade zu unterziehen. Also XAMPP in der aktuellen Version (1.7.4) mit Apache 2.2.17, MySQL 5.5.8 und PHP 5.3.5 installiert, und …

BOOOM, jeder Aufruf von phpunit krepierte mit obiger Fehlermeldung.

Dies lässt sich zwar einfach fixen indem man im File C:\xampp\php\phpunit.bat die Pfade absolut setzt, aber dann hat man noch immer nur eine veraltete phpunit Version, die einen nicht glücklich machen wird. Auf unseren Debian-Servern läuft derzeit PHPUnit 3.5.11 also gilt es diese Version auch lokal zu haben.

Spass mit Git Episode 1: Wie werden aus 126MB 4.8GB

Oder wie krieg ich alle im SVN getagten Typo3-Releases als typo3_src-Targets

Was brauch ich:

  1. git mit SVN Support
  2. Internet
  3. Genug Platz auf der Platte

Schritt 1: Wir holen und das Typo3-SVN-Repository in der git-Version auf die Platte

cd ~/tmp
mkdir repo
cd repo

git svn init --stdlayout https://svn.typo3.org/TYPO3v4/Core
git svn fetch

Das Ganze dauert je nach Bandbreite etwas. Updates gehen später natürlich schneller.

Die Option –stdlayout gibt an daß das SVN-Repo die Standard-Aufteilung in trunk/branches/tags verwendet.

Die finale Grösse des git-Repositories (im .git Verzeichnis) beträgt nach heutigem Stand ca. 126M. Während des Checkouts kanns schon mal auf > 400MB anwachsen.
git gc machts immer wieder schön klein.

Magento: eigenen SOAP API Call implementieren

Ich hatte einige Mühe das zum Laufen zu bringen, daher hier eine Anleitung, um andere davor zu bewahren. Dankbare mögen sich melden, es stehen viele Dinge auf meiner Amazon Wunschliste ;-)

Zuerst zur Struktur unseres Modules. Ich gehe davon aus, dass wir ein eigenes Modul haben, das den Catalog von Magento erweitert (das auch schon selbständig funktioniert) und wir folgende Verzeichnisstruktur haben:

app/code/local/Mycompany/MyclientCatalog/
 + Block/
 + Helper/
 + Model/
   + Category/
 + ...
 + etc/

Für die API erstellen wir jetzt folgende neue Dateien:

Model/Category/Api.php
etc/api.xml

mit folgendem Inhalt:

TYPO3 / Apache Solr Extension / dynamisches Feld (dynamicField) befüllen

Ziel: ein Feld (dynamicField, siehe Solr Dokumentation bzw. schema.xml) für ein Seiten-Dokument im Index dynamisch über eine Userfunction befüllen.

TypoScript Setup:

includeLibs.my_solr = EXT:user_my_solr/class.user_my_solr.php
plugin.tx_solr {
   enabled = 1
# …
   index {
      additionalFields {
# intS = Integer single value
# S = single value
# M = multi value
# ...
         myfield_intS = USER
         myfield_intS.userFunc = user_my_solr->get_myfield
      }
   }
}

und das kleine Script in typo3conf/ext/user_my_solr/class.user_my_solr.php:

<?php
class user_my_solr {
   function get_myfield($content, $conf) {
      global $TSFE;
// do something
// $value = 2323;
      return $value;
   }
}
?>

Aufpassen muss man ev., dass man die richtige Version der solr TYPO3 Extension hat. Bei älteren Versionen hat das definitiv leider noch nicht funktioniert.

MySQL Datenbank Tabellen auf UTF8 umstellen

Geglaubt, z.B. TYPO3 und MySQL komplett auf UTF8 umgestellt zu haben? Kyrillische Zeichen lassen sich trotzdem nicht speichern? Vielleicht sind die Datenbank Tabellen nicht auf UTF8 umgestellt worden?

Hier ein kleines Script, mit dem man das schnell nachholen kann:

<?php
$db = mysql_connect('localhost','username','password');
if(!$db) echo "Cannot connect to the database".chr(10);
mysql_select_db('database');
$result=mysql_query('show tables');
while($tables = mysql_fetch_array($result)) {
 foreach ($tables as $key => $value) {
   $query = "ALTER TABLE $value CONVERT TO CHARACTER SET utf8 ↩
             COLLATE utf8_unicode_ci"; 
   echo $query.chr(10);
   mysql_query($query);
   if (mysql_error()) echo mysql_error().chr(10);
 }
}
echo "Finished!".chr(10);
?>

PHP5 und XML mit XPath und Namespace

Folgende Daten aus dem Beispiel XML (stark vereinfacht) sollen mit PHP5 und DOMXPath verarbeitet werden.

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE document SYSTEM 'xmlschemas/domino_8_0_2.dtd'>
<document xmlns='http://www.lotus.com/dxl' version='8.0'>
  <item name="custom_attr"><text>value</text></item>
</document>

PHP Code:

<?php
$xml = " ... XML von oben ...";
$doc = DOMDocument::loadXML($xml);
$xp = new DOMXPath($doc);

$query = "//item[@name = 'custom_attr']";
$results = $xp->query($query);
foreach ($results as $node) {
  echo $node->textContent;
}
?>

Ergebnis: keines… hmmmm
Dokumentation gelesen und nach einiger Zeit doch noch auf folgendes gekommen:
da in dem XML ein Namespace verwendet wird, muss man diesen auch registrieren und beim XPath Query verwenden.
Wir bauen unser PHP Script also wie folgt um:

WordPress Migration auf andere Domain

Heute haben wir einen WordPress-Blog vom Test-Server auf die Produktion übernommen und sind dabei über ein ärgerliches „Feature“ gestolpert. WordPress speichert den Hostnamen nicht nur einmal zentral in der Konfiguration ab, sondern speichert in allen Blog-Einträgen, in allen Kommentaren und auch sonst noch an einigen Stellen die Site-URL komplett ab.

Damit stand an unzähligen Stellen im Blog eben http://TESTSERVER.at/blog anstatt z.B. http://blog.PRODUKTION.at/ (andere Domain und Blog nicht mehr in einem Subdirectory.

Dieses Feature, Bilder und Links absolut inklusive Hostnamen zu referenzieren, soll dabei helfen, dass die Links im RSS-Output auch funktioniert; wieso diese Referenzen aber nicht zur Laufzeit eingefügt werden (wie es TYPO3 macht) sondern wirklich „hart“ in der DB gespeichert werden müssen erschließt sich mir nicht ganz.

Anfrage