jQuery: Nach Ajax-Response script-Tags in bestimmten DIVs ausführen

Beim Laden über die schöne jQuery.ajax()-Funktion wollten wir nicht nur die Inhalte eines bestimmten DIVs austauschen, sondern auch alle JavaScripte im neuen DIV ausühren. Leider werden alle Script-Tags automatisch „bereinigt“ bevor man sie in das DOM einfügen kann. Nach einigen Versuchen kamen wir dann auf folgende Lösung.

$.ajax({
   url: "http://....",
   success: function ( data ) {
     
      // Dieses DIV soll ersetzt werden - und alle script-Tags innerhalb des DIVs ausgeführt werden
      var target=".testdiv";	

      // Erst mal den Inhalt des DIVs mit dem neuen Inhalt ersetzen
      $(target).html( $(target, data).contents() );

      // Jetzt über ein paar Umwege die gewünschten Script-Tags innerhalb des DIVs finden und ausführen
      var div = document.createElement('div');
      div.innerHTML = data;
      var ref = $($(div).find(target).html());
      ref.filter('script').each(function () {
         $.globalEval(this.text || this.textContent || this.innerHTML || '');
      });
   }
});

Für Suchmaschinen: „jQuery Ajax Script-Tag“ „execute script tags jquery ajax response“ „script tags ajax response“ „script in div ajax response“ „einzelne script-Tags ausführen jquery ajax“ „jquery script clean“ „ajax javascript script ausführen“

Flash Reload Problem jQuery IE Internet Explorer

Eine Stunde Kopfschmerzen: Ich lade per jQuery-Ajax den Inhalt einer neue Seite und füge ihn nach dem Laden über diese Zeile ins DOM ein. Das Problem: Alles JavaScripte des neuen, geladenen Dokumentes werden im IE8 automatisch ausgeführt, sobald er den Befehl $(‚.content‘, data) ausführt.
Bei unserem Projekt führte das zu Problemen, da über swfobject ein Flash-Film im DOM eingefügt wurde und so bei jedem Nachladen eines Inhaltes über AJAX auch der Flash-Film neu eingebettet wurde und von vorne startete:

// Laden des Inhalts per jQuery AJAX
$.ajax({  url: 'http://www.meineurl.de', success: function (data) {
      $('.content').html( $('.content', data).html() );
}});

Damit es keinen Reload des Flash-Films gibt, bestand die Lösung darin, über eine RegEx alle Script-Tags aus der Ajax-Rückgabe zu entfernen und dann erst zu parsen bzw. ins DOM einzufügen:

 // Laden des Inhalts per jQuery AJAX
$.ajax({  url: 'http://www.meineurl.de', success: function (data) {
 data = data.replace(/]*?>[\s\S]*?<\/script>/gi, '');
      $('.content').html( $('.content', data).html() );
}});

Zweites Phänomen: Der Flash-Film war in ein DIV eingebettet und das DIV wurde über jQuery dynamisch skaliert. Die Skalierung des DIVs führte in bestimmten Browsern ebenfalls zu einem Reload / Refresh des Flash-Films. Dieses Problem ließ sich relativ leicht über eine Anpassung im CSS des DIVs lösen:

.container_um_das_swf {
     height: 200px;
     overflow: hidden !important;
}

Pfad zum aktuellen JavaScript ermitteln

Problem: Ich will den Pfad zu dem aktuellen Javascript ermitteln. Nehmen wir an, ich habe ein Javascript unter dem Pfad /fileadmin/templates/js/script.js liegen und möchte über ein Script darin den Pfad „fileadmin/templates/js/“ ermitteln. In PHP ist das ja relativ leicht über den Befehl $_SERVER[’SCRIPT_NAME’] bzw. die magische Konstante dirname(__FILE__) zu lösen. Leider gibt es keinen vergleichbaren Befehl in JavaScript.

Ein kleiner Workaround macht es zumindest dann möglich, wenn das Script über einen <script>-Tag eingebunden wurde, also an irgendeiner Stelle im HTML-Quelltext steht. Dazu hilft ein kleiner jQuery-Einzeiler von 99°:

