Problem war, dass Redakteure keine Inhalte löschen konnten, aber auch nur manchmal. Es war möglich in der Listenansicht, aber nicht über das Mülleimer-Symbol in der „normalen“ Content bearbeiten Ansicht.
Die Rechte waren auf den ersten Blick richtig gesetzt, die Zugriffsrechte auch. Beim Anlegen der Elemente war es auch komisch – innerhalb eines 2-spaltigen FCEs war es nicht möglicht, dahinter oder davor schon. Wenn man doch ein Element innerhalb des 2-spaltigen FCE anzulegen versuchte, wurde es nicht korrekt verknüft und als „nicht verwendet“ dargestellt.
Die Lösung: Templa Voila bringt ein weiteres Feld mit, das sich in der Liste der „allowed excludfields“ gut tarnt – Seite:Inhalt. Dieses Feld muss bei der Gruppe mit ACLs ausgewählt werden und schon funktioniert es.
Manchmal ist es notwendig, dass die Bilder, die im BE reingestellt werden, im FE ein bestimmtes Aussehen verpasst bekommen, wie z.B. einen Rahmen in 2 Farben oder abgerundete Ecken. Interessanterweise hat sich rausgestellt, dass es einfacher ist, runde Ecken ins Bild zu rendern, als einen festen Rahmen.
Hier die Anleitung zum Erweitern des Render-Mechanismus, damit alle Bilder mit runden Ecken versehen werden: Dynamische Masken
Zu beachten dabei ist, dass die Stärke der Abrundung im Zusammenhang steht mit der Ausgangsbildgröße und der Ausgabebildgröße, d.h. alle Ecken sind unterschiedlich groß. Die Maske wird nämlich auf das ursprüngliche Bild gelegt und dann mit dem Bild zusammen kleiner skaliert, so dass es nicht möglich ist, bei allen Bildern in in jeder Eingangs- und Ausgangsgröße die Ecken gleich groß zu gestalten.
Ein gute Lösung für diese Problem ist mir bisher nicht bekannt. Was man aber machen kann, ist mit den Typo3 Variablen in borderSpace und wrap zu experimentieren, so dass man auf die Bilder einen Rand legen kann oder z.B. runde Ecken. Theoretisches Beispiel:
wrap =
… [etc.]|
Und so ein CSS:
.roundcorners {
position: relative;
}
.roundcorners .topleft {
position: absolute;
top: 0;
left: 0;
}
.roundcorners .topright {
position: absolute;
top: 0;
right: 0;
}
Auf vielen Seiten gibt es eine Suchbox, die oben irgendwo in der Ecke steht. Wenn man da was eingibt und absendet, landet man auf einer Seite, auf der die Ergebnisse angezeigt werden, meistens steht da auch noch eine Suchbox darüber. Was ist aber wenn man die Suchbox über den Ergebnissen nicht haben möchte, und für die kleine Suchbox oben in der Ecke nicht gleich die Macina Searchbox verwenden möchte und der Pagebrowser trotzdem funktionieren soll.
Zunächstmal braucht man nicht gleich die Macina Searchbox, um eine Box in einer Ecke zu machen, reicht ein wenig Typoscript.
lib.search = COA_INT
lib.search {
10 = TEXT
10.value =
20 = HTML
20.value =
wrap =
}
Fertig ist die Box! Man kann natürlich auch Klassen hinzufügen, um das Ding zu stylen oder ein fieldset drumrum. Die searchPagePID ist eine Konstante, die man definieren muss, an diese Seite wird das Ergebnis gesendet.
Auf die Ergebnisseite wird das Plugin indexed_search gelegt. Wenn man da aber das Formular nicht haben möchte, kann man es nicht einfach entfernen. Denn der Pagebrowser verlinkt nicht einfach, da wird per JavaScript ein Wert in dem Formular geändert und das Formular anschließend gesendet. Und wenn kein Formular da ist, dann gibt es JavaScript Fehlermeldungen. Mögliche Lösung ist das Ausblenden des Formulars mit CSS oder das verstecken der ungewollten Felder mit type=“hidden“.
Zu beachten ist bei all dem, dass das Formular in der Box einen anderen Namen hat, als die Suchbox selbst. Dann falls die gleich sind, gibt es auch Probleme beim Pagebrowser.
Und noch folgende ätzende Sachen: die Ausgabe der indexed_search läßt sich nicht steuern, d.h. es wird immer die Box, danach der Pagebrowser und dann das Ergebnis augegeben. Die Reihenfolge kann man nicht geeinflussen, man kann keine Wraps um die Bereiche machen und man kann sie nicht ausblenden, um irgendwann die indexed_search nochmehr zu zerstückeln (z.B. Suchbox in Spalte 1, Ausgabe in Spalte 2 und Pagebrowser in Spalte 3).
Problem: indexed_search fügt zu der Ergebnisliste auch die Meta-Tags hinzu. Blöd, weil die erstens auf jeder Seite die gleichen sind und so das Ergebnis erheblich verfälschen, zweitens weil die Meta-Tags direkt hintereinander ohne Leerzeichen geschrieben werden und so in meinem Liebligsbrowser(IE6) das Layout sprengen.
Zum Glück gibt es Kollegen, die das kennen und mit einem Bugfix aushelfen können.
Hier der Link: Indexed Search Metatags ignorieren
Falls die Seite mal weg sein sollte (oder jemanden das tolle Bananenbild stört), hier die Lösung. Die folgenden zwei Zeilen in indexed_search/class.indexer.php in der Funktion splitHTMLContent suchen und auskommentieren. Prost!
if(stristr($meta[$i][’name‘],’keywords‘)) $contentArr[‚keywords‘].=‘,‘.$meta[$i][‚content‘];
if(stristr($meta[$i][’name‘],’description‘)) $contentArr[‚description‘].=‘,‘.$meta[$i][‚content‘];
(vor allem für Markus, dem besten besten Freund, den man sich vorstellen kann)
Zunächst braucht man die Extension sr_language_menu, die schon die meiste Arbeit, wie das Abfragen, ob eine Seite existiert, ob eine Übersetzung vorhanden ist und das Markieren der aktuellen Sprache übernimmt. Dann kann man die Extension über den Constant Editor konfigurieren, da ist das meiste selbsterklärend.
Es gibt ein kleines Problem damit, dass Typo3 als internationale Anwendung davon ausgeht, dass Englisch die Default Sprache ist. Aber da kann man tricksen.
Das ist ein Auszug aus dem Templates (Constants), in dem Deutsch und Englisch als Sprache definiert werden. Wenn die Language ID 1 angegeben ist, dann wird die englische Version der Seite angezeigt.
config {
sys_language_uid = 0
language = de
locale_all = de_DE.UTF-8
}
[globalVar = GP:L = 1]
config {
sys_language_uid = 1
locale_all = en_EN.UTF-8
language = en
}
[global]
Hier wird eine Liste der Sprachen neben der Default angegeben.
# list of configured languages for lang selector
languageUids = 1
Und in diesem Teil wird im Setup das Wrap um die Menüpunkte angegeben.
// setup
plugin.tx_srlanguagemenu_pi1 {
flag.NO.stdWrap.wrap = |
flag.INACT.stdWrap.wrap =
flag.CUR.stdWrap.wrap =
}
Dann muss nur noch ein Menü zum Umschalten von Sprachen generiert werden. Dieser Schnipsel erzeugt ein kleines Menü mit „Sprache“ als Label. Je nachdem was vorher in Constants definiert worden ist, werden Flaggen oder eine Liste dargestellt. Nach dem Kopieren des Plugin-Inhaltes in lib.lang.10 wird noch angegeben, dass Deutsch die Default-Sprache ist, und falls man Flaggen benutzt, muss hier der Pfad zu einer deutschen Flagge angegeben werden, die aber auch im Extension-Verzeichnis liegend kann (dann fängt der Pfad mit EXT an). Weiter darunter ist definiert, wenn die aktuelle Sprache englisch ist, soll da dementsprechend Language stehen.
lib.lang = COA
lib.lang.5 = TEXT
lib.lang.5.value = Sprache:
lib.lang.5.wrap =
|
lib.lang.10 < plugin.tx_srlanguagemenu_pi1
lib.lang.10 {
defaultLanguageISOCode = DE
languagesUidsList = {$languageUids}
defaultLayout = 0
englishFlagFile = fileadmin/gfx/flags/de.gif
}
[globalVar = GP:L = 1]
lib.lang.5.value = Language:
[global]
Wenn alles so weit vorbereitet ist, kann man das Objekt einem Marker im Template zuweisen.
Ich habs zwar nicht selbst programmiert, aber die Firma bei der ich arbeite. network.publishing hat eine Extension entwickelt, mit der man Subversion in Typo3 integrieren kann. Man legt Repositories an und definiert in weiteren Datensätzen, ob es sich um eine Workingcopy handelt oder einen Export und ob das Ziel eine Extension oder einfach nur ein Ordner ist.
Die Extension gibt es seit einem halben Jahr, aber das neue ist der Diff-Viewer, der es ermöglicht, nun auch online Unterschiede zu der letzen Version anzeigen zu lassen.
Wir nutzen die Extension bei allen neuen Projekten und entwickeln so Extension und verwalten den fileadmin Ordner. Ich nutze es sehr gerne und bin begeistert und kann es nur weiterempfehlen. Hier die Links:
News bei NP: np_subversion erhält Diff-Viewer
Extension im TER: np_subversion 0.7.1
Im Moment habe ich keine Zeit zum Schreiben von typo3 Einträgen. Es passiert schon sehr viel, ich habe einige Sites an denen ich arbeite, aber irgendwie kommt momentan kein Material für einen Eintrag zusammen. Dafür passiert in letzter Zeit einiges mit meiner Extension pro_industrydb. Zum einen gibt es Weiterentwicklungswünsche, da komme ich leider nicht zu. Zum anderen gibt es auch mal Lob und Feedback. Das freut mich sehr, denn ich finde diesen ganzen Communitygedanken einfach grossartig und freue mich, wenn andere Leute von meiner Arbeit profitieren.
Jetzt gabs auch mal ein Update mit ein paar Fixes. Ich würde mich sehr darüber freuen, wenn meine Extension genutzt wird und dazu ein paar Kommentare verfasst werden.
Manchmal ist es notwenig, Bilder aus dem Media-Feld der Seite als Hintergrund zu verwenden, gelegentlich als Gifbuilder-Objekt. Dieses Beispiel rendert das Bild aus dem Media-Feld, versieht das ganze mit dem Untertitel/Titel der Seite und fügt noch ein farbiges Rechteck hinzu. Anschließend wird das ganze als Hintergrundbild in einen div mit der Id „header“ eingefügt. Vorteil dieses Verfahrens ist, dass der Header semantisch richtig und nicht als Bild dargestellt wird.
temp.header = COA
temp.header {
1 = TEXT
1.field = media
1.listNum = 0
1.wrap =
Neueste Kommentare