Re: [TYPO3-german] [Typo3 7.6.x] Performance von concatenate & compress von CSS/JS

[Dave Zen]

Das automatische Zusammenfassen ist schon schick - keine Frage. Es werden sogar 
die CSS Dateien aus den hinzugeladenen Extensions beachtet.

Die eigenen CSS/JS Dateien können mit Grunt ohne weiteres zusammengefasst und 
komprimiert werden, jedoch werden dann die CSS/JS Dateien aus den Extensions 
nicht beachtet und das ist schlecht. Diese tauchen dann wieder als einzelne 
Links auf. Ich kann die eigenen Dateien zwar minimieren aber wenn ich diese 
dann trotzdem vom Typo3 zusammenfassen lassen muss, ist der zeitliche Vorteil 
den man durch Grunt erreicht (um nur eine minimierte/zusammengefasste Datei 
auszuliefern) dahin.

Die einzige Alternative wäre, die CSS/JS Dateien aus den Extensions manuell der 
Gruntfile hinzuzufügen, oder? Das wäre zwar etwas Aufwand, da man immer 
aufpassen muss das man beim Hinzufügen von neuen Extensions nichts vergisst 
bzw. wenn man eine Extension löscht muss man vermutlich auch die CSS/JS Dateien 
in der Gruntfile löschen.

Gibt es da eine bessere Lösung?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Grids for bootstrap keine Spalten

[Schuler Andre]

Hallo
Ich habe auf: http://goldsuchen.ch.quarz.ch-meta.net/index.php?id=32
«Grids for bootstrap» (Typo3 8) am laufen. In einem Accordion möchte ich drei 
Spalten darstellen (col-md-3).
Leider werden die Spalten im Accordion nicht ausgegeben. An was kann das liegen?
Freundlicher Gruss
André
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Templavoila Bilderkopien loswerden

[Rumen Petrov]

Hallo zusamen,

In einer typo3 Installation, die auf v6.0 aufgesetzt wurde, wurden flexible 
Templavoila Elemente verwendet, die auch Bilder enthielten. Durch 
Referenzierung eines Elementes erstellt TV Kopien der Bildern, so dass sich 
über die Jahre relativ viele Datein und große Datenmengen angesammelt haben.
Mittlerweile wurde die Installation auf 7.6.23 upgegraded inkl. 
Templavoilaplus-Update.
Es liegen nun ca. 6,6 GB an Bildern unter fileadmin, jedoch sind durch unzählige Kopien davon die 
Ordner "fileadmin/_migrated/pics" auf 5,2 GB und "uploads/tx_templavoilaplus" 
auf 8,9 GB angewachsen.
In diesen Ordnern liegt meisten die Originaldatei, die auch ursprünglich im 
Fileadmin hinterlegt wurde, sowei viele Kopien, an die -01.jpg, -02.jpg, 03.jpg 
etc angehangen wurde.

Ich suche nun einen Weg, diese doppelten Bilder loszuwerden, am besten über die 
Datenbank und dem Filesystem.
Mir schweben folgende Möglichkeiten im Kopf rum:
- Ein Tool, das doppelte Dateien anhand Dateigröße / Hash erkennt, löscht und 
mit gleichem Dateinamen einen symbolischen Link auf die Originaldatei anlegt
- Ein Tool, das die Originaldatei im Fileadmin lokalisiert und in der Datenbank alle 
Einträge dahingehend ändert, dass nicht mehr die Kopien referenziert werden. Dazu müsste 
natürlich der urpsüngliche Unterordner aus Fileadmin ermittelt werden, da 
Ordnerstrukturen in diesen "processed" Ordnern ja nicht mit übernommen wurden.
- Zumindest schon mal die Bilder löschen / markieren, die nicht mehr verwendet 
/ referenziert werden.

Ist jemand mit solchen Cleanups vertraut oder kennt Tools, die weiterhelfen?

Besten Dank schon mal im Voraus!
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] kurioses Verhalten unter 7.6.9

[Steffen Liebig]

Hmm...das war's wohl doch nicht. Wir hatten auch noch nie zwei Sprachen, 
aber man weiß ja nie, auf welchen Wegen sich sowas noch ergeben kann. 
Ich muss mal schauen, ob der Fehler wieder auftaucht  und schaue 
beizeiten wieder rein, ob es neue Ideen gibt - dito, wenn ich selbst 
eine Lösung finde.


