Re: [TYPO3-german] Fluid Powered TYPO3 ?
Ich hab vorletzte Woche grad erst angefangen mir das als Alternative für TemplaVoila (das mit dem 7 LTS nicht mehr läuft) anzusehen. Unser (nicht unübliches...) Problem ist, dass wir bei unseren Webseiten sehr häufig "FCEs" einsetzen müssen und TYPO3 das halt schlicht nicht von sich aus hergibt. Mit TemplaVoila hatten wir uns zudem angewöhnt, viele Sonderfälle für die Redakteure leicht verständlich als Container-FCEs mit Unterelementen als inhaltliche FCEs zu bauen. Bei 6.2er-Seiten hatten wir solche Sonderfälle schon mit eigenen CTypes in Extensions versucht zu lösen (war aber nicht so toll) oder bei einer Seite, noch in 4.5, allein durch Seitenspalten, Multicolumn-Extension und Layout-Flags mit unheimlich viel Umarbeitung per postUserFunc - das funktioniert zwar, es ist aber für Redakteure ohne ständigen Blick in die Doku sehr unverständlich wie da dann was einzugeben ist. In 6.x hatten wir aufgrund derselben Bedenken kein anderes Templatingsystem einsetzen wollen, da nicht sicher schien welches sich am Ende durchsetzen würde und wir nicht nochmal in eine "Sackgasse" rennen wollten (wobei wir ja mit TV und DAM sehr lange gut gefahren sind). "Fluid Powered" ist scheinbar die Weiterentwicklung von "FED" - eines der vielen Frameworks die ca. zu 6.0-Zeiten aufploppten und in Konkurrenz zu u.a. GridElements standen. Übrig geblieben sind letztlich scheinbar nur diese beiden Extensions/Extension-Sammlungen, wobei ich persönlich nach einem schnellen Blick aufgrund der nach Außen hin sichtbaren Aktivität in der Entwicklung vom Bauchgefühl her eher zu "Fluid Powered" tendieren würde. Vom Templating her nimmt sich das vermutlich nicht viel wenn man sich einmal in eine Lösung eingearbeitet hat, was die Zukunft der Techniken angeht wird man sehen müssen was passiert... Das Problem ist, dass momentan glaube ich nichts eindeutig erkennbar ist und beide Lösungen bis 8 LTS schon wieder kippen könnten. Insbesondere bereitet mir die Ankündigung "Standalone Fluid" zu TYPO3 8.0 vom Dienstag etwas Sorgen. Da TV jetzt aber endgültig tot ist (in 6.2 hats ja noch problemlos funktioniert) brauchen wir _jetzt_ einen richtigen Ersatz. Custom CTypes und andere Notlösungen bringen einen für normale Webseiten aber nicht weiter; es braucht unbedingt eine Lösung mit der sich FCEs und Container-FCEs ohne großer Mengen PHP-Code templaten lassen - also "Fluid Powered" oder GridElements... Dass TYPO3 keine Lösung für FCEs bzw. flexiblere Template-Konfigurationen von Haus aus mitbringt ist - milde ausgedrückt - schade, denn das könnte vieles vereinfachen und man müsste nicht rumrätseln welche Extension denn nun die längere Zukunft vor sich haben könnte. Diese "site"-Distribution hab ich gar nicht probiert; bei uns hat aber mit der manuellen Installation von flux, fluidpages und fluidcontent aus dem TER in 7 LTS alles wichtige soweit erstmal funktioniert. Eine Beispiel-Extension war mittels der Extension "builder" schnell erstellt und ließ sich einfach für erste "Spielereien" anpassen. Schöne Ostern, Daniel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 Probleme nach Apache Update bei 1&1 Managed Server
Hi! On 05/23/2012 11:29 AM, Tobias Liegl wrote: > Auch im Install-Tool funktioniert der > GIF to GIF Test nicht (Image Processing > Scaling images > GIF to GIF). > Ist das bei dir auch so? Hab ich letzte Woche bei einem unserer Kunden (alter Puretec-Account, normaler Shared Webspace) auch feststellen müssen. GIF lesen funktioniert, GIF schreiben auch, nur GIF skalieren nicht wenn als GIF gespeichert werden soll? :/ War in dem Fall kein Problem, da wir PNG als Ausgabeformat eingestellt haben. Bei 1&1 blick ich aber eh nicht durch - bei einem Kunden läuft alles, beim nächsten kommen solche komischen Fehler, wieder einem anderen fehlt ImageMagick (und der Support gibt den Tip das per SSH auf dem Server selbst zu kompilieren...). Eigentlich sollte man meinen, dass beim Shared Webspace die Systeme bis auf die durch die Pakete gesteckten Limits identisch sind, offenbar läuft hier aber einiges wild durcheinander. Nebenbei achtet mal auch drauf, ob 1&1 bei Euch (zumindest bei Shared Webspace) ebenfalls mit einem der letzten stillen Updates das memory_limit verändert hat. phpinfo() zeigt bei einem unserer Kunden zwar 96MB oder sowas um den Dreh an, tatsächlich alloziierbar sind dann aber nur 30MB - zu wenig für T3D-Importe oder den Import der Extension-Liste. Damit ist Typo3 auf einigen Webspace-Tarifen (keine Ahnung welche, die werden ja auch gefühlt alle paar Monate neu eingeführt/umbenannt) nicht mehr sinnvoll lauffähig. Gruß, Daniel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] CUR.doNotLinkIt = 1 ohne Auswirkung unter Typo3 v4.5.19
Hi!
Wenn ich das richtig überblicke, dann legst Du einen Link im
stdWrap.cObject nochmal selbst an:
On 08/26/2012 02:11 AM, Jan Viehweger wrote:
> 1=TMENU
> 1{
[...]
> NO.stdWrap.cObject{
> 10=TEXT
> 10{
> field=title
> typolink{
Probier mal, zusätzlich zum doNotLinkIt Deinen selbstdefinierten
typolink zu verwerfen bzw. auszukommentieren, denn so wie es für mich
aussieht schachtelst Du 2 Links ineinander (einen Link vom Menü
generiert und einen zweiten von stdWrap.cObject.10).
Guckst Du Dir den Quellcode der generierten HTML-Seite direkt an oder
benutzt Du dafür Firebug bzw. den Entwicklermodus Deines Browsers?
Letzteres zeigt Dir das vom Browser korrigierte DOM und verschleiert
somit derartige Fehler (Links in Links sind nicht zulässig). In dem Fall
schau Dir nochmal direkt den Quelltext an, da könnte so eine
Schachtelung sichtbar sein.
Gruß,
Daniel
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3 bei 1&1 mittlerweile sinnvoll einsetzbar?
Hallo! Es kommt darauf an, was Du vorhast. Grundsätzlich funktioniert es schon. Wir haben derzeit zwei Kunden, die bei der Umstellung auf Typo3 bei 1&1-Shared-Hosting bleiben wollten, beide Hosting-Tarife existieren inzwischen aber nicht mehr (IMHO das ehemals größte und zweitgrößte). RealURL funktioniert bei beiden, CronJobs und SSH-Zugang waren nur im teureren der beiden Tarife möglich. Der Site Crawler funktioniert nur im teureren weil er sich aus Sicherheitsgründen nicht über das Backend starten lässt und somit einen CronJob benötigt. Möglicherweise gibt es dasselbe Problem bei DirectMail, haben wir bisher noch nicht ausprobiert. Sollen PDF-Dateien verarbeitet werden, muss man über den SSH-Zugang ein eigenes GhostScript kompilieren und per Wrapper-Script an ImageMagick anbinden; den meisten dürfte das zu kompliziert sein. Die Performance ist mäßig bis schlecht, auch das Backend hängt bei den einfachsten Operationen manchmal ziemlich lange fest. Sind die Seiten erstmal im Cache, merkt man als Webseitenbesucher zum Glück nicht mehr viel davon. Die Generierung ungecacheter Seiten dauert sonst teilweise spürbar zu lange. Die Generierung von PDF-Thumbnails läuft zwar mit unserem Workaround, braucht aber manchmal mehrere Aufrufe, bis alles ausgeneriert ist (möglicherweise eins der Limits). Die von Dir genannten Limits kommen mir für Typo3 sehr niedrig vor, evtl. gibt es damit u.a. das Problem, dass die Extension-Liste nicht importiert werden kann. Wie die Limits in den Tarifen unserer Kunden aussehen, kann ich leider im Moment nicht sagen. Da bei "Dual Perfect" scheinbar ein SSH-Zugang dabei ist, empfiehlt sich die Installation von Typo3 direkt auf dem Server. Bei unserem Kunden ohne SSH müssen wir Typo3 verzeichnisweise per FTP hochschieben, weil 1&1 sporadisch die Verbindung schließt. Meine Empfehlung wäre, zu einem anderen Shared Hoster zu gehen, der Typo3 explizit als unterstützt listet und den Ruf hat, dass dort alles vernünftig (und schnell) läuft. Sonst bliebe nur, auf Shared Hosting, zumindest in der überlasteten Form wie bei 1&1, zu verzichten. Empfehlungen kann ich leider keine nennen, da wir sonst mit dedizierten Servern arbeiten. Es gibt inzwischen sicherlich viele Hoster, die Typo3 auf der "Featureliste" anführen, mit Sicherheit weiß ich es aber (neben Mittwald natürlich) nur von Hetzner. Gruß, Daniel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 Caching, aus- und eingeloggt
Hi! Soweit ich weiß, erfolgt das Caching zumindest in 4.x grundsätzlich immer nach FE-Gruppen. Wenn Du zwei Benutzer der FE-Gruppe 1 hast, dann teilen sich diese einen Cache; ist ein dritter Benutzer Mitglied der FE-Gruppe 2, dann sieht dieser aber einen anderen Cache. Ausgeloggte Benutzer (quasi FE-Gruppe 0) teilen sich dann wieder einen weiteren Cache. Sobald man benutzerspezifische Daten unterbringt, muss das dann trotzdem in COA_INT/USER_INT verpackt werden, um vom Cache ausgenommen zu werden, aber z.B. für Menüs ist das dann nicht extra nötig. Über die Gründe kann ich nur spekulieren, vermute aber stark, daß es mit dem Rechtesystem zusammenhängt: Du kannst Inhalte ja immer nur auf FE-Gruppen, nie auf einzelne Benutzer einschränken. Damit ist es grundsätzlich ausreichend, Caches nach Gruppen statt nach Benutzern zu trennen. Du möchtest aber Caches nach Gruppen getrennt haben weil sonst z.B. ausgeloggte Benutzer u.U. Menüpunkte oder direkt Inhaltselemente von eingeloggten Benutzern sehen könnten. Die Daten doppelt zu speichern statt eine Duplizierung bei gleichen Inhalten zu vermeiden dürfte dabei der gewollten Einfachheit der Implementierung geschuldet sein, so ist das ganze dann weniger fehleranfällig. Gruß, Daniel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
