If you can dream it, you can do it
Nun sind schon wieder einige Wochen ins Chili-Land gegangen und es ist einiges passiert. Von Wachstumsschüben über Sonnenbrand bis hin zu Sturmverletzungen haben meine Chili-Pflanzen so ziemlich alles durchgemacht. Doch eins nach dem anderen.
Zwei Monate Chili-Wachstum sind nun seit meinem letzten Post vergangen. Von den 20 gesäten Samen haben insgesamt 19 gekeimt. Davon sind bis dato alle wohl auf. Natürlich gibt es Pflanzen, die ein bisschen mehr Gas geben als die anderen, aber alles zusammen genommen bin ich mit meinen Zöglingen bislang zufrieden. Zeit also für ein bisschen Statistik :-)
Nun ist etwas mehr als eine Woche vergangen, seit ich die Chili Samen ausgesät habe. Dabei habe ich jeweils 5 Samen von jeder Sorte in Quelltabletten gesetzt und weitere 5 in Anzuchttöpfe mit Anzuchterde. Da ich noch keine Erfahrung habe, habe ich mich dazu entschieden hier verschiedene Wege einzuschlagen. Zum einen um für das kommende Jahr zu wissen, welches der beste Weg war und zum anderen um euch gleich vorab vor Enttäuschungen zu bewahren.
Ein seit längerem gehegter Traum von mir ist es, meine eigenen Chilis anzupflanzen. Meistens hab ich dann aber immer die ideale Chili Samen Aussaatzeit verpasst. Mit der rechtzeitigen Erinnerung eines Freundes hat es diesmal allerdings geklappt. Gemeinsam wollten wir anpflanzen und unsere Ergebnisse vergleichen. Gesagt getan. Gewächshaus, Erde, Anzuchttöpfchen und Chili Samen wurden im Internet bei chili-shop24 bestellt und nach nur wenigen Tagen schon geliefert. Es war sogar noch genügend Zeit auf einschlägigen Webseiten nach Tips und Tricks zu suchen. Teilweise wird die Aufzucht mit massivem Aufwand betrieben. Da werden Heizkissen unter das Gewächshaus gelegt. Leuchtstoffröhren minutengenau über den Chilis an und abgeschaltet um einen „optimaleren“ Tagesablauf zu simulieren. Das war uns für’s erste mal dann doch zu viel. Ich vertraue auf die Fensterbank mit darunterliegendem professionellen Temperierer (im Volksmund Heizung genannt) und das Freiburger Wetter, das zumindest im letzten Jahr ausgiebig Sonne brachte.
„Das Original – Cocktailtour“ – So stand es auf einem Plakat in der Freiburger Innenstadt auf das ich durch einen überlebensgroßen Cocktail mit massiver Fruchtspießgarnitur aufmerkasm geworden bin. Nachdem ich 2010 schonmal eine Cocktail Tour in Hamburg mitgemacht hatte (ich hatte darüber berichtet), dachte ich mir es wäre mal wieder an der Zeit. Zumal ich auf der Cocktail Tour in Hamburg einige Bars kennengelernt hatte, die ich wohl ansonsten nie gefunden oder besucht hätte. Die Modalität war hier in Freiburg die gleiche: 5 Stunden Zeit, 9 Bars, 9 Cocktails. Das ganze Cocktailspektakel für schlanke 18€.
I just had the problem that I want to show different content elements on a TYPO3 page depending on the status of the user. Actually there were three cases:
Let’s see how that worked out…
A couple of weeks ago I was in a bar around Freiburg and it was freezing cold outside. Looking through their menu card I was in a situation I could not decide for a hot drink or one of their fancy (unfortunately freezing cold) cocktails. I remembered that I got some caipi glasses a couple of years ago with some fabric applied for hot drinks. So I asked myself if it would be possible to create a hot caipirinha cocktail. And it absolutely is possible :-) I guess somebody else had that idea before so I would not say I invented it, but I want to spread the word. So have a try!
7cl Cachaca (I absolutely prefer Ypioca)
3/4 Lime
2 heaped teaspoons of brown sugar
Hot water
Cut the lime into 12 pieces and use 9 of them for the drink. Put them into a caipirinha glass and add the sugar. Squeeze the limes thoroughly with a pestle. Afterwards add the Cachaca and stir it well. Now slowly fill the glass with the hot water and stir simultaneously. Enjoy your hot caipirinha cocktail. But be aware it may hit you :-)
I recently had the task to clean up a TYPO3 instance with round about 25000 frontend users. The goal was to reduce the 40 TYPO3 frontend groups to a minimum as the security policy changed. So the most of these groups have been deleted. As the user has to be part of at least one group to be able to login to the frontend, I had to assure that each user is member of a basic group. You can imagine I did not want to do that by hand in the TYPO3 backend for 25000 TYPO3 frontend users. So I thought about a possibility to do that with an SQL query.
Let’s assume the basic TYPO3 group is number 2. We want to add this group to everybody who is not a member. We have to pay attention to two constraints:
This results in two queries. Number one adding the group to all accunts with an empty „usergroup“ column. Number two adds „2,“ upfront all the other groups for all accounts not in group number 2.
As always: Try it on a testsystem upfront and make a backup of your database before you use this in real life. Beside that: Have fun…
If you had problems following this TYPO3 tutorial, please let me know in the comments. If it helped you or you think it can help others feel free to spread the word by sharing and liking the article. It also would help me improving the upcoming posts.
Am Black Friday muss man schnell sein. Das wissen alle, die schonmal an diesem denkwürdigen Tag versucht haben in Amerika irgendetwas einzukaufen. Aus diesem Grund verliere ich an dieser Stelle nicht zu viel Zeit, sondern schick euch gleich weiter auf die CrashPlan Webseite, auf der das Black Friday Angebot schon recht prominent prangert (allerdings nur bis zum 25.11.2012). Rabatt gibt es aktuell noch 95%, aber der reduziert sich bis Montag alle zwei Stunden. Also schnell vorbei schauen: Go to CrashPlan
Ein paar Worte für diejenigen, die nicht wissen worum es sich hier handelt und daher nicht gleich vor lauter Freude auf den Link klicken. CrashPlan ist eine Backup-Lösung, die es zum einen kostenlos ermöglicht Backups auf externe Rechner zu spielen, z.B. bei Freunden oder auf einen eigenen Server. Zum Anderen bietet CrashPlan allerdings auch die Möglichkeit für eine monatliche Gebühr (ab 3$) Backups auf deren Cloud Infrastruktur abzulegen. Dieser Service ist heute massiv reduziert zu haben, aktuell bekommt man ein Jahr für den Preis eines Monats.
Interessant ist das für alle, die zum einen Wissen, was ein Backup der eigenen Daten Wert ist (und aktuell vielleicht sogar schon eines machen, sei es mit Time Machine oder anderen Programmen), sich zum anderen aber auch vorstellen können, dass der eigene Rechner mitsamt der Backup-Platte gestohlen werden könnten oder einem Feuer, einer Naturkatastrophe o.ä. zum Opfer fallen könnten. Einen längeren Artikel spare ich mir an dieser Stelle, nicht dass es nachher heißt: „Ich war nicht schnell genug…“
Wer meine Webseite schon länger kennt, der weiss, dass ich stets darauf aus war alle Funktionalität in TYPO3 abzubilden. Zum einen, weil es sich dabei oftmals um eine Herausforderung handelte, die mein TYPO3 Wissen immer wieder auf die Probe stellte und erweiterte. So war es auch mit dem Blog.
TYPO3 hat mir stets als herausragendes Content Management System gedient und das tut es heute noch. Aber als die Blogosphäre begann sich aufzublähen wollte ich mit meiner Webseite auch ein Teil davon werden. Zunächst versuchte ich dabei wesentliche Funktionen eines Blogs mit den üblichen Bordmitteln umzusetzen. Das machte reichlich Arbeit, denn man muss ja eine Übersichtsseite produzieren mit Verlinkungen auf die Unterseiten, Blogrolls per Typoscript einbinden. Ein Unterfangen das schnell an Übersichtlichkeitsgrenzen stieß. Kommentare gabs über ein Gästebuchformular, das auf jeder Seite eingebettet war. Trackback und Pingback waren unter
Eines Tages stolperte ich über eine Webseite die Beschrieben hat, wie man einen Blog mit tt_news umsetzen könnte. Man würde sich die ganze Seitenanlegerei sparen und anteasern ginge sozusagen automatisch, und im weitesten Sinne ist ein Blogeintrag ja sowas wie eine Neuigkeit. Gesagt, getan. Alles umgestellt und schon waren wesentliche Blogfunktionalitäten mit von der Partie. Man konnte automatisch zwischen den Einträgen navigieren. Kategorisierung war auch am Start und eine Teaserseite war auch schon mit dabei. Lange war das die Variante meiner Wahl, bis plötzlich eine Meldung durch das Internet kursierte.
Da machte also eine Extension im TYPO3 Umfeld von sich reden, die die Hoffnung weckte annähernd an die Funktionen einer Blogsoftware wie WordPress heranzureichen. Dabei machte die Extension nicht wesentlich viel anders als ich es vorher schon gemacht habe. tt_news und ve_guestbook wurden kombiniert und mit ein paar zusätzlichen Features verklebt. So richtig rund lief das ganze aber nie. Zumindest nicht bei mir.
Als die schweizer Firma snowflake mit ihrer Extension t3blog aufschlugen ging ein raunen durch die TYPO3 Gemeinde. Eine Extension, die alle Funktionen eines Blogs mitbringen soll? Ohne Hacks und Knauperei? Ohne Kannibalisierung anderer Extensions? Das klang wie ein Traum.
Tatsächlich konnte man mit wenig Aufwand aus einem frisch aufgesetzten TYPO3 einen Blog machen. Posts, Kommentare, Teaserseiten, Blogroll, Navigation. Alles mit nur einer Extension. Trackback und Pingback sollte es auch können, hat aber zumindest bei mir nie funktioniert. Aber das war bis dato das Komfortabelste, was ich gesehen hatte.
Beim Einbau in eine bereits bestehende Seite stellte sich dann allerdings schnell heraus das t3blog nicht in erster Linie als Ergänzung für eine bestehende TYPO3 Seite gebaut wurde, sondern das Ziel eher war eine TYPO3 Instanz komplett als Blog zu nutzen.
Mein Ehrgeiz war geweckt und nach einigen Nächten hatte ich den Beweis erbracht, dass man – mit entsprechendem Aufwand – sehr wohl in der Lage ist t3blog relativ sauber in eine bestehende TYPO3 Webseite einzubauen. Für den Moment war ich zufrieden. Über anfängliche Kinderkrankheiten konnte man dann auch hinwegsehen.
Nach einiger Zeit hat sich dann aber eine gewisse Schreibfaulheit eingeschlichen. Ich hatte zwar alle Freiheiten, konnte meine Blogposts frei mit verschiedenen Contentelementen gestalten und das alles in der gewohnten TYPO3 Umgebung. Allerdings war das dann doch auch irgendwie kompliziert um mal eben schnell einen Post zu schreiben. Zumal ich zu der Zeit öfters mit dem Zug unterwegs war und das TYPO3 Backend für die regelmässigen Netzausfälle dann doch auch irgendwie etwas sperrig war. Auf iPad oder gar iPhone will man das dann auch eigentlich garnicht bedienen. So gammelte der Blog so vor sich hin.
Schon zu Beginn der Blog-Ära und auch immer mal zwischendurch habe ich mit WordPress experimentiert. Ich habe sogar bei Anfragen teilweise je nach Anforderung explizit zu diesem System geraten. Und plötzlich kamen ein paar verschiedene Punkte zusammen, die mich wieder dazu veranlasst haben einen Blick auf WordPress zu werfen.
So habe ich mir einige Tage gegönnt und mich mit WordPress bekannt gemacht. Wenn man keine speziellen Anforderungen hat, ist man auch sehr schnell am Start. Ich habe mir zunächst mal das erstbeste responsive Design Template geschnappt und versucht es an meine Vorstellungen anzupassen. Teilweise war ich dabei der Verzweiflung nahe. Zum Glück habe ich dann – nachdem ich zugegebenermaßen einiges gelernt habe – noch ein Template gefunden, dass den grössten Teil meiner Wünsche abdeckt. Dazu noch ein paar Plugins und fertig. Herzlich Willkommen im neuen Blog
Zunächst habe ich jetzt ein neues Spielzeug, das ich vermutlich in der nächsten Zeit häufiger nutzen werde. Ihr könnt also zuallererst mal mehr Aktivität erwarten. Da ich meine Bloggingtätigkeit nun in ein System verlagere, dass genau für diese Zwecke ausgelegt wurde, sollten auch die typischen Blogrelevanten Funktionen nun einfach funktionieren. Hinzu kommt, dass ich mich auch dazu entschieden habe, meine Fotos nicht mehr in TYPO3 anzeigen zu lassen, sondern ebenfalls hier im Blog.
Wenn ich jetzt wieder ein bisschen Zeit finde, dann werde ich das Design der Webseite ebenfalls anpassen und beide Systeme miteinander verknüpfen. Bis dahin bitte ich euch, den grafischen Bruch zu entschuldigen.
Zu guter letzt könnt ihr meinen Blog dank responsive Design nun auch auf Mobilgeräten in angepasster Form bewundern. Über eure Erfahrungen und Feedback freue ich mich natürlich jederzeit.
A couple of days ago I had a problem with one of our TYPO3 news editors. She was able to see all tt_news categories she should see. She also could select one category but as soon as she saved the entry in the TYPO3 backend, the chosen category box went empty. The more curious was that the category was obviously saved, as the entry was shown correctly in the TYPO3 frontend. But as soon as she made another change afterwards the category was deleted as the box was not filled with the correct entry.
It gave me kind of a hedache because I could not imagine why she can see all the stuff and can choose it and also can save it but cannot – well – load and show it to the chosen categories box.
Thanks to an old nabble entry I found after about 1 hour I figured out the problem. It seems that the box with the available categories is filled with another mechanism than the chosen categories box. If you have parts of the website not shown to the editor and categories in a special folder, this behaviour can happen because of the lack of access rights on this special folder.
Normally you do not want to let the editors see your – I call it – Storage Folder. If you store tt_news categories in there you might be afraid now that you will have to. But you don’t. The only thing that you have to do is give a group in which your editors reside (or if you want, everybody) read access to the folder. The steps to do that are quite easy:
You are done. The editor should now be able to select, save and also see the chosen category even after saving the entry.
Heute hatte ich ein TYPO3 Problem mit Powermail und dem jQuery Framework, das mich fast in den Wahnsinn getrieben hat. Recherchen bei Google brachten mich immer zum gleichen Ergebnis: t3jquery installieren. Genau das wollte ich aber nicht, da ich bei dem aktuellen Projekt so wenige Extensions wie möglich verwenden möchte. Nach durchexerzieren etlicher Tutorials, durchreiten von mehreren Dokumentationswüsten und durchwandern des üblichen Quellcode-Dschungels bin ich letztlich an der Workaround Oase angekommen. Aber wie immer erstmal zum Problem:
Auf dem TYPO3 Extension Markt findet sich für alles und jeden etwas mehr oder weniger gut passendes um sein gerade aktuelles Problem zu erschlagen. In Projekten mit vielen solcher Problemen endet man dann am Schluß mit einem Wust an Extensions, die sich im schlimmsten Fall gegenseitig negativ beeinflussen. Der Wartungsaufwand für den Administrator steigt natürlich auch mit jeder weiteren Extension. Aus diesem Grund versuche ich mit möglichst wenigen Extensions auszukommen.
Im konkreten Fall geht es nun um Grundfunktionalität, die an vielen Stellen der Webseite verwendet wird und ohne die heute kaum noch eine moderne Webseite herum kommt: jQuery (o.ä.). Das Javascript-Framework ist im Grunde recht einfach eingebaut, eine Skript-Anweisung im HTML genügt bereits um das Paket dynamisch von einem CDN laden zu lassen. Oder aber man installiert die Extension t3jquery die neben der Einbindung noch andere Funktionalität mit sich bringt, die man oft braucht, naja, wenn man viele Extensions verwendet, die auf jQuery angewiesen sind.
Viele dieser Extensions bringen netterweise gleich eine eigene jQuery-Datei mit und bauen die ein. So wie Powermail das auch tut. Bemerkt Powermail, dass t3jquery installiert ist, dann wird aber auf das von dieser Extension angebotene Paket zurück gegriffen.
Was ist aber nun, wenn ich das Framework über den oben erwähnten Einzeiler im HTML einbaue? Richtig, Powermail feuert seine Variante mit in die Ausgabe. Plötzlich hat man gleich mehrere jQuery Varianten, die der User sich beim Seitenaufruf runter lädt und wie zu erwarten irgendwas kaputt machen, weil sie sich gegenseitig ins Gehege kommen.
Eine Lösung muss her und die ist ganz klar formuliert: Von jedem Framework (jQuery, jQuery Tools, anythingslider etc…) darf am Ende nur ein Eintrag im ausgelieferten Quelltext stehen.
Mein erster Gedanke war: „Die Frameworks per Hand einbinden und Powermail sagen es soll sich nicht einmischen“.
Gesagt getan. Es gibt recht simple Anweisungen um Powermail unmissverständlich klar zu machen, dass man seine jQuery und jQuery Tools Frameworks bitte nicht verwenden möchte:
page.includeJSlibs {
powermail_jQuery >
powermail_jQueryTools >
powermail_jQueryToolsTabs >
}
Danach macht Powermail allerdings auch unmissverständlich klar, dass es die von Hand eingebundenen Frameworks auch nicht verwenden möchte. Ohne tiefer in den Code geschaut zu haben, vermute ich ein Feature statt eines Bugs. Denn wenn kein JS zur Verfügung steht, wird die Validierung der Felder wie früher auf der nächsten Seite angezeigt. Eine Option mit der man Powermail sagen kann, dass es sich drauf verlassen soll, dass da schon das richtige eingebunden ist, habe ich nicht gefunden.
Lösungsversuch gescheitert.
Zweite Idee: Wir lassen Powermail die Frameworks einbinden, wenn es denn unbedingt will.
Hier stoße ich auf das Problem, dass Powermail sich zwar leicht die entsprechenden Dateien unterschieben läßt, diese dann allerdings nur einbindet, wenn sich auf der Seite auch ein Powermail Formular befindet. Nun wird der geneigte Leser sicher verstehen, dass ich auf der Startseite mit Slidern und Bannern kein Powermail-Formular platzieren möchte.
In den Untiefen der Dokumentation finde ich allerdings noch ein Flag, mit dem man Powermail sagen kann, dass es immer liefern soll, auch wenn es selbst nicht zum Einsatz kommt. Also schnell mal alles zusammengebaut und getestet. Und siehe da, es funktioniert.
Sollte mal jemand vor einem ähnlichen Problem stehen, so sollte er sich folgenden Code mal anschauen:
[userFunc = user_powermailOnCurrentPage(1)] && [userFunc = user_powermailCheckT3jquery(false)] && [globalVar = LIT:1 > {$plugin.powermail.js.toHeader}]
// remove jQuery and jQueryTools libraries from header
page.includeJSlibs {
powermail_jQuery >
powermail_jQueryTools >
powermail_jQueryToolsTabs >
}
// Include jQuery and jQuery Tools in footer
page.includeJSFooterlibs {
powermail_jQuery.external = 1
powermail_jQuery = http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js powermail_jQueryTools.external = 1
powermail_jQueryTools = / fileadmin/js/jquery.tools/jquery.tools.form.min.js powermail_jQueryToolsTabs.external = 1
powermail_jQueryToolsTabs = / fileadmin/js/jquery.tools/jquery.tools.tiny.min.js}
[end]
# At this point we only add another bunch of JS frameworks
# fancybox, easing and sliding needed on some pages
page.footerData.10 = TEXT page.footerData.10.value (
<!-- scripts-->
<script src="/fileadmin/js/jquery.fancybox-1.3.4.pack.js?x67451" type="text/javascript"></script>
<script src="/fileadmin/js/jquery.anythingslider.min.js?x67451" type="text/javascript"></script>
<script src="/fileadmin/js/script.js?x67451" type="text/javascript"></script>
<!-- .scripts-->
)
Der obere Teil ist in leicht abgewandelter Form auch im mitgelieferten Powermail TS-Setup zu finden. Was hier interessant ist, ist die userFunc user_powermailOnCurrentPage(1). Diese prüft nämlich, ob powermail auf der aktuellen Seite aktiv ist. Als Parameter kann man mitgeben ob powermail-Javascript auf allen Seiten angezeigt werden soll. Im zweiten Teil fügen wir dann noch wie üblich alle anderen Frameworkteile hinzu.
Der gezeigte TS-Code funktioniert jetzt so wie er soll. Sicherlich kann man diesen noch ein wenig optimieren, was aber hier im Blog vermutlich eher zu Lasten des Verständnis gehen würde.
Sollte ich mal wieder zu kompliziert gedacht haben und jemand anderes hat hier einen Einzeiler oder dergleichen parat. Immer gerne in die Kommentare posten.