Re: [TYPO3-german] Kreuzstaging

[André Spindler]

Hallo in die Runde.

So ganz kann ich das aber auch nicht stehen lassen.
Beispiel: In eine bestehende Website kommt ein News-Modul nachträglich 
rein. Fluid-Templates, CSS, usw steht alles in den Dateien einer 
Setup-Extension und lässt sich wunderbar versionieren.
Aber was machst du mit den ganzen funktionellen Seiten? Wo konfigurierst 
du Detail-Seite, Liste und Ablageordner? Alle Seiten-IDs in allen 
Plugins? Am besten auch noch für alle Sprachen?
Und sagt jetzt bitte nicht ja - denn damit hast du die 
News-Konfiguration in Plugins vorgenommen und damit in der Datenbank 
stehen und nicht in versionierten Dateien.


Letztlich läuft es so:

Variante A - Datenübernahme LIVE->DEV:
Sofern das leicht machbar ist, Kopieren wir Datenbank und den fileadmin 
von LIVE nach DEV. Mit TYPO3 9 müssen noch nicht mal Domain-Records 
(falls vorhanden) umgestellt werden. Die gibt es nicht mehr.
VOR dem Kopieren werden neue "Dummy-Seiten" versteckt angelegt. Nach dem 
Kopieren wird in DEV das Feature implementiert, es sind ja alle 
relevanten IDs vorhanden. Und wenn es fertig ist, kommt es per 
Repository ins LIVE-System und wird nach finaler Content-Befüllung Live 
gestellt. Fertig.


Variante B - TYPO3_CONTEXT:
Sofern das Überschreiben von DEV mit LIVE nicht so leicht machbar ist, 
kann dieses Szenario greifen. TYPO3_CONTEXT ist bei uns IMMER gesetzt. 
Dann werden in DEV und LIVE die Seiten mit unterschiedlichen IDs 
generiert und im Typoscript über eine CONTEXT-Abfrage für DEV und LIVE 
unterschiedlich konfiguriert. Fertig. Sofern dann ab und zu tatsächlich 
auch mal wie bei A alles kopiert wird, müssen die Weichen dann halt 
angepasst werden.


Viele Grüße,
André Spindler

Am 08.07.2019 um 19:01 schrieb _doc:

Hallo Rainer,

Die Antwort von Marcus ist falsch, sofern man sich an die Regel der 
stricten Trennung von Inhalten und Code hält. Der Code und die 
Konfigurationen sollte sich dann nur in Dateien finden lassen, die man 
z.B. mit GIT versionieren kann.


Was optimierst du denn auf DEV? Normalerweise kann alles zur 
TYPO3-Optimierung in Dateien ausgelagert werden. Eine gute 
TYPO3-Aufsetzung enthält keine Configurationsdaten in der Datenbank 
(bzw. fast keine). TypoScript, TSConfig, Templates, 
BackendKonfigurationen, ... ist ausgelagert in Extensions und Dateien, 
die man zum Beispiel unter git versioniert.  In der Versionierung Git 
habe ich einen Brach Master und einen Develop, wenn alle Einstellungen 
im Develop-Branch gut sind, merge man die Version in den 
Master-Branch. Dann lädt man die Dateien aus dem Master-Branch auf den 
Server. Am besten per ssh-Tunnel mit einem Upload-Programm wie 
Magallanes v4 - Documentation, um Uploadfehler und Down-Zeiten klein 
zu halten. (Ich habe extra unter Windows ubuntu installiert, um dies 
privat machen zu können.)


Wenn man natürlich alles TypoScript und TSConfig in der Datenbank hat, 
dann sollte man das vorher rausziehen und in eine Extension auslagern.


Mit besten Grüßen

    Dieter


Am 08.07.2019 um 15:26 schrieb Marcus Raphelt:

Hi Rainer,

so wirklich zuverlässig würde es nur gehen, wenn Typo3 hier, wie 
bspw. Oxid, auf UUIDs statt AutoInc-Spalten setzen würde. Numerisch 
laufen Dev und Live *immer* auseinander.
Als Helferlein könnte ich SQLYog empfehlen, die Pro-Version hat einen 
Synchronisations-Wizard, der ganz gut funktioniert und zwischen zwei 
MySQL-Instanzen "rsyncen" kann.


Wirklich lösen lässt es sich nach meinem Kenntnisstand nur politisch 
/ organisatorisch.


Gruß
Marcus

Am 08.07.19 um 15:00 schrieb Rainer Schleevoigt:




Nun pflegen Redakteure im PROD-System Seiten und deeren Inhalte ein. 
Ich wiederum verbessere die TYPO3-Seite auf DEV. Nun kommt der 
Wunsch des Mergings.


Geht das überhaupt - best Practice?






___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german




___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] .htaccess in TYPO3 9.5.1

[André Spindler]

Hallo in die Runde,

was Johannes schreibt, ist korrekt, TYPO3 9 macht das im Installtool.
Die Kopiervorlage dafür ist 
EXT:install/Resources/Private/FolderStructureTemplateFiles/root-htaccess


In der vhost-Konfiguration habe ich folgendes drinstehen:

    Options -Indexes +FollowSymLinks -SymLinksIfOwnerMatch +Includes 
+ExecCGI

    AllowOverride Indexes FileInfo AuthConfig Limit Options=All,MultiViews
    DirectoryIndex index.php


Viele Grüße,
André

Am 12.11.2018 um 12:14 schrieb Birgit:

Hallo Michael,

Ergänzung: Logfiles liegen bei mir in typo3temp/var/log/


Viele Grüße
Birgit


Am 12.11.2018 um 12:06 schrieb Johannes C. Schulz - EnzephaloN IT-Solutions 
:

Hallo

Gehe ins InstallTool und dort in den Verzeichnis-Check. Dieser legt die 
htaccess für dich an.

Viele Grüße
Johannes C. Schulz
EnzephaloN IT-Solutions
{ von unterwegs gesendet}
Am 12. November 2018 12:02:47 schrieb "michae...@rocketmail.com" 
:


Hallo zusammen,


(Hoffentlich) Kurze Frage, ich finde in der Upgrade Dokumentation erst einmal 
nichts dazu:

Alle von mir genutzten früheren TYPO3 Versionen beinhalteten eine Datei 
typo3_src-/_.htaccess als Beispiel für
eine .htaccess Datei.

Diese Datei existiert mit 9.5.1 nicht mehr.

Ich habe es früher immer so einfach und sicher wie möglich gemacht:


   Options +FollowSymLinks
   AllowOverride None
   Require all granted
--->Include /srv/www/htdocs/typo3root/.htaccess  <--


D.h., AllowOverride zur Sicherheit auf "None", und dann das TYPO3-spezifische 
.htaccess einfach als Direktive
importiert/eingebunden. Funktionierte für alle 7.x und 8.x einwadnfrei. 
Funktioniert jetzt mit 9 leider nicht mehr :(

Ich habe es ohne das nicht mehr existierende .htaccess versucht, in den  Docs 
für 9 steht, dass
AllowOverride Indexes FileInfo
gesetzt werden soll. Funktioniert auch nicht wirklich.

Ich bekomme für alle Versuche ohne weitere Info "Oops, an error occurred!" 
statt der Backend-Loginseite.
Im Apache error_log wird dazu aber kein Eintrag geschrieben.
Ganz früher standen mal TYPO3 Fehlermeldungen in /typo3temp/logs, 
jetzt aber auch nicht mehr, der letzte
Logeintrag hier ist Jahre alt.


Tipps wären toll :-)


Viele Grüße,
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 8.7.x Bilder drehen

[André Spindler]

Hallo Helmut,

hast du das Bild an einem Rechner mit Windows gedreht?
Windows schreibt nicht die Bilddaten um, sondern hinterlegt die Drehung 
lediglich in den EXIF-Daten.
Ich vermute deshalb, dass das Bild, dass beim Hochladen "gedreht" wird, 
einfach nur wieder "zurück gedreht" wird. TYPO3 wertet meines Wissens 
keine EXIF-Daten für die Darstellung aus.
du müsstest also das Bild in einem Grafikprogramm drehen, damit auch die 
Bildinformationen gedreht werden. Dann sollte es funktionieren.


Viele Grüße,
André Spindler

Am 03.08.2018 um 17:17 schrieb Helmut Zötzl:

Hallo,

Bilder drehe ich normalerweise vorher am PC und lade sie dann hoch. 
Doch ein Bild drehte sich beim Upload in TYPO3 automatisch um 90 Grad.
Wisst ihr, wie man das hinbekommt, dass sich Bilder beim Upload nicht 
mehr drehen?

Oder wie man in TYPO3 8.7.x Bilder drehen kann.

Viele Grüße
Helmut Zötzl
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Fehlender BE-Menüpunkt TEMPLATES

[André Spindler]

Hallo Rainer,

ich hab das noch nicht gemacht, weiß nur, dass es das gibt...

Was bindest du als typo3 in der composer.json ein?
"typo3/cms-core"? "typo3/cms"? typo3/cms-base-distribution"?
Ich habe das hier gefunden, kann als Hilfestellung dienen: 
https://github.com/TYPO3/TYPO3.CMS.BaseDistribution/blob/master/composer.json 
(bezieht sich aber auf TYPO3 9)


Lieben Gruß,
André

Am 05.07.2018 um 15:52 schrieb Rainer Schleevoigt:

Hallo André und Çiğdem,