// Pfad zu einem JS zurückgeben
(function($){$.extend({'getJSPath': function ( file ) {return $('script[src$="'+file+'"]').attr('src').replace(file, '');}});})(jQuery);

Die Funktion kann dann so aufgerufen werden:

var path = $.getJSPath('script.js');
alert( path );

In dem Beispiel würde sich ein Fenster öffnen mit dem Text „fileadmin/templates/js/“.

Bin ich, wenn ich nicht bei Google bin?

Heute morgen erreichte uns die Mail eines irritierten Kunden. Betreff der Mail: Stimmt das? Im Anhang weitergeleitet: Die „Analyse“ einer Firma aus Hamburg, die sich auf Suchmaschinen-Optimierung spezialisiert hat und im Zuge einer „routinemäßigen Untersuchung“ leider mit Schrecken feststellen müsste, dass das Ranking der Webseite unseres Kunden auf Platz 157 von 158 sei. Ich kannte diese Firma inzwischen, denn es war bereits die dritte Mail dieser Art und der gleichen Firma, die ich in den letzten beiden Tagen bekommen hatte. Alle drei Mails kamen von unterschiedlichen Kunden, die von der gleichen Firma im Zuge eines Massenmailings angeschrieben wurden. Nachdem ich zum dritten Mal zu einer freundlichen Erklärung des Themas ansetzte, dachte ich: Zeit für einen kleinen Beitrag in unserem Labor!

Die Aufmachung des Ganzen wirkte seriös und es gab einen Link zu einem Login-Bereich, bei dem man detaillierte Einblicke in die Auswertung bekam. Immer offen für Kritik (und neue Erkenntnisse), loggte ich mich ein und wurde von einer langen Liste mit roten Ampeln konfrontiert, die in etwa sagten: Sie hätten besser Schreiner oder Schuster werden sollen als Webseiten zu backen.

Als sich der erste Schreck gesetzt hatte, schaute ich etwas genauer in die Zahlen.

bildschirmfoto-2011-08-10-um-210349

Das erste war ein auffälliger roter Balken in der Mitte mit der analysierten Domain unseres Kunden. Moment: War das wirklich die Domain unseres Kunden? Nein – die Domain gab es gar nicht, es handelte sich um eine URL, die nicht reserviert war und nur ähnlich klingt. Ein spannendes Thema und eine hohe Kunstfertigkeit, die ich noch nicht beherrsche: Wie analysiert man das Ranking einer Domain, die es gar nicht gibt? Aber, dachte ich, Auge zudrücken, Fehler passieren nicht nur Menschen, sondern auch Suchmaschinen-Optimierern.

Zweiter Blickfang: Der Panik-Bereich ganz oben. Hier war sie, die graue Liste des Grauens. Die gestreifte Verdamnis. Der tabellarisierte Albtraum. Höchst anschaulich und ohne jedes Mitleid wurde vor Augen geführt: Du existierst eigentlich gar nicht auf dieser Welt. Du bist unsichtbar während alle anderen fröhlich Deinen potentiellen Käufern zuwinken. Doch der Prozess selbstnihilistischer Erkenntnis wurde von einer Irritation getrübt: Unser Kunde verkauft doch Räder – warum ist ein Hersteller von Sport-Brillen laut Analyse auf Platz 1? Schnell griff ich zu Google und gab mal den Suchbegriff „Fahrräder“ ein. Das Ergebnis verwirrte mich noch mehr: Die Liste der Suchergebnisse bei Google hatte nicht im Entferntesten etwas mit der Ranking-Analyse dieser SEO-Firma gemeinsam. Nicht eine einzige Überschneidungen!

Natürlich war der erste Gedanke: Vielleicht habe ich die falschen Suchbegriffe eingegeben. Also versuchte ich es mit verschiedenen Varianten, Singular-Formen, mit und ohne Bindestriche, eben dem üblichen Repertoire. Ohne Erfolg. Und auch die Webseite der SEO-Firma selbst beantwortete die eigentlich erste und wichtigste Frage nicht, die wir unseren Kunden in Zusammenhang mit Suchmaschinen-Optimierung stellen: Nach welchen Begriffen soll die Seite denn überhaupt gefunden werden? Ein Urteil über das Ranking zu fällen ohne die Suchbegriffe zu nennen ist schlau – zumindest, wenn man Menschen verunsichern möchte um neue Kunden zu gewinnen.