Am 26.01.2018 um 19:37 schrieb Birgit:

Hallo Steffen,

hatte gestern das Gleiche gesehen in einer 7.6 Installation.

Die Ursache war, dass Einstellungen einer zweisprachigen Website kopiert wurden 
in eine einsprachige.

Prüf mal config.linkVars und realurl_conf.php.

Im Beispiel sah das so aus:

  im Typoscript Setup

config.linkVars = L(0,1)

in realurl_conf.php war gesetzt:

1 => array (
 'GETvar' => 'L',
 'valueMap' => array (
 'de' => '0',
 'en' => '1'
 ),
 'noMatch' => 'bypass‘,

Hätte da noch gestanden:
'valueDefault' => ‚de'
hätte real_url auch kein /de/ eingehängt trotz linkVars.

de = 0 ging ins Leere und warf den Fehler, weil das fehlte:

config {
 sys_language_uid = 0
 language = de
}

Vielleicht hilft es dir.


viele Grüße
Birgit



Am 26.01.2018 um 18:34 schrieb Steffen Liebig :

Hallo zusammen,

mir kam die Tage eine Fehlermeldung in die Mailbox, derzufolge eine Unterseite nicht 
erreichbar sei. Das Problem war schnell gefunden - es hatte sich ein "/de" in 
die Adresse gemogelt. Wir nutzen Typo3 7.6.9.

Zunächst dachte ich, es läge an den News, wo der Fehler entdeckt wurde. Ich 
kopiere die Adressen in eine andere Unterseite, wo Links zu den News stehen. 
Vermutlich hat dort jemand einen Link angeklickt und das System fand die Seite 
nicht.

Auf diesem Weg tauchte es bei den News auf, was mir dann gemeldet wurde - dachte ich 
zunächst. Heute fand ich heraus, dass Typo3 selbst vor jede Unterseite dieses 
"/de" setzt. Offenbar nur sporadisch, ich kann also den Fehler nicht richtig 
reproduzieren. Könnte sein, dass das mit dem Löschen des Caches zusammenhängt. Aber wieso 
fängt es dann irgendwann wieder damit an ?

Eigentlich sollte sowas gar nicht auftreten. Wir hatten noch nie eine 
Sprachsteuerung im Einsatz. Selbst wenn diese nur im Hintergrund mitliefe, 
sollte das dann eher dauerhaft auftreten und damit schon früher aufgefallen 
sein.

Hat jemand eine Ahnung, wie so ein Fehler zustande gekommen sein könnte ?

Besten Dank für jede Anregung

Steffen


PS: Über einen Umstieg auf Typo3 8 brauchen wir nicht zu reden. Es wäre aber 
denkbar, dass das Problem dort wieder auftaucht. Außerdem hatte ich mit der 8 
wieder andere Probleme, die sich nicht lösen ließen. Das Thema habe ich 
abgehakt.

___
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 7.6.x] Performance von concatenate & compress von CSS/JS

[sas]

Hallo. wenn man heutzutage SCSS/LESS schreibt erübrigt sich das meist mit 
GRUNT/GULP. Dennoch lasse ich meist per TYPO3 die Skripte nochmals 
zusammenfassen. Oft muss man dann aber einzelne davon ausschließen, sonst kann 
es zu Fehldarstellungen oder Skriptfehlern kommen.

font-awesome = blah../font-awesome.min.css
font-awesome {
   #excludeFromConcatenation = 1
   disableCompression = 1
}

Das mit den Skripten muss man nicht so eng sehen, wenn danach der Redakteur in 
einen Slider 10 Bilder à 700kb packt ...
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: Keine PDF Generierung auf Windows Server IIS

[sas]

Kurzes Update.

Ich verwende jetzt GraphicsMagick auf dem Windows Server 2012 R2.
Trotzdem ändert sich nichts. Graphics Magick funktioniert alle Bildformate 
werden geschrieben, außer PDF und AI

Woran könnte das liegen? Weiß jemand Rat?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Frage zu Domain Records

[Birgit]

Hallo Michael

ich setze immer:

config.baseURL = https://meine-domain.de/
config.absRefPrefix < config.baseURL
config.prefixLocalAnchors = all

In der realurl_config.php setzt du ja die id der Rootpage pro Domain.

Es kann sein, dass die autoconfig von realurl nicht klar kommt, wenn eine 
Domain ausgeblendet ist.
Das habe ich noch nicht probiert.
Ich baue mir die realurl_config.php immer selbst.