Am 05.07.18 um 15:43 schrieb André Spindler:

Hallo Rainer und Çiğdem,

das Problem dürfte woanders liegen.
Zur Verifizierung: Rainer - welche Extensions sind denn beim Blick in 
den ExtensionManager überhaupt da? Er ist ja als Modul nach wie vor 
vorhanden, nur der Download von Extensions ist gesperrt.
Ich gehe davon aus, dass es nur nur Bruchteil von dem ist, was man 
als "Standard-Lieferumfang" kennt.


Grund:
Ursprünglich wurde bei der Composer-Installation immer das komplette 
TYPO3-Paket mit allen System-Erweiterungen geladen.
Irgendwo im 8.7.er Versionszweig (8.7.9?) gab es aber eine Änderung, 
die auch im 9er TYPO3 drin ist. Es ist jetzt möglich, per 

genau den Sprung habe ich gemacht.
Hier is der Screenshot: 
https://github.com/subhh/HOS-TYPO3-discovery-distribution/blob/master/Bildschirmfoto%202018-07-05%20um%2015.45.40.png


Was müsste ich nachinstallieren? Im Composer?

Vielen Dank für eure Unterstützung. Meine TYPO3-Jahre liegen weit 
zurück (v4.7) und das ist mein erstes projekt nach dieser pause.


rainer
Composer nur noch die System-Erweiterungen zu laden, die auch 
wirklich gewollt sind.
Es kommt nicht mehr alles, aber alle benötigten Module müssen 
explizit in der composer.json gelistet werden.
Bei dir sehe ich da nur "typo3/cms-core". Das ist halt auch nur der 
Core und das, was TYPO3 unbedingt braucht. Das müssten genau die 
Erweiterungen sein, die sich auch nicht deaktivieren lassen.
Probiere es mal mit "typo3/cms". Oder füge die von dir benötigten 
Module hinzu.


Lieben Gruß,
André


Am 05.07.2018 um 14:48 schrieb M. Cigdem Klengel:

Hi Rainer,

(ich bin es gar nicht gewohnt, dass jemand meinen Namen richtig 
richtig schreibt ;-)  danke schon man für diesen erhellenden Moment).


Also du hast schon im Exentsionmanager nachgeschaut?
Dort taucht das Template Modul auf, das aktiviert werden kann als 
tstemplate

https://seafile.ifw-dresden.de/f/fc13d8cb9b304d77ad32/?dl=1

Schöne Grüße,
Çiğdem


Am 05.07.2018 um 14:17 schrieb Rainer Schleevoigt:

Hallo Çiğdem,

vielen Dank für deine rasche Antwort. Ich habe TYPO3 damit 
https://github.com/subhh/HOS-TYPO3-discovery-distribution/blob/master/composer.json 
installiert. Die dort angeforderten Extensions:


"helhum/typo3-console": "^4.1",
"subugoe/find": "^3.1",
"typo3/cms-introduction": "^3.0",
"solarium/solarium": "^3.7"

habe ich dann im BE eingeschaltet.

Leider kann ich beispielsweise die Templates (typoscript) im BE 
nicht bearbeiten.


So sieht es aus: 
https://github.com/subhh/HOS-TYPO3-discovery-distribution/blob/master/Bildschirmfoto%202018-07-05%20um%2014.15.01.png



Am 05.07.18 um 10:16 schrieb M. Cigdem Klengel:

Hi Rainer,

hast du bei den Extensions nachgeschaut ob die fehlenden Module 
aktiviert werden müssen?

Bei mir kam das mal vor.

Schöne Grüße,
Cigdem


Am 05.07.2018 um 10:11 schrieb Rainer Schleevoigt:

Hi,

in einem gerade frisch installierten TYPO3 v8.7.16 auf CentOS mit 
PHP7.2 sehe ich im BE lediglich Page und List im Webbereich. Wie 
kann das angehen?













___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german




___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Fehlender BE-Menüpunkt TEMPLATES

[André Spindler]

Hallo Rainer und Çiğdem,

das Problem dürfte woanders liegen.
Zur Verifizierung: Rainer - welche Extensions sind denn beim Blick in 
den ExtensionManager überhaupt da? Er ist ja als Modul nach wie vor 
vorhanden, nur der Download von Extensions ist gesperrt.
Ich gehe davon aus, dass es nur nur Bruchteil von dem ist, was man als 
"Standard-Lieferumfang" kennt.


Grund:
Ursprünglich wurde bei der Composer-Installation immer das komplette 
TYPO3-Paket mit allen System-Erweiterungen geladen.
Irgendwo im 8.7.er Versionszweig (8.7.9?) gab es aber eine Änderung, die 
auch im 9er TYPO3 drin ist. Es ist jetzt möglich, per Composer nur noch 
die System-Erweiterungen zu laden, die auch wirklich gewollt sind.
Es kommt nicht mehr alles, aber alle benötigten Module müssen explizit 
in der composer.json gelistet werden.
Bei dir sehe ich da nur "typo3/cms-core". Das ist halt auch nur der Core 
und das, was TYPO3 unbedingt braucht. Das müssten genau die 
Erweiterungen sein, die sich auch nicht deaktivieren lassen.
Probiere es mal mit "typo3/cms". Oder füge die von dir benötigten Module 
hinzu.


Lieben Gruß,
André


Am 05.07.2018 um 14:48 schrieb M. Cigdem Klengel:

Hi Rainer,

(ich bin es gar nicht gewohnt, dass jemand meinen Namen richtig 
richtig schreibt ;-)  danke schon man für diesen erhellenden Moment).


Also du hast schon im Exentsionmanager nachgeschaut?
Dort taucht das Template Modul auf, das aktiviert werden kann als 
tstemplate

https://seafile.ifw-dresden.de/f/fc13d8cb9b304d77ad32/?dl=1

Schöne Grüße,
Çiğdem


Am 05.07.2018 um 14:17 schrieb Rainer Schleevoigt:

Hallo Çiğdem,

vielen Dank für deine rasche Antwort. Ich habe TYPO3 damit 
https://github.com/subhh/HOS-TYPO3-discovery-distribution/blob/master/composer.json 
installiert. Die dort angeforderten Extensions:


"helhum/typo3-console": "^4.1",
"subugoe/find": "^3.1",
"typo3/cms-introduction": "^3.0",
"solarium/solarium": "^3.7"

habe ich dann im BE eingeschaltet.

Leider kann ich beispielsweise die Templates (typoscript) im BE nicht 
bearbeiten.


So sieht es aus: 
https://github.com/subhh/HOS-TYPO3-discovery-distribution/blob/master/Bildschirmfoto%202018-07-05%20um%2014.15.01.png



Am 05.07.18 um 10:16 schrieb M. Cigdem Klengel:

Hi Rainer,

hast du bei den Extensions nachgeschaut ob die fehlenden Module 
aktiviert werden müssen?

Bei mir kam das mal vor.

Schöne Grüße,
Cigdem


Am 05.07.2018 um 10:11 schrieb Rainer Schleevoigt:

Hi,

in einem gerade frisch installierten TYPO3 v8.7.16 auf CentOS mit 
PHP7.2 sehe ich im BE lediglich Page und List im Webbereich. Wie 
kann das angehen?













___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] TYPO3 8.7 LTS fehlende Übersetzungen

[André Spindler]

Hallo Alex

Ich kann das allerdings so bestätigen:
- Im Sprachen-Modul die Sprachdateien aktualisiert, es gab keine 
Fehlermeldung, dort steht bei erneutem Aufruf auch Datum und Uhrzeit von 
gerade eben
- sämtliche Caches geleert (hab ich mir zumindest angewöhnt, wenn ich in 
eigenen Extensions Sprachlabels ändere)
- Aufruf eines Inhaltselements im Backend: Ich sehe die Felder "Frame", 
"Space Before" und "Space After" mit englischem Label und englischen Werten


Es sollte auch nicht an fehlenden Zugriffs-/Schreibrechten im 
Dateisystem liegen, denn im Installtool sind bei der Dateisystemprüfung 
ALLE Einträge grün. Und in der Systemkonfiguration gibt es auch keine 
Fehler.


Lieben Gruß,
André

Am 28.11.2017 um 18:48 schrieb Alexander Opitz:

Hi Markus,

das klingt eher danach, das Du die aktuellen Sprachdateien nicht
herunter geladen hast.

Viele Grüße Alex//

Markus Soeth wrote:

Hallo,
mir ist aufgefallen, das an vielen Stellen die deutsche Übersetzung in
der 8.7 LTS Version unvollständig ist. Würde mich auch gerne an der
Übersetzung beteiligen, aber der Translation Server scheint nur so
partiell zu funktionieren. #

Habt Ihr ähnliche Probleme z.B. Content Element "Menü"  (Subpages;
Abstracts, etc)
oder untder dem Reiter Erscheinungsbild "Space before", "Frame"

Wie habt Ihr das gelöst oder wo könnte man sich beteilligen um das
Problem zu beheben. Laut Translation Server soll eigentlich fast der
gesamte Core zu 100% Übersetzt sein.
https://translation.typo3.org/de/




___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Menügenerierung: Performancevergleich Datenprozessor - Viewhelper

[André Spindler]

Hallo noch mal,

okeee - so groß sind die Erfahrungen damit dann wohl noch nicht.

Aber genau darum ging es mir. Dass der intern mit Typoscript arbeitet 
war klar, sieht man beim Blick in den Quellcode.


