Re: [TYPO3-german] [TYPO3-core] Announcing TYPO3 CMS 7.2
On 05/05/2015 03:12 PM, Reinhard Führicht wrote: Hallo, ich habe das Problem nun gelöst. Grund für das Verhalten war, dass aus irgendwelchen Gründen einige Extensions in der PackageStates.php gefehlt haben. U.a.: t3skin, sv, saltedpasswords, rsaauth, recordlist Erst nachdem ich diese manuell wieder hinzugefügt und typo3temp/Cache geleert habe, kann ich mich nun wieder ins Backend einloggen. We had similar reports and Nicole was finally able to nail it: A bugfix was merged to master and 6.2: https://review.typo3.org/#/c/39133/ https://review.typo3.org/#/c/39147/ Regards Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] [TYPO3-core] Announcing TYPO3 CMS 7.2
Hey. On 28.04.2015 14:53, Hendrik Reimers wrote: Mein Problem hat sich erledigt, nachdem ich den Sourceforge Download nutzte. Bei den Quellen von get.typo3.org scheint es derbe Probleme zu geben. We had some issues with the packaging script that required some changes due to different 7.2 composer / library bundling for the download files. That is why the checksums changed, we uploaded the download files a second time. All should be fine now. Regards Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Extbase: Verständnisfrage zu Dependency Injection
Hey, On 05/09/2014 05:16 PM, Stefan Padberg wrote: Das verlangsamt die Entwicklung natürlich etwas...;-) Hint: Add options.clearCache.system = 1 to your users TSconfig, after BE reload, you'll get an additional clear system cache entry in BE clear-cache flash menu. This will take care of killing extbase reflection caches, too. Regards Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Installtool Login schlägt fehl bei Typo3 6.2.0
Moin. Jo, wie Philipp sagt muesste das ein Sessionproblem sein, die Loesung wuerde mich aber interessieren. Moeglicherweise koennen wir das install tool in dem Detail verbessern, das es eine Fehlermeldung ala oehm, du hast da nen Rechteproblem erzeugt. Bitte Feedback wenn du eine Loesung findest! On 05/06/2014 05:09 PM, Andreas Glöggler wrote: Leider ist immer noch das gleiche Problem beim Einloggen in das Install-Tool. Muss eigentlich openssl auf dem Apache-Server laufen? Kann es evtl. daran liegen: $TYPO3_CONF_VARS['SYS']['encryptionKey'] = '* (length: 96 characters)';? Das ist nur eine obfuscated Anzeige im Configuration Modul im Backend, das zeigt die echte Zeichenkette an der Stelle nicht an. In der LocalConfiguration.php muesste sowas drin stehen. 'encryptionKey' = 'af4863b01bbcb603501e800a81afcd01298973160281c4523bb4accb0a4d562e4f9cc9f731e19a427175e62a7bf8afba', Insofern alles tutti, das ist nicht dein Fehler. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Zurück zum 4.5 / 6.1 Feeling
Moin, On 05/05/2014 01:07 PM, Jan Kornblum wrote: Oder kann man sich selbst irgendwie einen eigenen (platzsparenderen) Skin o.ä. zusammenbauen, den man dann über alle 6.2 Instanzen drüberlegen kann? Also grundsaetzlich ist das Skinning in T3 mit 6.2 deutlich besser geworden: Alle wichtigen Core Module sind auf halbwegs sauberes html und css umgestellt, es ist also moeglich mit ein paar CSS file das BE weitgehend anzupassen (ein paar selten genutzte modules fehlen noch). Felix Kopp hat hier gute Arbeit geleistet, und auch georgify-tables hat viel gebracht. Felix hat mit ext:flat auch ne passende Extension am Start, die nochmal viel im Backend umstellt (als ich zuletzt gespielt habe war die git version deutlich weiter als der ter release). Das gibt zumindest mal ne Idee was inzwischen ohne richtig schlimme Hacks machbar ist. Stark verschachtelte Page Ansichten werden etwas heftig, da kann man sicher an den teilweise recht fetten Abstaenden vielleicht auch nochmal schrauben. Ansonsten finde ich die meisten 6.2 Changes in der Richtung gut, zB. die grossen Ueberschriften mag ich sehr, da sie das Nutzerauge deutlich besser leiten. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 6.2: Schweigsame Fehlermeldung
Moin, On 04/22/2014 05:17 PM, g4-l...@tonarchiv.ch wrote: Genau das war ja meine Schlussfolgerung aus dem NULL-Experiment. Daher lautet eben meine Frage: Warum kommt das klinik-Objekt nicht mehr an, obwohl das unter 4.6 funktioniert hat? Wie vorangehend beschrieben: Das Objekt wird ganz normal in Fluid via link.action Viewhelper übergeben. Ich habe an dem Code seit 3 Jahren (4.5) nichts geändert und er hat alle Updates überstanden. Aber bei 6.2 scheint irgend was anders zu sein. In extbase haben sich afaik 2 Details geaendert, die da reinspielen koennten. Dein eigentliches Problem ist wahrscheinlich das das eingehende Objekt nicht validiert. 1. Hat sich das Handling mit der errorAction geaendert, da habe ich die Details gerade aber nicht im Kopf. Haengt damit zusammen, das @dontvalidate und die andere Annotation nicht mehr greifen. Dh. wenn du eine Zielaction anspringen willst, deren Argumente nicht validieren, dann springt er in die errorAction, die normalerweise die Quellaction ruft, fuer die wird aber das Objekt nicht mehr gebaut (deshalb braucht man auch @dontvalidate nicht mehr). Die kaputten Objektargumente werden dann erst in Fluid wieder ueberlagert (glaube die Argumente werden irgendwo in originalRequest oder so aehnlich geparkt). 2. Werden Objekte jetzt rekursiv validiert. Wenn du also Unterobjekte dran haengen hast, und davon validiert eins nicht, dann validiert die gesamte Struktur nicht, und dann kann er die action nicht ansprechen. In der Richtung musst du mal suchen, das genaue Handling muesste dir der AbstractController zeigen von dem du ableitest. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 Update 6.2 auf 6.2.1 Backend = Fehler 403
Moin, On 04/19/2014 10:14 AM, Sebastian Schmal wrote: hab es hin bekommen. es wurde wohl durch das automatische T3 Update die symlinks falsch aufgebaut. habe jetzt noch mal alle neu gesetzt und nun geht es wieder! Kannst du da mal ein paar Details geben? Das Feature ist neu in 6.2, wir haben uns alle Muehe gegeben das gut abzusichern, es waere aber toll wenn wir da noch ein wenig Feedback kriegen in welchen Szenarien das noch klemmen kann. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Kuriositäten mit 6.2
Moin. On 04/16/2014 12:51 PM, Ralf-Rene Schröder wrote: und nur als gut gemeinter Tipp: mach dir von LocalConfiguration.php und PackageStates.php Backups... es ist sehr ärgerlich wenn die durch Schreibfehler plötzlich leer sind (keine Ahnung ob der Fehler überhaupt noch passieren kann, aber da ich es mal hatte und sehr frustriert war dieses nur als Hinweis) Tipp am Rande. Wer mit 6.2 in der PackageStates rumfummelt und es schafft die irgendwie kaputt zu kriegen, und wenn dann kein Backup da ist: Benennt die PackageStates.php in irgendwas anderes um, und ruft das Install Tool ueber typo3/install/index.php auf. Das erzeugt dann eine neue PackageStates.php, in der nur das absolute Minimum an Extensions aktiviert ist. Viel weniger als bei der Erstinstallation. Damit kommt das Backend auf jeden Fall wieder hoch und ihr koennt im Extension Manager alle Extensions aktivieren die ihr braucht. Ist am Anfang ganz lustig, ein so leeres Backend habt ihr sicher noch nie gesehen. Ist natuerlich mit Vorsicht zu geniessen da zB. der DB Compare im Install Tool jede Menge Zeug wegwerfen will wenn so wenig Extensions geladen sind. Den sollte man dann eher nicht ausfuehren. Aber immerhin kann man auf die Tour eine neue PackageStates erzeugen lassen, was als Notloesung schonmal ganz praktisch sein kann wenn man das System kaputt gespielt hat ;) Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 6.2 Extbase - Problem mit makeInstance() und Repository
Moin,
On 04/15/2014 12:43 AM, g4-l...@tonarchiv.ch wrote:
Hallo,
In meine Model Klasse benötige ich an einer Stelle ein Repository,
welches mit makeInstance() instanziiert wird:
/**
* Returns the messung
*
* @return
Tx_Extbase_Persistence_ObjectStorageTx_Hplusinfo_Domain_Model_Messung
*/
public function getMessung() {
$repository =
t3lib_div::makeInstance('Tx_Hplusinfo_Domain_Repository_MessungRepository');
return $repository-findByKlinik($this);
}
Hier kriege ich aber den Fehler:
#1: PHP Catchable Fatal Error: Argument 1 passed to
TYPO3\CMS\Extbase\Persistence\Repository::__construct() must implement
interface TYPO3\CMS\Extbase\Object\ObjectManagerInterface, none given,
Naja, Dein Konstruktur erwartet als erstes Argument eine Instanz die das
Interface ObjectManagerInterface implementiert, das hast du makeInstance
nicht mitgegeben. Dein rufender Code muesste diese Klasse instantiieren
und dann als 2. Parameter makeInstance geben: Weitere Parameter an
makeInstance werden als Konstruktorparameter der zu instantiierenden
Klasse uebergeben.
Wenn du aber ohnehin schon mit extbase Klassen hantierst, solltest du
zur Objekterzeugung nicht mit makeInstance(), sondern mit dem
Objektmanager arbeiten:
- Wenn du von einer Klasse aus instantiierst die nicht selbst mit dem
ObjectManager erzeugt wurde (zB. innerhalb einer nativen scheduler
Klasse), kannst du den ObjektManager mit makeInstance erzeugen, und
machst danach sowas wie $myFoo = $objectManager-get('theClass'). In
deinem Fall wuerde der ObjektManager sehen das du einen
Konstruktorparameter nicht uebergeben hast, ein passendes Object
instantiieren und dem Konstruktor Deiner Klasse uebergeben (das nennt
sich Konstruktor injection).
- Wenn du bereits im extbase scope bist, hast du den Objectmanager
bereits recht oft in $this-objectManager liegen (zB. in controllern),
wenn nicht kannst du entweder den ObjectManager, oder ggf. auch die
Klasse die du haben willst injekten lassen (mit @inject annotation an
einer Klassenproperty, oder mit einer inject* Methode).
Grundsaetzlich ist es ratsam extbase Klassen grundsaetzlich durch den
ObjectManager erzeugen zu lassen, und nicht mit makeInstance.
Gruesse
Christian
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 6.2 Extbase - Problem mit makeInstance() und Repository
Moin nochmal, In meine Model Klasse benötige ich an einer Stelle ein Repository, welches mit makeInstance() instanziiert wird: ah, das faellt mir erst beim zweiten lesen auf: Normalerweise solltest du das nicht machen muessen, repositories in models zu nutzen ist an sich erstmal code smell der auf komische architektur oder fehlerhafte abstraktion hinweist. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Anfängerproblem
Hey, On 04/05/2014 11:26 PM, Schröder Jörg wrote: Hallo, ich habe typo3 auf meinen Server hochgeladen und meinen Webseitennamen eingegeben mit dem Anhang: /typo3_src-4.7.17/typo3/index.php (Der Anhang /typo3 macht folgendes: Error 404 - Not found) Es kam folgende Fehlermeldung Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /homepages/12/d357153059/htdocs/typo3_src-4.7.17/typo3/index.php on line 160 Was ist der Fehler? Was soll ich tun - leider verstehe ich noch nicht viel typo3 - Latein.- Willkommen in der TYPO3 community! Der juengste Spross von TYPO3 mit der Nummer 6.2 hat eine ganze Menge getan um die Einsteigerhuerden zu verringern und Dir eine funktionierende Website unmittelbar nach der Installation zu bieten. Probiere doch mal die Neuinstallation von 6.2.0 aus, oder warte auf die 6.2.1, die in Kuerze veroeffentlicht werden wird (6.2.0 laeuft soweit, in der Website fehlen nur ein paar Bilder). Wenn du das hinkriegst hast du Support fuer mindestens drei Jahre sowie eine ordentlich vorkonfigurierte Site von der man viel lernen kann. Bei Fragen und Problemen gibt es neben Mailinglisten fuer den ambitionierten Entwickler oder Integrator auch User Groups in der Gegend, das kann beim Einstieg ungemein hilfreich sein. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Class 'TYPO3\CMS\Core\Core\Bootstrap' not found
Moin, On 04/04/2014 07:21 AM, mike me wrote: Seit kurzem erhalte ich aber eine neue Fehlermeldung - keine Ahnung wie das nun zu Stande kam Fatal error: Call to undefined method TYPO3\CMS\Core\Core\Bootstrap::redirectToInstallerIfEssentialConfigurationDoesNotExist() in public_html/WEBSEITE/typo3/index.php on line 39 Seltsam, das ist ja sogar noch frueher. Das Require auf die Klasse mit der Methode ist ja genau 2 Zeilen darueber. Hast du vielleicht einen opcode cache wie apc, xcache oder zend laufen? Versuch mal im install Tool ein Clear PHP opcode cache. Wenn das nix bringt starte deinen Webserver, bzw. deinen laufenden PHP Interpreter neu um sicher zu sein das der opcode cache neu aufgebaut werden muss. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Class 'TYPO3\CMS\Core\Core\Bootstrap' not found
Hey, On 04/02/2014 10:24 PM, mike me wrote: Fatal error: Class 'TYPO3\CMS\Core\Core\Bootstrap' not found in SERVER/WEBSEITENNAME//typo3/typo3_src-6.1.7/typo3/sysext/cms/tslib/index_ts.php on line 40 Das BE funktioniert einwandfrei. Ich habe bereits einige Foren und Hilfen durchsucht, leider ohne Erfolg. Wie an einigen Orten beschrieben, habe ich auch schon die index.php Datei ausgetauscht - die sind jedoch alle gleich. Spannend ist folgende Beobachtung: Wenn ich den Cache leere/lösche im BE funktioniert die Seite genau 1x. Sprich: ich kann die Seite laden. Danach - egal wo ich klicke, kommt wieder die Fehlermeldung. Hmm, das riecht nach einer Extension die komische Dinge in ext_tables.php, ext_localconf.php oder ext_autoload.php macht. Das wuerde ich zumindest (un)qualifiziert raten. Versuch mal ein paar der Extensions die in typo3conf/ext liegen und geladen sind zu entladen, ich schaetze das ist dann weg und du kannst das damit vielleicht auf eine einzige Erweiterung eingrenzen. Spontan waere zB. eine nicht aktuelle Version von news ein Kandidat, die fummelt in der ext_autoload.php (aus Gruenden) rum. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Class 'TYPO3\CMS\Core\Core\Bootstrap' not found
Moin. On 04/02/2014 11:24 PM, Philipp Gampe wrote: Also die index.php von 4.7 und die index.php von 6.2 sind bestimmt nicht gleich. Prüfe dies doch bitte nochmal doppelt. https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/index.php https://git.typo3.org/Packages/TYPO3.CMS.git/blob/TYPO3_4-7:/index.php Ah Philipp, stimmt, das ist auch noch denkbar, danke. @Mike: Gerne ist index.php im document root ein symlink auf typo3_src/index.php, dann hast du als Admin beim Upgrade keine Schmerzen. Wenn das nicht geht, aus irgendwelchen Gruenden, musst du dich selbst um die Kopie der Datei kuemmern wenn der Core diesen File anpasst: Beim Blick in die Version von 4.7 und die jetzige aus 6.2 (wir haben den index.php Change bereits mit 6.0 gemacht) siehst du, das die 6.0er deutlich einfacher und aufgeraeumter ist. Diese Aenderung war wichtig, da sie den Aufruf des neuen Bootstraps aus 6.0 fuer das Frontend umsetzt. Wir sind mit solchen Dingen aber vorsichtig und versuchen es zu vermeiden wenn es irgendwie geht, da es zu genau solchen Fehlerfaellen fuehren kann. @Mike: Bitte gib uns eine Rueckmeldung ob Philipp's Vermutung richtig ist, kopiere ggf. einfach mal die typo3_src/index.php in dein document root und gucke ob dein Problem dann gefixt ist. @Philipp: Wenn es an FE index.php liegt, kriege ich trotzdem gerade nicht auf den Kreis wieso das FE in non-cached laeuft und der Fehler erst bei cached auftritt. Wuerde erwarten das der Bootstrap immer auf die Nase faellt ... @Philipp: Moeglicherweise koennten wir einen Contentvergleich fuer index.php in die FolderStructure im InstallTool einbauen. zB. ist mir bekannt das einer der grossen Hoster auch keine Symlinks fuer einzelne Dateien zulaesst. Das ganze ist also kein richtig seltener Anwendungsfall. Dann muessen wir sowas basteln wie index.php sollte ein symlink sein auf typo3_src/index.php (das ist jetzt so), und dazu einen Fallback darf auch ein File sein, aber dann mit _diesem_ content. Auf die Tour koennten wir im Install Tool hinten auf Hey, deine index.php ist kaputt ... und wenn es richtig cool ist, dann vlt. sogar noch ein soll ich das mal fuer dich fixen?. File content vergleich gibt es so schon, nur das mit dem Fallback ist bisher nicht moeglich (und das fixen auch nicht, hat dann auch wieder Windows Implikationen). Was denkst du? Wenn wir das hinkriegen wuerde uns das solche Fehler abfangen, und wir waeren freier mit etwaigen weiteren Inhaltsaenderungen fuer index.php. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 6.2Beta6 im BE weiße leere Seite
Moin. On 03/15/2014 12:14 PM, Patrick Zanker wrote: Nun habe ich das Problem gelöst!!! Es hat irgendwas an den Rechten nicht gestimmt mit 644 für Dateien und 755 für Verzeichnisse funktioniert es nun. Warum auch immer. Jetzt geht es!!! Das haben wir in der beta7 entschaerft [1], dort werden die Rechte etwas relaxter gesetzt waehrend der Installation. Gruesse Christian [1] https://review.typo3.org/#/c/25416/ ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] sys_log von DB in externe Datei auslagern
die Spalte sys_log in meiner Typo3 Datenbank war ziemlich groß. Da ich nicht will, dass ich die Datenbank jedes mal leeren muss, wollte ich die Logdaten in eine externe Datei auf meinem Server schreiben lassen. Ich habe das nun soweit im Typo3 Install Tool eingerichtet - über den Befehl file,/pfad/datei.log - dass die Logtexte in eine Datei auf meinem Server geschrieben werden. Jetzt ist es jedoch so, dass Typo3 in die Datenbank und in die Textdatei loggt. Ich wollte fragen, ob es hier eine Möglichkeit gibt, das Logging für die Datenbank komplett zu entfernen, so dass nur noch in meine Datei auf dem Server geschrieben wird. nope. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3_MOD_PATH Fehler beim Speichern von Template
On 03/03/2014 09:25 PM, Sebastian Milinski wrote: Beim Speichern bekomme ich den unten angefügten Fehler. Das System ist TYPO3 4.2.6, vor Kurzem auf einen neuen Server kopiert. da wirst du hier keine vernuenftige antwort mehr kriegen. die version wird seit 5 jahren oder so nicht mehr benutzt, sehr unwahrscheinlich das dir da jmd noch sinnvolle tipps zu geben kann. gruesse christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] .htaccess = Duplicate Content
On 09/24/2013 08:36 PM, Peter Schäfer wrote: wenn ihr mit eingetragenen Domain arbeitet könnt ihr auch dort die Weiterleitung einrichten ... Dann muss php hochgefahren werden und typo3 bootstrap und db queries und all so zeug, das kostet zeit. Also lieber im Webserver abfruehstuecken, das ist fixer. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Benutzer auf https umleiten - mixed content verhindern
Moin.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
Genau, sowas sollte Serverseiting umgeschrieben werden.
Wenn die Site dann ohnehin nur noch ueber https erreichbar ist (weil
http immer umgeschrieben wird), dann kann man auch gleich noch paar
weitere Goodies setzen:
a) HSTS http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Damit erklaert man nem Client das die Site nur https bietet, der Client
merkt sich das und fragt fortan direkt https ab, nicht mehr http. In
nginx ist die noetige Einstellung:
add_header Strict-Transport-Security max-age=15768000;
b) $GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieSecure'] = 2;
Betrifft FE und BE user cookies (also die von T3 erstellt werden). Das
Setting sagt dem Browser es soll die Cookies nur noch ueber https senden.
c) $GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieHttpOnly'] = TRUE;
Browser verhindert JavaScript Zugriff auf TYPO3 session cookies. Das
sollte JS im Normalfall eh nicht tun muessen, daher sollte es problemlos
sein das zu setzen.
Gruesse
Christian
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3 6.0.5 Update EM wirft Fehler
Hey. On 05/07/2013 10:45 AM, Johannes C. Schulz - EnzephaloN IT-Solutions wrote: Hups - sorry. Habe im UpdateManager den Eintrag neue Datenbanktabellen für EM übersehen. Dachte daß das DB-Compare gereicht hätte, aber das zeigte nicht an daß der EM noch neue Datenbanktabellen braucht. Jetzt läuft der EM. Mmmh, ja. Du bist auch nicht der erste der drauf reingefallen ist. Ich werd das Thema im Team nochmal ansprechen. Wir hatten schon mehrfach drueber nachgedacht im EM controller irgendwo selbst zu checken ob die Repository Tabelle existiert und sinnvolle Daten hat und ggf. halt anzulegen und die row da reinzustopfen. Damit waere der EM nicht vom Upgrade Wizard abhaengig. Das ist codeseitig nicht elegant, aber angesichts einer besseren User Akzeptanz wahrscheinlich sinnvoll. Als Verbesserung zwischen 6.0.4 und 6.0.5 wird inzwischen zumindest ueberhaupt eine Fehlermeldung ausgegeben, vorher bist du da einfach in ein em laedt sich tot gelaufen - Das betrifft auch weitere Query Fehler beim Importieren der Daten, die lustigerweise uebrigens auch im 4.5 / 4.7er em auftreten (und dort auch verdeckt sind). Dazu kommt, auf Grund diverser Abhaengigkeiten koennen wir nicht einfach eine aussagekraeftige Exception werfen (die erklaert was zu tun ist), das hatten wir auf dem Extension Sprint kurz probiert, musste aber (erstmal) verworfen werden. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3 6.0.5 Update EM wirft Fehler
Hey, On 05/07/2013 04:48 PM, Johannes C. Schulz [EnzephaloN IT-Solutions] wrote: Warum nicht einfach das Compare im InstallTool die Sache erledigen lassen. Also auch bei der Neuinstallation sollten die Tabellen meiner Meinung nach automatisch angelegt werden - oder versteht Ihr dem EM nichtmehr als typo3-Software sondern als externe Extendion? Compare legt die Tabelle auch brav an. Aber die darf nicht leer sein, da muss eine Zeile fuer das Repository rein. Das handled Import static data im Install Tool. Sicherheitshalber hatten wir auch noch den Ugrade Wizard dazugepackt (weil Import von leuten eh selten gerufen wird), aber das reicht nicht. Da der em allerdings eh keine multiplen Repos kann (das konnte der alte em auch nicht richtig), koennte man das alles an der Stelle aber auch komplett vereinfachen und auf die Tabelle ganz verzichten. Insgesamt ist der letzte Patch an der Stelle noch nicht gesprochen ;) Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3 6.0.5 Update EM wirft Fehler
Moin. On 05/07/2013 06:17 PM, Jost Baron wrote: wie wäre es, wenn man die Multi-Repo-Funktionalität mal zum Laufen bringt? Ich könnte mir vorstellen, dass man in dem Zuge auch VCS-Repositories integriert, so dass man z.B. Extensions von Github direkt mit dem EM importieren und vor allem auch updaten könnte. Das würde die Maintainance einer Installation mit nicht-TER extensions (gridelements2 hab ich im TER z.B. noch nicht gesehen) wohl etwas vereinfachen. Ist nur ne Idee die ich neulich hatte, nicht wirklich durchdacht... Hab momentan aber auch keine Zeit mich da im Detail hinterzuhängen. Naja, mittelfristig werden wir wohl composer support haben, dann hat sich das Thema erledigt. Vorarbeiten im Core werden wohl fuer 6.2 reinkommen, auch wenn der em das dann noch nicht mit einer gui verarztet. Von daher bezweifle ich aber das aktive contributor noch sehr viel Energie in multi-ter-repo-support stecken werden. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Fehlermeldung in neuer 6.0.4 Installation
On 03/21/2013 10:55 AM, Heike Herzog-Kuhnke wrote: Core: Error handler (BE): PHP Warning: Illegal string offset 'uid' in [...]/typo3_src-6.0.4/typo3/sysext/backend/Classes/Utility/BackendUtility.php line 2956 Den hat Helmut vor ein paar Tagen in allen stabilen Versionen gefixt, siehe https://review.typo3.org/#/c/18978/ Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Fehlermeldung in neuer 6.0.4 Installation
On 03/21/2013 12:21 PM, Heike Herzog-Kuhnke wrote: Core: Error handler (BE): PHP Warning: Creating default object from empty value in [...]/typo3/typo3_src-4.5.25/typo3/sysext/fluid/Classes/ViewHelpers/Format/HtmlViewHelper.php line 116 Der ist schon laenger in 6.1 / 6.0 gefixt, habe den Fix vor ein paar Tagen auch in 4.7 und 4.5 reingenommen: https://review.typo3.org/#/c/19001/ https://review.typo3.org/#/c/19000/ Core: Error handler (BE): PHP Warning: filemtime(): stat failed for [...]/typo3/typo3temp/extensions.xml.gz in /homepages/35/d448188980/htdocs/typo3/typo3_src-4.5.25/typo3/sysext/em/classes/index.php line 2466 Den hab ich bisher nicht gesehen. Sind die wichtig, was muss ich ändern. Fehlen noch Rechte? Also das sind alles Warnings von PHP 5.4, der ist bei unsauberem Code etwas kleinlicher. Ausser die Warning zu werfen richten die im Normalfall aber keinen Schaden an. Der Core ist noch nicht 100% sauber fuer diese PHP Version. Wir fixen zwar immer wieder ein paar Fehler (die meisten lassen sich recht simpel fixen), es gibt aber noch welche. Sinnvoll waeren issues in forge fuer die einzelnen Stellen, moeglichst mit backtrace und/oder einer kurzen Beschreibung wie es reproduzierbar ist. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Fehlermeldung in neuer 6.0.4 Installation
On 03/21/2013 04:06 PM, Heike Herzog-Kuhnke wrote: Und wie ich gerade feststelle, ist die 4.5.26 noch nicht freigegeben und in den normalen Downloads drin. Na, dann schaue ich morgen noch einmal. Die angesprochenen Warnings sind momentan noch nur in den Entwicklversionen behoben, die erst spaeter als neue minor Releases (zB. als 4.5.26) veroeffentlicht werden. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Error bei Update 4.6.17 4.7.10
On 03/08/2013 09:59 AM, LUCOMP mediale kommunikation internetDesign Bernhard Ludwig wrote: nach dem Update von 4.6.17 auf 4.7.10 erhalte ich im BE bei Aufruf eines jeden Links folgenden Error: Class 'Tx_Extbase_Utility_Extension' not found in xxx/typo3/typo3conf/temp_CACHED_ps049d_ext_tables.php on line 891 Wie kann ich den Fehler beseitigen? lade die extension extbase. gruesse christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] jumpurl Fehler nach Update auf 4.7.9
On 03/07/2013 11:32 AM, Ralph Brugger wrote:
direct_mail/res/scripts/class.tx_directmail_checkjumpurl.php
function checkDataSubmission ($feObj) {
..
// finally set the jumpURL to the TSFE object
$feObj-jumpurl = $jumpurl;
+# set juHash as done for external_url in core:
http://forge.typo3.org/issues/46071
+t3lib_div::_GETset(t3lib_div::hmac($jumpurl, 'jumpurl'),
'juHash');
bad idea! This re-introduces the security hole.
The logic is ok for the 'external url' handling in TSFE because the
target link does NOT come from outside, but is fetched from DB in the
same process.
If you use this 'hack' in the direct_mail handling, where the target
link is provided by external _GET, you re-introduce the security hole
that was fixed by the security patch in the first place.
Regards
Christian
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gibt es einen 4.5-latest-stable download link
On 03/07/2013 03:18 PM, chris Wolff wrote: Hi Liebe Typo3 Liste, für ein update/download script hätte ich es gerne einen url mit dem ich mir immer das aktuellste 4.5 typo3 ziehen kann. http://get.typo3.org/ ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] +1 / -1 Thread
On 01/27/2013 11:44 PM, Ingo Renner wrote: http://www.youtube.com/watch?feature=fvwpNR=1v=7dM0TDWA-iY Aww. +1 :) Thx Ingo. Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] +1 / -1 Thread
Moin. Disclaimer: Eigene Meinung, ich spreche hier nicht offiziell als core member. On 01/25/2013 07:24 PM, Jan Kornblum wrote: Was ich nicht verstehe, warum dann überall davon geredet wird, dass pibase ab 6.0 bzw. 6.x nicht mehr funktioniert und alle Extensions neu geschrieben werden müssen. Wo liegt hier (mein) Mißverständnis bzw. das der anderen? Wer sagt das? pibase wird nicht gedropt soweit wir in die Zukunft sehen koennen. Das daraus resultierende Codemuesli einer nicht trivialen Extension ist zwar schlimm, der Core waere aber mindestens zum jetzigen Zeitpunkt ganz schoen bescheuert, wenn er sich mutwillig 90% aller TER Extensions kaputt machen wuerde. Die pibase Basisklasse heisst vielleicht zwar jetzt FrontendController statt pibase, der alte Name funktioniert aber weiter. Es gibt genau zwei Stellen die in 6.0 mutwillig brechen: * Wie ueblich sind diverse ganz furchtbar vergammelte Core-Methoden geloescht worden, die meisten davon sind seit 4.5 oder laenger als veraltet markiert, der kleinere Rest seit 4.6. * Alle XCLASS'es brechen, die Anmeldung hat sich geandert. Waehrend der 6.0 Entwicklung gab es zwar zwischendurch eine Kompatibilitaetsschicht, die war aber so zielunsicher und hat soviel Performance gefressen, das die wieder gedropt wurde. Es ist trotzdem moeglich, eine Extension mit Xclasses parallel fuer 4.5 und 6.0 kompatibel zu machen. Da Xclasses sowieso schon immer einfach mal so auch bei Minor Releases brechen koennen, und das auch schon immer offiziell genau so kommuniziert wurde, wurde die fehlende Kompatibilitaetsschicht an genau dieser Stelle in Kauf genommen. Ansonsten muessen Extensionentwickler gelegentlich mal die Kompatibilitaet Ihrer Extensions checken, den deprecation Log lesen und Wartungsarbeiten durchfuehren. Der Core *muss* das gelegentlich forcieren, damit er sich ueberhaupt weiterentwickeln kann. Eine nicht gewartete Extension mit der letzten Version aus 2009 ist dann halt im Zweifel kaputt ... aber wer will eine Extension nutzen deren Entwickler keine Fehler mehr loesen? Ich habe diese Woche in einer Extension, die ich 1 Jahr nicht angefasst habe, 4.3 und 4.4 Support gedropt und 6.0 Funktionalitaet verifiziert. In keiner der core Versionen von 4.5 bis 6.0 wirft diese Extension deprecation Fehler. Inklusive Release hat mich das effektiv zwei Stunden gekostet. Der 6.0er Core bringt die mit weitem Abstand groessten Codeaenderungen in der Geschichte des Projektes. Die Umstellung auf Namespaces ist ein Quantensprung in Hinsicht auf Lesbarkeit und logischen Aufbau und vereinfacht den Einstieg in das Projekt erheblich. Die Kompatibilitaetsschicht ist so gut, das sogar die seit Jahren praktisch nicht gewartete und ausgesprochen umfangreiche Extension tt_news noch relativ gut funktioniert. Als Alternative hat Georg es locker und nebenbei hingekriegt, seine news Extension kompatibel fuer 4.5 bis 6.0 zu machen. Sein Kompatibilaetscode ist in einer Helferklasse gekapselt, die sich zum Rueberkopieren in eigene Extensions geradezu anbiedert. templavoila hat ein paar kleinere Anpassungen im Backend gebraucht, weil die Extension mit seinem 8 Jahre alten Code im Backend Modul teilweise furchtbaren Mist baut, den heute kein vernuenftiger Mensch mehr so zusammentackern wuerde. Zwar wird der Core die nicht namespaced Klassen irgendwann loeschen (hoffentlich fuer 6.2, weil die LTS Maintenance sonst ernsthaft dauerhaft keinen Spass machen wird), es gibt aber bereits jetzt diverse Ansaetze, auch dann noch 10 Jahre alten Extensioncode zu unterstuetzen. Insgesamt sehe ich die Agenturaufgabe alte Instanzen zu warten recht entspannt. Ich schaetze mal grob, bei uns ist der Aufwand fuer ein major core ugrade ca. um den Faktor 40 kleiner als der initiale Aufwand fuer den Launch eines Projektes. Kunden, denen man das nach 3 Jahren fuer den Sprung von einer LTS auf die Naechste nicht als Notwendigkeit verkaufen kann, will man schlicht nicht haben, weil die im Umkehrschluss vermutlich auch sonst nicht alle Tassen im Schrank haben. Ich durfte kuerzlich von 3.7 auf 4.5 updaten (nein, keine Instanz von uns). Eine nicht ganz triviale Instanz, aber auch nicht wirklich gross. Mit subversion einrichten, Upgrade, finalem Switch auf utf-8 in der Datenbank, Testing, Cleanup, Dokumentation, Controlling, Kommunikation und Rollout war das nach nem Personentag gelaufen. An dem Ding war seit 6 Jahren oder so nichts im Code passiert. Hat einer von Euch mal versucht ein Bestandsprojekt von drupal 5 auf 7 zu ziehen? Oder ein Magento-Update nach 4 Jahren? Im Fazit kann sich TYPO3 definitiv nicht vorwerfen lassen Kompatibilitaet zu vernaechlaessigen. Im Gegenteil macht sich der Core soviele Gedanken um Rueckwaertskompatibilitaet, das dabei teilweise Agilitaet und Weiterentwicklung auf der Strecke bleiben. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org
Re: [TYPO3-german] +1 / -1 Thread
On 01/26/2013 09:11 AM, Thomas Skierlo wrote: Ich werde jetzt ein veredeltes „div“ schreiben. div_2013_ts_007 Have fun Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] +1 / -1 Thread
On 01/26/2013 08:34 PM, Peter Linzenkirchner wrote: Ironie Mir gefällt TV auch sehr gut, möchte aber trotzdem nicht die anderen Attribute auf mich beziehen. FCEs besser finden als Grid Elements wird langsam zu einer Art Outing ... /Ironie TV hat schlicht ein paar inhaerente, nicht wegdiskutierbare Probleme. Dabei lassen sich genau 5 verschiedene Punkte festmachen, die TYPO3 Instanzen von groesseren Projekte zu einer nicht deploybaren Plage machen, wenn man als Agentur nicht bereits ernsthaft zuviel Zeit draufgeworfen hat um das (nicht) zu loesen: 1: XML in der Datenbank! Da TYPO3 leider keinen coolen uuid support hat, sind sinnvolle db deployments zwischen dev-staging-implementation-live systemen nicht machbar. 2: XML in der Datenbank! String parsing von db feldern waehrend einer Livestellung ohne Downtime um neue Felder einzufuegen machen keinen Spass. 3: XML in der Datenbank! Multilanguage Sites mit neuen Settings im TV TO/DS Muesli machen echt gar keinen Spass bei der Livestellung. 4: XML in der Datenbank! Einzelne Inhaltselemente im Frontend durch ein Plugin zu rendern ist so hirnerweichend, knochenmarkerzitternd, abgrundtief furchtbar, dass sogar hartgesottene TV-Verfechter vor dieser trivialen non-TV Anwendung zurueckschrecken. 5: XML in der Datenbank! Freunde des Frontends haben praezise, exakt, genau null Moeglichkeiten, uebergreifende Dinge in Inhaltselementen per TypoScript zu loesen. Bei Flexforms kann man einen Teil der obigen 5 verschiedenen Probleme noch gluecklicherweise bis zu einem gewissen Grad umgehen: Wenn Beispielsweise ein Entwickler, statt ein neues extbase Plugin mit controller-action Kombination anzumelden, das action-drop-down im Flexform um eine neue Action erweitert, und man deshalb beim Deployment alle bestehenden Inhaltselemente dieses Plugins manuell klicken oder automatisch umparsen muss ... also dann kann man im Zweifel dem Entwickler immerhin die Hande abhacken (painful punishment). Diese Alternative ergibt sich auf Grund des alternativlosen TV XML in der Datenbank leider nicht. Ansonsten kann TV kann fuer schnukelige kleine Projekte durch nette und vergleichweise einfach zu erfassende Funktionalitaet und Struktur bei redaktionellen Arbeiten auch die richtige Loesung sein. Mit Kaetzchen. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] PHP-Fehler seit Umstellung auf 4.7
On 10/31/2012 01:42 AM, Hugo wrote: Core: Error handler (BE): PHP Warning: Illegal string offset 'uid' in .../typo3/sysext/beuser/class.tx_beuser_switchbackuser.php line 31 Das ist der Fehler in class.tx_beuser_switchbackuser.php http://forge.typo3.org/issues/37578 Fein. Der ist jetzt gefixt in 4.5 bis 6.0, ist dann in den naechsten bugfix releases dabei. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] PHP-Fehler seit Umstellung auf 4.7
Hey, On 10/28/2012 11:44 AM, Hugo wrote: Core: Error handler (FE): PHP Warning: Illegal string offset 'minH' in .../t3lib/class.t3lib_stdgraphic.php line 2435 Core: Error handler (FE): PHP Warning: Illegal string offset 'minW' in .../t3lib/class.t3lib_stdgraphic.php line 2429 Core: Error handler (FE): PHP Warning: Illegal string offset 'maxH' in .../t3lib/class.t3lib_stdgraphic.php line 2371 Core: Error handler (FE): PHP Warning: Illegal string offset 'maxW' in .../t3lib/class.t3lib_stdgraphic.php line 2358 Core: Error handler (FE): PHP Warning: Illegal string offset 'noScale' in .../t3lib/class.t3lib_stdgraphic.php line 2158 Pending in review system: https://review.typo3.org/#/c/12543/ Core: Error handler (BE): PHP Warning: Illegal string offset 'uid' in .../t3lib/class.t3lib_befunc.php line 3095 Core: Error handler (BE): PHP Warning: Illegal string offset 'uid' in .../typo3/sysext/beuser/class.tx_beuser_switchbackuser.php line 31 Core: Error handler (BE): PHP Warning: Creating default object from empty value in .../typo3/sysext/fluid/Classes/ViewHelpers/Be/AbstractBackendViewHelper.php line 38 Currently unknown to me. Regards Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] [TYPO3-core] Announcing TYPO3 6.0 beta1
Repost to newsgroups, mail user get the mail twice, sorry about that. Dear TYPO3 Community, The TYPO3 Core Development Team just released a first beta version of TYPO3 6.0 TYPO3 version 6.0 beta1 is now ready for you to download. The packages can be downloaded here: http://typo3.org/download/ For details about the release, please see: http://typo3.org/news/article/release-of-typo3-version-60-beta1/ This is the first beta version we release for 6.0. MD5 checksums: 43fa3127b0e30c1d1c198a04cc034343 blankpackage-6.0.0beta1.tar.gz 39dfa51037ddbf34b49ce28d59ae399f blankpackage-6.0.0beta1.zip 3db4713753cde5bac18ea63522a22121 dummy-6.0.0beta1.tar.gz 11164b62ad99e2027d076ca34c1814c0 dummy-6.0.0beta1.zip 345aa5b1d91dadcc989cbef33ab86788 governmentpackage-6.0.0beta1.tar.gz 76e33bceef25a2fbf6fa70d4e5d25084 governmentpackage-6.0.0beta1.zip d534423d51ad2495313e146de992514b introductionpackage-6.0.0beta1.tar.gz 37a98772e1e95390acc73c41c63cfc8e introductionpackage-6.0.0beta1.zip 86db9b0f5c0844b90e118d1437cbf35c typo3_src+dummy-6.0.0beta1.zip 7fcdaa9c9fa1599e693f26cbb014c6ab typo3_src-6.0.0beta1.tar.gz 6edb634531e0e07cb9b460125475a95d typo3_src-6.0.0beta1.zip Kind regards, Christian -- Christian Kuhn Release Manager TYPO3 6.0 TYPO3 inspiring people to share! Get involved: typo3.org ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Announcing TYPO3 6.0 beta1
Dear TYPO3 Community, The TYPO3 Core Development Team just released a first beta version of TYPO3 6.0 TYPO3 version 6.0 beta1 is now ready for you to download. The packages can be downloaded here: http://typo3.org/download/ For details about the release, please see: http://typo3.org/news/article/release-of-typo3-version-60-beta1/ This is the first beta version we will release for 6.0. MD5 checksums: 43fa3127b0e30c1d1c198a04cc034343 blankpackage-6.0.0beta1.tar.gz 39dfa51037ddbf34b49ce28d59ae399f blankpackage-6.0.0beta1.zip 3db4713753cde5bac18ea63522a22121 dummy-6.0.0beta1.tar.gz 11164b62ad99e2027d076ca34c1814c0 dummy-6.0.0beta1.zip 345aa5b1d91dadcc989cbef33ab86788 governmentpackage-6.0.0beta1.tar.gz 76e33bceef25a2fbf6fa70d4e5d25084 governmentpackage-6.0.0beta1.zip d534423d51ad2495313e146de992514b introductionpackage-6.0.0beta1.tar.gz 37a98772e1e95390acc73c41c63cfc8e introductionpackage-6.0.0beta1.zip 86db9b0f5c0844b90e118d1437cbf35c typo3_src+dummy-6.0.0beta1.zip 7fcdaa9c9fa1599e693f26cbb014c6ab typo3_src-6.0.0beta1.tar.gz 6edb634531e0e07cb9b460125475a95d typo3_src-6.0.0beta1.zip Kind regards, Christian -- Christian Kuhn Release Manager TYPO3 6.0 TYPO3 Core Developer TYPO3 inspiring people to share! Get involved: typo3.org ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Log-Zeit um 2 Stunden hinten
Hey, On 06/12/2012 02:44 AM, Thomas Thasmo Deinhamer wrote: die Log-Zeit im BE-Log ist um 2 Stunden hinten. Welche core version? Ich glaube das belog modul in git master (upcoming 6.0) hat da ne Macke in der Zeitausgabe, ich habe aber noch nicht eingegrenzt wo genau das passiert. Wenns in =4.7 passiert isses vermutlich ein Server setup issue. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Log-Zeit um 2 Stunden hinten
Hey, On 06/12/2012 06:27 PM, Thomas Thasmo Deinhamer wrote: Ja, meine belog in TYPO3 6.0.0-dev. Ja, das ist 'known' (zumindest bei mir), glaube es gibt noch kein forge issue dazu. Hab da schonmal oberflaechlich dran gesucht, konnte das aber in extbase nicht sauber eingrenzen ... Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] SaltedPasswords und der Scheduler
Hey, On 02/22/2012 12:43 AM, Philipp Gampe wrote: Wir haben hier ein ähnliches Setup, zusätzlich werden unsere User noch über LDAP in die BE Usertabelle gespült. Dies bedingt, dass dort ein Passwort gesetzt wird, welches nachträglich umgewandelt werden muss. Als Autor des Tasks melde ich mich auch mal ;) Freut mich, das der Task inzwischen von vielen Leuten eingesetzt wird! In dem Teil steckt etwa ein guter Manntag (Marcus Krause und ich), und unsere oberste Prio lag darin, den Task so wasserdicht zu machen, das der unter keinen Umstaenden irgendwelche Passwoerter kaputt macht. Das hat glaub ich auch gut hingehauen, wir haben den recht gut getestet und Bugs in Richtung 'Hilfe, die Pw's meiner 10k fe-user sind Schrott' hatten wir bisher nicht :) Habe jetzt 3 Sachen in dem Thread aufgelesen: 1) Anzahl der Rows, die pro Run gewandelt werden, per additional Field konfbar machen. 2) Ob sich der Task abschalten darf, wenn er fertig ist, oder von vorn anfaengt 3) Loecher im auto-increment der db beruecksichtigen Alle 3 sind Features, die bis zum 28.2. wasserdicht sein muessen um noch in 4.7 rein zu koennen. Fuer Teile gibt es ja schon Patches, ich werde versuchen zu reviewen, habe aber wenig Zeit und kann nichts versprechen. 2) und 3) haengen zusammen und muessen genau durchgesehen werden, das die keinen Mist bauen: Hier kann man leicht Endlosschleifen kriegen, Rows ueberspringen oder mehrfach abarbeiten. Im Zweifel faellt das dann erst spaet auf, und dann ist das Geschrei gross. Unit Tests sind also angebracht. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Geplante Tasks im Schedular immer verspätet
Hey, On 10/04/2011 03:43 PM, Bernd Wilke wrote: das @daily habe ich im Internet gefunden. hm. '@daily' ist mir zwar noch nicht begegnet, aber kleiner Hinweis: 24*60*60 = 86400 Seit 4.5: @daily = @midnight = 0 0 * * * Die @ Keywords sind ein Sonderfeature fuer Schreibfaule aus dem normalen Unix cron. Weiterhin gibt es: @yearly = @annually = 0 0 1 1 * @monthly = 0 0 1 * * @weekly = 0 0 * * 0 @hourly = 0 * * * * Weitere Beispiele fuer lustige cron command Syntax findet man uebrigens in den Tests in typo3/sysext/scheduler/tests/class.tx_scheduler_croncmd_normalizeTest.php Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 Update auf 4.5.4 Steigerung des Intern Trafik, dramatisch -- hilfe Hilf
Hey, On 08/28/2011 10:35 PM, Pedro Julio wrote: Das Caching von Typo3 ist aktiviert, ich habe keine Extension gefunden die das caching löscht. Ich habe das Caching geändert, damit der Datenbank-Server ein wenig entlasten wird (mit dem cachingframework). $TYPO3_CONF_VARS['SYS']['useCachingFramework'] = '1' ... Bitte gleiche Deine Konfiguration mit der offiziellen Doku unter http://wiki.typo3.org/Caching_framework ab. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3-Server überlastet
Hey, On 08/15/2011 07:49 AM, Pedro Julio wrote: SELECT tx_dam.uid, tx_dam.pid, tx_dam.title, tx_dam.media_type, ... Die wird vermutlich schwer zu optimieren sein ... INSERT INTO tt_news_cache (identifier,content,crdate,tags,lifetime) ... Das ist caching framework fuer tt_news ... bitte mal gucken, ob die Tabelle als InnoDb laeuft (sollte), ggf. einschalten und mysql innodb settings optimieren (wichtig ist besonders innodb_buffer_pool_size: Die Stelle ich oft auf die Haelfte des verfuegbaren RAM, oder so). INSERT INTO tx_realurl_urldecodecache ... Ja, die werden langsam wenn die Tabellen gross werden. Wir schalten bei uns oft realurldecode und realurlencode caches ab weil der Lookup in der Tabelle schnell laenger dauert als das neu zu berechnen. Dafuer gibts nen realurl setting. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 Update einspielen... wie macht ihr's?
Hey, On 07/27/2011 02:16 PM, Philip Hahn wrote: Bei mir läuft es so, dass ich ein SVN-Repo habe, wo alle von mir benötigten T3-Sourcen und T3-Extensions drin sind. Diese werden immer in ihrer neuesten Version mit einem SVN-Tag versehen und in die einzelnen Projekte mit svn:externals eingebunden. Das hat den Vorteil, dass im eigentlichen Projekt-SVN nur die wirklich zu programmierenden Extensions landen und nicht jedes Projekt-SVN mit den selben Sachen vollgemüllt wird. Kommt nun eine neue Version, wird diese ins SVN gespielt und der Tag mit der neuen Version aktualisiert. Dann geht's per SSH auf die Server und mit svn up zieht sie das Projekt die aktuellen Sourcen. Cache leeren und *zack* ist das Ganze live. wir machen das aehnlich. Wir haben pro Projekt ein Repository fuer typo3conf/ext, und deployen auch den Core darin. Per Definition liegt aller Code (Core, Extensions, localconf, .htaccess, Templates, Css co.) innerhalb von typo3conf/ext (nichts in fileadmin), und wir haben auch noch eine branches / trunk Struktur um dev und live mit Releases auseinander halten zu koennen. Es gibt noch ein spezielles Repository fuer uebergreifende Sachen wie Core + einige Extensions, das wir ueber ein paar einfache Skripte in sync mit dem jeweiligen Projekt halten koennen. Auf die Tour haben wir in den Projekten alle Freiheiten (und keine Projektuebergreifenden Seiteneffekte), koennen Releases machen und Dinge ueber Hotfixes zuegig Live bringen, und trotzdem in Dev oder ggf. auch Staging entwickeln. Tatsaechlich hat wohl jede groessere Agentur eine eigene Logik dazu und alle machen das subtil anders, die allgemeinen Anforderungen loesen aber hoffentlich inzwischen alle: Volle Code-Kontrolle, einfache Releasemoeglichkeit, schnelle Hotfixes, Trennung von redaktionellen Daten, definierte Ablaeufe, einfache Projektuebergabe an Kollegen. Wahrscheinlich werde ich auf dem TYPO3 Barcamp in Hamburg (#t3chh11) naechste Woche mal ne kleine Session dazu machen, diese Wie deployt Ihr denn? Fragen tauchen wirklich ziemlich oft auf. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] realurl % enableCHashCache
Hey, On 07/15/2011 02:46 PM, Andreas Neumann wrote: ich bin momentan ein bisschen betriebsblind: Habe irgendeine Chance den Wert von $this-extConf['init']['enableCHashCache'] aus einem +ext-Template heraus zu beeinflussen (und nicht in der localconf.php) Ich glaube nein. Und ich waere auch ziemlich sauer wenn mir eine extension an der realurl config rumpfuscht. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Scheduler und Cache bestimmer Seiten löschen
On 07/07/2011 07:33 PM, Stephan Bauer wrote: ich habe mir ein Import-Script erstellt, das jetzt mit dem Scheduler aufgerufen wird. Was ich noch nicht gefunden habe, ist die Möglichkeit den Cache einzelner Seiten zu löschen, also etwas wie TCEMAIN.clearCacheCmd Kann mir vielleicht jemand einen Hinweis geben? EXT:enetcache (TER) bringt einen scheduler und einen cli Task mit dem man gezielt page Caches von Seiten loeschen kann, wenn das caching framework eingeschaltet ist. Hintergrund: Mit caching framework bekommt jeder Seitencache den Tag PageId_4711 (4711 ist die ID der Seite), man kann also sehr leicht gezielt Caches einzelner Seiten invalidieren. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] multiplyDBfieldSize für Chinesisch,Finnisch,Spanisch nötig?
Hey, On 03/31/2011 10:09 AM, Markus Kobligk wrote: Finnisch und Spanisch sollte ja kein Problem sein, aber was ist mit Chinesisch? Ist es für Chinesisch(evtl. auch für Spanisch/Finnisch) notwendig die Option multiplyDBfieldSize im Install-Toll auf 2 zu erhöhen? Nein. multiplyDBFieldSize ist obsolet, erzeugt Fehler und sollte auf keinen Fall mehr eingesetzt werden. Der TYPO3 Kern ist multibyte sicher und kann per Default auch mit Chinesisch umgehen. Der letzte mir bekannte Bug in der Ecke war #12230, da stimmte die TS Funktion crop nicht ganz. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Medien bei Text mit Bild, keine Datei-Kopie verwenden
On 02/19/2011 05:31 PM, Tom Lehmann wrote: Suche grad nach einer Moeglichkeit, wie ich beim CE Text mit Bild ein Bild einbinde, dass ich direkt referenziere, es soll also keine Kopie angelegt werden. Soweit ich mal gelesen habe, geht sowas aber nur im RTE als normales Bild, oder eben ein plain-HTML. [TYPO3 v4.4.4] TCA: internal_type = 'file_reference', ist in der doc_core_api dokumentiert. Ist irgendwann in den core gekommen, bin nicht mehr sicher wann. Fuer Bestandsfelder muesstest Du Dir irgendwas basteln um Bestandsdaten zu pruefen und ggf. zu fixen. Insgesamt ist das oft keine gute Idee: Urspruenglich wurde die Kopie nach uploads/ erfunden um kaputte Inhaltselemente im FE zu verhindern, wenn ein User in fileadmin/ Dateien loescht. file_reference ist dazu gedacht eine Referenz nutzen zu koennen wenn viele grosse Dateien gehandelt werden (zB. Videos). Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Download der letzten Trunk-Version
On 02/17/2011 02:00 PM, Andreas Kiessling wrote: Alternative sind irgendwelche Klicki-Bunti GUI SVN Clients wie tortoise. ich muss hier aber einwerfen, dass zumindest unter Windows der Shell Client und Tortoise ab und zu mal rumzicken und ich oft mehrere Anläufe zum Auschecken brauche. Ich loese Dinge auf der Shell. Volle Kontrolle und ich verschwende keine Zeit mit sinnlosem Muell. Jeder Griff zur Maus ist Zeitverlust. Mit Onkel Win habe ich keine Erfahrung. Daher hab ich bewusst ungestimmt nach dem Motto formuliert: Sollte aus unerfindlichen Gruenden jemand was Grafisches haben muessen, dann hab ich mal gehoert, das angeblich XY manchmal funktioniert ;) BTW: Vielleicht findet Ihr das komisch, aber ich liebe noch immer vim. Ich steige nur auf IDE's um, wenn ich in den Genuss komme mal ein aufwaendigeres Modul coden zu duerfen. Ich erhalte dann zwar ein paar Annehmlichkeiten, aber die Editoren stinken alle (egal ob eclipse, phpstorm oder sostwas). Im normalen Wahnsinn (Tagesarbeit) huepfe ich munter mit vi durch Projekte und Server und loese Probleme ... und ich bin uebel schnell dabei, die Effektivitaet von vim in Kombi mit svn und diversen anderen Kommandos auf der Shell erreicht schlicht keine IDE. Learning ist uebrigens gar nicht so schwierig: Die wichtigsten vim Kommandos passen auf eine Kaffeetasse ;) Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Gigantischer Cache unter 4.5
Hey. On 02/07/2011 09:57 PM, J. Schaller wrote: Mir fallen fast die Augen aus dem Kopf, als ich sehe, daß die Tabelle cache_pages 1.3 GB (sic!) groß ist! Das geht doch noch ;) Ich kenne Installation die Faktor 10 haben ... Unter vorherigen Versionen war die Größe der GESAMTEN db mit gecachten Seiten nie größer als 200MB, mit leerem Cache 93MB. Da kann doch irgendwas nicht stimmen... hat jemand ähnliches bei sich beobachtet? Warum Deine Caches ploetzlich so gross werden kann ich Dir nicht sagen, muesstest Du selbst mal debuggen, konzeptionell hat sich im Core an der Stelle nicht viel veraendert. Habe dann versucht, den Cache per Knopfdruck zu löschen, ging aber nicht. Das Symbol war am Kreiseln, aber wahrscheinlich ist das Script per timeout ausgelaufen, da der Cache zu groß war. Es half nur noch die Cache-Tabellen zu leeren (truncate). Sowohl mit, also auch ohne aktiviertes caching framework wird bei Klick auf 'Clear all cache' ein truncate auf den core cache Tabellen durchgefuehrt. Allerdings ist es meines Wissens in realurl noch immer so, dass dort ein delete * gemacht wird fuer die beiden tx_realurl decodecache und encodecache Tabellen ... und die werden auf diese Art geloescht in 'clear all cache' wenn realurl aktiviert ist ... Waere mal ein Ticket wert in realurl, damit das gefixt wird fuer 4.4 und hoeher. Das koennte dein Ausloeser fuer lange Loeschzeiten sein. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Gigantischer Cache unter 4.5
Hey. On 02/08/2011 05:15 AM, Michael wrote: nachdem ich Typo3 4.5 am Tag seines Erscheinens aufgespielt hatte, [...] daß die Tabelle cache_pages 1.3 GB (sic!) groß ist! [...] - Also deaktiviertes (das ist noch die Defaulteinstellung) caching framework, mit aktiviertem cf laufen die Daten nach cachingframework_cache_pages und co. BTW: Wenn Du nicht verhindern kannst das die Tabelle so gross wird, hilft es eventuell (!) das caching framework einzuschalten, und fuer den pages Cache zusaetzlich die Datenkompression zu aktivieren. Das verkleinert die Datentabelle drastisch. Mehr Details unter [1]. hmmm... keine Ahnung, ob das related ist, aber seit 4.5.0 gibt's einen scheduler task Caching Framework Garbage Collection. Der garbage collection Task ist nur sinnvoll wenn das caching framework eingeschaltet ist. Ich kann mir allerdings nicht vorstellen, dass man den task zwangsweise einrichten muss, um die DB tabellen nicht in's Unendliche wachsen zu lassen. Mit aktiviertem cf ist der Task fuer das db Backend _sehr_ sinnvoll und sollte ausgefuehrt werden! In diesem Zusammenhang wuerde mich interessieren, was der Garbage Collector genau tut, wann es Sinn macht, den task zu aktivieren und ob das vielleicht irgendwas mit J.'s Problem zu tun hat? :-) Der Task ist ueberfluessig wenn das cf _nicht_ eingeschaltet ist wie bei J. der Fall. Mit eingeschaltetem cf loescht er abgelaufene Eintraege aus den Tabellen. Mit dem alten Caching funktioniert die garbage collection noch automatisch: Bei einem Zugriff auf das Frontend werden mit einer Wahrscheinlichkeit von 1/100 abgelaufene Eintraege geloescht. Dieses Vorgehen ist aber aus unterschiedlichen Gruenden haesslich und wurde daher im neuen Caching mit dem Task geloest, um Unabhaengig von FE Zugriffen gezielt Muell wegraeumen zu koennen. Bei aktiviertem cf ist meine Empfehlung den Task einmal naechtens auszufuehren wenn der Server sonst nicht viel zu tun hat. Bin ausserdem ueber bug #15306 gestolpert: http://bugs.typo3.org/view.php?id=15306 Mit diesem Ticket wurde der garbage collection Task in 4.5 integriert. Gruesse Christian [1] http://wiki.typo3.org/Caching_framework ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Konstanten werden nicht übernommen/funktionieren nicht!
On 01/13/2011 04:06 PM, Ecker Dominik wrote: Ich habe das große problem, dass wenn ich Änderungen in den Constants vornehme, diese nicht übernommen werden. Ganz egal was bzw. mit welcher extension ich etwas mache, es bleiben immer die Default-Werte stehen. TS-Setup funktioniert ganz normal, das Problem besteht nur bei den Constants. Wenn ich z.B. die constants.txt von tt_news direkt am Server bearbeite werden diese Änderungen übernommen, in typo3 selbst geht garnichts! Kennt jemand eine Lösung für mein Problem? Bitte helft mir! Ein klassischer Fehler waere: Falsche Ladereihenfolge. Wenn zB. das tt_news static template erst _nach_ deinem Template mit den Konstanten geladen wird, ueberschreibt es Deine eigenen Konstanten wieder. Hilfreich ist ein Blick in den Template Analyzer, der fuehrt alle Templates auf, die auf einer Seite greifen. Geladen wird von oben nach unten, dh. ein weiter unten stehendes Template kann Dinge aus darueber aufgefuehrten Templates ueberschreiben, nicht umgekehrt. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] t3lib_iconWorks::getSpriteIconForRecord() must be an array, null given
Hey, On 12/29/2010 01:09 PM, TOM wrote: Nach einem Update auf 4.4.6 lassen sich die tt_news-Inhaltselemente für die Anzeige nicht mehr editieren. Stattdessen bekomme ich: t3lib_error_Exception PHP Catchable Fatal Error: Argument 2 passed to t3lib_iconWorks::getSpriteIconForRecord() must be an array, null given, called in /www/typo3/SOURCE/typo3_src-4.4.6/t3lib/class.t3lib_treeview.php on line 663 and defined in /www/typo3/SOURCE/typo3_src-4.4.6/t3lib/class.t3lib_iconworks.php line 738 Hatte ich auch eben. Soweit ich das auf die Schnelle sehen konnte ist das eine Macke im tt_news treeview, der die icon Darstellung auch ruft, wenn eine Seite mit Kategorien geloescht wurde, oder nicht auffindbar ist. Weiter hab ich bisher nicht geforscht. Das erklaert aber zumindest warum kein Fehler auftritt wenn ein neues Element angelegt wird. Gruesse Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] t3lib_iconWorks::getSpriteIconForRecord() must be an array, null given
Hallo nochmal,
On 12/29/2010 08:11 PM, Christian Kuhn wrote:
Soweit ich das auf die Schnelle sehen konnte ist
das eine Macke im tt_news treeview, der die icon Darstellung auch ruft,
wenn eine Seite mit Kategorien geloescht wurde,
Brutaler Hack um das erstmal zu fixen (Achtung: Nur mal eben schnell
hingezimmert, ohne Garantie!)
tt_news/lib/class.tx_ttnews_categorytree.php
Zeile 132:
$firstHtml .= $this-getIcon($rootRec);
ersetzen durch:
if (is_array($rootRec)) {
$firstHtml .= $this-getIcon($rootRec);
}
Wenn laeuft bitte als Bug bei tt_news einreichen.
Gruesse
Christian
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching
Hey, Siedlaczek, Sandy wrote: Eine Begrenzung gibt es wohl nicht, da unsere cache_pages gerade auf 8,2 GB angewachsen ist, nachdem ich recache und den indexed_search Crawler angeschmissen habe. Ich frage mich allerdings immer, ob der Cache bei diesen Datenmengen überhaupt noch seinen Zweck erfüllt. Eine Obergrenze gibt es nicht. Man bekommt halt nur irgendwann Schwierigkeiten genug RAM auf mysql zu werfen damit die Tabelle schnell bleibt. Ein eingeschalteter slow-log sollte erste Hinweise geben wann es wirklich unschön wird. Abhilfe kann eventuell enetcache [1] schaffen: Die Extension liefert ein Backend für das caching framework mit, das die Daten vorm Stopfen in die Datenbank mit gzip packt (und beim Rausholen entpackt). Damit kann man die Tabelle um den Faktor 6-8 oder so kleiner kriegen, was natürlich extrem praktisch für mysql ist. Natürlich geht diese Lösung zu Lasten der CPU der Maschine, das sollte bedacht / ausprobiert werden. In unseren Fällen ist der Vorteil durch den frei werdenen RAM sehr viel größer als das bisschen zusätzliche Rechenzeit. Grüße Christian [1] http://typo3.org/extensions/repository/view/enetcache/current/ ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] neue feuser_register extension
Hallo Ingo, Ingo Schmitt wrote: wir haben in einigen Projekten gesehen, das man mit der guten alten sr_feuser_register Extension sehr oft mit Kanonen auf Spatzen schiesst. Bei Updates haben wir sehr oft Probleme mit Inkompatibilitäten und Bugs zu kämpfen, die z.B. auch zum Teil mit einer nicht eindeutigen Nummerierung der Version einhergehen. Es gibt in forge auch noch die feuser_register von Frank: http://forge.typo3.org/projects/show/extension-feuserregister Die ist im Code schön hübsch, flexibel und wird von uns produktiv eingesetzt. Oliver arbeitet offenbar auch gerade dran. Grüße Christian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