Erst als ich weiter nach unten scrollte und mir im Detail anschaute, nach welche Kriterien denn die Seite als „schlecht“ befunden wurde, dämmerte mir, wie das Urteil zustande kam. Eine lange Liste führte mehr oder weniger relevante Kriterien auf, nach denen die Webseite analysiert wurde. Viele Klassiker wie „Enthält Keywords“, „Es fehlen Hinweise für Suchmaschinen“ – aber auch einige eher Unbekannte. Das Ganze legte die Vermutung nahe, dass das Ranking auf einem eigens von der Hamburger Firma entwickelten Beurteilungs-System basiert. Das erklärte auch die Kluft zwischen dem Ranking dieser Firma und der „realen Welt“ – also Google. Richtig war zwar, dass einige der gelisteten Punkte zu einer besseren Auffindbarkeit führen können. Ob sie das dann aber auch wirklich tun, kann jeder selbst überprüfen – wenn er die Suchbegriffe kennt. Und zumindest hier wurde mir der Bezug zur Realität nicht ersichtlich.

Das Geschäftsmodell fand ich wiederum interessant: Ich bezahle eine Firma dafür, dass ich auf der Liste, die sie nach eigenen Kriterien erstellt hat, ein besseres Ranking bekomme. Eigentlich doch die beste Art, seinen Kunden Erfolg garantieren zu können. Nur eines ist mir bis jetzt nicht ganz klar: Nehmen wir mal den gar nicht so unwahrscheinlichen Fall an, dass die Rundumschlag-Akquise dieser Firma erfolgreich ist und viele unterschiedliche Kunden des gleichen Segments ihr Ranking auf der privaten Ranking-Liste verbessern möchten: Nach welchen Kriterien entscheidet die Firma dann, wer oben ist? Vielleicht einfach danach, welcher Kunde sich gerade eingeloggt hat.

Aber zurück zum Thema. Wenn schon ein eigenes Bewertungssystem herangezogen wird, lohnt die Frage: Wie relevant sind die Kriterien denn im Detail? „Keine Keywords“ steht da ganz oben. Komisch, wo doch Keywords bei Google bekanntlich keine Rolle mehr spielen. „Es fehlt ein Browser-Icon“: Verdammt – auf was Suchmaschinen heute alles Wert legen. „Ihre Startseite wird nicht in Google gefunden“ – Oh nein, die Leute verpassen unsere nicht vorhandenen Intro-Animationen! Schön fand ich auch „Ihre Domain wird nicht bei Twitter gefunden“.

Das könnte jetzt das Ende einer kleinen Geschichte sein, aber sie hat noch keine wirkliche Pointe. Also dachte ich: Wenn doch diese Firma sich offensichtlich zum Ziel gesetzt hat, unseren Kunden der Reihe nach zu verunsichern und zu sagen, was an ihren Webseiten alles falsch ist: Was hat denn diese Firma aus Hamburg bei Ihrer eigenen Webseite alles richtig gemacht?

bildschirmfoto-2011-08-10-um-212808

Die erste Frage stelle ich Google. Sollte jemand, der sich für einen Experten der Suchmaschinenoptimierung ausgibt nicht auch bei einer Suchmaschine ganz oben stehen? Das wäre ja sonst wie der glatzköpfige Haarwuchsmittel-Verkäufer. Nach der zehnten Seite immer noch keine Spur. Und nur falls Sie fragen: Natürlich verrate ich nicht, unter welchen Begriffen ich gesucht habe. Da ich zu faul bin, die anderen Suchmaschinen zu testen nehme ich mir ein Tool zur Hand. Ein Klick vergleicht das Ranking bei den 5 großen Suchmaschinen. Puh, sieht das ernüchternd aus. Nein, mein Gefühl bestätigt sich: Diese Firma aus Hamburg braucht dringend eine ausführliche Beratung in Sachen SEO. Und wie es der Zufall will, hätte ich da auch schon eine Liste mit Kriterien, nach denen ich die Seite analysieren kann. Also: Gehen wir sie mal durch…