Ich hab jetzt zwar nicht mit Milliarden von Antworten gerechnet, aber 
hatte das ganz bewusst mal offen gelassen. Und gar nicht auf kleine oder 
große Menüs reduzieren wollen. Eben WEIL ich vermute, dass es je nach 
Größe/Typ der eine oder der andere Weg der sinnvollere ist.


Deshalb Danke für eure Beiträge, auch wenn sie mir leider nicht wirklich 
weiter geholfen haben ;-)


Liebe Grüße,
André

Am 12.09.2017 um 09:38 schrieb Stefan Padberg:

Hallo in die Runde,

Bejamin Kott hat den DataProcessor für das Menü im Wesentlichen
entwickelt. Das Hauptmotiv war eine saubere Trennung zwischen
Frontend-Entwicklung und Backend-Entwicklung. Die Frontentwickler kamen
mit Typoscript nicht zurecht. Sie haben jetzt die Möglichkeit, sich mit
den menu-Fluidvariablen ihren eigenen Navi-HTML-Code zu schreiben.

Benjamin Kott erzählte auf dem TYPO3 Camp RheinRuhr letztes Jahr, dass
es ihm nicht möglich war, den DataProcessor von Typoscript-Code
freizuhalten. Typoscript ist offensichtlich eine äußerst mächtige
Konfigurationssprache, die sich nicht so leicht durch besser ins
Extbase-Umfeld passenden Code ersetzen lässt. Das war mal eine
erhellende Aussage von einem Core-Entwickler. Keiner der Core-Entwickler
will gegenwärtig Typoscript aufgeben.

Von daher ist davon auszugehen, dass der Dataprocessor etwas mehr an
Rechenzeit verbraucht als reines Typoscript. Wer also die vereinfachte
Handhabung mit den Fluidvariablen nicht benötigt, kann sich sein HMENU
natürlich immer noch selber schreiben.

Beste Grüße
Stefan



Am 11.09.2017 um 19:10 schrieb Dr. Dieter Porth:

Hallo André,

wer falsche Fragen stellt, erhält auch mit Milliarden-schwerer Forschung
immer sicher eines: falsche Antworten.

cObject ist eine Krücke für die ehemaligen TypoScriptler und der Feind
jeden puren MVC-Konzeptes. Den Dataprozessor dagegen rechnet man noch
zum Controller zu, weil er vorm ersten View alle Daten fertig zur
Verfügung stellt.

Tendeziell bin ich schon am Überlegen, zukünftige Projekte ordentlich zu
trennen, um  ein überschaubare Kontrolle für SEO-Text und
domain-übergreifende Namespace-Eintragungen zum Beispiel für
Bezahlservices Tageszeitungen-Cloud, Wetterdienste, ... zu haben.  Ich
denke, meine zukünftigen Projekte könnten auch folgende TypoScript
Konfiguration aufweisen:

page = PAGE
page.headerData.10 = FLUIDTEMPLATE
page.headerData.10 {..

TypoScript als Krücke im Rendering macht Webseiten meist unnötig
kompliziert, weil es Rendering und Datenabfrage vermischt. TypoScript
als Renderhilfe ist rationalisierungsfeindlich.

Welche Art von Menü meinst du? Meinst du zum Beispiel ein
CSS-getriggerte responsive-Tab-DropDown-Menü, dass beim 'hover' im
DropDown-Menü im Vorschaufeld einen Teaserbild mit Text zur Seite
anzeigt, wobei sich das Dropdown des Menüs bis zu vier Ebenen tief sein
kann,  oder meinst  ein einfaches List-Menü. Oder meinst du ein Menü, wo
die Hintergrundfarbe bei den Links durch die Kategorien der Seite
bestimmt wird und welches Vorschaubilder hat.

Für die Standardfälle ist vermutlich das TypoScript-Geraffel in der
Ausführung schneller. Für die angedachten komplexeren Fälle wird man
aber schon aus Clean-Code-Gründen und mit Blick auf die zukünftige
Automatisierungen immer
den Menü-Prozessor verwenden, weil er pflegbarer, leider modifizierbar
und besser Daten und Ausgabe trennt.

Warum ist dir die Millisekunde Performance wichtig? Mir ist
überschaubarer Code lieber als eine Mikrosekunde an Performance; denn
wenn ein System langsam ist, habe ich die falsche Software, das falsche
CMS und/oder ein falsches Konzept gewählt bzw. genauer: eine Antwort auf
eine falsch gestellte Frage gefunden.

Mit besten Grüßen

   Dieter



Am 11.09.2017 um 11:03 schrieb André Spindler:

Hallo miteinander!

Mit TYPO3 8(.5) wurde der Fluid Datenprozessor für Menüs eingeführt.

Dazu ist noch relativ wenig online an Erfahrungen zu finden. Wird der
schon von euch verwendet?
Mich interessiert hier die Performance im Vergleich zur Einbindung
eines Menüs als HMENU per cObject-Viewhelper.

Technisch macht der Datenprozessor ja genau das. Er erzeugt eine
typoscript-Konfiguration für ein HMENU und ruft dieses auf, um ein
json Array zu erzeugen. das wird dann an Fluid übergeben, welches
durchlaufen werden muss, um daraus das auszuliefernde HTML zu
generieren. Im Vergleich zur cObject-Einbindung aufwändiger. Aber
greifen hier möglicherweise Cache-Mechanismen von Fluid, welche das
abfangen. Gibt es vielleicht Unterschiede je nach Umfang des Menüs,
indem sich bei kleinen vielleicht eher cObject lohnt und bei großen
der Datenprozessor - oder umgekehrt?

Danke und liebe Grüße,
André





___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Vermisst: Condition „useragent"

[André Spindler]

Hallo Marek,

also ich hab das immer in einer CSS-Datei - alle Auflösungsangaben. Das 
was sich unterscheidet, ist ja immer nur ein kleiner Teil. Überwiegend 
Abmessungen und Positionen. Manchmal ein Wechsel der gegenseitigen 
Ausrichtung. Aber das optische Erscheinungsbild bleibt ja. Und das macht 
eh den größten Teil des CSS aus.


Ob eine zu ladende CSS-Datei 10kb oder 20kb hat, das ist egal. 4 Dateien 
mit je 5kB ist da allerdings was anderes.


Viele Grüße,
André

Am 17.09.2017 um 15:10 schrieb Marek:

Hallo André,

Das Problem liegt doch in der Ladezeit. Es müssen nicht immer alle 
CSS-Dateien geladen werden. Arbeitet man mit Media-Queries  was für 
Hoch- und Querformat wunderbar ist , lädt man immer alle Versionen der 
CSS-Dateien mit. Dafür reicht ein Blick in die Netzwerkanalyse. Du 
hast recht, wenn der Server vorher das Betriebssystem überprüfen soll, 
dann ist es eine zusätzliche Last, aber stets mehrere CSS-Dateien 
auszuliefern auch.

Viele Grüße


Quote: André Spindler wrote on Tue, 12 September 2017 18:35


Hallo Marek,

irgendwie widersprichst du dir da selbst.
(...)
Die neueren Geräte und Browser können die Media-Queries verarbeiten, 
da ist das kein Problem. Und weil Desktop-Systeme -wie du selbst 
schreibst - geupdated sind, ist das dort auch kein Problem.Also löst 
"Mobile first" gerade dein Problem.

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Vermisst: Condition „useragent"

[André Spindler]

Hallo Marek,

irgendwie widersprichst du dir da selbst.

Du schreibst, dass dass bei "mobile first" die Leute mit veralteten 
und/oder billigen Smartphones ausgeschlossen werden. Genau das Gegenteil 
ist der Fall.
Denn mit "mobile first" liefere ich die Seite ja gerade 1:1 als mobile 
Ansicht aus. Das ist auch die Ansicht, die ich auf alten Geräten und 
(auch auf Desktop) in Browsern bekomme, die das alles nicht unterstützen.

Das kriegst du dann auch auf dienen alten Browsern.
Die neueren Geräte und Browser können die Media-Queries verarbeiten, da 
ist das kein Problem. Und weil Desktop-Systeme -wie du selbst schreibst 
- geupdated sind, ist das dort auch kein Problem.Also löst "Mobile 
first" gerade dein Problem.


Lg, André

_
Am 12.09.2017 um 17:14 schrieb Marek:

Das ist kompletter Blödsinn, weil die meisten Browser auf den Desktops 
mit Updates aktuell gehalten werden und das Bewusstsein für die 
Updates größer ist. Auch bei iOS ist das Bewusstsein für Updates 
durchaus ausgeprägt. Ich habe auch hier Android-Smartphones, für die 
es noch nie ein Update gab und der Browser keine neuen 
CSS-Eigenschaften wie Grid nicht unterstützt. Mobile first heißt in 
der Vergangenheit verweilen oder Leute mit veralteten oder billigen 
Smartphones ausschließen. ___

TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Menügenerierung: Performancevergleich Datenprozessor - Viewhelper

[André Spindler]

Hallo miteinander!

Mit TYPO3 8(.5) wurde der Fluid Datenprozessor für Menüs eingeführt.

Dazu ist noch relativ wenig online an Erfahrungen zu finden. Wird der 
schon von euch verwendet?
Mich interessiert hier die Performance im Vergleich zur Einbindung eines 
Menüs als HMENU per cObject-Viewhelper.


Technisch macht der Datenprozessor ja genau das. Er erzeugt eine 
typoscript-Konfiguration für ein HMENU und ruft dieses auf, um ein json 
Array zu erzeugen. das wird dann an Fluid übergeben, welches durchlaufen 
werden muss, um daraus das auszuliefernde HTML zu generieren. Im 
Vergleich zur cObject-Einbindung aufwändiger. Aber greifen hier 
möglicherweise Cache-Mechanismen von Fluid, welche das abfangen. Gibt es 
vielleicht Unterschiede je nach Umfang des Menüs, indem sich bei kleinen 
vielleicht eher cObject lohnt und bei großen der Datenprozessor - oder 
umgekehrt?


Danke und liebe Grüße,
André

--

_
André Spindler ty...@andre-spindler.de
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] mm_forum

