Another Blog about the Wide Web World

Führt man das compare beim Database Analyser im TYPO3 Install Tool aus, könnten diese Zeilen erscheinen.
# ALTER TABLE cache_hash ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_hash ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_hash_tags ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_imagesizes ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE sys_log ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_pages ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_pagesection ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_pages ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_pages_tags ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_pagesection ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_pagesection_tags ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_typo3temp_log ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_md5params ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_treelist ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE fe_session_data ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE fe_sessions ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_phash ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_fulltext ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_rel ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_words ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_section ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_grlist ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_stat_search ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE index_stat_word ENGINE=InnoDB;
Current value: ENGINE=MyISAM
Bleiben diese Zeilen auch nach einem “write to database”, dann liegt das Problem meist darin, dass die Datenbank tatsächlich die InnoDB nicht unterstützt. Dies kann man nochmal überprüfen, indem man sich in PhpMyAdmin einloggt und die genannten Tabellen man überprüft und schaut, ob im DropDown Feld unter Typ kein InnoDB vorhanden ist. Dies war z.B. bei einem kleineren WebPack unter hosteurope der Fall.

Das fehlende Update der Tabellen scheint aber keine Fehler hervorzurufen und kann somit ignoriert werden. Ich vermute, dass dies auch reine Performance Optimierung war.

Diese Meldung erhält man, wenn Skripte zu lange zum ausführen gebraucht haben und in der php.ini der Wert auf 30 gesetzt ist. Bei mir tauchte es z.B. bei der DB-Überprüfung in TYPO3 “Manage Reference Index” bei jeweils verschiedenen Dateien (class.t3lib_refindex.php) auf. Man kann den Wert u.a. auch im Skript selbst mit der PHP Funktion set_time_limit ändern. Die Option würde ich allerdings nicht präferieren. Beste Lösung ist, den Wert in der php.ini zu ändern, das passiert unter “max_execution_time”. Wenn man darauf keinen Zugriff hat, dann bleibt nur noch eine Möglichkeit: htaccess Datei mit dem Wert php_value max_execution_time 500 Mehr als 600 würde ich nicht empfehlen, da dann tatsächlich das Skript zu langsam läuft und sich der Fehler dann im Skript selbst befindet.

ImageMagick ist bei den kleineren WebPacks leider nicht dabei, aber Voraussetzung für TYPO3. Eine super Anleitung zur manuellen Installation von ImageMagick findet ihr im TYPO3 Wiki. Kleiner Tipp für MacUser: Bei mir hat es Probleme gegeben, als ich die Dateien über Mac hochgeladen habe. Versucht das mal mit einem FTP Programm unter Windows, falls es auch bei euch nicht klappt. Mir hat es geholfen. Dann noch ein kleiner Tipp, falls mal wieder die Bilder nicht angezeigt werden, Install Tool aber ImageMagick findet: Meistens funktioniert dann combine, und writing, aber reading und scaling nicht. Dann ist die Option unter “All Configuration” > im_useStripProfileByDefault deaktiviert sein.

Ihr nutzt nur lokale Extensions. Klickt ihr auf Update und es kommt die Meldung

ERROR: Could not remove extension directory "/pfad/zur/extension/httpdocs/typo3/ext/extensionname/". Reasons:
Error: "pfad/zur/extension/httpdocs/typo3/ext/extensionname/datei.php" could not be deleted!
.
.
.

Das liegt dann daran, dass TYPO3 nicht die Berechtigung hat diese Dateien zu löschen. Hier hat wahrscheinlich der FTP User vielleicht die Dateien nach einem Umzug hochgeladen (somit liegen die Rechte am FTP user und nicht bei TYPO3). Hat man keinen SSH Zugang wird es etwas schwieriger diese Dateirechte zu ändern.

Bei hosteurope gibt es glücklicherweise die Möglichkeit unter Allgemeines > Dateiverwaltung diese Rechte zu ändern.

Lang, lang ist’s her. Ich gebe zu, ich bin keine “richtige Bloggerin”. Trotzdem möchte ich gerne einige Erfahrungen mit euch teilen. An Erfahrungen hat es in letzter Zeit nicht gefehlt, was fehlte war die Zeit zum Schreiben. Als kleine Entschädigung gibt es ein neues, frisches Wordpress Theme und eine kleine Ankündigung auf die nächsten Beiträge.

Ich werde nächstes Wochenende (21. – 23. Mai 2010) beim TYPO3camp Hamburg dabei sein und einen Bericht dazu verfassen.

Zudem bin ich am 1. und 2. Juni 2010 bei der webinale in Berlin und freue mich schon unheimlich darauf. Auf beiden Events werd ich eine geliehene DigiCam mitnehmen (meine ist kaputt gegangen) und hoffentlich ein paar schöne Fotos schießen. Die wird es dann auf meinen Flickr Account zu sehen geben. Werde mir nun endlich auch einen Pro Account registrieren. Mein nächster Einkauf wird eine neue DigiCam sein, so wird es dann auch endlich mehr Fotos auf meinem Flickr Account geben.

Ganz abgesehen davon entschädige ich meine Besucher demnächst mit meinen Projekten, an denen ich arbeite. Im Moment geht mein Studium in den Endspurt, freue mich bereits jetzt auf meine Bachelor-Arbeit über ein noch nicht veröffentlichtes SEO-Monitoring-Tool. Zur Zeit arbeite ich noch mit zwei Freunden an einem Film, 3D, Flash, TYPO3 Projekt. Ihr dürft gespannt sein! Wenn ihr auf dem aktuellen Stand bleiben wollt, dann: follow me on Twitter!

