Ein Blog von netzhaut.de

0

robots.txt für TYPO3

Suchmaschinen kann man an die Hand nehmen und ihnen gezielt seine Website zeigen bzw. an mancher Ecke vorbeiführen. Die robots.txt ist dabei eines der Hilfsmittel zur Führung. Es gibt Ecken in TYPO3 und in der konkreten Website, die für Suchmaschinen inhaltlich irrelevant sind. Warum also sollte man das freundlichen Crawler nicht sagen? Diese werden dankbar sein, dass wir ihnen Arbeit ersparen – und wir sind froh, dass solch irrelevante Teile in keinem Suchindex auftauchen. Hierfür können via Allow gezielt auf Pfade hingewiesen werden, via Disallow hingegen gezielt ausgeschlossen werden. Vorsicht: Die Angaben in der robots.txt stellen lediglich Bitten/Empfehlungen für Crawler...

0

Chrome: Warnung vor unsicheren Ressourcen

Bei einer Website stießen wir kürzlich auf eine Warnung von Chrome (v 41), wie sie rechts zu sehen ist. Schnell war abgeklärt, dass keine „veraltete Kryptographie“ im Einsatz ist. Also nahmen wir den Teil „Diese Seite enthält jedoch andere, nicht sichere Ressourcen.“ unter die Lupe. Per Durchsicht im HTML-Quellcode konnten wir keine Resourcen-Einbindung mit „http://“-Quellen entdecken. Zur Sicherheit wurden sämtliche Javascripte und CSS-Dateien herausgenommen. Chrome meldete weiterhin seine Bedenken. Aus Clientsicht ließ sich nichts mehr erkennen. Wir guckten uns die Sache daher serverseitig an: welche Resourcen werden denn dort angefordert (nachdem wir externe Quellen ausschließen konnten)? Doch im access-Log tauchten...

0

Standard-Mailform

Minimales Setup für Standard-Mailformular sollte mitbringen: Reply-To an Websitebesucher fester From-Name… …und From-Email (sonst ggf. falsch automatisiert ermittelt) Konfiguration könnte somit etwa aussehen wie folgt: Name | *replyto_name=input E-Mail | *replyto_email=input Nachricht | *Nachricht=textarea | from_name=hidden | example.com | from_email=hidden | info@example.com | formtype_mail=submit | Absenden | html_enabled=hidden | subject=hidden | example.com Mailformular

1

Mit getText in generischen Markern auf tt_content zugreifen

Heute benötigte ich innerhalb eines generischen Markers von tt_news Zugriff auf das Content-Element, in dem die Meldung angezeigt wird (also die Plugin-Einbindung). Warum man sowas braucht? Naja, Projekte entwickeln sich manchmal kreativ… 😉 Generische Marker werden im Zuge des Renderings der einzelnen Newsmeldungen ausgewertet, d.h. der Zugriff über field etc. ist jeweils auf den tt_news-Datensatz, nicht auf das Inhaltselement. Der Datensatz selbst hat auch keine Verknüpfung zum Inhaltselement. 🙁 Die Kollegen der marit.ag haben vor Längerem den Artikel „Datenbankfelder dynamisch per stdWrap.data auslesen“ verfasst. Damit ließe sich (via „getText“) auf beliebige Datensätze dynamisch zugreifen wie folgt: genericmarkers {       ...

0

Suggest-Wizard mit PAGE_TSCONFIG_*-Werten

Wird bei Relationen die Auswahl (zu) groß, ist oftmals die Einschränkung via TCA und PAGE_TSCONFIG_*-Werten in den addWhere-Klauseln sinnvoll. Zusammen mit dem Suggest-Wizard wäre damit die Datenmenge für den Redakteur handhabbar. Leider stoßen wir hier aber auf ein Problem, wie Frank im Kommentar zu Steffen Blogartikel „Using the new TCA wizard „suggest“ for autocompletion in BE fields of TYPO3 4.3“ schon anmerkt: Just found out, that suggest doesn’t work with „foreign_table_where“-conditions with markers like „###PAGE_TSCONFIG_IDLIST###“. Only the explicit csv-list works in that case. Aber warum? Schaut man sich die Klasse t3lib_TCEforms_Suggest an, so sieht man, dass lediglich zwei Marker ersetzt...

0

realURL: optimierte Multi-Domain-Konfiguration

Ausgangssituation In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.

2

Extensionmanager: Fatal error: Call to a member function getUid() on a non-object

Gestern war es wieder einmal so weit: leises Fluchen war zu hören. Grund hierfür war, dass der Extensionmanager einer frischen TYPO3-Installation keine Extension installieren wollte, sondern seinen Dienst mit einer Fehlermeldung abbrach: Fatal error: Call to a member function getUid() on a non-object in /var/www/test/typo3/6.1.5/typo3/sysext/extensionmanager/Classes/Utility/Repository/Helper.php on line 251 Recht schnell war verständlich, dass hier auf ein nicht vorhandenes Repository versucht wird zuzugreifen. Aber warum? Bei einer frischen Installation sollte das doch funktionieren? Und es tut doch normal auch… Wir wollten es wissen. Was geht hier (manchmal) schief? Wir setzten schnell eine frische Test-Installation auf – alles passt. Dann gab so...

12

Imagesize und Crop abhängig von der colPos

Um Bilder nicht nur eine feste Breite in Abhängigkeit von der colPos zuzuweisen, sondern auch noch zu croppen, bentötigt man folgendes Snippet: temp.tt_content.image < tt_content.image tt_content.image = CASE tt_content.image {   key.field=colPos   0 < temp.tt_content.image   1 < temp.tt_content.image   2 < temp.tt_content.image     1.20.1.file.width >   1.20.1.file.height >   1.20.1.file {     width = 698c     height = 400c   }   2.20.1.file.width >   2.20.1.file.height >   2.20.1.file {     width = 200c     height= 150c   } }

1

locallang-Einträge werden nicht übernommen

Manchmal könnte man fast verzweifeln. Die neue Extension für den Kunden ist endlich fertig, es soll nur noch schnell ein Textchen mehr an einer Stelle rein. Kein Problem, locallang.xml ergänzt und im Fluidtemplate auch noch eine Zeile ergänzt – im Frontend bleibt die Stelle jedoch leer. Eine Überprüfung, ob der Key denn auch korrekt ist, bestätigt: ja, ist korrekt 🙁 Ursache ist (wie leider so oft) der Cache, der es (zu) gut meint. Lösung: Seit TYPO3 4.6 cacht der l10n-Parser (basierend auf dem Caching Framework) die Übersetzungen. Ein Löschen dieses Caches bringt dann den neu hinzugekommenen Wert auch zum Vorschein....

0

realurl: aus Mountpoint echte Seite machen

Immer mal wieder kommt es vor, dass (gerade bei Multi-Domain/Multi-Tree-Seiten) an verschiedenen Stellen im Baum dieselber Seite erscheinen soll. Gelöst ist das schnell via Mountpoint. Nach einiger Zeit wird dann aber festgestellt, dass diese doch nur eigentlich gleich ist, sich aber in ein paar kleinen Details unterscheiden müsste. Kein Problem: schnell die Originalseite danebenkopiert, angepasst, den Mountpoint gelöscht – prima. Ja, wäre da nicht noch realurl. Der Pfadname sollte gleichbleiben, müsste aber ja nun auf die neue Seite führen. Aber egal, wie oft man den realurl-Cache (Encode-, Decode-Cache, ID-to-Path-Mapping) löscht, aus irgendeinem Grund will realurl weiterhin einen Mountpoint auflösen 🙁...