[André Spindler]

Hallo Peter,

keine Ahnung, ob dir das weiterhilft, aber unter 
https://github.com/TYPO3-extensions/mm_forum gibt es eine Version 1.10-dev
Wir hatten bei zwei Websites ein Upgrade von 4.5 auf 6.2 gemacht, bei 
denen mm_forum installiert war. Habe dazu noch Notizen gefunden.


Erster Anlauf war tatsächlich die Version von 
http://die-netzmacher.de/titel/mm-forum-fuer-typo3-62/ zu ziehen. Das 
war eine mm_forum 1.11, letzte Änderung vom 12.11.2014.
Die hat allerdings nicht wirklich funktioniert, z.B. das Frontend war 
danach zerschossen.


Zweiter Versuch dann die oben genannte Version, da war die (aktuell) 
letzte Änderung zumindest am 26.10.2015.
Wir hatten die zwei Upgrades letztes Jahr im Sommer gemacht, also noch 
etwas früher, und hatten damit dann kaum Probleme. Zumindest weniger als 
mit der Version von den Netzmachern.


Lieben Gruß,
André

Am 09.06.2016 um 12:59 schrieb Ralf-Rene Schröder:

SORRY... das war ein wirklich blödes Posting von mir...
du suchst ja gerade diese Version 2 ... leider kann ich nicht helfen

Am 09.06.2016 um 12:13 schrieb Ralf-Rene Schröder:

Am 09.06.2016 um 09:27 schrieb Peter Linzenkirchner:

Leider gibt es keine Migration von mm_forum auf typo3_forum, deshalb ist das 
leider im Augenblick keine Alternative.

ich habe es zwar nicht getestet, aber von der Version 2 sollte laut Doku
ein Upgrade funktionieren (Umfang kann ich nichts zu sagen)
https://github.com/mittwald/typo3-forum


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] typo3 als Seitentitel möglich?

[André Spindler]

Hallo zusammen,

Ich denke, das kommt darauf an, wie die URLs generiert werden:

 * www.domain.de/typo3/ wird mit Sicherheit nicht funktionieren,
 * www.domain.de/typo3.html dagegen schon.

Kommt auf die RealURL-Konfiguration an.

Wobei sich da natürlich die Frage stellt, was der Ersteller ursprünglich 
gemeint hat. Gefragt hat er nach dem SeitenTITEL. Und die ist von 
RealURL völlig unabhängig, da ich ja ein davon abweichendes Pfadsegment 
verwenden kann. Wenn der Pfad anders lautet, ist da "typo3" sowieso kein 
Problem...


Lieben Gruß,
André


Am 28.05.2016 um 14:21 schrieb Peter Kühnlein:


Am 28.05.2016 um 12:44 schrieb Renzo Bauen:

Hallo Peter

das Problem ist, dass es dann mit RealURL diese URL gibt
www.meinweb.de/typo3
Und darunter wäre ja eigentlich das Backend aufzurufen...  => Konflikt!

Gruss Renzo


Ah! Ok!... Danke, dass Du mir vom Schlauch geholfen hast! An RealURL 
hatte ich nicht gedacht!


Gruss, Peter



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 7.6.5 userfunc funktioniert nicht

[André Spindler]

Hallo Bernd,

das könnte durchaus sein - kling zumindest logisch.

Ich habe mir das jetzt nicht konkret angeschaut, aber kann es sein, dass 
da nur Mappings zwischen Extensions, Namespaces und Pfaden gespeichert 
werden, aber keine einzelnen Klassen?
Denn wenn ich bei einer Extension mit schon vorhandenen Klassen einfach 
eine neue Klasse /*dazu */baue, dann wird diese gefunden. Nur die 
/*erste */Klasse einer Extension nicht...


Wäre es nicht sinnvoll, wenn man die ClassMap vom Autoloader nicht auch 
über das Installtool aktualisieren könnte?
Denn übel wird es dann, wenn ich zum Beispiel eine Art 
"Framework"-Extension mit überwiegend Konfigurations- und Setup-Daten 
habe, aber bisher keine PHP-Klassen. Dann aber möglicherweise andere 
Extensions davon abhängig sind, weil sie die Konfiguration auslesen. 
Spätestens wenn man im EM abhängige Extensions deaktivieren und wieder 
aktivieren muss, wird es haarig.


Lieben Gruß,
André


Am 22.04.2016 um 11:04 schrieb bernd wilke:

Am Fri, 22 Apr 2016 08:18:09 +0200 schrieb André Spindler:


Hallo Manuel,

ich hatte gerade gestern auch genau dieses Problem. Sämtliche Caches
geleert, selbst über das Installtool.
Dann habe ich die Extension kurz deinstalliert und dann wieder
installiert. Dann ging der Aufruf.
Auch das schon ausprobiert?

Frage in die Runde:
Welchen Cache gibt es unter 7.6.5, der bei Änderungen an den
installierten Extensions neu aufgebaut wird, aber sonst durch keinerlei
Funktion erreichbar ist?