viele Grüße
Birgit

> Am 31.01.2018 um 15:19 schrieb Michael :
> 
> Hallo Birgit,
> 
> 
> zum zweiten Mal ganz herzlichen Dank für Deine Antworten!
> 
> Stichwort "domainübergreifende Verhalten": Diese Typoscript-Settings dürften 
> doch "nur" dann aktiv werden, wenn die
> Seite aktiv ist, auf die sich das Template bezieht, oder?
> 
> Nochmals kurz mein Beispiel:
> 
> Home1:
>   Als Anfang der Website benutzen = TRUE
>   DOMAIN = domainA
>   absRefPrefix = /
>   ... Unterseiten ...
> 
> Home2:
>   Als Anfang der Website benutzen = TRUE
>   DOMAIN = domainB
>   absRefPrefix = /
>   ... Unterseiten ...
> 
> 
> Wenn Home2 DEAKTIVIERT ist, wird Home1/domainA unter dem Hostnamen domainB 
> aufgerufen. EGAL, was ich im Template für
> Home1 setze, content_from_pid_allowOutsideDomain = 0 oder FALSE ändert nichts.
> 
> Spannend finde ich, dass realURL in diesem Szenario alle Links auf "domainB/" 
> setzt, sie  sind also "tot".
> domainB/index.php?id= funktioniert aber.
> 
> 
> Stichwort "Installtool / Fehlerseite":
> 
> [FE][pageNotFound_handling] steht bei mir so ziemlich von Anfang an auf 
> "true". Da TYPO3 immer noch eine Menge
> Geheimnisse vor mir hat, vermeide ich Automatismen, wo es geht. Und ein 
> eindeutiger Fehler ist mir lieber als eine
> nebulöse Weiterleitung "The next visible page upwards in the page tree is 
> shown" ;-)
> 
> Somit habe ich also noch keine Idee, warum TYPO3 zwar domainübergreifende 
> Links auf Wunsch sauber verbieten lässt, bei
> direktem Aufruf über einen anderen Hostnamen (domainB), bei deaktivierter 
> Root Home2 und somit deaktiviertem Domain
> Record domainA, trotz anderem Domain Record (domainA), die Seite  Home1 
> anzeigt.
> 
> Spannend sind auch meine Ergebnisse aus Deinem Tipp:
> 
>> Standardmäßig ist das die nächste erreichbare Seite.
> 
> Ich habe jetzt als Workaround versucht, direkt unter der Wurzel des 
> Seitenbaums, also vor allen "wichtigen" Teilbäumen
> pro Domain, eine "Dummy Landing Page" anzulegen. So einfach wie möglich, 
> page.10.value = Hier hat irgendwas nicht
> funktioniert!
> 
> 
> Wenn Home2 jetzt DEAKTIVIERT ist:
> 
> - wird bei Aufruf von domainB/
>   diese Dummy Landing Page aufgerufen
> 
> -> Genau was ich möchte, wenn schon keine Fehlermeldung kommt.
> 
> 
> - wird bei Aufruf von domainB//index.php?id=
>   die Seite  aufgerufen
> 
> -> Genau das, was ich NICHT möchte :-(
> 
> 
> 
> Abschließende Frage: Mich überrascht dieses Verhalten, habe ich da ein von 
> TYPO3 beabsichtigtes Verhalten noch nicht
> verstanden, oder würdet Ihr das als Bug einstufen?
> 
> 
> 
> 
> Viele Grüße,
> Michael
> 
> 
> 
> Am 30.01.2018 um 19:15 schrieb Birgit:
>> Hallo Michael,
>> 
>> 
>>> Jeder Versuch, z.B. an
>>> RealURL vorbei einen id=.. Aufruf von domaiA auf domainB zu versuchen, 
>>> führt zu "The page did not exist or was
>>> inaccessible. Reason: ID was outside the domain", prima.
>> 
>> das domainübergreifende Verhalten ließe sich bei Bedarf über Typoscript 
>> Setup steuern mit:
>> 
>> config {
>>   // zeige Inhalt dieser Seite
>>   content_from_pid_allowOutsideDomain = 1
>>   // Befindet sich der Link ausserhalb des roots wird die entsprechende 
>> Domain an den Link gehängt
>>   typolinkCheckRootline = 1
>> // domainübergreiefende Links erlauben 
>>   typolinkEnableLinksAcrossDomains = 1
>> }
>> 
>>> Da ich aber konkret an "Home2" gerade bastele, ist mir aufgefallen, dass 
>>> TYPO3 IMHO etwas unerwartet reagiert, wenn z.B.
>>> Home2 deaktiviert ist. Ein Aufruf über "http(s)://domainB" landet in dem 
>>> Fall auf domainA, TYPO3 "sucht" sich also in
>>> diesem Fall die "erstbeste" andere Startseite.
>>> 
>>> Kann man das (einfach) irgendwie abstellen?
>> 
>> Hatte ich heute auch in einer neuen Installation mit drei Domains.
>> Es wird die Fehlerseite aufgerufen.
>> 
>> Standardmäßig ist das die nächste erreichbare Seite.
>> Bei zwei Domains nebeneinander ist das dann die Startseite der sichtbaren 
>> Domain.
>> 
>> Du kannst im Installtool eine Fehlerseite definieren.
>> In dem Fall wäre evtl. eine statische HTML-Seite sinnvoll, die du z.B. in 
>> fileadmin hinterlegen kannst.
>> 
>> 
>> viele Grüße
>> Birgit
>> 
>> 
>> 
>> 
>> 
>>> Am 30.01.2018 um 19:06 schrieb Michael :
>>> 
>>> TYPO3 8.7.9
>>> 
>>> 
>>> Hallo zusammen,
>>> 
>>> 
>>> ich habe folgenden Seitenbäume:
>>> 
>>> Home1:  
>>> Als Anfang der Website benutzen = TRUE
>>> DOMAIN = domainA
>>> absRefPrefix = /
>>> ... Unterseiten ...
>>> 
>>> Home2:  
>>> Als Anfang der Website 

Re: [TYPO3-german] Frage zu Domain Records

[Michael]

Hallo Birgit,


zum zweiten Mal ganz herzlichen Dank für Deine Antworten!

Stichwort "domainübergreifende Verhalten": Diese Typoscript-Settings dürften 
doch "nur" dann aktiv werden, wenn die
Seite aktiv ist, auf die sich das Template bezieht, oder?

Nochmals kurz mein Beispiel:

Home1:  
Als Anfang der Website benutzen = TRUE
DOMAIN = domainA
absRefPrefix = /
   ... Unterseiten ...

Home2:  
Als Anfang der Website benutzen = TRUE
DOMAIN = domainB
absRefPrefix = /
   ... Unterseiten ...


Wenn Home2 DEAKTIVIERT ist, wird Home1/domainA unter dem Hostnamen domainB 
aufgerufen. EGAL, was ich im Template für
Home1 setze, content_from_pid_allowOutsideDomain = 0 oder FALSE ändert nichts.

Spannend finde ich, dass realURL in diesem Szenario alle Links auf "domainB/" 
setzt, sie  sind also "tot".
domainB/index.php?id= funktioniert aber.


Stichwort "Installtool / Fehlerseite":

[FE][pageNotFound_handling] steht bei mir so ziemlich von Anfang an auf "true". 
Da TYPO3 immer noch eine Menge
Geheimnisse vor mir hat, vermeide ich Automatismen, wo es geht. Und ein 
eindeutiger Fehler ist mir lieber als eine
nebulöse Weiterleitung "The next visible page upwards in the page tree is 
shown" ;-)

Somit habe ich also noch keine Idee, warum TYPO3 zwar domainübergreifende Links 
auf Wunsch sauber verbieten lässt, bei
direktem Aufruf über einen anderen Hostnamen (domainB), bei deaktivierter Root 
Home2 und somit deaktiviertem Domain
Record domainA, trotz anderem Domain Record (domainA), die Seite  Home1 anzeigt.

Spannend sind auch meine Ergebnisse aus Deinem Tipp:

> Standardmäßig ist das die nächste erreichbare Seite.

Ich habe jetzt als Workaround versucht, direkt unter der Wurzel des 
Seitenbaums, also vor allen "wichtigen" Teilbäumen
pro Domain, eine "Dummy Landing Page" anzulegen. So einfach wie möglich, 
page.10.value = Hier hat irgendwas nicht
funktioniert!


Wenn Home2 jetzt DEAKTIVIERT ist:

- wird bei Aufruf von domainB/
diese Dummy Landing Page aufgerufen

-> Genau was ich möchte, wenn schon keine Fehlermeldung kommt.


- wird bei Aufruf von domainB//index.php?id=
die Seite  aufgerufen

-> Genau das, was ich NICHT möchte :-(



Abschließende Frage: Mich überrascht dieses Verhalten, habe ich da ein von 
TYPO3 beabsichtigtes Verhalten noch nicht
verstanden, oder würdet Ihr das als Bug einstufen?




Viele Grüße,
Michael



Am 30.01.2018 um 19:15 schrieb Birgit:
> Hallo Michael,
> 
> 
>> Jeder Versuch, z.B. an
>> RealURL vorbei einen id=.. Aufruf von domaiA auf domainB zu versuchen, führt 
>> zu "The page did not exist or was
>> inaccessible. Reason: ID was outside the domain", prima.
> 
> das domainübergreifende Verhalten ließe sich bei Bedarf über Typoscript Setup 
> steuern mit:
> 
> config {
>// zeige Inhalt dieser Seite
>content_from_pid_allowOutsideDomain = 1
>// Befindet sich der Link ausserhalb des roots wird die entsprechende 
> Domain an den Link gehängt
>typolinkCheckRootline = 1
> // domainübergreiefende Links erlauben 
>typolinkEnableLinksAcrossDomains = 1
> }
> 
>> Da ich aber konkret an "Home2" gerade bastele, ist mir aufgefallen, dass 
>> TYPO3 IMHO etwas unerwartet reagiert, wenn z.B.
>> Home2 deaktiviert ist. Ein Aufruf über "http(s)://domainB" landet in dem 
>> Fall auf domainA, TYPO3 "sucht" sich also in
>> diesem Fall die "erstbeste" andere Startseite.
>>
>> Kann man das (einfach) irgendwie abstellen?
> 
> Hatte ich heute auch in einer neuen Installation mit drei Domains.
> Es wird die Fehlerseite aufgerufen.
> 
> Standardmäßig ist das die nächste erreichbare Seite.
> Bei zwei Domains nebeneinander ist das dann die Startseite der sichtbaren 
> Domain.
> 
> Du kannst im Installtool eine Fehlerseite definieren.
> In dem Fall wäre evtl. eine statische HTML-Seite sinnvoll, die du z.B. in 
> fileadmin hinterlegen kannst.
> 
> 
> viele Grüße
> Birgit
> 
> 
> 
> 
> 
>> Am 30.01.2018 um 19:06 schrieb Michael :
>>
>> TYPO3 8.7.9
>>
>>
>> Hallo zusammen,
>>
>>
>> ich habe folgenden Seitenbäume:
>>
>> Home1:   
>>  Als Anfang der Website benutzen = TRUE
>>  DOMAIN = domainA
>>  absRefPrefix = /
>> ... Unterseiten ...
>>
>> Home2:   
>>  Als Anfang der Website benutzen = TRUE
>>  DOMAIN = domainB
>>  absRefPrefix = /
>>
>> ... Unterseiten ...
>>
>>
>> Webserver Apache, pro DOMAIN ein VHOST. Beide aber identisch bis auf 
>> "ServerName", also "DocumentRoot", "> etc. identisch, da beide ja für eine TYPO3 Instanz.
>>
>> Funktioniert exakt so, wie ich es wünsche, wenn BEIDE Seiten Home1 und Home2 
>> aktiviert sind: Jeder Versuch, z.B. an
>> RealURL vorbei einen id=.. Aufruf von domaiA auf domainB zu versuchen, führt 
>> zu "The page did not exist or was
>> inaccessible. Reason: ID was outside the domain", prima.
>>
>>
>>
>> realURL trägt auch sofort die "Sprechende URL" "/" mit "ID der Wurzelseite" 
>> = Home2 (domainB) in die URL-Daten aller in
>> Menüs verwendeter Seiten 

[TYPO3-german] Composer-Fehler

[M. Cigdem Klengel]

Hallo allerseits,

ich habe einen Testserver für TYPO3 mit der Version 7.6.23.
Bei einigen composer-Spielerreien (Hinzufügen einer zu installieren 
Extension) habe ich ein simples composer.phar update ausgeführt, was 
dazu geführt hat dass ich bei jedem erneuten Aufruf des Befehls folgende 
Meldung erhalte:


Installation of typo3/cms is not possible any more for TYPO3 versions 
9.0.0 and higher.
Please require typo3/minimal instead for minimum required TYPO3 system 
extensions,

and/or require individual system extensions like typo3/cms-extension-name
E.g. composer require typo3/cms-tstemplate
[RuntimeException]
Installation stopped.

Teile aus der composer.json:

  "extra": {
    "typo3/cms": {
  "cms-package-dir": "vendor/typo3/cms",
  "web-dir": "web"
    }
  },
  "minimum-stability": "dev",
  "name": "Typo3composer",
  "repositories": [
    {
  "type": "composer",
  "url": "https://composer.typo3.org/;
    }
  ],
  "require": {
    (...)
    "typo3/cms": "^7"
  }
}


Ehm, ich habe meine TYPO3 Version gar nicht geupdatet, ich falle also 
überhaupt nicht in den 'for TYPO3 versions 9.0.0 and higher' .

Hat jemand eine Idee was los sein könnte?
Es ist nur ein Testserver, notfalls ist der fix wieder aufgesetzt, aber 
ich würd schon gern wissen was los sein könnte.


Schöne Grüße,
Cigdem


---

"The thing about programming is that sometimes you just have
to accept that ‘magic’ is a perfectly good explanation for why
something works."
 
---



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

Re: [TYPO3-german] Frage zu Domain Records

[Michael]

Hallo Markus,


ganz herzlichen Dank für Deine Antwort, auch wenn ich dieses schon wusste.

Grund für meine scheinbare Redundanz ist, dass ich mit separaten .conf Files je 
VHOST auf Apache-Ebene Domains quasi
ein- und und ausschalten kann. Evtl. Apache Standard, zumindest aber in 
OpenSuse werden alle .conf unter
/etc/apache2/vhosts vom Apache herangezogen. Meine Vhost .conf heissen dann 
z.B. 1_localhost-80.conf, 2_domain-tld.conf,
3_roundcubemail-443.conf usw. Und mit

mv 3_roundcubemail-443.conf 3_roundcubemail-443.conf.SAV
system reload apache

kann ich dann z.B. sehr simpel Roundcube "nach außen", also über die externe 
URL webmail.domain.tld, temporär "offline"
setzen. Über einen ssh Tunnel (localhost:) komme ich aber nach wie vor 
dran, um Upgrades etc. machen zu können.

Sobald eine konkrete Domain / ein Vhost fehlt, greift dann eine Wildcard 
Umleitung auf eine statische HTML Seite.

Gilt auch für TYPO3, da meine Webseiten (zum Glück) (noch?) so einfach sind, 
dass ich seit meinem Start, mit 7.6.13
glaube ich, jeden Upgrade bis zur aktuellen Version 8.7.9 völlig stressfrei in 
Minuten durchführen konnte. Meist direkt
am Tag des Announcements.

Auch für das in meiner Mail nachgefragte TYPO3-interne Domain-Szenario nutze 
ich je Domain zusätzlich einen eigenen
Vhost, für besagten Mechanismus. In frühen "Bastelphasen" greife ich auf neue 
Seiten über einen SSH-Tunnel auf localhost
zu. Evtl. mangelndes TYPO3-Wissen, aber wenn ich z.B. einen Domain-spezifischen 
Seitenbaum ab der Wurzel deaktiviere,
oder auch über das Modul "Arbeitsumgebungen" in einer Entwicklungsumgebung 
arbeite, funktioniert zwar beachtlich viel.
Aber afaik das eine oder andere leider nicht. realURL und Entwicklungsumgebung 
oder einer deaktivierten Seite klappt bei
mir nicht wirklich, möchte ich aber vor Freigabe testen, Wobei generell als 
One-Man-Show der "Freigabeprozess" denkbar
einfach ist: ich schiebe per "Stapelverarbeitung" wenn ich denke fertig zu sein 
alles in die Live-Umgebung.



Nochmals Danke,
Michael



Am 31.01.2018 um 11:07 schrieb Marcus Raphelt:
> Moin,
> 
> kurz dazu: wenn beide sowieso quasi identisch sind, kannst Du auch nur einen 
> VHost mit ServerName und ServerAlias
> verwenden.
> Also
> 
> ServerName www.domain1.de
> ServerAlias www.domain2.de
> DocumentRoot /var/www/blah/web
> 
> Gruß
> Marcus
> 
> Am 30.01.18 um 19:06 schrieb Michael:
>> Webserver Apache, pro DOMAIN ein VHOST. Beide aber identisch bis auf 
>> "ServerName", also "DocumentRoot", "> etc. identisch, da beide ja für eine TYPO3 Instanz.
>>
>>
> 
> ___
> 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] 4.5 sicher machen