Zudem arbeite ich unter Hochdruck an einem Relaunch von unserem Rezept-Portal kochen OHNE. Wir setzen die bereits bestehende, selbst programmierte Website und Datenbank in Drupal um und werden aus dem Portal eine Community machen. Wenn ihr an einer Lebensmittelallergie oder einer Lebensmittelunverträglichkeit leidet, dann solltet ihr das Portal dringend besuchen. Ihr findet dort  Rezepte laktosefrei, fructosearm, ohne Ei, ohne Milch glutenfrei, ohne Weizen, ohne Soja oder histaminarm. Zudem könnt ihr unser privates Projekt unterstützen indem ihr Fan, äh ein “Gefällt mir” von kochen OHNE bei Facebook werdet.

Ein schönen Restsonntag wünsch ich euch!

Paulina

Vom 10. bis 12. September fand zum 5. Mal die Internationale TYPO3 Konferenz statt. Ich durfte mich glücklich schätzen in Frankfurt dabei sein zu können. Ich habe mir viele sehr gute Seminare angehört und zudem noch viele nette Menschen kennengelernt. Vielen Dank für die schöne Zeit! Meinen Bericht zur T3CON09 habe ich typo3blogger.de zur Verfügung gestellt. Leider hatte ich keine Zeit mehr vom zweiten Tag zu berichten, aber ich hoffe, euch gefällt wenigstens der vom ersten Fotos zur T3CON09 bei Flickr!

Google Adwords bietet einem die Möglichkeit mit einem gelieferten Code das Conversion-Tracking durchzuführen. Fügt man den Code über ein HTML-Inhaltselement von TYPO3 ein, dann erkennt Google den Code leider nicht. Man muss dementsprechend so vorgehen:

• Auf die Seite gehen, die den Code enthalten soll. (Liste- oder Seiten-Modul)
• Neuen Datensatz anlegen
• “Template” auswählen
• In das Feld “Setup” vom Template (bitte auch Namen vergeben) den Code einfügen:

page.config.xhtml_cleaning = none

• Und dann natürlich noch den Conversion-Code:

page.100 = TEXT
page.100.value (
<Hier Google Conversion Code einfügen>
)

Ich erinnere mich grad an mein anderen Kampf mit der recht schönen, aber doch sehr unwilligen Extension Glossary Extended v. 1.0.200 (EXT: sg_glossary) im Zusammenspiel mit RealURL v. 1.5.3 (EXT: realurl) bei Typo3 (4.2.6).

1. Tipp: Um eine Meldung auf Seiten auszuwerfen, die noch keine Einträge besitzen muss man ein Teil der Datei glossary_list.tmpl (typo3conf/ext/sg_glossary/pi1/) ändern. Zum Beispiel so:

[...]
<!-- ###EMPTYRESULT_PART### -->
<p>Noch keine Eintr&auml;ge vorhanden</p>
<!-- ###EMPTYRESULT_PART### -->
[...] 

Und im TS:

plugin.tx_sgglossary_pi1.search.emptyResultAsSubpart = 1

2. Tipp: Im gleichen Ordner ist auch die locallang.php zu finden. Hier man kann man andere Ausgaben ändern. Grundsätzlich wird deutsch genutzt, wenn auch die Lokalisierung deutsch ist. Leider tauchte bei mir ein Problem mit den Umlauten auf. Denn in den url’s waren auf einmal bei den Einträgen A, O und U Umlaute mitdabei. Wie man sich vorstellen kann hat RealURL bzw. die Konfiguration diese nicht richtig aufgelöst. Dies scheint meiner Meinung nach ein noch immer ungelöstet Problem bei der Glossary zu sein. Mir hat bisher nur dies geholfen: Ich habe in der Datei ext_typoscript_setup.txt in Zeile 187 den index geändert. Dies würde dann so aussehen: Mehr …

Beim update von Typo3 (4.2.2 -> 4.2.6) tauchte mein bereits gelöstet erneut Problem auf. Hätte ich keine Sicherung der alten Version gemacht, wäre das Problem nicht so schnell behoben. Ich nutze mit meiner Typo3 Installation RealURL v. 1.5.3 (EXT: realurl) und die Extended Glossary v. 1.0.200 (EXT: sg_glossary). Beim erstmaligen Aufruf einer Seite der Glossary tauchte ein Mysql Fehler auf: 

Warning: mysql_free_result(): supplied argument is not a valid
MySQL result resource in /.../t3lib/class.t3lib_db.php on line 836

Warning: mysql_fetch_assoc(): supplied argument is not a valid
MySQL result resource in /.../t3lib/class.t3lib_db.php on line 809

Eine Notlösung habe ich bereits gefunden: In der genannten Zeile einfach eine if-Schleife um das Problemkind bauen. Das würde dann so aussehen:

function sql_fetch_assoc($res) {
     if ($res) {
        $this->debug_check_recordset($res);
        return mysql_fetch_assoc($res);
     }
}

Genau das selbe dann in der Funktion sql_free_result.

Wenn jemand eine schönere Lösung gefunden hat, möge er sie mir bitte mitteilen!

Bei der sehr schönen Extension namens Customer References (EXT: customref) tauchte ein Fehler auf. Nach einem Serverumzug sind die Kategoriezuordnung der Kunden verloren gegangen. Die Liste war somit unvollständig und auch im Quellcode tauchte die Punkte nicht mehr auf. Die Seiteninhalte, sowie die Datensatzsammlung waren vollständig. Der Fehler befindet sich in der Datei “class.tx_customref_refcustomer.php”. Dort sollte man im Bereich “Returns an Array of Categorie IDs this refcustomer is assigned with” (im Bereich der Zeilen 200) die Zeile 

'tx_customref_categorie, tx_customref_referencecustomer ' .

durch 

'tx_customref_categorie INNER JOIN tx_customref_referencecustomer ' .

ersetzen. Fertig!

Quelle: Dank an ManuH bei Typo3.net