hierbei wird es sich wohl eher nicht direkt um einen Cache handeln.
ich vermute mal die ClassMap es Autoloaders wurde nicht aktualisiert.
das wird eben bei keinem Cache Löschen gemach, allerdings beim De-/
Installieren von Extensions.
Händisch kannst du es natürlich auch machen:
rm typo3temp/autoload/*
  



bernd


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 7.6.5 userfunc funktioniert nicht

[André Spindler]

Hallo Stefan,

also genau das hatte ich gemacht:
- options.clearCache.system=1
- Im Installtool "Clear Cache" ausgeführt

Trotzdem ging es nicht, ich musste die Extension deinstallieren und 
anschließend wieder installieren, damit er die Klasse findet.


Lieben Gruß,
André


Am 22.04.2016 um 08:39 schrieb Stefan Padberg:

Am 22.04.2016 um 08:18 schrieb André Spindler:

Hallo Manuel,

ich hatte gerade gestern auch genau dieses Problem. Sämtliche Caches
geleert, selbst über das Installtool.
Dann habe ich die Extension kurz deinstalliert und dann wieder
installiert. Dann ging der Aufruf.
Auch das schon ausprobiert?

Frage in die Runde:
Welchen Cache gibt es unter 7.6.5, der bei Änderungen an den
installierten Extensions neu aufgebaut wird, aber sonst durch keinerlei
Funktion erreichbar ist?


Hallo Andre,

zum einen den System Cache. Der wird im UserTsConfig mit
options.clearCache.system=1 gesetzt.

Aber der reicht manchmal nicht. Da bleibt einem nichts anderes übrig,
als ins Installtool zu gehen und dort "Clear Cache" zu drücken. Das ist
noch umfassender.

Hier hat neulich jemand den Tipp gegeben, das Installtool während der
Extension Entwicklung in einem zweiten Browserfenster immer parat zu
haben, um "Clear Cache" machen zu können.

Beste Grüße
Stefan







___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 7.6.5 userfunc funktioniert nicht

[André Spindler]

Hallo Manuel,

ich hatte gerade gestern auch genau dieses Problem. Sämtliche Caches 
geleert, selbst über das Installtool.
Dann habe ich die Extension kurz deinstalliert und dann wieder 
installiert. Dann ging der Aufruf.

Auch das schon ausprobiert?

Frage in die Runde:
Welchen Cache gibt es unter 7.6.5, der bei Änderungen an den 
installierten Extensions neu aufgebaut wird, aber sonst durch keinerlei 
Funktion erreichbar ist?


Lieben Gruß,
André

_
André Spindler
Schmidstraße 21 - 85399 Hallbergmoos
Telefon: 0811/9986774 - an...@andre-spindler.de

Am 22.04.2016 um 04:48 schrieb Manuel Bachl:

Hallo da draussen,

vielleicht kann mir hier ja jemand weiterhelfen. Ich versuche über 
eine userfunc dem Body die zugewiesenen Kategorien (zumindest die 
Kategorien die Unterkategorien einer bestimmten Kategorie sind) als 
Klasse übergeben. Allerdings nicht alle Kategorien, sondern die 
hinterlegte Kategorie nur dann, wenn es nur eine Kategorie gibt, 
sollte "neutral" ausgegeben werden. Um es deutlicher zu formulieren 
möchte ich folgendes erreichen: Es gibt eine Kategorie "Schulzweige" 
unter dieser Kategorie sind vier weitere Kategorien eingeordnet. 
Sollte die Seite genau eine oder gar keine dieser vier Kategorien 
zugewiesen bekommen haben soll der Body die Klasse "neutral" bekommen. 
So weit bin ich aber noch gar nicht, hierbei benötige ich später noch 
Hilfe, daher erwähne ich es schon einmal.


Mein aktuelles Problem:

Ich habe anhand diverser Dokumentationen und Tutorials versucht die 
userfunc vie Taposcript aufzurufen. Nun scheint dies nicht zu 
funktionieren. selbst ein einfaches `die('test')` innerhalb der 
aufgerufenen funktion wird nicht ausgeführt. Daher vermute ich dass 
der Aufruf nicht funktioniert.


mein Code:


Typoscript:
```
bodyTag >
bodyTagCObject = USER
bodyTagCObject {
userFunc = Finndrop\FdsCommon\Util\BodyTagHelper->buildBodyTag
fallbackClass = 'neutral'
}
```

BodyTagHelper.php:
```
SELECTquery(
   '*',
   'sys_category',
   'uid IN (' . intval($GLOBALS['TSFE']->id) . ')'
   );

   $bodyClass = '';
   $rows = $this->selectThem($query);

   if (count($rows) == 1) {
   foreach ($rows as $key => $row) {
   $bodyClass .= $row . ' ';
   }
   } else {
   $bodyClass = $conf['default'];
   }

   return ''

   }

   /**
* Select the pages categories
*
* @param $query string SQL query
* @return array Array with pages categories
*/
   protected function selectThem($query) {
   $res = $GLOBALS['TYPO3_DB']->sql_query($query);
   $output = array();
   while ($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
   $output[] = $row['header'];
   }
   return $output;
   }
}
```

Die Datei BodyTagHelper.php liegt in einer Extension in `Classes/Util`

Ich wäre wahnsinnig Happy wenn hier jemand weiterhelfen könnte.

Danke schonmal und liebe Grüße
Manuel Bachl
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] realurl 2.0.x

[André Spindler]

Stimmt nicht ganz bzw nur für TYPO3 7.6. Unter TYPO3 6.2 ist es nicht 
vorhanden, da im Code (ext_tables.php) eine Versionsabfrage enthalten ist.


Am 06.03.2016 um 19:11 schrieb Matthias Eberlein:
Das Modul für realurl 2.0 ist jetzt dort wo du deine andren module 
unter anderem ach das info modul hast zu finden. Icon sieht aus wie 
eine pille.

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Wie schützt ihr Extension-Files gegen direkten Aufruf im Browser

[André Spindler]

in der .htaccess-Datei, die mit dem 7.6er Core ausgeliefert wird, steht 
zum Beispiel das drin:


"(?i:^\.|^#.*#|^(?:ChangeLog|ToDo|Readme|License)(?:\.md|\.txt)?|^composer\.(?:json|lock)|^ext_conf_template\.txt|^ext_typoscript_constants\.txt|^ext_typoscript_setup\.txt|flexform[^.]*\.xml|locallang[^.]*\.(?:xml|xlf)|\.(?:bak|co?nf|cfg|ya?ml|ts|dist|fla|in[ci]|log|sh|sql(?:\..*)?|sw[op]|git.*)|.*(?:~|rc))$">

# Apache < 2.3

Order allow,deny
Deny from all
Satisfy All


# Apache ≥ 2.3

Require all denied



Das lässt sich dann noch um sowas wie ".ts", ".typoscript" usw erweitern...

Lieben Gruß,
André


Am 17.11.2015 um 13:21 schrieb Arne-Kolja Bachstein:

Huch, sorry. Hätte bis zum Ende lesen sollen :-)


Am 17.11.2015 um 13:17 schrieb Alexander Averbuch :

Hallo zusammen,

ich habe mehrere TYPO3-Websites geprüft und habe festgestellt, dass einige 
Extension-Files oder TypoScript-Files aus dem fileadmin-Verzeichnis aufrufbar 
sind.

Mein Problem: Ich entwickle eine große Website mit ca. 40 Extbase-Extensions. 
Leider sind die Dateien wie ext_tables.sql oder 
Configuration/TypoScript/setup.txt gar nicht geschützt, und jeder, der sich mit 
TYPO3 auskennt, weiß, wo sie liegen und kann sie aufrufen. Ich finde es 
überhaupt nicht gut. Das ist auf jeden Fall Futter für einen Hacker. Was kann 
man unternehmen? Wenn ich im .htaccess alle Dateien im Verzeichnis 
typo3conf/ext schütze, muss ich noch berücksichtigen, dass ext_icon.gif und 
alle Dateien aus dem Resources/Public-Ordner aufrufbar sein müssen. Und 
vielleicht gibt es bei einer oder anderer Extensions andere Dateien/Ordner, die 
aufrufbar sein müssen. Ich sehe im Moment keine allgemeine Lösung. Wenn ich auf 
Anhieb eine TYPO3-Website nehme, ist sie von dem Problem auch betroffen.
Probiert mal bei euren Websites sowas wie:

www.domain.ltd/typo3conf/ext/meiextension/Configuration/TypoScript/setup.txt   
oder
www.domain.ltd/typo3conf/ext/meiextension/ext_tables.sql

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Fehlendes/Entfallenes Feld section_frame in der 7er LTS

[André Spindler]

Hallo miteinander,

kurz nach Veröffentlichung der 7.4 mit fluid_styled_content hatte ich 
auch schon nachgefragt (https://forge.typo3.org/issues/70534).
Die Wiedereinführung wurde abgelehnt. Kann sich jeder seine eigene 
Meinung dazu bilden.


Was aber wichtig ist:
Das Feld "section_frame" ist in der Datenbank-Definition zur Extension 
"css_styled_content" enthalten. Sobald diese Extension deaktiviert wird, 
fliegt das Feld beim nächsten DB_Compare im Installtool aus dem System. 
Da wäre ich mit aussagen wie "Da das Feld in der Datenbank wohl noch 
vorhanden ist, kann man das Feld über TCA im Backend wieder verfügbar 
machen" vorsichtig.
Die saubere Lösung ist die, selbst eine Extension dafür zu bauen, welche 
das Feld neu mitbringt/definiert. Dann am Besten auch gleich noch eine 
Migrations-/Importfunktion für die Übernahme der alten Werte.
Zur Ausgabe braucht es natürlich dann noch entsprechdende 
Fluid-Templates bzw. vor allem ein modifiziertes Fluid-Layout


Lieben Gruß,
André

Am 13.11.2015 um 00:19 schrieb Johannes C. Laxander:

Hallo Lars,

das Thema haben wir heute auch in der T3UG Stuttgart diskutiert, und können die 
Entscheidung ebenfalls nicht nachvollziehen.
Diese Tatsache kann auch einen Umstieg auf die neue Version ungemein 
erschweren. Viele haben Layout und Section Frame auch in Kombination 
eingesetzt. In der Gruppe wurde es eher als ein Rückschritt betrachtet.
Da das Feld in der Datenbank wohl noch vorhanden ist, kann man das Feld über 
TCA im Backend wieder verfügbar machen. Aber ob das eine dauerhafte Lösung sein 
kann weiß ich nicht.
Gruß, Johannes.


-Ursprüngliche Nachricht-
Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-
boun...@lists.typo3.org] Im Auftrag von Lars Brinkmann
Gesendet: Donnerstag, 12. November 2015 23:20
An: German TYPO3 Userlist 
Betreff: [TYPO3-german] Fehlendes/Entfallenes Feld section_frame in der 7er LTS

Hallo zusammen,

in der neuen 7 LTS ist ja das Feld section_frame entfallen. Ich finde das etwas
schade, habe ich das Feld doch sehr häufig benutzt, um ein Inhaltselement
unterschiedlich formatieren zu können.

Zum Beispiel "Eingerückt, links mit Border", "Linie ober- und unterhalb", etc.

Nun ist ja anscheinend in der 7er nur das Layout-Feld übrig geblieben.
Dieses nutze ich aber meistens für andere Aufgaben, z.B. bei der Verwendung
von Bootstrap um das Container-DIV vorher mit einem DIV zu wrappen, um einen
fluiden Hintergrund zu haben.

Bislang habe ich noch keine Idee, wie ich das fehlende section_frame ersetzen
kann, um Redakteuren die Möglichkeit zu geben, ein Inhaltselement anderweitig
zu formatieren. Mit section_frame reichte halt ein DIV-Wrapper mit CSS-Klasse.
Nun würde mir eigentlich nur einfallen, für jeden Fall ein eigenes Template
anzulegen.

Welche Möglichkeiten gibt es noch? Am liebsten wäre mir ja, section_frame kommt
zurück.

Viele Grüße, Lars Brinkmann
--
brinkmann.l...@gmail.com
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Überschreiben von Werten aus der locallang.xlf bei tx_news

[André Spindler]

Hallo Masterchief,

wenn ich dich recht verstanden habe liegt das Problem darin, dass die 
Wochentage in Englisch ausgegeben werden.

Der genannte lokalisierte String wird aber verwendet (mit "[...] Uhr").

Das hat mit den Labels nichts zu tun, denn der Platzhalter %A wird über 
eine PHP-Funktion befüllt.

Wie sehen denn deine Lokalisierungseinstellungen aus?
Du muss im Template folgendes setzen:

config.locale_all = de_DE.UTF-8

Das "de_DE.UTF-8" ist mitunter abhängig vom Server (Dieses sogenannte 
"Locale" muss installiert sein), sollte aber funktionieren.


Lieben Gruß,
André


Am 29.10.2015 um 08:53 schrieb Stefan Padberg:

Hallo Masterchief,

hast du auch den Cache gelöscht?

(Ich meine den Ordner "Cache" in "typo3temp"!)

Beste Grüße
Stefan


Am 29.10.2015 um 08:42 schrieb Master Chief:

Hallo Leute,

folgendes Ziel: Customizing der Datums-Ausgabe bei der o.g. Extension.
Standardmäßig wird das Datum angegeben.

Was bisher funktioniert hat über Typoscriptkonfig:

plugin.tx_news._LOCAL_LANG.default.dateFormat = %A, %d.%m.%y %H:%M Uhr

Problem ist, dass %A die Strings in Englisch ausgibt.

Was nicht funktioniert hat:
1)im obigen Statement direkt die entsprechende Sprache zu setzen also
_LOCAL_LANG.de (-> kein Effekt)
2)über Typoscript den entsprechenden Key zu überschreiben, weil diese
mit einem Punkt deklariert sind zB


3)die locallang.xlf zu kopieren und global zu überschreiben. Hierbei bin
ich unter anderem auf diesen Fehler gestoßen:
https://forge.typo3.org/issues/46525

Aber ehrlich gesagt hat es bei mir auch mit dem dort vermerkten
funktionstüchtigen Teil nicht funktioniert :(

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:news/Resources/Private/Language/locallang.xlf'][]

= 'EXT:news/Resources/Private/Language/locallang_test.xlf';

Ist es eigentlich best practice die ext_localconf.php anzupassen? Ist
diese bei extension-updates ausgenommen? Desweiteren bin ich noch
darüber gestolpert, dass man manchmal manuell Cachefiles im Filesystem
löschen muss (/typo3_testsystem/typo3temp/Cache/Data/l10n) um Änderungen
zu sehen. Gibt es da irgendeine sinnvolle Erklärung außer "muss man halt
manchmal machen"? Kann man das Caching zu Testzwecken global deaktivieren?

Das waren jetzt 1-2 Fragen mehr als gedacht, hoffe jemand kann etwas
Licht ins Dunkle bringen :)

Grüße, Thomas

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Dokumentations-Schnittstelle ausgefallen?

[André Spindler]

Hallo Liste,

seit gestern Abend versuche ich, im Dokumentationsmodul mehrerer 
Installationen, einzelne Online-Dokumentationen herunterzuladen. Aber da 
geht überhaupt nichts, Hat sich da was in der letzten Zeit geändert?
Habe es unter 6.2.14, 7.0.2, 7.1.0, 7.2.0 und 7.3.1 getestet (7.4 hab 
ich noch nicht). Auf mehreren Server/Distributionen mit 
unterschiedlichen PHP-Versionen.


Dabei treten die angehängten Fehler auf. Am meisten irritiert mich die 
Tatsache, dass im TYPO3 7.2/7.3 es je nach herunterzuladender 
Dokumentation es unterschiedliche Fehler gibt. Teilweise schlägt die 
Initialisierung der PEAR-Bibliothek fehl, offensichtlich wird sie aber 
auch teilweise korrekt initialisiert, liefert aber dann den Fehler beim 
Versuch des Downloads...


Kann mir da jemand weiterhelfen bzw das Problem bestätigen - liegt 
vielleicht bei docs.typo3.org?


Lieben Gruß,
André Spindler



TYPO3 6.2.14, 7.0.2, 7.1.0 beim Download der Doku für die 
recycler-Extension:

Herunterladen fehlgeschlagen
Kein Archiv mit gerenderter Dokumentation auf docs.typo3.org gefunden.

TYPO3 7.2.0, 7.3.1 beim Download der Doku für die recycler-Extension:
*Fatal error*: require_once(): Failed opening required 'Net/URL2.php' 
(include_path='/data/typo3/typo3_src-7.2.0/typo3/contrib/vendor/pear/http_request2:/data/typo3/typo3_src-7.2.0/typo3/contrib/vendor/pear/pear_exception:.:/usr/local/php-5.6.1/pear') 
in 
*/data/typo3/typo3_src-7.2.0/typo3/contrib/vendor/pear/http_request2/HTTP/Request2.php* 
on line *24

*bzw.
*Fatal error*: require_once(): Failed opening required 'Net/URL2.php' 
(include_path='/data/typo3/typo3_src-7.3.1/typo3/contrib/vendor/pear/http_request2:/data/typo3/typo3_src-7.3.1/typo3/contrib/vendor/pear/pear_exception:.:/usr/local/php-5.6.1/pear') 
in 
*/data/typo3/typo3_src-7.3.1/typo3/contrib/vendor/pear/http_request2/HTTP/Request2.php* 
on line *24*


TYPO3 7.2.0, 7.3.1 beim Download der Doku für die core-Extension:
Herunterladen fehlgeschlagen
Kein Archiv mit gerenderter Dokumentation auf docs.typo3.org gefunden.



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] TER-Spiegelserver mit veralteten Daten

[André Spindler]

Hallo Liste,

wie kann ich verhindern, dass der EM bei der Aktualisierung der Daten 
einen Mirror mit veralteten Informationen aufruft? Und mit veraltet 
meine ich nicht ein paar Tage, sondern Wochen!


Beispiel:
Ich habe in einer Installation die Extension metadata im Einsatz, 
Version 2.1.4. Am 28. Juli ist die Nachfolgeversion 2.2.0 erschienen, 
aktuell ist 2.2.2 vom 05. August.


Problem:
Nun habe ich den Caretaker laufen, auch um mir veraltete Extensions zu 
melden, dazu wird in der Caretaker-Installation viermal am Tag die 
Extension-Liste aktualisiert und dann der Test durchgeführt.
Das Ergebnis ist dann, dass je nach TER-Server bzw Mirror eine mehr oder 
weniger aktuelle Liste kommt. Erst gestern ist dieser Test dann wieder 
auf grün gesprungen und mir wurde ausgegeben, die Installation (mit 
metadata Version 2.1.4) wäre aktuell.


Folgerung:
Mindestens ein TER-Mirror ist noch auf einem Datenstand vom 28. Juli 
oder älter. Das sind nun 2 Wochen!


Frage:
Hat jemand eine Idee, wie ich herausfinden kann, um welchen Mirror es 
sich handelt und wie ich verhindern kann, dass dieser verwendet wird?


Lieben Gruß,
André Spindler
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Synchronisation von 2 Typo3-Installationen

[André Spindler]

Hallo Thomas.

Das wird so nicht funktionieren. Zumindest nicht mit einer 
wirtschaftlichen Lösung.
Irgendwann legt ein Redakteur im RTE in A einen Link auf Seite mit der 
uid=10 an.
Dann steht in irgendeinem Bodytext sowas drin: link 10. Und jetzt 
brauchst du ein Mapping, weil die 10 während deines Syncs in 11 geändert 
werden muss, die ID im System B. Das muss natürlich auch sauber geparst 
werden, dein ein Link auf die DATEI mit der uid 10 (link file:10) darf 
u.U. nicht geändert werden...
Und schon brauchst du ein Mapping und entsprechende Konverter, den 
Referenzen gibt es in allen möglichen Feldern und Tabellen. Da findest 
du kein Ende.


Aber was für ein Szenario soll das denn sein, wo in einem TYPO3 zum 
einen direkt gearbeitet wird und dann zusätzlich Änderungen aus einem 
zweiten System automatisch eingespielt werden sollen?


Lieben Gruß,
André

Am 07.08.2015 um 10:12 schrieb Thomas Gabler:

Am 07.08.2015 um 08:40 schrieb Lars Peter Søndergaard:

Hi Thomas,

nicht bidirektional? Wie soll das funktionieren?

Ein Problemfall wäre zum Beispiel:

1. A und B sind identisch. Die letzte erstellte Seite hat die id=10.
2. Du erstellst eine neue Seite bei B, welche die id=11 bekommt.
3. Da die Daten nicht nach A synchronisiert werden, weiß A nichts von 
der neuen id. Würdest du also eine neue Seite unter A erstellen, 
würde diese ebenfalls die id=11 erhalten, und spätestens beim Versuch 
die neue Seite mit B zu synchronisieren, einen Fehler verursachen, 
oder wie man es vom typischen PHP Projekt erwarten würde: etwas 
vollkommen unerwartetes passiert (scnr).




Man kann z.B. feststellen, dass bei beiden Installationen diesselbe id 
existiert, aber dass das crdate unterschiedlich ist. Dann sind es 
definitiv 2 unterschiedliche Datensätze (je einmal von A und B 
generiert).
Damit darf dann die Seite von A natürlich nicht mit derselben id 
ersetzen, sondern nur hinzufügen (insert statt replace). Damit bekommt 
diese Seite von A eine neue id in B.


Wenn dieselbe id (in A und B) existiert, aber das crdate identisch 
ist, dann muss diese id/Seite erneuert werden.


Grüße
Thomas
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] realURL bei Typo3 6.2.12

[André Spindler]

Hallo Volker,

wurde das Upgrade auf einer Entwicklungs- oder temporären Kopie mit 
einer ANDEREN Domain gemacht?
Dann prüfe mal deine Konfiguration dahingehend, ob sie auch für die 
aktuelle Domain gilt, unter der die Seite läuft. Das Auftauchen von IDs 
statt des Seitenpfades ist immer ein Indiz dafür, dass die Konfiguration 
nicht komplett richtig ist und RealURL zur verwendeten Domain keine 
Konfiguration findet.


Lieben Gruß,
André


Am 18.07.2015 um 23:32 schrieb g4-l...@tonarchiv.ch:

On 07/18/2015 04:39 PM, Volker Mustermann wrote:

Hallo,

nach erfolgreichen Update von Typo3 4.5.40 auf Typo3 6.2.12 sollten
die sprechenden URLs so aussehen:

//domain.com/seitentitel/

angezeigt wird aber:

//domain.com/seiten_id/ also z.B.: //domain.com/62/

Ich habe alle anderen Extensions schon deaktiviert. Auch habe ich
realURL schon komplett deinstalliert und gelöscht. Leider ohne
Erefolg. Ich habe realURL schon auf über 20 Seiten eingerichtet -
bisher ohne Probleme. Kennt jemand den Effekt oder kann mir
weiterhelfen. Ich habe schon Typoscript und Einstellungen von realURL
mehrfach durchgeforstet.

Schon mal vielen Dank im Voraus
Volker
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Ich habe den Umstieg von 4.6.x zu 6.2 schon länger hinter mir und kann
mich deshalb nicht mehr erinnern, ob es damals Probleme mit realUrl gab.

Für dein Problem müsste ja tx_realurl_advanced.php verantwortlich sein.
Wie sieht den der entspr. Abschnitt in deiner realurlconf.php aus?

Hier eine aus laufendem Betrieb:

$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array(
...
 'pagePath' = array(
 'type' = 'user',
 'userFunc' =
'EXT:realurl/class.tx_realurl_advanced.php:tx_realurl_advanced-main',
 'spaceCharacter' = '-',
 'segTitleFieldList' =
'tx_realurl_pathsegment,title',
 'languageGetVar' = 'L',
 'rootpage_id' = '1',
 'excludePageIds' = '6,30,31,59,32,41,33,34,35',
 ),
...
}

Grüße,
TIll
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Felder in FAL Metadata im Backend umbenennen

[André Spindler]

Hallo Andreas,

siehe dazu auch https://forge.typo3.org/issues/67365#note-1

Gruß,
André

Am 09.06.2015 um 12:09 schrieb Andreas Keck:

Hallo Florian,
danke für den Report und für den Tip. Ich werde es dann erstmal so 
lösen wie du. Grundsätzlich denke ich aber, es sollte schon eine 
Möglichkeit geschaffen werden, wie auch immer die aussehen kann, per 
TsConfig die Dateiliste zu formatieren.


Gruß Andreas ___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


--

_
André Spindler
Schmidstraße 21 - 85399 Hallbergmoos
Telefon: 0811/9986774 - an...@andre-spindler.de

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Caretaker

[André Spindler]

Sorry, hab ich vorhin vergessen: Läuft bei mir unter 6.2


Am 27.01.2015 um 15:03 schrieb Stefan Bublies:

Hallo Peter,

ich habe gerade mal in meiner Installation geschaut. Ich hatte am 
Anfang ähnliche Probleme...


Ich habe bei mir noch die Notification strategies konfiguriert -- 
Danach funktionierte es bei mir einwandfrei.


Also quasi folgendes (neben den hier schon beschriebenen Anpassungen):

- tt_address Datensatz mit Mailadresse etc.
- Role
- Notification strategies

Ach ja, bei mir läuft das ganze noch unter einem TYPO3 CMS Version 4.5

Ehrlich gesagt war das am Ende mehr trial and error ;)

Viele Grüße,

Stefan

--

Web. www.dt-internet.de

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Caretaker

[André Spindler]

Hallo Peter,

also bei mir funktioniert das ganz gut:
1. Adress-Datensätze für die E-Mail-Empfänger anlegen.
2. Rollen anlegen - habe bei mir nur eine : Main admin
3. In den Instanzgruppen bei Contacts (nicht Notifications) die 
Adresse hinterlegen und die Rolle zuordnen.


Mit Eskalationsstufen usw. habe ich mich nicht beschäftigt - das 
funktioniert bei mir auch ohne weitere Angaben.


Wichtig ist möglicherweise noch die Konfiguration in der 
Caretaker-Extension selbst - hier die relevanten Werte:


[caretaker.notifications.send_states] = -2,-1,0,1,2
[caretaker.notifications.simple_mail.mail_subject] = Caretaker on SERVER
[caretaker.notifications.simple_mail.mail_from] = ABSENDER
[caretaker.notifications.simple_mail.mail_link] = 
http://DOMAIN/index.php?id=6tx_caretaker_pi_singleview[id]=###

[caretaker.notifications.simple_mail.enabled] = 1

Villeicht hilft ja das weiter...

Lieben Gruß,
André

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Mirror-Server fürs TER deaktivieren

[André Spindler]

Hallo zusammen,

Ich hatte eben folgende Situation:
- TYPO3 CMS 6.1.er Installation mit gridelements 2.0.3
- vor 2 Tagen, am 29.11., wurde gridelements 2.1.1 veröffentlicht
- Im EM die Daten vom TER geholt; wurde korrekt durchgeführt (blaue Bestätigung)
- Wollte Update einspielen - nicht vorhanden! Für Gridelements wurde kein 
Update angezeigt
- Erneut im EM die Daten geholt; wurde erneut aktualisiert
- Jetzt konnte ich das Update sehen und einspielen

Ich folgere daraus:
Bei der ersten Aktualisierung hat der EM irgendeinen Mirror erwischt, der nicht 
aktuell war. Bei der zweiten Aktualisierung war es ein zumindest aktuellerer. 
Anders kann ich mir nicht erklären, dass eine zweite Aktualisierung überhaupt 
durchgeführt wurde. Bei gleichem Datenstand kommt ja immer ein entsprechende 
Meldung.

Meine konkrete Frage:
Es kann ja nicht sein, dass es zwei Tage (oder auch länger) dauert, bis die 
Spiegelserver aktualisiert wurden. Was kann man dagegen tun?
Vorschlag 1: Deaktivieren aller Spiegelserver, da das Konzept wohl nicht 
funktioniert
Vorschlag 2: Deaktivieren der Spiegelserver, die aus welchen Gründen auch immer 
nicht aktuell gehalten werden (können)
Vorschlag 3: Ich konfiguriere meine Installation so, dass sie keine oder nur 
bestimmte Mirror-Server nutzt. Wo mache ich das? Früher ging das in der 
Konfiguration im EM, seit 6.0 geht das nicht mehr. Man ist also auf Gedeih und 
Verderb darauf ausgeliefert, dass die Mirror-Server korrekt laufen. Was sie 
aber nicht tun...

Lieben Gruß,
André

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 6.2.4, felogin: Login in IE10 nicht möglich

[André Spindler]

Eben getestet. Funktioniert bei mir.
Dann beim Antworten hier gesehen, dass vom veralteten IE10 die Rede ist.
Habe nur die aktuelle Version 11 am Start. Sorry.

-Ursprüngliche Nachricht-
Von: typo3-german-boun...@lists.typo3.org
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Jost Baron
Gesendet: Dienstag, 15. Juli 2014 13:23
An: typo3-german@lists.typo3.org
Betreff: [TYPO3-german] Typo3 6.2.4, felogin: Login in IE10 nicht möglich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin!

Aus irgendeinem Grunde kann man sich auf einer Seite nicht im frontend
einloggen, wenn man mit dem IE10 unterwegs ist. Mit dem neuesten
Chrome funktionierts. Woran kann das liegen? Gibt es workarounds?

Einstellungen: Es werden salted passwords genutzt, loginsecurity ist rsa.

Gruß Jost
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPFDw8ACgkQNme/yCvmvTK4HACgh4T5Sm8UWOI2vRBIV4aZrRG2
bnUAn0JhlvoiWLyENTbHiwdJSHwSV6x0
=JFUx
-END PGP SIGNATURE-
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] DB-Update nach Hochladen einer neuen Extension Version?

[André Spindler]

Hallo Liste!

Ich habe auf einer Installation eine Extension per Upload aktualisiert,
welche neue Datenstrukturen mitgebracht hat.
Wurde im Entwicklungssystem mit neuen Features versehen und dann
rüberkopiert.

Wie kann ich da ein Datenbank-Update machen? Der alte EM hatte das immer
angezeigt und die entsprechende SQL-Befehle auch schon zur Ausführung
angeboten.
Unter den neuen TYPO3 Versionen 6.x finde ich das nicht mehr.
Aber wie mache ich das? Nach dem Upload war die Datenbank-Struktur noch die
gleiche.

Ich habe mir beholfen, die Extension nach dem Hochladen erst zu deaktivieren
und dann zu aktivieren. Die neuen Tabellen und Felder waren da.
Dafür wurden in den Typoscript-Templates alle Einbindungen gelöscht und ich
musste die Typoscript-Einbindung neu machen.

Aber das kann's doch alles nicht sein:
1. bei Abhängigkeiten müssen alle darauf aufbauenden Extension auch erst mal
deaktiviert werden.
2. in dem Fall war's nur ein Typoscript-Template. Es soll aber durchaus
Installationen mit mehreren Seitenästen und Root-Templates geben. Da fällt
das dann überall raus.
3. Bei der Aktualisierung aus dem TER werden die Strukturen offensichtlich
angepasst. Vielleicht sollten jetzt alle Entwickler und Agenturen sämtliche
Versionen ihrer Extension noch ins TER pumpen, damit solche Probleme nicht
auftreten? Aus meiner Sicht auch keine Lösung...

Oder kann mir jemand sagen, wie ich das manuell auslöse?

Lieben Gruß,
André

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] femanager

[André Spindler]

Hallo Peter.

Bei mir läuft das problemlos. Hast du mal alle Caches geleert?
Beim femanager gab es zwischendrin mal deutliche Umbauten bei den
Validierungen und einhergehend auch bei den Labels. Nicht, dass da noch was
altes im Cache hängt...

Lieben Gruß,
André


-Ursprüngliche Nachricht-
Von: typo3-german-boun...@lists.typo3.org
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Peter
Linzenkirchner
Gesendet: Donnerstag, 19. Juni 2014 19:41
An: German TYPO3 Userlist
Betreff: [TYPO3-german] femanager

Hallo Liste 

weiß jemand, wie es möglich ist, die E-Mails und Warnmeldungen von femanager
ins Deutsche zu übersetzen? Bei mir sind aktuell zwar die Labels in Deutsch,
aber die versendeten E-Mails und ein Teil der Fehlermeldungen sind Englisch.


Prinzipiell geht es ja über Typoscript (wie in der Doku auch beschrieben),
aber bevor ich mich daran mache, an die Hundert Einträge per Typoscript in
drei Sprachen zu übersetzen, möchte ich vorher ausschließen, dass ich nichts
übersehe ... :-) Evtl. muss man die sprachen der E-Mails irgendwo angeben,
und ich finde die Einstellung nur nicht. 

Die Spracheinstellungen der Installation habe ich upgedatet. 
TYPO3 6.2.3 und aktuelle Version des femanager. 

Danke
Peter



--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] 6.2 Installation Links

[André Spindler]

Auf einem System mit mehreren Installationen lässt sich das noch optimieren, um 
Aufwand bei Release-Updates zu sparen:

-t3
--typo3_src-4.5.34
--typo3_src_4.5.current - ./typo3_src-4.5.34
--typo3_src-6.1.9
--typo3_src_6.1.current - ./typo3_src-6.1.9
--typo3_src-6.2.3
--typo3_src_6.2.current - ./typo3_src-6.2.3
:
-www.domain1.de
--htdocs
---typo3_src - ../../t3/typo3_src-4.5.current
:
-www.domain2.de
--htdocs
---typo3_src - ../../t3/typo3_src-6.1.current
:
-www.domain3.de
--htdocs
---typo3_src - ../../t3/typo3_src-6.2.current
:
-www.domain4.de
--htdocs
---typo3_src - ../../t3/typo3_src-6.2.current


Wenn die 6.2.4 rauskommt, stellst du nur den Symlink von typo3_src-6.2.current 
um. Und schon sind alle 6.2er-Installationen up-to-date!
Release-Updates beinhalten (normalerweise!) keine Breaking changes und so war 
das bei mir bisher auch nie ein Problem. Habe so ein System seit nun über einem 
Jahr bei mir laufen.
Bei einem Upgrade (z.B. domain2.de auf TYPO3 CMS 6.2) musst du natürlich dort 
in der Präsenz auf den anderen Ast wechseln, klar.

Lieben Gruß,
André


-Ursprüngliche Nachricht-
Von: typo3-german-boun...@lists.typo3.org 
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von bernd wilke
Gesendet: Mittwoch, 18. Juni 2014 12:25
An: typo3-german@lists.typo3.org
Betreff: Re: [TYPO3-german] 6.2 Installation Links

Am 18.06.14 12:00, schrieb Wechsler:
 Guten Tag gepflegte Community

 Ich habe eine Verständnis Frage zu den drei Links, welche neu gesetzt
 werden müssen.

 Meine Ordnerstruktur sieht folgendermassen aus:

 -www.webseite.de
 -- htdocs

 Auf welcher Ebene kommen nun die Links und auf welcher der Typo3 Source?
 Kommt die Src nun in das htdocs? Und die Links neben das htdocs?

 PS: Lässt sich Typo3 auch ohne die neuen links auf typo3_src
 installieren?


die Links sind zur einfachen Verwaltung unterschiedlicher TYPO3 Versionen.

wo genau dein typo3_src-6.2.3 liegt ist eigentlich egal.

innerhalb deines htdocs muss auch nicht unbedingt ein typo3_src/ 
existieren. es macht das folgende nur einfacher:

-www.webseite.de
--htdocs
---typo3_src (symlink zu typo3_src-6.2.3/ o.ä.)
---typo3 (symlink zu typo3_src/typo3/ [1])
---index.php (symlink zu typo3_src/index.php [2])

[1] also indirekt auf .../typo3_src-6.2.3/typo3/
[2] also indirekt auf .../typo3_src-6.2.3/index.php

wenn es jetzt ein update gibt braucht nur der symlink typo3_src auf die 
neue Version geändert werden und die anderen beiden anderen Links 
stimmen weiterhin.

je nach Serverstruktur kannst du deine TYPO3 sourcen neben htdocs 
ablegen oder auch neben deine domains.

gerade wenn es diverse Installationen/Domains auf einem Server gibt 
empfiehlt sich ein Verzeichnis mit allen TYPO3-Versionen zu erstellen, 
wovon dann jeweils die benötigte Version per Symlink in die einzelnen 
Installationen gelinkt wird.

also zb.

-t3
--typo3_src-4.5.34
--typo3_src-6.1.9
--typo3_src-6.2.3
-www.domian1.de
--htdocs
---typo3_src - ../../t3/typo3_src-4.5.34
:
-www.domian2.de
--htdocs
---typo3_src - ../../t3/typo3_src-6.1.9
:
-www.website.de
--htdocs
---typo3_src - ../../t3/typo3_src-6.2.3
:


bernd
-- 
http://www.pi-phi.de/cheatsheet.html
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] veraltete Extension (gridelements) / PHP-version

[André Spindler]

Es gibt natürlich noch eine andere Möglichkeit:

Auf meinem System läuft zwar CentOS 6.5, das brachte aber ursprünglich auch nur 
ein PHP 5.3.10 mit.
Neuere und auch performantere PHP-Versionen parallel dazu auf einem Server geht 
nicht, weil ein paar Installationen noch unter 5.3 laufen und ich definitiv 
weiß, dass manche Extensions Probleme machen werden. Migration ist diesen 
Sommer bzw. Herbst geplant.

Wobei das nicht stimmt: Als Apache-Modul (modphp) kann sich nur ein PHP-Binary 
einbinden. Die Alternative bzw. die Lösung ist fastcgi.
Damit kann ich für jeden einzelnen vhost ein separates PHP-Binary verwenden. 
Das von Hand zu konfigurieren, ist allerdings extrem aufwändig. Da du aber (wie 
ich) Plesk 11.5 nutzt, geht das einfach vonstatten. Plesk macht nämlich die 
ganze Arbeit...
Von Haus aus gibt es aber im Plesk nur php-fastcgi in der Version, die du 
direkt über deinen Paketmanager im System hast.
Es hindert sich aber niemand daran, dir ein aktuelles php zusätzlich aufs 
System zu holen. Sourcen herunterladen, Kompilieren (dauert) und in Plesk 
registrieren.
Ich habe unter 
http://www.stone-is.com/en/blog/hosting/compiling-multiple-php-versions-for-plesk-115-centos-64-x64/29/
 dazu ein Tutorial gefunden.
Ist konkret für CentOS geschrieben, aber das allgemeine vorgehen sollte damit 
klar werden. Ich gehe davon aus, dass du als Serveradmin weißt, wie du neue 
Programme auf deinem System kompilierst. Das entscheidende ist nur gegen Ende 
die Registrierung deines neuen fastCGI-Moduls in Plesk. Aber das sollte auf 
jeder Distribution identisch sein.
Ich habe mir damit zusätzlich noch PHP 5.4 und 5.5 auf den Rechner gezogen. Die 
TYPO3 4.5er und die eine 4.7er Installation laufen noch unter dem nativen 5.3, 
die 6.1 TYPO3-Versionen mit PHP 5.4 und auf die migrierten 6.2er TYPO3s lasse 
ich das PHP 5.5 los. Bis jetzt keine Probleme.

Und wenn man schon dabei ist, kann man notfalls noch eines der letzten 5.3er 
dazu nehmen und ist halt dann bei PHP 5.3.24 oder so...

Vielleicht hilft dir das weiter :)

Lieben Gruß,
André


-Ursprüngliche Nachricht-
Von: typo3-german-boun...@lists.typo3.org 
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Alto Speckhardt
Gesendet: Mittwoch, 18. Juni 2014 09:11
An: German TYPO3 Userlist
Betreff: Re: [TYPO3-german] veraltete Extension (gridelements) / PHP-version

Hallo Michael,


 Teste die kopierte Site auf dem neuen Server sorgfaeltig (lass am Besten
 den Kunden mit-testen und bestaetigen).
 Sofern alles ok ist [...]

Auch das klingt für mich nicht richtig. Selbst wenn auf den ersten
Blick keine Probleme auftreten, es bleibt stets ein Restrisiko, und
das ist nicht gut genug.

Die einzige Möglichkeit, das Extension-Update unter Mißachtung der 
Versions-Warnung durchzuführen wäre für mich, wenn der Extension-Autor 
sagen kann, ob die Warnung eine Formalität ist oder eine handfeste 
Ursache hat, die man lieber nicht ignorieren sollte.

Das und nichts anderes wollte ich mit meiner ursprünglichen Frage
herausfinden.


-- 
Mit freundlichem Gruß
Alto Speckhardt
mailto:a...@treadstone79.de

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german