„Keywords“: Ja, gibt es. Aber was sind das denn für Begriffe? Genau 9 Stück finde ich im Quelltext der Homepage – die Hälfte davon vollkommen austauschbar und damit irrelevant („Hamburg“, „Agentur“, „Suchmaschinen“). Besonders schön finde ich das letzte Keyword. „such“ steht da am Ende. Ich stelle mir gerade den Internet-Benutzer vor, der verzweifelt nach einer Firma sucht, die das Ranking seiner Webseite verbessern kann. Klar, dass er als erstes bei Google „such“ eingebe. Ich such ja schliesslich, oder?

bildschirmfoto-2011-08-10-um-211154

„Description“: Ja, gibt es. Wir sind eine Google AdWords Agentur mit Sitz in Hamburg und betreuen nationale und internationale Kunden. Auch schön – aber ich dachte es geht um Suchmaschinen-Optimierung. Und: Muss ich das mit den internationalen Kunden jetzt wirklich wissen? Vielleicht wäre noch der Zusatz „Bekannt aus der TV-Werbung“ dahinter schön gewesen.

„Es fehlen Hinweise für Suchmaschinen“, „Es fehlt ein Sprachhinweis“, „Keine robots.txt vorhanden“ – drei Mal rotes Licht, Leute! So kann das ja nichts werden mit Eurem Ranking.

Immer wenn man denkt: Schlimmer kann es eigentlich nicht kommen, kommt es dann doch. Der Albtraum ist materialisiert in einer blauen Kugel neben der URL-Angabe: Statt eines Browser-Icons grinst mich hier nur das Default-Symbol von Safari an. Wie soll man denn nur auf dieser Welt ohne Browser-Icon zu Ranking-Ruhm gelangen?

Internet Explorer IE 7 / IE 8 transparente PNGs

Beim fadeIn() oder fadeOut() mit jQuery erscheint im Internet-Explorer 7 und 8 immer noch ein schwarzer Rand um transparente 24-bit PNGs. Ich habe viele Lösungen gesehen, von denen nicht wirklich alle funktionieren.
Hier die 99°-Lösung, die sich sowohl um Hintergrundbilder als auch Bilder im IMG-Tag kümmert.

Der Trick dabei ist eine Kombination aus einem transparenten Hintergrundverlauf und zoom:1 der im IE hasLayout auslöst.

Da ich nicht weiß, wie der IE9+ mit PNGs umgeht, habe ich es auf IE7 und IE8 beschränkt. Die Zeile läßt sich aber auch schnell ändern…

Hier ist eine Online-Testseite