[Marcus Raphelt]

Hallo,

das CMS ist in dem Fall nur eine Komponente des Gesamtsystems... es 
nützt zwar schon, Typo in dem Fall hinreichend sicher zu konfigurieren, 
aber mal so grob:


-Datenbank: der Benutzer sollte nur Rechte für die Typo-DB haben
-Die Datenbank sollte von außen nicht erreichbar sein
-Der Webspace muss inkl. Benutzern und Gruppen abgeschottet sein, auch 
in Bezug auf die Datei- und Ordnerrechte
-Der Typo3-Core sollte auf readonly gesetzt werden. Ich persönlich lege 
die Typo-Cores grundsätzlich außerhalb aller Webroots ab und setze sie 
auf root:root.

-Unnötige Extensions entfernen (Quixplorer, phpmyadmin, phpshell...)

Bonus points:
-Kein Zugriff per FTP
-Kein Backendzugriff ohne SSL
-Backend per Basic Auth schützen
-Regeln für fail2ban aufsetzen, die Angriffe auf den Webspace
-Apache mod_security

Gruß
Marcus

Am 31.01.18 um 10:40 schrieb B2:

Hallo zusammen,
hat jemand Erfahrung damit eine Typo3 Version 4.5 sicher zu machen?
Es geht um eine Seite mit viel Content welches man möglichst sicher 
machen möchte, "ohne auf die neuen Versionen" zu gehen. Extensions 
kann man reduzieren auf das Minimum.
Aus einem anderen CMS System kenne ich dass man SQL Datenbanken intern 
umbenennen kann, Backend mit Passwortschutz versehen kann. Gibt es 
eine Trickkiste um so etwas sicherer im Netz zu sein für die 4.5 Version?


