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.
Archiv der Kategorie: Webentwicklung
ImageMagick, hosteurope und TYPO3
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.
[local] Extension Update schlaegt fehl
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.
webinale 2010 und TYPO3camp Hamburg
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
Google Conversion Tracking mit TYPO3
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>
)
googlemail & analytics sind keine freunde
Wir Webdesigner nutzen häufig Web-Statistiken. Gerade für Suchmaschinenoptimierung und andere Optimierungsmaßnahmen sind die kostenlosen Web-Statistiken von Google ein Traum. Ich werde jetzt nicht auf die datenschutzrechtlichen Probleme eingehen, die Analytics mit sich bringt, dazu gibt es es viel im Internet.
Worum es mir geht: Möchte man einen Nutzer für sein Analytics Account einrichten, so sollte dies ein Google Account sein (nicht nur eine Gmail-Account!) und die primäre Adresse für den Google Account sollte auch keine Googlemail-Adresse sein. Wer also den Dienst Gmail nutzt, hat dementsprechend in seinem Google Account diese Adresse als primäre eingetragen bekommen. Ich musste mir daher auch einen neuen Account anlegen, der keinen Gmail-Dienst nutzt. Nachdem ich mir diesen eingerichtet habe, konnte ich auch problemlos auf einen Analytics Account zugreifen, der mir freigegeben wurde.
Wer hätte das gedacht? Google steht sich selbst im Weg! 😀
Zusatz: Vielen Dank für den Kommentar von Oliwa: Trägt man den Account bei Analytics mit @gmail.com ein, funktioniert die Freischaltung für die Analytics-Statistiken! Gerade eben ausprobiert!
sg_glossary und realurl-Konfiguration
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ä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: sg_glossary und realurl-Konfiguration weiterlesen
Mysql-Fehler beim Aufruf von sg_glossary
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!
Typo3 customref: Fehlende Kategoriezuordnung
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