(function($){

	// 99° IE 7/8 fading PNG fix
	$.extend({
		'pngFix': function ( obj ) {
			var vs = parseFloat($.browser.version);
			if (!$.browser.msie || ($.browser.msie && vs < 7 || vs > 8)) return;
			var magic = ';-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#00FFFFFF,endColorstr=#00FFFFFF)";filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#00FFFFFF,endColorstr=#00FFFFFF);zoom: 1;';
			var clone = ['background-image', 'background-position', 'background-repeat', 'width', 'height'];
			var arr = $('*').filter(function() {
				if (this.nodeName == 'IMG' && $(this).attr('src').indexOf('.png') > -1) return true;
				return (this.currentStyle ? this.currentStyle['backgroundImage'] !== 'none' : document.defaultView.getComputedStyle(this,null).getPropertyValue('background-image') !== 'none');
			});
			$(arr).each( function () {
				
				if (this.nodeName != 'IMG') {
					var ref = $(this);
					ref.wrapInner('
'); $(clone).each( function ( k, v ) { ref.find('.pngfix').css( v, ref.css(v) ); }); ref.css({'background-image':'none'}); ref.find('.pngfix').attr('style', (''+ref.find('.pngfix').attr('style')).split(magic).join('')+magic ); } else { $(this).attr('style', (''+$(this).attr('style')).split(magic).join('')+magic ); } }); } }); })(jQuery); $(function () { $.pngFix(); });

Typo3 4.5 – Update-Checkliste

Hier eine Liste der Probleme (und Lösungen) die wir immer wieder beim Update von Typo3 auf Version 4.5+ hatten:

Rotes Fragezeichen statt Flaggen-Symbol

Im Backend erscheint ein rotes Fragezeichen statt dem Flaggen-Symbol. [für Suchmaschinen: roter Kreis mit Fragezeichen statt Flagge Fahne Fähnchen. Fehlendes Flaggen-Symbol in Standardsprache. Flagge fehlt nach Update auf Typo3 4.5.]

Die Lösung: Root-Seite bearbeiten, dort unter „Resources“ im Page TSConfig schauen. Aus dem „de.gif“ muss ein „de“ werden:

mod.SHARED {
	defaultLanguageFlag = de
	defaultLanguageLabel = deutsch
}

Mehr Infos auch hier

Fehlende Icons für Kopieren und Einfügen bei TemplaVoila und Inhaltselementen

Absurde Lösung: Die Dateien localconf.php, realurl_autoconf.php und extTables.php von überflüssigen Leerzeilen am Ende des Dokumentes (also nach dem schliessenden PHP-Tag) befreien.

TemplaVoila vergisst das komplette Mapping nach Update

Sehr ärgerlich: Das Mapping aller Templates und FCEs geht nach dem Update verloren. Scheint an einem Update des Feldes „templatemapping“ der Tabelle „tx_templavoila_tmplobj“ zu liegen, die durch das Update von MEDIUMTEXT zu MEDIUMBLOB geändert wird. Sobald dort ein UTF8-codiertes Zeichen enthalten ist (z.B. ein Umlaut) wird das Mapping zerschossen.

Erste Lösung: Falls das Update noch nicht passiert ist.
Beim Update von TemplaVoila kommt der Hinweis, dass die Datenbank aktualisiert werden muss. Dort das Häkchen für das Feld „templatemapping“ entfernen.

Zweite Lösung: Falls das Update schon gewütet hat.
Nach dem Update von TemplaVoila per phpMyAdmin mit diesem Befehl zurück zu MEDIUMTEXT ändern:

ALTER TABLE  `tx_templavoila_tmplobj` CHANGE  `templatemapping`  `templatemapping` MEDIUMTEXT;

Dritte Lösung: Nach dem Update von TemplaVoila diese MySQL-Befehle in phpMyAdmin ausführen. So sollte man auch für zukünftige Updates gewappnet bleiben, da die Zeichen, die Ärger machen in latin1 konvertiert werden:

ALTER TABLE  `tx_templavoila_tmplobj` CHANGE  `templatemapping`  `templatemapping` MEDIUMTEXT;
UPDATE tx_templavoila_tmplobj SET templatemapping = convert(CONVERT(CONVERT(templatemapping USING utf8) USING binary) using latin1);
ALTER TABLE  `tx_templavoila_tmplobj` CHANGE  `templatemapping`  `templatemapping` MEDIUMBLOB;

GMENU erscheint nicht mehr korrekt, Transparente GIFs haben schwarzen Hintergrund

Betrifft vor allem ein Upgrade aus Versionen vor Typo3 4.4. Die folgenden Einstellungen in der localconf.php haben bei mir das Problem gelöst. Falls das Problem weiterhin besteht, mal versuchen im GMENU niceText und antiAlias auf „0“ zu setzen!

$TYPO3_CONF_VARS['GFX']["im_path"] = '/usr/bin/';       // Hier eigenen Pfad eingeben!
$TYPO3_CONF_VARS['GFX']['im_path_lzw'] = '/usr/bin/';       // Hier eigenen Pfad eingeben!
$TYPO3_CONF_VARS['GFX']['im_version_5'] = 'im6';      
$TYPO3_CONF_VARS['GFX']['im_imvMaskState'] = '1';     
$TYPO3_CONF_VARS['GFX']['im_v5effects'] = '1';    
$TYPO3_CONF_VARS['GFX']['im_combine_filename'] = 'composite';    
$TYPO3_CONF_VARS['GFX']["TTFdpi"] = '96';     
$TYPO3_CONF_VARS['GFX']['TTFLocaleConv'] = '';     
$TYPO3_CONF_VARS['GFX']["thumbnails_png"] = '0';      
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '1';    
$TYPO3_CONF_VARS['GFX']['gdlib_2'] = '2'; 
$TYPO3_CONF_VARS['GFX']['png_truecolor'] = '1'; 

Seiten einfügen und Contextmenü verschwunden

Wenn die Leiste mit den Icons und Buttons über dem Seitenbaum zum Einfügen von Seiten oder SysFoldern verschwunden ist, dann mal einen Blick in die localconf.php werfen und diese Zeilen auskommentieren:

// diese Zeile muss raus!
$TYPO3_CONF_VARS['BE']['defaultUserTSconfig']='';

Nach Laden einer Seite aus dem Cache erscheint „No Typoscript Template Found“

Keine Ahnung – vermutlich eine seltsame Kombination aus MySQL-Version und Typo3. Nach einem Update seitens des Hosts konnte man jede Seite nur ein einziges Mal anschauen. Sobald die Seite aus dem DB-Cache geladen wurde, erschien die Warnung „No Typoscript Template Found“. Nach Leeren des FE-Cache (Blitz) ging es dann wieder für einen Klick. Die Lösung war eine Änderung in der localconf.php:

$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;\' . LF . \'SET CHARACTER SET utf8;\' . LF . \'SET SESSION character_set_server = utf8;\' . LF . \'SET character_set_connection = utf8;';

Typo3 erlaubt nur maximal 20 Bilder beim Upload

Das waren gerade ein paar echte Kopfschmerzen: Wir hatten mit TemplaVoila ein FCE mit „Sections for Elements“ angelegt, dass es erlaubte mehrere Zeilen mit Bild und Text hochzuladen. Funktionierte wunderbar bis mehr als 20 Bilder hochgeladen wurden. Das 21. Bild wurde nicht mehr hochgeladen – ohne jede Warnmeldung oder Log-Eintrag.
Erster Gedanke: Ein Entwickler von Typo3 oder der TemplaVoila-Extension dachte sich: „Kein Mensch wird mehr als 20 Bilder in einem Formular hochladen“ und hatte einfach eine Schleife auf 20 Durchläufe begrenzt. Nachdem wir den Quelltext des Typo3-Core und alle Extensions nach „<= 20“ und ähnlichen Textstellen erfolglos durchsucht hatten, fiel uns eine Besonderheit auf: Wenn man die Reihenfolge der „Elements“ in TemplaVoila vertauscht, also z.B. das 21. Element in der Liste ganz nach oben schiebt, dann läßt sich das Bild problemlos hochladen.

Die Lösung war letztendlich an ganz anderer Stelle gefunden – und so banal wie alle immer: PHP-seitig gab es in der php.ini eine Einstellung für die Variable „max_file_uploads„, der als default auf 20 steht. Dieser Wert kann bei je nach Servern durch folgende Änderungen erhöht werden:

1. Eine .htaccess Datei mit der letzten Zeile in diesem Beispiel:


php_value upload_max_filesize 40M
php_value always_populate_raw_post_data 1
php_value post_max_size 40M
php_value memory_limit 256M
php_value max_execution_time 600
php_value max_file_uploads 100

2. Den php-Befehl

ini_set('max_file_uploads', 100);

3. Eine Änderung in der php.ini (falls man Zugriff darauf hat – bei größeren Webpaketen meistens über den Kunden-Login)

PID Rootline als Klasse an den body-Tag hängen

So bekommt man an den <body>-Tag alle PIDs als Rootline in einer Klasse angehängt. Das Ergebnis sieht dann z.B. so aus:
<body class=“rpid_1 rpid_67 rpid_95 „>…</body>

Wir brauchten das für eine Webseite, bei der sich das Design bestimmter Unterseiten ändern sollte – aber wir keine zusätzliche CSS-Datei über eine PAGE-Condition einbinden wollten.

## PID aller übergeordneten Seiten als class an body hängen! 
temp.body = COA
temp.body {
  10 = HMENU
  10 {
    special = rootline
    special.range = 1 | -1
    1 = TMENU
    1 {
      NO {
        doNotLinkIt = 1
        doNotShowLink = 1
        allStdWrap.cObject = COA
        allStdWrap.cObject {
          10 = TEXT
          10 {
            field = pid
          }
          10.noTrimWrap = |rpid_| |
        }
      }
    }
  }
  10.wrap = 
  10.wrap.insertData = 1
}

page.bodyTagCObject < temp.body

wrap der Body ändern, wenn Submenü existiert

Bei einem Projekt ging es darum, den gesamten Inhalt in Typo3 von einem anderen Wrap zu umgeben, falls ein Untermenü existiert. Im konkreten Fall sollte eine neue Klasse „page_with_subnavi“ direkt nach dem Body-Tag erscheinen, falls ein Submenü für den gewählten Menüpunkt existiert.

Wie bei den wohl meisten von Euch wurde im Setup des Seitentemplates der Parser für die Seite in der Variable „page“ gespeichert. In diesem Fall haben wir TemplaVoila die Kontrolle übergeben – was aber für das Beispiel nicht relevant ist. Wichtig ist nur: Die verwendete Variable heißt in diesem Beispiel page:

page = PAGE
page {
  typeNum = 0
  10 = USER
  10.userFunc = tx_templavoila_pi1->main_page
}

In diesem Beispiel wird ein einfaches HMENU erstellt und in der Variable lib.sub_navi_left gespeichert:

lib.sub_navi_left = HMENU
lib.sub_navi_left {
   entryLevel = 2
   1 = TMENU
   1.noBlur = 1
   1.wrap = 
   1.NO = 1
   1.NO {
      1.wrapItemAndSub = 
  • |
  • } }

    Und so wird der Wrap des PAGE-Objektes (bei diesem Beispiel in der Variable „page“ gespeichert) verändert, falls die Sub-Navi exisitert:

    page.stdWrap {
      wrap = |
      outerWrap = |
      outerWrap.override = 
    |
    outerWrap.override.if.isTrue.cObject < lib.sub_navi_left required = 1 }

    Natürlich läßt sich das ganze auch einfach auf die existierende Class eines DIVs anwenden. In diesem Beispiel wurde nicht das PAGE-Objekt verändert, sondern einfach der Text "centerbox" (wenn kein Untermenü existiert) bzw. "centerbox w_subnavi" (falls ein Untermenü existert) in der Variable lib.centerbox_class gespeichert. Diese Klasse wurde denn über TemplaVoila einem DIV als Attribut für "class=" zugewiesen.

    lib.centerbox_class = TEXT
    lib.centerbox_class {
      value = centerbox
      override = centerbox w_subnavi
      override.if.isTrue.cObject < lib.sub_navi_left
    }
    

    Das hier ist noch für Suchmaschinen geschrieben, in der Hoffung jemand findet diese Seite unter den Begriffen, nach denen wir selbst gesucht hatten um die Lösung zu finden: condition wenn untermenü existiert typo3, bei untermenü andere klasse typo3, wenn untermenü anders wrappen typo3

    Titel anzeigen bei Ansicht im Seitenmodul „Liste“ (tt_news)

    Gerade im Zusammenspiel mit TemplaVoila nützt die eigentlich so wunderbare Backend-Ansicht der News (tt_news) im Modul „Seite“ nicht mehr viel – sie wird einfach von TemplaVoila „verschluckt“. Leider stellt man bei dem Bearbeiten der News über das Seitenmodul „Liste“ fest, dass seit einer aktuellen Version von tt_news keine Titel mehr in der Listenansicht mehr angezeigt werden.

    Abhilfe schafft ein kleiner Eintrag in der Datei /typo3conf/extTables.php:

    PHP-Code:
    
    $TCA['tt_news']['ctrl']['label'] = 'title';
    $TCA['tt_news']['ctrl']['label_alt'] = 'datetime';
    $TCA['tt_news']['ctrl']['label_alt_force'] = 1;

    Danach sehen die Dateneinträge der News von tt_news im Seitenmodul „Liste“ wie gewohnt wieder so aus:

    bildschirmfoto-2010-04-08-um-212335