Gruss Martin

___
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] Frage zu Domain Records

[Marcus Raphelt]

Moin,

kurz dazu: wenn beide sowieso quasi identisch sind, kannst Du auch nur 
einen VHost mit ServerName und ServerAlias verwenden.

Also

ServerName www.domain1.de
ServerAlias www.domain2.de
DocumentRoot /var/www/blah/web

Gruß
Marcus

Am 30.01.18 um 19:06 schrieb Michael:

Webserver Apache, pro DOMAIN ein VHOST. Beide aber identisch bis auf "ServerName", also 
"DocumentRoot", "

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

Re: [TYPO3-german] 4.5 sicher machen

[M. Cigdem Klengel]

Hallo Martin,

es geht ja nicht nur darum, sondern auch um die Version der 
unterstützten DB und PHP, die unsicher werden, da keine 
(Sicherheits)Updates dafür geliefert werden. Es ist das ganze 
Zusammenspiel von aktuellem CMS, aktueller DB- und PHP-Version, die die 
Sicherheit bringen.


Schöne Grüße,
Cigdem


Am 31.01.2018 um 10:40 schrieb B2:

Hallo zusammen,
hat jemand Erfahrung damit eine Typo3 Version 4.5 sicher zu machen?
Es geht um eine Seite mit viel Content welches man möglichst sicher 
machen möchte, "ohne auf die neuen Versionen" zu gehen. Extensions 
kann man reduzieren auf das Minimum.
Aus einem anderen CMS System kenne ich dass man SQL Datenbanken intern 
umbenennen kann, Backend mit Passwortschutz versehen kann. Gibt es 
eine Trickkiste um so etwas sicherer im Netz zu sein für die 4.5 Version?


Gruss Martin

___
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] 4.5 sicher machen

[B2]

Hallo zusammen, 

hat jemand Erfahrung damit eine Typo3 Version 4.5 sicher zu machen? 

Es geht um eine Seite mit viel Content welches man möglichst sicher machen möchte, "ohne auf die neuen Versionen" zu gehen. Extensions kann man reduzieren auf das Minimum. 


Aus einem anderen CMS System kenne ich dass man SQL Datenbanken intern 
umbenennen kann, Backend mit Passwortschutz versehen kann. Gibt es eine 
Trickkiste um so etwas sicherer im Netz zu sein für die 4.5 Version?

Gruss Martin

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