[TYPO3-german] Update von 6.2.12 auf 6.2.15 unter Windows
Hallo, ich möchte gerne aufgrund der Sicherheitslücke auf 6.2.15 updaten. Dabei erhalte ich folgende Meldung: "Automatic TYPO3 CMS core update not possible: Update not supported on Windows OS" Wie kann ich unter Windows (Server 2008 / IIS 7.5) das Update am besten manuell durchführen? Vielen Dank und Grüße Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Update von 6.2.12 auf 6.2.15 unter Windows
Hallo Arne, vielen Dank für den super Tipp. Gruß Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] [TYPO3 CMS 7.6] Dependency Injection
Hallo zusammen, Ich habe einen Controller der eine Utility Klasse injected. Jetzt möchte ich von dieser Utility Klasse auch auf den Controller zugreifen. Wenn ich den Controller allerdings in meiner Utility Klasse via inject einbaue, bekomme ich einen "Cyclic dependency" Fehler. Gibt es in meiner Utility Klasse irgendeine Verbindung zu meinem Controller? Ist das immer nur eine Einbahnstraße? 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] realURL: "Sprechende URL" für Startseite wird nicht (mehr?) verwendet
TYPO3 8.7.9
realURL 2.3.1
Hallo zusammen,
ich habe vorhin folgendes entdeckt, von dem ich glaube, dass es neu ist, evtl.
seit meinem Update auf realURL 2.3.1 vor
ein paar Tagen:
- Bei Aufrufen der Startseite über eine Domain wird diese Startseite ohne
"Sprechende URL", d.h. /index.php?id=...,
aufgerufen.
- In sämtlichen Menüs und Sitemaps werden die "Sprechenden URLs" fehlerfrei
angezeigt und verwendet
- Aufruf der Startseite mit "Sprechender URL" funktioniert auch.
==> Ich bin mir ziemlich, aber leider nicht 100%tig sicher, dass diese erste
Weiterleitung auf die Startseite bis vor
kurzem auf die "Sprechende URL" verweisen hat. <==
Wäre schön, wenn das (wieder) funktioniert.
Daher folgende Frage(n):
- Kann ich realURL evtl. irgendwie dazu bekommen, alle URL-Daten / Pfaddaten
neu zu generieren? Diese Schaltflächen
"Alle Einträge ... löschen (schädlich!)" in den Backend-Masken von realURL
flößen mir einen Heidenrespekt ein :-)
- Wurde hier evtl. Logik in realURL 2.3.1 heimlich oder von mir überlesen
geändert?
Mein Seitenbaum sieht wie folgt aus:
- Wurzel = "Verweis" (auf Startseite), Nicht in sprechende URL aufnehmen =
TRUE, Pfadsegment für untergeordnete Seiten =
leer, Verweismodus = Ausgewählte Seite, Als Anfang der Website benutzen = TRUE.
...
- Startseite, Typ Standard, Nicht in sprechende URL aufnehmen = FALSE,
Pfadsegment für untergeordnete Seiten = "home"
Die Domain wurde auf der Wurzelseite definiert, Parameter zur Umleitungs-URL
übertragen = FALSE, In Links immer diese
Domain voranstellen = FALSE
Im Template (gültig für alle hier relevanten Seiten):
config {
absRefPrefix = /
linkVars = L
uniqueLinkVars = 1
# realURL
tx_realurl_enable = 1
}
realURL Settings:
basic.enableAutoConf = TRUE
basic.autoConfFormat = PHP source (slow)
Webserver ist Apache.
Bei Aufruf von http://:
- 301 Moved Permanently auf httpS://
- 307 Temporary Redirect auf https:///index.php?id=...
Vielen Dank für alle Antworten/Tipps!
Lieben Gruß,
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] realURL: "Sprechende URL" für Startseite wird nicht (mehr?) verwendet
Hallo Birgit,
so tief war ich dann doch noch nicht in die Doku vorgedrungen, ganz vielen
herzlichen Dank für Deine schnelle Antwort !!!
Funktioniert jetzt mit dem "Tausch" der Startseiten zwar anders als
ursprünglich vorgesehen, aber aus FE-Sicht gefällt
es mir sogar besser. Früher war die URL der Einstiegsseite /home, jetzt
ist es nur noch /. Einfacher für
den Nutzer. Alle Menüs etc. komplett sauber, alles funktioniert.
Aus BE-Sicht fand ich das "Lehrbuch-Beispiel" /Seiten 1-n zwar
irgendwie "ordentlicher", kann ich aber prima mit
leben :-)
Viele Grüße,
Michael
Am 30.01.2018 um 11:26 schrieb Birgit:
> Hallo Michael,
>
> die Rootpage bzw. Homepage darf kein Shortcut mehr sein.
>
> Du musst ggf. den Shortcut umkehren von der Home-Seite zur Rootpage der
> Domain.
>
> https://github.com/dmitryd/typo3-realurl/wiki/Notes-for-Integrators
>
>
> Viele Grüße
> Birgit
>
>
>> Am 30.01.2018 um 05:07 schrieb Michael :
>>
>> TYPO3 8.7.9
>> realURL 2.3.1
>>
>>
>> Hallo zusammen,
>>
>>
>> ich habe vorhin folgendes entdeckt, von dem ich glaube, dass es neu ist,
>> evtl. seit meinem Update auf realURL 2.3.1 vor
>> ein paar Tagen:
>>
>> - Bei Aufrufen der Startseite über eine Domain wird diese Startseite ohne
>> "Sprechende URL", d.h. /index.php?id=...,
>> aufgerufen.
>> - In sämtlichen Menüs und Sitemaps werden die "Sprechenden URLs" fehlerfrei
>> angezeigt und verwendet
>> - Aufruf der Startseite mit "Sprechender URL" funktioniert auch.
>>
>> ==> Ich bin mir ziemlich, aber leider nicht 100%tig sicher, dass diese erste
>> Weiterleitung auf die Startseite bis vor
>> kurzem auf die "Sprechende URL" verweisen hat. <==
>>
>> Wäre schön, wenn das (wieder) funktioniert.
>>
>> Daher folgende Frage(n):
>>
>> - Kann ich realURL evtl. irgendwie dazu bekommen, alle URL-Daten / Pfaddaten
>> neu zu generieren? Diese Schaltflächen
>> "Alle Einträge ... löschen (schädlich!)" in den Backend-Masken von realURL
>> flößen mir einen Heidenrespekt ein :-)
>> - Wurde hier evtl. Logik in realURL 2.3.1 heimlich oder von mir überlesen
>> geändert?
>>
>>
>>
>>
>> Mein Seitenbaum sieht wie folgt aus:
>>
>> - Wurzel = "Verweis" (auf Startseite), Nicht in sprechende URL aufnehmen =
>> TRUE, Pfadsegment für untergeordnete Seiten =
>> leer, Verweismodus = Ausgewählte Seite, Als Anfang der Website benutzen =
>> TRUE.
>> ...
>> - Startseite, Typ Standard, Nicht in sprechende URL aufnehmen = FALSE,
>> Pfadsegment für untergeordnete Seiten = "home"
>>
>>
>> Die Domain wurde auf der Wurzelseite definiert, Parameter zur Umleitungs-URL
>> übertragen = FALSE, In Links immer diese
>> Domain voranstellen = FALSE
>>
>>
>> Im Template (gültig für alle hier relevanten Seiten):
>>
>> config {
>>
>> absRefPrefix = /
>> linkVars = L
>> uniqueLinkVars = 1
>>
>> # realURL
>> tx_realurl_enable = 1
>>
>> }
>>
>>
>> realURL Settings:
>>
>> basic.enableAutoConf = TRUE
>> basic.autoConfFormat = PHP source (slow)
>>
>>
>> Webserver ist Apache.
>>
>> Bei Aufruf von http://:
>> - 301 Moved Permanently auf httpS://
>> - 307 Temporary Redirect auf https:///index.php?id=...
>>
>>
>>
>>
>>
>> Vielen Dank für alle Antworten/Tipps!
>>
>> Lieben Gruß,
>> 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] Frage zu Domain Records
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", "http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Frage zu Domain Records
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] Frage zu Domain Records
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
[TYPO3-german] 9.5.21: Site configuration / robots.txt
Hallo, kurze Frage. Ich habe in den neuen Option zur "Site Configuration" versucht, über "Static Routes" eine einfache robots.txt anzulegen. So wie ich es aus den Docs https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/SiteHandling/StaticRoutes.html verstanden habe, wird hier eine statische Seite parallel zum üblichen Weg über CONTENT etc. erzeugt. Ich bekomme aber einen HTTP/404 für meinedomain.tld/robots.txt , klappt also nicht. Tipps, was ich falsch gemacht haben könnte? Viele Grüße, Michael -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 9.5.21: Site configuration / robots.txt
>> Am 28.09.2020 um 14:14 schrieb Gert Redlich : >> >> Am 28.09.2020 13:30, schrieb Michael: >>> Hallo, >>> >>> kurze Frage. Ich habe in den neuen Option zur "Site Configuration" >>> versucht, über "Static Routes" eine einfache robots.txt anzulegen. >>> So wie ich es aus den Docs >>> https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/SiteHandling/StaticRoutes.html >>> verstanden habe, >>> wird hier eine statische Seite parallel zum üblichen Weg über CONTENT >>> etc. erzeugt. >>> >>> Ich bekomme aber einen HTTP/404 für meinedomain.tld/robots.txt , >>> klappt >>> also nicht. >>> Tipps, was ich falsch gemacht haben könnte? >>> >>> Viele Grüße, >>> Michael >> >> Hallo Michael, >> >> warum so umständlich, >> >> warum die robots.txt nicht einfach ins root Verzeichnis des >> jweweiligen Webs plazieren ? >> >> wo ist der Vorteil ? >> >> -- >> >> mit freundlichen Grüßen >> Gert Redlich >> ___ Am 2020-09-28 15:16, schrieb li...@berlin-typo3.de: > Die im Site-Modul konfigurierte robots.txt ist nur dann vorteilhaft, > wenn in der Installation mehrere Domains/Websites angelegt sind, die > jeweils eigene robots.txt haben sollen. > > Was funktioniert nicht? > Wird keine Datei im Hauptverzeichnis angelegt - oder kannst du in der > URL keine robots.txt aufrufen? > > Viele Grüße > Birgit > > 2in1 Antwort am Birgit und Gert :-) Ich nutze TYPO3, um zwei (kleine) Webauftritte auf einem Apache laufen zu haben. Mit einer TYPO3 Instanz. Separate "Sites" in TYPO3, jeweils mit eigener Domain. Die "DocumentRoot" und "Directory" Direktiven in der Apache VHOST Definition zeigt auf (das gleiche) Verzeichnis .../typo3root Wenn ich auf Dateisystem-Ebene, am TYPO3 vorbei, da ein robots.txt File hinlege, wird das vom Apache auch gefunden. Wobei mir aber schon nicht mehr klar ist, ob dieses dann vom Apache "direkt" ausgliefert wird, oder "indirekt" über TYPO3. Auf jeden Fall habe ich dann aber "nur" eine einzige robots.txt, für beide Domains, also http(s)://domainA.tld/robots.txt und http(s)://domainB.tld/robots.txt liefern die gleiche Datei. Was natürlich auch machbar ist, so kompliziert aufgebaut und vor allem inhaltlich wichtig sind meine beiden Sites nicht. Aber die Sub-Struktur ist unterschiedlich, eine "AllInOne" robots.txt mit den zu durchsuchenden Pfaden für beide Sites hieße dann, dass die Crawler in Pfade geschickt würden, die es nur spezifisch pro Site gäbe. Daher fand ich diese recht neue Möglichkeit, sowas doch in eine über das Backend zu verwaltende Konfiguration pro Domain/Site eigentlich der Idee nach sehr einfach, "straightfoward" auf denglish :-) Zu Birgits Frage > Wird keine Datei im Hauptverzeichnis angelegt Nein, wenn ich nicht wie oben beschrieben eine robots.txt manuell erzeuge, dann existiert unterhalb der DocumentRoot keine robots.txt. In der gesamten Substruktur nicht. Ich verstehe aber schon nicht wirklich, ob die überhaupt da sein müsste: Meine ursprüngliche Vermutung war, dass eine über die Site Configuration erstellte "StaticRoute" auch dynamisch zum Abruf von TYPO3 generiert/gerendert wird. Die Site Configuration erlaubt ja z.B auch das Abfangen von HTTP/403, 404 etc., das habe ich als Weiterleitung auf eigens in TYPO3 dafür angelegte simple Seiten ausprobiert, klappt prima. Mein evtl. falsches Verständnis war daher, dass der Apache jede beliebige Pfad/URL unter http(s)://domainAoderB.tld/ an TYPO3 übergibt/weiterreicht. Viele Grüße, Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 9.5.21: Site configuration / robots.txt
Am 2020-09-28 18:53, schrieb Gert Redlich: >> ___ > > Hallo Michael, > > ich habe auf einem virtullen Webserver 9 domains laufen > > unter anderen diese 4 großen Webs > > www.fernsehmuseum.info (und .de) > www.magnetbandmuseum.info (und .de) > www.tonbandmuseum.info > www.hifimuseum.de > > auch mit subdomains > > dort sind 4 oder sogar mehr robots.txt spezifiziert > > das Handling macht der Apache, weils im root zu finden ist. > > das ist der einfache gerade Weg - und auch kontrollierbar > und vermutlich ausreichend Hallo Gert, danke erst einmal für Deine nette ausführliche Antwort. > Virtueller Webserver / 9 Domains: Meinst Du damit ein VHOST für alle 9 Domains? Wenn ja, wäre ich neugierig, wo Deine verschiedenen robots.txt dann bei Dir stehen, so wie ich es verstanden habe, gäbe es dann ja nur eine DocumentRoot? > das Handling macht der Apache, weils im root zu finden ist. Das war auch meine erste Vermutung, aber der 404 wird durch TYPO3 angezeigt. Genau da fängt aber mein Nichtverstehen an: - Ich will vom Apache domain.tld/robots.txt - Apache gibt das, weil ServerName/VHOST eben ein TYPO3-Vhost ist, an TYPO3 weiter - TYPO3 wirft den 404 aus, wenn Datei nicht physikalisch da --> Warum, wenn doch genau das laut Doku die "static route" in der Site Defintion ausliefern soll? Grübelnde Grüße, Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Content nach eingespieltem Backup verschwunden
On 27/03/12 21:43, "M.Graßhoff" wrote: [...] > Dabei kam raus, dass Direct Mail das Problem verursacht, dass im FE kein > Content mehr angezeigt Wurde. [...] > Sobald ich Direct Mail wieder hinzufüge, kein Content mehr... Stammt das Plesk-Backup vielleicht von einem anderen server? Falls ja: was ist anders? PHP Version? TYPO3 Version? memory limit? execution time? etc. Und heisst "kein content im FE", dass eine "weisse" Seite dargestellt wird? Dann ggf. log level erhoehen und log files anschauen. HTH - Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3 installations & extension status monitoren
On 2012-04-11 19:36, Tobias Liegl wrote: [...] ein Kunde wünschst sich verschiedene typo3 installationen auf verschiedenen servern bei verschiedenen hostern zu "monitoren" Caretaker könnte sein was du suchst: http://www.typo3-caretaker.org/ Etwas aufwendiger, aber moeglicherweise die etwas flexiblere Loesung koennte "Nagios" sein: http://nagios.org/ Damit ueberwacht man ueblicherweise Server, Dienste, Netzwerke usw. und laesst sich warnen (per Email, SMS oder was auch immer), wenn ein Server ausgefallen ist, Plattenplatz knapp wird, bestimmte Dienste nicht mehr reagieren, Speicherprobleme auftreten usw. Ein Nagios Server zusammen mit der TYPO3 Extension "nagios" kann dich auch warnen, wenn eine bestimmte, zum Beispiel veraltete, TYPO3 Version laeuft oder eine Extension betrieben wird, die "insecure" ist. http://schams.net/nagios Eine Auswahl weiterer Loesungen findest du unter "Similar Projects" bei http://schams.net/nagios Siehe auch Diskussion vom August 2011: http://lists.typo3.org/pipermail/typo3-german/2011-August/080188.html Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] RSS-Feed der Extensions vom TER
On 13/04/12 17:36, untangler wrote: [...] > um einen Überblick über die Aktualisierungen zu haben. > Seit 2. April gibt es leider keine Aktualisierungen mehr. > Wird es mit dem neuen TER wieder einen RSS-Feed für die Extensions geben? Ersatzweise halten dich folgende Feeds auf dem Laufenden. Neue Extensions: http://t3extensions.org/feed/extensions/new.xml Extension Updates: http://t3extensions.org/feed/extensions/updates.xml Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] [TYPO3-core] Announcing TYPO3 4.4.15, 4.5.15 and 4.6.8
On 19/04/12 04:39, Peter Linzenkirchner wrote: > Wer nach dem Update auf 4.5.15 das Problem hat, dass Redakteure Teile > des Seitenbaums nicht mehr ausklappen können: das ist ein kleiner Bug > im Update, der sich nicht bei Admins auswirkt. [...] Ich frage mich immer wieder, warum bei TYPO3 Core Updates security fixes mit "normalen" bug fixes vermischt werden? Bei einer so maechtigen und komplexen Applikation wie es TYPO3 ohne Zweifel ist, ist es voellig normal, dass ein Update Seiteneffekte haben kann und sich soetwas wie der Bug #36238 einschleichen kann. Das Einspielen von Sicherheitsupdates kann nicht in Frage gestellt werden, aber derzeit riskieren Service Provider immer gleichzeitig neue Bugs, wenn eine neue TYPO3 version released wird. Mir ist klar, dass es einen 100% bug-freien Zustand wohl nie geben wird (jeder bug-fix kann weitere bugs erzeugen), allerdings wuerde ein Core Update, das *ausschliesslich* einen security fix beinhaltet, das Risiko deutlich reduzieren. Zumindest ist mir bisher kein Fall bekannt, bei dem ein security fix neue bugs erzeugt hat :-) Kurzum: gibt es eine plausible Erklaerung, warum security updates nicht ausschliesslich den fix der sicherheitsluecke beinhalten, so wie es auch bei extension updates vorgeschlagen wird: http://typo3.org/teams/security/extension-security-policy/ Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] [TYPO3-core] Announcing TYPO3 4.4.15, 4.5.15 and 4.6.8
On 19/04/12 21:23, Björn Pedersen wrote: [...] >>> Ich frage mich immer wieder, warum bei TYPO3 Core Updates security fixes >>> mit "normalen" bug fixes vermischt werden? [...] >> Das Hauptproblem: Man-power, um die fixes in weitere 3 branches zu >> integrieren und zu testen(!). > http://lists.typo3.org/pipermail/typo3-team-core/2011-December/051034.html Danke fuer den Link zum Thread. Ich kann den erhoehten Aufwand durchaus nachvollziehen :-) Allerdings sehe ich bei dem aktuellen Prozess ein echtes Risiko und da es nicht zum ersten Mal passiert ist, dass sich bei einem Security Release Fehler eingeschlichen haben, die die Arbeit von Redakteuren beeintraechtigten, habe ich auch Verstaendnis fuer Admins, die mit dem Einspielen von Security Releases zoegern (und erst einmal Abwarten, ob die Community moeglicherweise Bugs mit dem Release meldet), was ja auch nicht die Loesung sein kann. Aber gut zu wissen, dass dieses Problem bereits bekannt ist. Ich werde das weiter verfolgen :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Updates
On 2012-04-23 19:36, Heike Herzog-Kuhnke wrote: Tja, dass heißt dann letztendlich in den sauren Apfel beißen, sobald eine Security-Info ankommt. Bei den Extensions mache ich das sowieso. Das ist eben eine Frage der Risiko-Abschaetzung. Nicht jeder Bug muss sofort ge'fixed werden, da er unter Umstaenden deine Redakteure gar nicht betrifft oder man kann ihn umgehen. Auch bei Security Updates kann eine Abschaetzung erfolgen - abhaengig von der jeweiligen TYPO3 Instanz, Konfiguration usw. Es macht auf jeden Fall Sinn, sich das bulletin genau durchzulesen und dann zu entscheiden, ob die eigene(n) Instanze(n) ueberhaupt betroffen sind, die Schwachstelle ausgenutzt werden kann, usw. Ein paar weitere Infos zum Thema findet man auch in der Pflicht-Lektuere "TYPO3 Security Guide" ;-) http://typo3.org/extension-manuals/doc_guide_security/current Schade nur, dass man solche Scurity-Patches nicht einfach über den Extension-Manager oder etwas ähnliches laden kann. Das würde den typo3-Nutzern, die nur die Sicherheitslücke schließen wollen ein paar feuchte Pfötchen ersparen, die so ein Upgrade, zumindest für die noch nicht ganz so fest im Sattel sitzenden typo3 User mit sich bringt. Nun, eine strikte Trennung zwischen "Core" und "Extensions" steht wohl ausser Frage - allerdings gibt es bereits mehrere Diskussionen, ob Sicherheitsupdates mit "normalen" Bugfixes vermischt werden sollten, siehe: http://lists.typo3.org/pipermail/typo3-german/2012-April/084570.html http://lists.typo3.org/pipermail/typo3-team-core/2011-December/051034.html Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Wartungsvertrag TYPO3 ?
On 2012-05-03 18:58, Björn Hahnefeld wrote: Stelle dich als Beispiel einmal Euren Wartungsvertrag in die Liste und lass das diskutieren. Solche Wartungsvertaege sind ja auch sicher fuer andere recht interessant und auf diese Weise koennte man einen Muster Wartungsvertrag gemeinsam erarbeiten an dem man sich orientieren kann. Das würde auch mich freuen, denn ich wäre ebenfalls an so etwas interessiert! Ich habe so dunkel in Erinnerung, dass es diese Initiative schon einmal vor ein paar Monaten gab (und ich glaube sogar in dieser mailing list) und das irgendwer sogar angefangen hat, etwas darueber im Wiki zu schreiben. Vielleicht findet ja jemand etwas dazu :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Obsolete Extensions which are not marked obsolete
On 27/07/12 02:16, Christian Wolff wrote: [...] >> Wer nicht mindestens einmal im Jahr bei seiner Extension im TER nachschaut >> und diese entsprechend markiert wird ganz einfach ins Archiv verschoben [...] > ich würde zum veralteten extension eher folgenden ansatz pflegen: [...] > in ter suche würde ich unmaintained extensions per default nicht listen > (über erweiterte optionen natürlich zugänglich) > es gab vor einigerzeit (ein jahr oder so) schon mal eine diskursion zu > dem thema. Ich glaube, es gab schon mehrere Versuche, das aktuelle Konzept vom TER zu ueberarbeiten. Die letzte Initiative liegt nur ein paar Monate zurueck: http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-January/003933.html Die darauf folgende Diskussion zog sich ueber einige Wochen hin... http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-January/thread.html http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-February/thread.html http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-March/thread.html ...bis letztendlich eigentlich ein ganz guter Ansatz gefunden wurde. Nur um die Umsetzung hat sich anscheinend noch niemand gekuemmert :-) Und da wir mittlerweile auch schon kurz vor dem "feature freeze" der TYPO3 version 6.0 stehen, befuerchte ich, dass selbst einer der grundlegensten features (siehe unten) nicht in die neue Version eingeflossen ist (aber ich kann mich taeuschen). Force TYPO3 dependency setting on TER upload: http://forge.typo3.org/issues/37150 Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] lokalen mirror vom TER repository
On 03/08/12 21:16, Andi wrote: >>> Aber mal ne andere Frage: wie gross ist eigentlich das komplette TER, da >>> werden ja auch noch zig Versionen von Extensions gespeichert? >> >> wuerde mich an dieser Stelle auch mal interessieren. Infos darueber hatte >> ich leider auch nicht finden koennen. Im TER wurden bisher ca. 27000 .t3x Files veroeffentlicht. Das sind ungefaehr 5600 TYPO3 extensions. Saemtliche Files belegen ca. 10GB an Speicherplatz. Von den jeweils zuletzt veroeffentlichten Versionen sind uebrigens ca. 1900 als "BETA" (34%), 1800 als "STABLE" (33%) und 1400 als "ALPHA" (26%) deklariert (die restlichen als obsolete, experimental, test oder unknown). Und fuer die Statistiker unter uns: in den letzten 365 Tagen wurden 475 *neue* Extensions und 1032 Extension-Updates veroeffentlicht :-) Stand: 04 August 2012 - und alle Angaben ohne Gewaehr. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] lokalen mirror vom TER repository
On 05/08/12 12:09, Andreas Becker wrote: > All dieses klumb gehoert ausgemissted und in ein separates TER Archiv. dem stimme ich zu... zumindest teilweise :-) ich habe kein problem damit, 5600 extensions (oder mehr) in einem repository unter typo3.org liegen zu haben, oder deren meta daten durch einen import des extensions.xml files in den datenbanken zu halten. aber ich glaube, fast alle von uns interessieren sich nur fuer einen bruchteil dieser menge, wenn es darum geht, bei der taeglichen arbeit mit TYPO3 extensions zu suchen und zu importieren/installieren. der grossteil der extensions - ich nenne ihn mal "unmaintained extensions" - wird sehr selten benoetigt. daher waere es wuenschenswert, aus der gesamtmenge den (ir)relevanten teil filtern zu koennen. > Wer seine Extension in den letzten 365 Tagen nicht ein einziges mal > ueberprueft und an die LTS UND die current stable Vsn angepasst hat > fliegt raus und wird ins ARCHIV gepackt bis er die Extension wieder > updated! wir haben diese tolle "dependency" einstellung fuer extensions. dort kann man als ext entwickler u.a. die min/max TYPO3 version angeben. diese angabe koennte zwingend sein und die "max" TYPO3 version duerfte nicht groesser, als die aktuellste stable version sein (z.B. TYPO3 v4.7.10). extensions, die nicht mehr upgedated werden, wuerden somit automatisch in den "unmaintained" status fallen, sobald eine neue TYPO3 version released wird (und der entwickler nicht zumindest eine neue version mit angepasster dependency hochlaedt). im extension manager koennte man dann "unmaintained" extensions per default einfach *nicht* anbieten; das selbe fuer die suche im TER oder in irgendwelchen anderen systemen, die auf der extension list basieren. mit dieser policy wuerden keine extensions geloescht oder in ein archiv verschoben werden. das heisst, auch faelle, in denen man doch noch alte extensions benoetigt (oder diese zumindest anzeigen moechte), werden weiterhin beruecksichtigt. es geht eher um die klassifizierung von "unmaintained" extensions und die damit verbundene filterung. dieses konzept wurde vor ein paar monaten erarbeitet und diskutiert, siehe meine verweise im folgenden thread: http://lists.typo3.org/pipermail/typo3-german/2012-July/086995.html ...nur um die Umsetzung hat sich anscheinend noch niemand gekuemmert. > Danke Michael fuer diesen imposanten Einblick. ich hatte mir auch mal die arbeit gemacht und untersucht, was es denn praktisch bedeuten wuerde, wenn man nur noch extensions anzeigt (z.B. im EM oder im TER), die momentan ueberhaupt eine gueltige dependency zu TYPO3 versionen haben... dabei musste ich feststellen, dass das derzeit nur ein ganz geringer teil ist, was bedeutet, dass man zuerst die dependency pflicht einfuehren sollte, bevor man sich ueberhaupt gedanken ueber die filterung macht. ansonst wuerde die anzahl der verfuegbaren extensions naemlich nicht von 5600 auf 1000 schrumpen, sondern auf zwei oder drei hundert (sofern meine untersuchungen stimmen) :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] lokalen mirror vom TER repository
On 05/08/12 20:15, Andreas Becker wrote: > Also dann wuerde ich einfach mal sagen eben diese Pflicht einzufuehren - wo > liegt das Problem? Mir ist niemand bekannt, der sich um die Umsetzung kuemmert... also: hau rein, Andi! ;-) > [...] Das mit den dependencies stimmt, jedoch ist eine > dependency auf eine Extension die nicht mehr maintained wird dann auch im > Grunde nicht das gelbe vom Ei. hmmm... good point! Ueber diesen Fall sollte man sicherlich noch einmal nachdenken. Allerdings hat das ja erst einmal nichts mit der dependency zur TYPO3 version zu tun - oder zumindest nur indirekt. Danke fuer den Diskussions-Anstoss, Andi. Vielleicht traegt das ja zu der "TER Clean-Up" Initiative bei. Aber wir kommen etwas von Thema ab, das hat nichts mehr mit dem "lokalen mirror vom TER" zu tun, befuerchte ich :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Cal Extension Probleme mit externem Kalender und Scheduler
On 08/08/12 19:06, Mirko Schaal wrote: > im PHP-Cli ist allow_url_fopen auf Off und damit konnte > t3lib_div::getUrl den Kalender nicht laden - trotzdem > merkwürdiges verhalten von cal, das dann einfach alle Einträge > gelöscht werden. Naja, wahrscheinlich denkt EXT:cal dann, dass der externe Kalender keine Eintraege hat und will das selbe auch "lokal" abbilden. Hast du schon einen bugreport erstellt? http://forge.typo3.org/projects/show/extension-cal Vielleicht interessiert das Verhalten auch die Enwickler :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 in der Amazon Cloud
On 13/08/12 18:32, Yvon Folz wrote: > Da wir mehrere Instanzen laufen lassen werden. Wie > verhält es sich mit der Conf Datei von Real Url und Typo3 selbst. Hier > steht doch der Domain Name drinnen? Sowie in der Real Url Config? Und was genau ist das Problem? :-) Eine EC2 Instanz ist im Grunde eine ganz normale Maschine, wie bei jedem x-beliebigen Hosting Provider. Die Instanz bekommt (zusaetzlich zu einer privaten) eine oeffentliche IP und einen domain name zugewiesen. Der domain name lautet zum Beispiel: ec2-175-12-34-56.ap-southeast-1.compute.amazonaws.com Wenn du eine andere Domain (zum Beispiel yvon-typo3.com) auf die Instanz zeigen lassen moechtest, traegst du die oeffentliche IP als A-record im DNS ein - oder den Amazon domain name als CNAME. Vorausgesetzt, der Webserver (z.B. Apache) ist richtig konfiguriert, reagiert TYPO3 auf die HTTP Anfragen und du kannst deinen domain name (yvon-typo3.com) in den config files benutzen. Man sollte allerdings zwei grundlegende Sachen beachten: (1) wenn die EC2 Instanz runtergefahren und neu gestartet wird, bekommt sie eine neue IP und einen neuen domain name. Das ist fuer den Produktiveinsatz natuerlich nicht sehr guenstig. Dafuer bietet Amazon aber so genannte "Elastic IPs" an: feste IP Adressen, die an eine Instanz gebunden sind. Siehe: http://www.google.com/search?q=aws+elastic+ip (2) sofern die EC2 Instanz eine "instance store" maschine ist, sind saemtliche Daten fluechtig. Das heisst, nach einem reboot oder restart sind alle Daten weg (inkl. der Daten in der MySQL Datenbank, wenn diese im selben Container wie die Instanz liegt). Das bedeutet, du musst dich selbst darum kuemmern, dass die Daten von Zeit zu Zeit weggeschrieben werden oder du solltest die Instanz als EBS (Elastic Block Store) aufsetzen. > Oder > kann ich diese durch die PHP Umgebungsvariablen problemlos wechseln? ...ich wuesste nicht, wozu man hier PHP Umgebungsvariablen benoetigt. > Sorry. Cloud Dienste sind ein wenig Neuland für mich. Erfahrungswerte? AWS klappt bestens. EBS Instanz mit Debian 6.0.x squeeze, Apache, MySQL und PHP (plus die typischen web-hosting Pakete). Darauf TYPO3 und ein regelmaessiges Backup zu'nem S3 Bucket (mindestens in einer anderen availibility zone, besser in einer anderen geographical location). Eine AWS "micro" Instanz funktioniert, ist aber sehr, sehr langsam. "Small" reicht fuer ein paar kleine TYPO3 sites. Fuer eine high-traffic site mit sehr grossen peaks haben wir mal fuer ein oder zwei Wochen eine "large" Instanz (oder groesser) gestartet. Es gibt noch mehr Potential, wenn man weitere Dienste von Amazon verwenden moechte: das CDN eignet sich besonders gut fuer statische Inhalte. Die MySQL Datenbank koennte man zu Amazon's RDS auslagern und wer eine Vielzahl von Mails versendet sollte sich Amazon SES anschauen. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] RSS-Feed der Extensions vom TER
On 2012-09-12 17:39, Pim Snel wrote: um einen Überblick über die Aktualisierungen zu haben. Seit 2. April gibt es leider keine Aktualisierungen mehr. [...] Ersatzweise halten dich folgende Feeds auf dem Laufenden. http://t3extensions.org/feed/extensions/new.xml http://t3extensions.org/feed/extensions/updates.xml Thanks. I really missed them. and/or follow @t3extensions on Twitter for *new* extension releases: https://twitter.com/#!t3extensions Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Login auf Http oder https-Seite
On 13/10/12 21:05, David Greiner wrote: >>> Sollte eine Seite, die ein Login-Formular (oder wegen mir auch ein >>> anderes Formular) beinhaltet, selbst nur via https aufrufbar sein, oder >>> "reicht" es, wenn das Target der Form eine Https-Seite ist? SSL (also https) verschluesselt die Kommunikation zwischen Client und Server - also die Daten, die zwischen Client/Server ausgetauscht werden. Das Formular an sich ist in den meisten Faellen nicht vertraulich und muss daher meiner Meinung nach nicht unbedingt bereits durch eine https session geschuetzt werden. Die Daten, die im Formular eingegeben und dann durch "submit" an den Server geschickt werden, dagegen schon! Daher muss die in der als action="..." angegebenen Adresse mit https:// beginnen. Browser zeigen dem end-user allerdings heutzutage an, wenn Daten ueber eine geschuetze Kommunikation empfangen/gesendet wurden - zum Beispiel durch eine farbliche Hervorhebung der location bar oder eines Icons in der Statuszeile. Wird das Formular ueber http empfangen, fehlt natuerlich diese Anzeige und dem Benutzer wird erst *nach* dem Absenden angezeigt, dass die Daten ueber eine SSL Verbindung gesendet wurden. Daher kann es von Vorteil sein, bereits das Formular ueber https zum Client zu senden. Bei bestimmten Vorgaengen (z.B. einem Checkout Prozess ueber mehrere Steps bei einem online shop) kann man bereits sehr frueh auf https wechseln, auch wenn noch keine wirklich sensible Daten gesendet werden - beispielsweise gleich am Anfang eines Prozesses, bei dem im weiteren Verlauf zu schuetzende Daten ausgestauscht werden. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Core-Warnungen zu class.t3lib_iconworks.php in sys_log
On 26/10/12 02:42, Peter Linzenkirchner wrote: > [...] Leider ist es eine Life-Installation, so dass ich nicht alle > Extension ausschalten und nacheinander wieder anschalten könnte. > Wenn jemand eine Idee hätte ... ? Kopie der LIVE site auf einer TEST Umgebung herstellen, sicher stellen, dass der Fehler auch in der TEST Umgebung auftritt und dann debuggen? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 CMS Version 4.5.21 BE kann nicht dargestellt werden
On 09/11/12 20:09, Daniel Ceballos | basecom GmbH & Co. KG wrote: > den typo3temp-Ordner habe ich leider schon mehrmals geleert. Dies > erzielte keinen positiven Effekt. Ich habe gerade ein paar TYPO3 4.5.x und 4.7.x auf die jeweils aktuellste Version gebracht - alles reibungslos und ohne Probleme. Ich loesche in der Regel alle Files in typo3temp/ und die temp_* Dateien in typo3conf/ Hast du letzteres schon einmal probiert? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] scheduler_http ???
On 30/11/12 11:02, Ralf-Rene Schröder wrote: [...] > you have to request “http://example.com/index.php?eID=scheduler_http” to > invoke the scheduler. If everything was OK, the time listed under “Last > run” in the “Setup check” of the module “Scheduler” has changed and > “return_var” in frontend will be “0”. > > ich bekomme aber 126 als return_var zurückgeliefert und der scheduler > wird auch nicht angestoßen [...] Ich habe keine Erfahrung mit der EXT:scheduler_http - aber nach einem kurzen Blick in die sourcen der extension vermute ich, dass der Benutzer, unter dem der web-prozess laeuft, das CLI script des schedulers nicht ausfuehren kann: "typo3/cli_dispatch.phpsh" Beispielsweise, weil das script generell nicht ausfuehrbar ist oder nicht ausfuehrbar fuer den o.g. Benutzer oder der Benutzer gar nicht darauf zugreifen kann. Wenn die Berechtigungen zum Beispiel so aussehen: # ls -all typo3/cli_dispatch.phpsh -rwxr--r-- 1 root root 4743 Nov 8 11:50 typo3/cli_dispatch.phpsh und der Apache prozess unter "www-data" laeuft, kann es nicht gehen und ein return value von 126 waere logisch. Sollte das der Fall sein, fallen mir drei Loesungswege ein: (1) aendere die Berechtigungen des Files, z.B. chmod o+x ... Nachteil: jenes musst du ggf. wiederholen, wenn du TYPO3 neu installierst oder ein Update durchfuehrst. Ergo: vergisst man leicht. (2) wende dich freundlich an den/die Entwickler(in) und frage, ob er/sie das Script nicht ueber PHP aufrufen kann. In etwa (natuerlich nicht mit dem hard-coded path): $execCmd = '/usr/bin/php ' PATH_typo3 . 'cli_dispatch.phpsh scheduler'; anstatt (wie jetzt): $execCmd = PATH_typo3 . 'cli_dispatch.phpsh scheduler'; Noch besser waere natuerlich a) die TYPO3 API fuer system calls zu verwenden und b) vorher zu pruefen, ob ein exec() fehlschlagen wuerde. (3) [falls (2) zu keiner Loesung fuehrt] passe die extension selbst an und veroeffentliche deine verbesserte Version im TER. (4) [falls (2) zu keiner Loesung fuehrt und (3) auch nicht geht] frage einen entwickler, der sich damit auskennt und beauftrage ihn/sie :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Wie mit Preview- und Live-Version umgehen?
On 11/12/12 21:53, bernd wilke wrote: >>> Also, es geht darum, wie man eine Preview-Instanz von Typo3 haben kann, >>> die mit einer Live-Instanz synchronisierbar ist. Denn manche Änderungen >>> müssen erst dem Kunden präsentiert werden, bevor sie wirklich live gehen >>> können. [...] >> Aber wenn es 2 Instanzen sein >> sollen, kopier doch die Preview Instanz komplett + DB Dump >> ändere die localconf entsprechend und wenn Änderungen live gehen sollen, >> dann kopier die Datenbank von A nach B Das kommt darauf an... :-) Bei einem *neuen* System ist das bisher geschilderte sicherlich die typische und einfachste Moeglichkeit (machen wir auch so). Problematisch wird's aber, wenn eine bestehende TYPO3 Installation bereits "live" ist, staendigen Aenderungen unterliegt (z.B. Content, FE User Daten, Adress-Datensaetze, etc.) und parallel zu dieser Installation eine Test- oder Preview-Instanz laufen muss. Irgendwann musst du beide Instanzen zusammenfuehren und wenn die Daten in der Test/Preview Instanz dann mittlerweile outdated sind (z.B. weil der Kunde doch mehrere Tage fuer das Review und die Abnahme brauchte), dann kann man nicht mehr einfach die Datenbank auf der Live-Instanz drop'en und gegen die (veraltete) Test/Preview DB ersetzen. Im TER gibt's die EXT:neustastaging (quote) "This extensions provides backend modules and a staging cron script to realise a multi server workflow system with TYPO3." Ich persoenlich habe aber noch keine Erfahrung damit gemacht. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] T3 6.0 inkompatible Erweiterungen z.B. gridelements
On 13/12/12 13:08, Philipp Gampe wrote: >> fragt sich, wer diese Markierung übernehmen soll ... > > Das kann die Community mit ihrem TYPO3.org Account übernehmen. Das waere dann ein Rating und wirft garantiert andere Problematiken auf. Der Developer der Extension sollte mit Leichtigkeit sagen koennen, mit welchen TYPO3 Versionen die Extensions getestet wurde und jenes beim Upload (pflichtmaessig) angeben. >> Das leidige alte Problem halt: Ob eine Extension kompatibel ist, weiß man >> genau dann, wenn man sie installiert hat [...] > > Ist ist angedacht, automatisch die min/max Versionen für die Extensions im > TER zu setzen. Aber man muss halt genau aufpassen, dass man nicht > versehentlich zu viel sperrt, sonst sind die Extension Autoren frustriert. Extensions, die nicht mehr maintained werden, sollten zumindest default-maessig nicht mehr angeboten werden. Das heisst nicht, dass sie nicht mehr zugaenglich sein sollten. > Alternativ könnte man auch eine Angabe der min/max Version beim Upload > erzwingen. Wenn man die aktuelle Stable immer als Höchstwert zulässt, dann > müssten die Extension Autoren halt einmal im halben Jahr eine neue Version > hochladen. Danke Philipp! :-) Siehe thread: http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-January/003933.html Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] JS/CSS Compression für Inline-JS und -CSS
On 01/01/13 06:23, Daniel Bachmann wrote:
> config {
>minifyJS = 0
>minifyCSS = 0
>compressJs = 0
>compressCss = 0
>concatenateJs = 0
>concatenateCss = 0
> }
>
> Ich glaube das funktioniert ab Version 4,6. Ggf. auch 4.5.
Ist meines Wissens nach erst ab 4.6 eingefuehrt worden. "minify*" und
"compress*" sind identisch, wobei "minify" nicht mehr benutzt werden sollte:
config.compressJs is the new name for config.minifyJS which has been
deprecated.
config.compressCss is the new name for config.minifyCSS which has been
deprecated.
see: Rename and deprecate config.minifyJS/config.minifyCSS
http://forge.typo3.org/issues/28677
Ein paar weitere Infos findet man auch in den Release Notes von 4.6,
ganz am Ende der Seite, unter "JS/CSS Compression":
http://wiki.typo3.org/TYPO3_4.6
Ausserdem sollte an dieser Stelle erwaehnt werden, dass "compression of
javascript files with jsmin" in 6.0 wieder entfernt wurde:
(quote) "The default compression of certain javascript files in frontend
and backend with the jsmin library was removed from the core due to
license issues. The code segment was substituted with a hook, so
extensions can now deliver compression solutions if needed. In general,
it is a good idea to configure a webserver to compress javascript and
css files on the webserver with gzip."
see: jsmin.php uses non-free license
http://forge.typo3.org/issues/31832
Man sollte also etwas aufpassen, wie und mit welcher TYPO3 version man
die JS/CSS compression vom core einsetzt :-)
Cheers
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Probleme mit Domainaufruf -> cooluri
On 09/01/13 02:21, Leo Führinger wrote: >> ich habe folgendes Problem in einem Intranet (der Server ist auch nur von >> intern erreichbar): Ich verstehe noch nicht so ganz das Problem... vielleicht geht es anderen auch so :-) >> Das Intranet (Homepage) kann über intranet.firma.de aufgerufen werden. Sie >> liegt in /var/www/html/intranet Das heisst, deine TYPO3 Instanz liegt in "/var/www/html/intranet/", richtig? Also: /var/www/html/intranet/typo3_src /var/www/html/intranet/index.php usw. >> Nun soll die Seite >> auch über intranet.firma.de/intranet aufgerufen werden können. Wozu denn das? Na, egal. Wuerde ein Redirect ok sein? Also, user gibt http://intranet.firma.de/intranet in seinem browser ein, und wird umgeleitet zu: http://intranet.firma.de ? Dann koennte man a) eine Seite namens "Intranet" in TYPO3 erstellen, type: Externe URL und als Ziel "http://intranet.firma.de"; eintragen. Oder b) ein "Redirect" in Apache eintragen (siehe [1]): Redirect /intranet http://intranet.firma.de Oder c) mit Apache's RewriteCond und RewriteRule arbeiten (siehe [2]). >> Hier taucht aber immer ein von cooluri verursachter Fehler auf: >> Die Seite wurde nicht gefunden. Klar, weil es wahrscheinlich keine Seite mit dem Seitentitel "Intranet" gibt... siehe CoolURI cache. >> Cooluri gibt die Homeseite wie folgt aus: >> intranet.firma.de/intranet/home.html Das finde ich etwas seltsam... wenn das DocumentRoot auf "/var/www/html/intranet/" zeigt, wo kommt dann das "/intranet/" in der URL her? Das sieht mir erst einmal nicht nach der default Konfiguration von CoolURI aus. >> Die vhost.conf sieht so aus: >> [...] >> Alias /intranet6 /var/www/html/intranet6/ [...] >> Dieser Alias Eintrag "/intranet6" ist korrekt, oder? Und hat nichts mit der TYPO3 installation zu tun? Und es gibt keinen zusaetzlichen Alias namens "/intranet", richtig? Und in der .htaccess stehen auch keine Eintraege, die dir da irgendwie reinpfuschen? Cheers Michael [1] http://httpd.apache.org/docs/current/mod/mod_alias.html [2] http://httpd.apache.org/docs/current/mod/mod_rewrite.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Kopie auf Windows -> Zeichensatz
On 09/01/13 02:54, A. Sauder wrote:
>>> Den Dump der DB habe ich vom Linux aus gemacht und spiele diesen auch
>>> gleich auf dem Windows Rechner wider ein.
[...]
> Sämmtliche Umlaute werden so angezeigt, als hätte ich ISO-Zeichensatz in
> der DB und die Seite selber UTF-8. Sprich Ü wird zu Ãœ
Schau dir mal die globalen Settings des MySQL servers auf der Windows
Kiste an (file: my.cnf, mysql.ini oder so) und pruefe, ob die explizit
einen UTF8 Datensatz setzen.
Vergleiche (nach dem Import der DB auf der Windows Kiste), wie die
Tabellen auf beiden DB Servern aussehen ("SHOW TABLE STATUS"). Achte
dabei z.B. auf die Spalte "Collation".
Du kannst versuchen, beim Anlegen der Datenbank die collation auf
"utf8_general_ci" o.ae. zu setzen.
Erzwinge die gewuenschte collation beim Import, indem du dem MySQL
dumpfile (weit oben) folgende Zeile hinzufuegst:
SET NAMES 'utf8' COLLATE 'utf8_general_ci'
Vergleiche den character set auf beiden Datenbanken:
SHOW VARIABLES LIKE 'character\_set\_%';
Ausserdem (wird aber wohl nichts bringen, wenn der Dump auf einem
anderen Linux system funktioniert), wenn du denn dump erstellst, setze
mit folgenden Parameter explizit den character set:
--default-character-set=utf8
Und noch ein Tipp:
http://blog.oneiroi.co.uk/mysql/mysql-forcing-utf-8-compliance-for-all-connections/
Cheers and good luck ;-)
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Größe der DB wächst!
Andreas Becker wrote: in der letzten Zeit habe ich das Phänomen, dass die Typo3 DB wächst ohne daran eine Änderung vorgenommen zu haben. index_searched installed und tt_news installed? Hast du denn ein aehnliches Problem mit einer stetig wachsenden Datenbank festgestellt (oder vielleicht sogar einen Loesungsvorschlag dafuer), wenn jenes eindeutig auf index_searched + tt_news zurueckzufuehren ist? Jemand berichtete mir vor einiger Zeit genau von diesem Problem (allerdings wuchsen die Cache tables in der DB dann auf mehrere GB innerhalb einiger Tage) - und ein woechentliches TRUNCATE ist hier sicherlich nicht die ideale Loesung :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Benötige Hilfe bei meinen Templat es
Hager Christian wrote:
[...]
CSS Klassennamen sollten nicht mit einem numerischen Zeichen beginnen.
Besser waere sowas wie zum Beispiel: id="page123" anstatt id="123".
Bei den anderen Template steht in der Body id z.B.: 456, oder 789,
Ich möchte jetzt haben das bei dem Template wo die Body Id "123" ist,
der div "ccc" einen anderen Hintergrund hat. Wenn ich dem div ccc
einen Hintergund per css eingebe ist dies ja dann bei allen Templates
so, und das will ich ja vermeiden.
Suchst du vielleicht sowas wie:
body#page123 div#ccc {
background-color: white;
}
body#page456 div#ccc {
background-color: black;
}
Unter der Verwendung von id="page123", siehe oben :-)
HTH
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Server
On 08/02/13 08:15, Björn Händler wrote: > Wer nur eine Webseite als Visitenkarte zeigen will, ist mit Notepad++ gut > bedient - mehr brauchts nich ;) Quatsch! "vi"... dafuer braucht man noch nicht mal eine grafische Oberflaeche. Alles andere ist overkilled [SCNR] ;-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] powermail 2.0.x und CAPTCHA
Hi, hat es schon jemand geschafft, eine alternative CAPTCHA Loesung in powermail2 zu integrieren? Mir ist bewusst, dass das "offiziell" (noch) nicht geht (siehe Manual), trotzdem wage ich es mal, nachzufragen :-) http://typo3.org/extension-manuals/powermail/2.0.6/view/1/50/ FAQ: How to use another Captcha Extension? "At the moment we support only a calculating captcha in the powermail core. Maybe other extensions in a later version." Es haben mittlerweile mehrere Kunden ihr Unmut ueber das "default" CAPTCHA geaeussert und die bisher verfuegbaren Konfigurations-Optionen (font-size, colour, background, etc.) sind nicht ausreichend :-( Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] powermail 2.0.x und CAPTCHA
On 21/02/13 21:35, Christian Hennecke wrote: >> hat es schon jemand geschafft, eine alternative CAPTCHA Loesung in >> powermail2 zu integrieren? Mir ist bewusst, dass das "offiziell" (noch) >> nicht geht (siehe Manual), trotzdem wage ich es mal, nachzufragen :-) [...] > Es könnte sich lohnen, sich spamshield anzuschauen. Damit gibt es dann > kein captcha mehr, was Benutzer nerven könnte. Müßte eigentlich mit > powermail 2 laufen. Ich bin generell kein grosser Freund von CAPTCHAs. Danke fuer Tipp! Mal sehen, ob spamshield hier helfen kann und ob wir unsere Kunden (die eigentlich explizit CAPTCHAs verlangten) ueberzeugen koennen :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Commerce: Leere Seite bei letztem Schritt des Bestellvorgangs
On 23/02/2013, at 6:30, Roth wrote: > Der Fehler ist folgender: > Fatal error: Class 't3lib_htmlmail' not found > Jetzt hab ich gelesen, dass in 4.7 htmlmail nicht mehr unterstützt wird. > Gibt es eine Alternative dazu? SwiftMailer: http://swiftmailer.org/ http://buzz.typo3.org/teams/core/article/your-first-blog/ > Eigentlich sollte ein adapter das abfangen: [zitat] "Existing extensions will use various mail functions in the current TYPO3 API. To make sure that all mails sent from the TYPO3 installation use the new transport mechanisms an adapter is included which catches all calls to the 'old' functions and forwards them to the Swift Mailer functions. This adapter is not 100% perfect,..." Aber ganz ehrlich - wir reden von einem Feature, was mit TYPO3 4.5 eingefuehrt wurde (gibt es diesen adapter eigentlich immer noch)? Wer jetzt noch htmlmail voraussetzt am besten gleich mal die Entwickler der EXT:commerce fragen, ob das wirklich der Fall ist :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] [t3blog] Mail bei Veröffentlichung
On 28/02/2013, at 10:29, Philipp Gampe wrote: >> TYPO3-Updates und Security Issues > > Dafür gibt es aber die Announce Liste: > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-announce > > Ich empfehle jedem sich dort anzumelden, da auf diesen Kanal immer gesendet > wird, weil es der primäre Kanal ist. ...und der *offizielle* Kanal, neben der "security bulletin" website des Security Teams: http://docs.typo3.org/typo3cms/SecurityGuide/GeneralInformation/SecurityBulletins/Index.html Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Commerce: Leere Seite bei letztem Schritt des Bestellvorgangs
On 04/03/13 09:12, Roth wrote: [...]am besten gleich mal die Entwickler der EXT:commerce fragen, ob das wirklich der Fall ist :-) [...] > Meine Suche nach Kontaktdaten eines EXT Entwickler waren bisher nicht > erfolgreich. Ich suche weiter. Hat jemand einen Tipp bin ich sehr > dankbar dafür. Du meinst die Entwickler der "commerce" extension, oder? Die Project Leader sind derzeit: Ingo Schmitt und Volker Graubaum. http://typo3-commerce.org/ (seems to be offline) http://forge.typo3.org/projects/extension-commerce http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-commerce In der mailing liste findest du auch die Kontaktdaten in der Signatur von Ingo Schmitt (siehe Archiv: Tue Feb 19 08:52:56 CET 2013). Ich wuerde deine Frage einfach an die mailing liste senden und vorher vielleicht mal die issues auf forge.typo3.org checken, ob das Problem nicht schon bekannt ist (siehe URL oben). Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] typo3temp/pics mit 12 MB index
On 18/04/13 23:38, Janine Schendel wrote: Der typo3temp/pics ordner hat eine Indexdatei von 12 MB Was genau ist denn diese "Indexdatei"? Mir waere neu, dass in typo3temp/pics/ irgendwelche Dateien von TYPO3 geschrieben werden, die *keine* Bilder sind. Gibt es zu solchen großen Projekten schon die Möglichkeit den pics Ordner aufzuteilen, neue temporäre Ordner für eigene Extensions anzulegen? Wenn ich dich richtig verstanden habe, bist du auf typo3temp/pics/ gestossen, weil du untersucht hast, warum eure Site so langsam ist. Temporaere Bilder in typo3temp/pics/ sind statische Files und werden (nachdem sie einmal erzeugt wurden) beim Ausliefern zum Client nicht von PHP oder TYPO3 angefasst. Das Erzeugen dieser Files dauert natuerlich eine gewisse Zeit, aber wenn sie existieren, dann werden sie nur noch vom Web-Server versendet. Schonmal untersucht, ob der Server selbst, das Netzwerk oder die Resourcen des Web-Servers optimal sind? Tools, wie z.B. Firebug fuer Firefox koennen auch hilfreich sein, um Zeiten zu messen, um bestimmte Resourcen (HTML generiert von TYPO3 oder statische Files) beim Client zu empfangen. Der größte Teil der Bilder wird von einer eigenen extension verwendet. Wenn es sicher ist, dass der Server oder das Netzwerk zu langsam ist, um Files auszuliefern, eignet sich ggf. ein Proxy/Cache *vor* dem Web-Server (beispielsweise nginx, CloudFront, usw.). Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] nicht benötigte Datenbanktabellen welche können gelöscht werden??
On 25/04/13 02:24, RDE - Gert Redlich wrote: ich habe in einem Projekt eine DB mit ca. 2 GB Größe. Jetzt würde ich gerne wissen welche Tabellen in der DB nicht benötigt werden bzw. wo temporäre Datensätze angelegt werden und welche davon gelöscht werden können. [...] und denke dran, die "innodb" Dateigröße in Deinem mysql Verzeichnis ändert sich erst mal nicht. Auch wenn sämtliche Tabellen geleert "würden", die Filesize bleibt. Hilft hier nicht auch der MySQL Befehl "OPTIMIZE"? http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html Bzw. in der command line mittels: mysqlcheck --optimize [ []] ... ] (oder "mysqloptimize") Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Kickstarter - Server error direkt nach Erstellen der Extension
On 24/04/13 02:21, Silke Capo wrote:
[...]
"HTTP Error 500 (Internal Server Error): An unexpected condition was
encountered while the server was attempting to fulfill the request."
[...]
Ich habe oben in die Extension folgendes geschrieben:
ini_set('error_reporting', E_ALL ^ E_NOTICE);
ini_set("display_errors", 1);
bekomme aber keine Fehlermeldung angezeigt.
Versuch' mal, die Einstellungen in der php.ini vorzunehmen, anstatt in
einer Extension. Abgesehen davon, findest du denn Eintraege in den
webserver logs (access_log oder error_log)?
Cheers
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 6.1 RC1
On 02/05/13 01:46, andy_bright wrote: Bei mir ist MySql 5.0.97 installiert. Da das Problem bei Maximilian auch mit MySQL 5.3.8 auftritt, wird mein Hinweis wahrscheinlich nicht die Loesung sein,... aber bitte beachtet, dass TYPO3 6.1, wie auch schon die TYPO3 6.0 offiziell eine MySQL version 5.1 oder hoeher voraussetzen http://typo3.org/download/ Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] OT - Forge - Benutzername ändern/aktualisieren
On 04/05/13 20:37, Rene wrote: wie kann ich meinen Namen in Forge aktualisieren? Bei mir steht immer "Rene no-lastname-given", was etwas unschön ist. Hatte ich kuerzlich auch :-) Gehe zu https://typo3.org/my-account/login/ und melde dich an. Gehe zu https://typo3.org/my-account/edit-personal-data/ (oder klicke: "Manage your account -> Edit personal data") Im Feld "Name:" steht wahrscheinlich momentan nur dein Vorname. Trage hier deinen Vornamen und Nachnamen ein, klicke auf "update account" und einige Stunden spaeter ist auch auf forge der volle Name sichtbar. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Update von T3 6.0.4 auf T3 6.1.0 - Inhaltselemente leer ?
On 06/05/13 20:25, Tobias Leichsenring | EDVSolutions.org wrote: T3 6.0.4 auf T3 6.1.0 hochgesetzt. Danach musste ich leider auch nach Durchführung aller relevanten Aufgaben wie Extensions updaten, Sprachen updaten, Temp löschen feststellen, dass keine Inhaltselemente mehr ausgegeben werden. [...] Im Frontend steht nur "Hier kommt einmal der Inhalt hin" - was ein Platzhalter aus dem Template ist. Nur mal so geraten... nutzt du TemplaVoila? Ist das Mapping noch vorhanden? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Update von T3 6.0.4 auf T3 6.1.0 - Inhaltselemente leer ?
Hallo Tobias, meine Frage nach dem Mapping bezog sich auf TemplaVoila. Wenn du TV nicht nutzt, hat sich eigentlich auch das Mapping erledigt. Ich kam nur da drauf, da du geschrieben hast, dass im FE Platzhalter aus dem Template angezeigt werden - das ist ein typisches Verhalten, wenn TemplaVoila kein Mapping (mehr) kennt. Mir ist das ein paar mal untergekommen, wenn ein extension update von TV gemacht wurde - aber das ist lange her. In neueren Versionen von TV habe ich auch damit keine Probleme mehr. Egal - wenn du TV nicht nutzt, wird's das ja wohl nicht sein :-) Cheers Michael On 06/05/13 21:03, Tobias Leichsenring | EDVSolutions.org wrote: Hallo Michael, nein TemplaVoila nutze ich nicht, zumindest aktuell nicht. Ob das in früherer zeit einmal genutzt wurde, kann ich leider nicht sagen, weil ich die Betreuung der Seite übernommen habe. Wie kann ich denn das Mapping prüfen ? Tobias -Ursprüngliche Nachricht- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Michael Gesendet: Montag, 6. Mai 2013 12:34 An: German TYPO3 Userlist Betreff: Re: [TYPO3-german] Update von T3 6.0.4 auf T3 6.1.0 - Inhaltselemente leer ? On 06/05/13 20:25, Tobias Leichsenring | EDVSolutions.org wrote: T3 6.0.4 auf T3 6.1.0 hochgesetzt. Danach musste ich leider auch nach Durchführung aller relevanten Aufgaben wie Extensions updaten, Sprachen updaten, Temp löschen feststellen, dass keine Inhaltselemente mehr ausgegeben werden. [...] Im Frontend steht nur "Hier kommt einmal der Inhalt hin" - was ein Platzhalter aus dem Template ist. Nur mal so geraten... nutzt du TemplaVoila? Ist das Mapping noch vorhanden? Cheers 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] TYPO3 4.x und MySQL 5.5
Hi! Kann jemand von Erfahrung berichten (gute, wie schlechte), TYPO3 4.5, 4.6 und/oder 4.7 mit einer MySQL 5.5 (produktiv) laufen zu lassen? Offiziell setzen die 4.x Versionen ja MySQL 5.0.x bis 5.1.x voraus und erst ab TYPO3 6.x kann man MySQL 5.5 verwenden. Wir ueberlegen uns, unsere Server langsam auf Debian 7 "Wheezy" zu aktualisieren und dort ist das default MySQL package die Version 5.5 (wir nehmen ungerne non-default packages). Hat dazu jemand ein Meinung - oder noch besser: Erfahrung mit TYPO3 4.x und MySQL 5.5? :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TYPO3 4.x und MySQL 5.5
On 14/05/13 13:29, Christian Platt wrote: >> Kann jemand von Erfahrungen berichten (gute, wie schlechte), TYPO3 >> 4.5, 4.6 und/oder 4.7 mit einer MySQL 5.5 (produktiv) laufen zu >> lassen? > wir setzen produktiv und ohne Probleme T3 4.7 und MySQL 5.5 auf SLES ein, ohne Probleme. Cool - danke fuer die Info. Dann werden wir wohl mal unseren naechsten dev/test server mit Wheezy und MySQL 5.5 bestuecken. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Powermail double opt in
On 2013-05-28 20:34, schumahs wrote: Ich habe mit Double opt in Probleme. Beim versenden der Mail zur Bestätigung ist das Datumsformat noch richtig..nach Bestätigung bekommt das Datumsformat einen Timestamp. Beschreibt das hier dein Problem: http://forge.typo3.org/issues/40654 Dann scheint das ein "known issue" zu sein, welches bereits vor 9 Monaten gemeldet wurde. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] TER-Upload unbedingt wieder als Core-Funktion bereitstellen
On 01/06/13 05:15, Domi wrote: [...] Ich hoffe einfach nur ein paar +1 zu sammeln, dass vielleicht im nächsten LTS der Upload wieder in der Core enthalten sein würde. Im Grunde ist es doch egal, ob eine Ext-Upload-Funktion im Core, in einer Extension oder web-basierend im TER vorhanden ist. Es geht eher darum, dass sie ueberhaupt (wieder) vorhanden ist :-) Allerdings bringt das Sammeln von +1 recht wenig, wenn sich niemand um die Umsetzung kuemmert. Vielleicht hast du ja Zeit, Lust, Knowledge bei der Entwicklung von extdeveval zu helfen und das fehlende Feature einzubauen? http://forge.typo3.org/projects/extension-extdeveval https://git.typo3.org/TYPO3v4/Extensions/extdeveval.git Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Security-Meldung zu sg_zfelib
On 2013-06-04 03:10, Peter Linzenkirchner wrote: soeben kam eine Security-Meldung rein zu sg_zfelib: [...] The extension author failed in providing a security fix for the reported vulnerability in a decent amount of time. Die Extension gibts aber noch im TER [...] Weiß jemand genaueres? Laut dem Bulletin sind alle Versionen dieser Extension einschliesslich Version 1.1.774 (zuletzt im August 2011 aktualisiert) unsicher und angreifbar. Die Version, die am 03. Juni 2013 hochgeladen wurde (Version 1.1.779) ist nicht als "insecure" klassifiziert. Laut der Beschreibung des Autors enthaelt Version 1.1.779 den Security Fix, wurde aber wahrscheinlich von niemanden geprueft und/oder moeglicherweise wurde der Upload der neuen Version nicht mit dem Security Team abgestimmt (meine Spekulation), siehe: http://docs.typo3.org/typo3cms/SecurityGuide (Kapitel "Incident handling"). Wenn du dem Autor vertraust, verwende die Version 1.1.779. Alle anderen Versionen davor wuerde ich vom Server entfernen... asap :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Fatal Error ab_downloads Typo3 6.1
On 14/06/13 04:28, Martin wrote: [...] ich habe nun den falschen Code mit dem richtogen Code durch das WIKI erstetzt und es scheint im Moment wieder ordentlich zu funktionieren. Hoffe es bleibt auch so. Ich gehe mal stark davon aus, dass sich der Code nicht selbst modifiziert ;) Das wäre es ja auch nochlol. Aber dir ist bewusst, dass jedes TYPO3 core update, also z.B. von 6.1.1 zu 6.1.2, das File wieder ueberschreibt, oder? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Twitter Extension
On 15/06/13 06:55, Schirmer wrote: Gibt es eine Twitter-Extension, die bei Euch funktioniert? Ich habe "educo Tweet", "Frontend Twitter Feed" und "Social Connect" ausprobiert. Die letzte funktinierte noch vor paar Tagen. [...] Am 11. Juni 2013 hat Twitter u.a. die API 1.0 abgeschaltet, siehe: https://dev.twitter.com/calendar https://dev.twitter.com/blog/changes-coming-to-twitter-api https://dev.twitter.com/blog/current-status-api-v1.1 https://dev.twitter.com/blog/api-v1-retirement-final-dates Somit gehen all Extensions, die die alte API 1.0 nutzen, seit diesem Tag nicht mehr. Die neue version 0.4.2 der EXT:edtweet (released am 12. Juni) unterstuetzt nun die API 1.1 und funktioniert ohne Probleme: http://t3extensions.org/details/edtweet Zum Beweis: klicke oben auf das "Follow Us" icon. Das Popup nutzt die EXT:edtweet :-) Ueber den Stand der anderen beiden Extensions kann ich leider nichts sagen, aber ich gehe davon aus, dass es auch mit der API 1.0 zusammenhaengt, wenn sie "ploetzlich" (also seit dem 11. Juni) nicht mehr funktionieren. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Twitter Extension
On 15/06/13 19:38, Newsdesigner wrote: [...] Ich bekomme immer die Fehler: Sorry, the requested view was not found. The technical reason is: No template was found. View could not be resolved for action "user". Das liegt wahrscheinlich an etwas anderem. Ich erinnere mich an irgendwelche "deprecated" Dateinamen-Konventionen: (Zitat) "template and layout files in "typo3conf/ext/edtweet/Resources" are all-lowercase. This is deprecated since TYPO3 4.4 (for templates) and since TYPO3 4.6 (for layouts). These files should have an upper-case first character now, e.g. User.html rather then user.html." Das wuerde zumindest die Fehler unter 6.x erklaeren. Allerdings laeuft edtweet bei mir auch unter 4.7.10. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Externe MySQL Datenbank anbinden (V6.1)
On 2013-06-19 19:46, Simon wrote: ich benutzte eine lokale Installation mit XAMPP 1.8.1 [PHP: 5.4.7], Typo3 Version 6.1, ja mit der aktuellsten Typo3 Version hat man wohl echt wenig Spaß :( Naja, du benutzt eine extension, die zuletzt im April 2012 aktualisiert wurde und als upload comment "...a lot of new features and patches for TYPO3 4.6" angegeben wurde: http://t3extensions.org/details/wfqbe TYPO3 6.1 funktioniert gut, wenn man die dazu passenden extensions verwendet :-) Aber wir kommen vom Thema ab, sorry. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Externe MySQL Datenbank anbinden (V6.1)
On 2013-06-19 20:41, Simon wrote: @Michael: danke für den Hinweis! Blöd, dass es nicht direkt im EM angezeigt wird Da gebe ich dir voellig Recht! Aber wir arbeiten daran: http://typo3.org/news/article/announcing-ter-cleanup-process/ Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] php im fileadmin
On 11/07/13 18:18, Georg Ringer wrote: ftp, ssh ginge am schnellsten ...und wenn FTP/SSH keine Optionen fuer dich sind, koennte dich der Hinweis im Abschnitt "fileDenyPattern" im SecurityGuide interessieren: http://docs.typo3.org/typo3cms/SecurityGuide/GuidelinesIntegrators/GlobalTypo3Options/Index.html "In most cases backend users [...] must not have the option to upload/edit PHP files or other files which could harm the TYPO3 CMS instance." Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Firefox 22 und typo3-Backend
On 13/07/13 21:35, Philipp Gampe wrote: ich habe hier das Problem, daß Firefox Version 22 (unter openSuse 12.3) und das Typo3-Backend (Version 4.5.27 LTS) sich nicht vertragen, d.h., daß nach ein paar Aktionen im Backend der komplette Firefox abschmiert. Ich vermute, daß das evtl. mit einer neuen Javascriptengine des FF zusammenhängt. Unabhängig von eventuellen Fehlern im Backend JavaScript darf ein Browser deswegen nicht abschmieren. IMHO ist dies ein dicker Firefox Bug. ich glaube nicht, dass das ein genereller Fehler von Firefox ist. Ich nutze Firefox 22 unter Ubuntu 12.10 (GNU/Linux 3.5.0) und Ubuntu 12.04 LTS mit diversen TYPO3 Versionen (4.5, 4.7, 6.0, 6.1 und 6.2-dev) ohne Probleme. @Christian: was du probieren koenntest: - eventuelle FF Themes abschalten (vorruebergehend deaktivieren) - (alle?) FF Add-Ons abschalten (vorruebergehend deaktivieren) - FF im debug modus starten (siehe unten) - JavaScript engine von OpenSuse mit anderen vergleichen Firefox debug modes (siehe auch: "firefox --help") -g or --debug: Start within debugger -d or --debugger: Specify debugger to start with (eg, gdb or valgrind) -a or --debugger-args: Specify arguments for debugger Vielleicht ist auch der Parameter "-safe-mode" interessant :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] CoolURI Problem
Hi, falls das nicht zum Erfolg fuehrt, wuerde ich mal schauen, was in der baseUrl steht. Gegebenenfalls fehlt dieser Eintrag vollstaendig oder der Pfad ist nicht korrekt (z.B. fehlender / oder so). Cheers Michael On 17/07/2013, at 17:32, Jana Golinowski wrote: > Hallo Michael, > >> müssen die Zeilen von dir zu meinen hinzu oder ersetzen die welche? > > die kommen dazu. Und zwar als erste Regel (wie es in dem Kommentar steht) > nach RewriteEngine On. > > Ich habe das übrigens auch nur aus der originalen _.htaccess von TYPO3 > kopiert (in meinem Fall Version 4.7). Du kannst deine Regeln ja mal damit > vergleichen. > > Grüße, Jana. > ___ > 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] Firefox 22 und typo3-Backend
On 17/07/2013, at 7:34, Andreas Knoblauch wrote: > Gehe auch davon aus, dass es an der neuen Javascript-Enegine vom Firefox > liegt. Schon mal probiert, etwas anhand dieser Vorschlaege herauszufinden: http://lists.typo3.org/pipermail/typo3-german/2013-July/094435.html Oder "about:config" in der Adresszeile des Browsers eingeben und OdinMonkey deaktivieren: javascript.options.asmjs Wie gesagt, ich habe diese Probleme nicht und will nur helfen :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:edtweet Suche (Twitter einbinden)
On 25/07/13 16:44, Heinz Schilling wrote: Die Erweiterung läuft soweit, dass ich die Timeline anzeigen lassen kann. Nur mit der Suche will es nicht klappen. Hat jemand dies erfolgreich im Einsatz? TYPO3 4.5.28 edtweet 04.2. Wir haben zwar EXT:edtweet im Einsatz, aber nutzen nicht die Such-Funktion. Allerdings kam gerade die Version 0.4.3 raus, die ein Bugfix-Release ist: http://t3extensions.org/details/edtweet Laut upload comment ist's zwar ein "Twitter id bug fix" und die Suche wird nicht erwaehnt, aber vielleicht ist's Wert, ein Update zu versuchen? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:edtweet Suche (Twitter einbinden)
On 2013-07-26 00:04, Heinz Schilling wrote: Ein Update brachte leider nichts. Wärst Du bitte so nett, kurz auszuprobieren ob die Suche bei Euch funktioniert? Dann wüsste ich, ob's ein Bug ist oder nicht. Sorry - das kann ich leider derzeit nicht machen. Vielleicht hat jemand anderes Zeit/Lust dazu? Oder setze dich mit dem Entwickler in Verbindung. Tut mir leid. Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] BE Benutzer von Nicht-Admins verwalten lassen
Hi community, gibt es eine Moeglichkeit, "normalen" BE Benutzern (nicht-Admins) zu erlauben, andere BE Benutzer anzulegen, bzw. zu loeschen und zu editieren? Bei einem unserer Kunden findet eine sehr starke Fluktation innerhalb des Teams statt und wir wuerden es gerne einem bestimmten BE Benutzer (oder einer Benutzergruppe) erlauben, sich um die Benutzerverwaltung der Redakteure zu kuemmern - ohne (voreingestellte) Berechtigungen aendern zu koennen und ohne ueber einen Admin Account zu verfuegen. Bin auf eure Vorschlaege gespannt :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] BE Benutzer von Nicht-Admins verwalten lassen
Hi Renzo, mabi, Nicole, klar - die "Task Center - Actions"... damit geht's prima!! :-) Hab's gerade ausprobiert und das erfuellt genau das, was ich suche. Vielen Dank fuer den Tipp. Cheers Michael On 2013-08-13 06:53, Nicole Cordes wrote: um das mit den Actions noch weiter auszuführen. Du musst im Extensionmanager die Extension sys_actions installieren. Dann kannst du auf Root-Ebene einen neuen Datensatz vom Typ Action hinzufügen. In diesem wir ein Standarduser, so wie er später auch angelegt werden soll, definiert und die Benutzergruppe zugewiesen, die Zugriff auf diese Action haben soll. Dann kann der User dieser Gruppe mittels den Aufgaben (links in der Navigation) entsprechend Benutzer anlegen und seine (!) angelegten Nutzer verwalten. Liebe Grüße, Nicole ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 Downgrade auf 4.5 Fehler
Hi, siehe http://docs.typo3.org/typo3cms/InstallationGuide/ Die Punkte im Kapitel "Upgrade" lassen sich in der Regel auch gut fuer eine Downgrade verwenden, speziell die cache sachen, DB Compare, usw. - oder bringen dich auf den richtigen Weg. Cheers Michael On 2013-08-15 22:29, Renzo Bauen wrote: Oder auf dem Ordner fileadmin, typo3conf und typo3temp gibt es nicht die richtige Zugriffsrechte (rw). Vielleicht liegt es auch am nicht gemachten Compare im Installtool. Ich glaube da wurden mal ID von tinyint in integer umgewandelt oder so... ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Firefox 22 und typo3-Backend - gelöst
On 2013-08-20 18:30, Christian Rößler wrote: Es liegt an einem Fehler der nvidia-Treiber (webgl-Bibliothek), die scheinbar seit FF22 angesprochen wird. [...] In der about:config den Wert webgl.disabled auf "true" setzen beseitigt das Problem - seitdem keinen Crash mehr. Also muß man auf einen nvidia-Treiber-Bugfix warten, oder die offenen nouveau-Treiber benutzen. Wow - good pick, well done :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] EXT:cal und Sommer/Winterzeit (DST)
Hi, die EXT:cal nimmt das Datum 06 Oktober 2013 nicht an. Versucht man, einen neuen Record mit diesem Datum zu speichern oder einen existierenden mit diesem Datum zu aktualisieren, springt EXT:cal immer zurueck zum 05 Oktober 2013 - ohne Warnungen, Fehlermeldungen usw. Der 05 Oktober steht dann auch als Datum in der DB (anstatt der 06 Oktober). Jenes scheint mit der Zeitzone zusammenzuhaengen, mit der der Server konfiguriert ist, und der Tatsache, dass am 06 Oktober Daylight Saving Time (DST) in dieser Zeitzone beginnt :-) Konrekt: die Zeitzone ist EST (also UTC+10 hours) und in Melbourne begin DST am 06 Oktober 2013, laut: http://www.timeanddate.com/time/dst/2013.html Obwohl ich persoenlich Server lieber auf UTC konfiguriere, ist das in diesem Fall aus verschiedenen Gruenden nicht moeglich. Dem Kunden konnten wir auch bisher nicht dazu ueberreden, sein Event auf den 05 oder 07 zu legen ;-) ...daher muessen wir wohl bei der Extension ansetzen :-) Ticket: http://forge.typo3.org/issues/51220 Aber vielleicht hat ja jemand das selbe Problem und eine Loesung oder zumindest ein Workaround? Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:cal und Sommer/Winterzeit (DST)
On 2013-08-22 06:32, Olivier Dobberkau wrote: Aber vielleicht hat ja jemand das selbe Problem und eine Loesung oder zumindest ein Workaround? phpmyadmin? timestamp manipulieren? Aeh, ja - das haben wir natuerlich gemacht. Ist aber leider keine sehr verlaessliche Loesung, wenn jeder Redakteur durch einen einzigen Klick das Datum wieder "kaputt" machen kann :-) (selbst, wenn er/sie nicht das Datumsfeld editiert, sondern nur auf "Save" klickt). Danke fuer dein Input, Olivier. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] [TYPO3-UG Oesterreich] 4.5.29 erhebliche Sicherheitslücken?
On 2013-08-22 12:55, Andreas Becker wrote: Da auf der TYPO3.org Webseite keine Infos dergleichen angezeigt werden waere ich sehr daran interessiert zu erfahren wie man seine Webseiten so sicherer machen kann! D.h wie man die Infos der Extensions und des Cores verstecken kann [...] Das Verstecken oder Verschleiern von Informationen schliesst keine Sicherheitsluecken. Ich investiere lieber meine Zeit dafuer zu sorgen, dass mein Core und die Extensions aktuell gehalten werden. Welchen Weg wuerdest du denn vorschlagen um TYPO3 Webseiten auch fuer die Zukunft abzusichern. Das offizielle TYPO3 Security Guide lesen und befolgen: http://docs.typo3.org/typo3cms/SecurityGuide/ Security Bulletins verfolgen und Updates einspielen, wenn erforderlich: http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-announce Ich denke hier zB auch an das Integrieren eines Update Checkers fuer Extensions der dem KUNDEN mitteilt das da was an seiner Seite veraltet oder gar sicherheitsrelevant ist. http://schams.net/nagios (oder eines der verwandten Loesungen, siehe: "Similar Projects"). Noch ein paar weitere Links zu dem Thema: http://en.wikipedia.org/wiki/Security_through_obscurity http://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea http://slashdot.org/features/980720/0819202.shtml Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Upload Extension
On 2013-08-28 01:29, Peter Linzenkirchner wrote: ich habe gestern eine Extension ins TER geladen (TYPO3 6.1 mit Hilfe der Extension "Extension Uploader"). Dabei wurde beim Upload in der ext_emconf.php der Abschnitt [...] ausgeleert. Er sollte so aussehen: 'depends' => array( 'typo3' => '4.5.0-6.1.99' ), Hi Peter, moeglicherweise ist das ein "known issue" der EXT:extension_uploads, siehe: https://github.com/Trenker/typo3.extension_uploader/issues/5 wie kann ich eine Extension ins TER bringen, ohne dass das passiert? Der Upload mit dem Extension Manager einer TYPO3 4.5 version klappt weiterhin recht gut. Ansonsten gibt's noch die kommandozeilen-basierten Typo3ExtensionUtils: https://github.com/etobi/Typo3ExtensionUtils Hope this helps! Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Probleme bei der Installation
Hallo, ich habe frueher mal mit Typo gearbeitet, aber lange Zeit nicht mehr. Jetzt wollte ich gerade wieder etwas damit machen und hab mir das introductionpackage runter geladen. nach dem laden auf einen webserver wollte ich mit der datei enable_install_tool die installation starten, aber ich bekomme nur eine weisse seite. die logs vom apache sagen dass die ...localconfiguration.php is not writable. dann hab ich die datei gesucht, aber die liegt gar nicht in dem verzeichnis. ich vermute mal wenn diese nicht vorhanden ist, dass dann der fehler kommt das diese nicht schreibbar ist. wenn ich sie anlege, kommt die meldung localconfiguration not valid (ohne inhalt). jetzt hab ich noch in das blankpackage einen blick geworfen, aber auch hier sehe ich keine localconfiguration.php, in der doku finde ich auch keinen hinweis darueber ob die anzulegen ist und wie diese aussehen soll. Aber was laeuft da falsch? die muesste doch mit default werten in den downloads mit drinnen sein, oder? ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Probleme bei der Installation
Danke fuer den Hinweis, da hab ich auch immer Gesucht. Viel falsch machen kann man eigentlich Nicht. Ich hab ein Linux dann beide packages Jeweils zip und Tar.gz runtergelaufen und mit Dem archivmanager entpackt. Es kann ja mal Schief laufen aber 4 mal? Kann vielleicht jemand bei dem jetzigen stable Es auch mal runterladen und entpacken, und schauen Ob es dann da ist? ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Probleme bei der Installation
Jup. 6 irgendwas, das aktuelle stable halt. Und auf das gesamte Verzeichnis ein chmod Rekursiv 777 gemacht (einfach mal zum spielen) Und aus den Logs des apache kommt lediglich die Meldung Das die localconfiguration. Php nicht schreibbar Ist. Aber vielleicht wird diese wirklich erst zur Laufzeit Erstellt und das klappt nicht. Werden denn die Daten fuer Datenbank etc Erst waerend des install Tools aufgenommen und dann In die localconfiguration geschrieben oder muessen Die bereits vor dem starten des Tools vorhanden sein? ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3-Update für kleiner Reviosion - wie?
On 2013-09-05 16:35, Georg Ringer wrote: Es gibt reichliche Dokumentation, wie eine TYPO3-Grundinstallation oder auch einen Upgrade im Falle einer grossen Revision erfolgt. Leider habe ich aber nichts zum Thema kleineren Updates, bzw. Patch-Installation gefunden. Wie sollte ich vorgehen? sourcen tauschen, cache clearen, done. That's it... und ein bischen ausfuehrlicher ist's hier erklaert: http://docs.typo3.org/typo3cms/InstallationGuide/Upgrade/Index.html Die Dokumentation beschreibt ein generelles Update und weist auf Besonderheiten einer "Patch-Installation" hin. Wie Georg schon schrieb, sind zwei, drei Schritte in der Regel ausreichend... aber wenn man eine TYPO3 Installation geerbt hat, ist ein Blick in das Install Tool (und das "Report Module") sicherlich nicht verkehrt :-) Viel Spass! Cheers, Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 Installation funktioniert nicht
On 2013-09-15 22:18, Frederik Witte wrote: habe Windows 7, auf xampp installiert. Xampp ist 100% richtig installiert, arbeite jetzt schon ca 1/2 Jahr mit Xampp und hatte nie Probleme. Ich hatte glaube ich 2 verschiedene introduction packages. Einmal hatte ich 6.1... und dann habe ich, um es nochmal zu probieren, die neuste Version runtergeladen(6.2) und damit hat es auch nicht geklappt. Das 6.2 Introduction Package habe ich mir noch nicht angeguckt (das ist sowieso derzeit noch "alpha"), lass' uns also erst einmal auf das 6.1 konzentrieren: Jedoch fehlen mir einige Sachen. Ich habe links in der Leiste in der "List" "Page",etc. steht, kein "Info". Das ist korrekt: "Info" ist per default nicht installiert. Gehen in den Extension Manager und waehle aus der Dropdown Box (ganz oben) den Punkt "Manage Extensions" aus (wenn nicht bereits aktiviert). Gebe als Suchbegriff "info" ein und klicke auf das "Activate" icon (weisser Lego-Stein) bei dem Eintrag "Web>Info". Das dauert ein paar Sekunden und "Info" erscheint unter "Web". Darüberhinaus funktioniert bei mir der News Editor nicht. Als "admin" angemeldet, klicke ich auf Web -> News (linke Spalte im Backend), dann im Page Tree auf "News entries", dann erscheint im Content Bereich ein Liste mit den fuenf News records. Diese kann ich dann editieren und speichern. Was genau meinst du mit "funktioniert bei mir nicht"? Machst du irgendetwas anders? Info/Modify unter "Template" hat nicht die Möglichkeiten, welche in der Dokumentation stehen, da mir der Punkt "Typoscript Template" in dem Tree komplett fehlt. Im Page Tree gibt es kein "Typoscript Template" mehr. Das TypoScript liegt nun in Dateien unter: fileadmin/default/... (siehe Verzeichnisse TSConfig und TypoScript und darunter). Diese Dateien werden mittels eingebunden. Wenn du die checkbox "Include TypoScript file content" unter Template -> Info/modify aktivierst, wird der Code aus den Dateien im textfield dargestellt. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Hilfetexte unter 4.4
On 14/08/10 06:08, Philipp Gampe wrote: [...] >> Es scheint, dass das Problem bei mir nur im SeaMonkey auftritt. Der >> sollte aber mit Firefox identisch sein,... [...] > Das müsste nach einem Browsercache löschen weg sein. Auch wäre die Frage, > welcher Versionsnummer des Firefox Seamonkey entspricht. Ich könnte mir > vorstellen, dass Seamonkey etwas hinterher hängt. Ich moechte gerne noch einwerfen, dass das Problem bei mir mit Firefox ebenfalls (manchmal) auftritt. Siehe Thread: http://lists.typo3.org/pipermail/typo3-german/2010-July/070173.html Falls es ein Bug-Ticket dafuer gibt, waere es cool, wenn ihr den Link (oder zumindest die ID) hier postet. Ich moechte gerne meine Infos dazu posten, sofern ich irgendwelche Zusammenhaenge feststellen kann. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typolink im RTE wird falsch gerendert
On 20/08/10 11:21, Domi Garms wrote: > ich möchte gerade eine alte TYPO3 Installation aufmöbeln und habe > bemerkt dass alle Typolinks, die ich im RTE vergebe, falsch gerendert > werden. Egal ob interne oder externe URI, es wird immer die domain 2 > mal vorne dran gestellt. [...] Komisch, von diesem Fehler habe ich vor ueber einem Jahr mal gehoert: http://lists.typo3.org/pipermail/typo3-german/2009-June/059915.html Das dazugehoerige Ticket beschreibt zwar nur externe Links und sollte schon recht lange gefixed sein, aber vielleicht besteht ja ein Zusammenhang mit deinem Problem? http://bugs.typo3.org/view.php?id=11009 HTH, Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typolink im RTE wird falsch gerendert
On 20/08/10 12:17, Domi Garms wrote: >> Komisch, von diesem Fehler habe ich vor ueber einem Jahr mal gehoert: >> http://lists.typo3.org/pipermail/typo3-german/2009-June/059915.html > > super, ich bin mir sicher das es sich genau darum handelt, [...] cool :-) > Da ich sowieso bald die Version > aktualisieren werde, wird der Fehler ja dann behoben sein. ...oder als workaround einfach den Patch einspielen, siehe note 0029073: http://bugs.typo3.org/view.php?id=11009#c29073 Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] ImageMagick als PHP Modul
On 23/08/10 20:58, ad wrote: [...] Wenn ich im Install-Tool bin, finde ich unter PHP-Info "imagick" -> "imagick module enabled". ImageMagick ist soweit ich das verstehe ein PHP-Modul und hat somit keinen Pfad wie /usr/bin/. Ist das richtig, oder muss ich nur den Pfad herausfinden? Das ist schon richtig! "php5-imagick" ist wirklich das ImageMagick Modul fuer PHP5. Siehe: http://www.google.com/search?q=php5+imagick+module Wir vermuten wahrscheinlich alle, dass (d)eine Frage lautet: "wie kann ich TYPO3 dazu bringen, das PHP Module, anstatt das binary im filesystem zu verwenden?" :-) Ich befuerchte, TYPO3 unterstuetzt ausschliesslich den Shellaufruf, wie Rainer geschrieben hat; da ich bisher noch nichts ueber den Modul-Ansatz gelesen habe. Ich lasse mich aber gerne eines besseren belehren ;-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Smoothgallery
Hallo zusammen, ich benutze auf meiner Seite sowohl die Smoothgallery als auch rsaccordion. Doch irgendwie kriege ich beides nicht richtig zum Laufen. In der aktuellen Konfiguration läuft RSAccordion problemlos, in der Smoothgallery erscheint statt eines Bildes der Ladebalken und das »Birnensymbol«, um ein Bild vergrößert anzuzeigen. Wenn ich auf das Symbol drücke, erscheint das Bild und es lässt sich auch entsprechend navigieren. Eingesetzt wird folgende Konfiguration: => TYPO3 4.4.2 => T3Mootools 1.2.3 => Smoothgallery 1.4.0 => rsaccordion 1.1.1 Muss ich noch irgendetwas beachten, damit ich auch in der normalen Ansicht ein Bild erhalte? Beste Grüße Michael Gnessner ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Smoothgallery
Hallo Johannes, > > Muss ich noch irgendetwas beachten, damit ich auch in der > > normalen Ansicht ein Bild erhalte? > > > Schau dir mal dsie beiden Seiten an: > http://t3test.jochla.de/index.php?id=rgaccordion bzw. > http://t3test.jochla.de/index.php?id=rgsmoothgallery > und dann überprüfe mal, ob du bei dir die Mootools-Library jeweils auch nur > einmal eingebunden hast, denn sonst kann es nämlich zu Konflikten kommen. > Ich meine noch zu wissen, dass rgsmmothgallery nur mit 1.2.1 läuft und > rgaccordion aber 1.2.3 benötigt. Du musst als dafür sorgen, dass auf den > entsprechenden Seiten die richtige Version eingebunden wird. Ich hatte da > auch ewig rumexperimentiert! Vielen Dank für Deine Links, ich werde Sie mir noch anschauen. Aktuell läuft die Gallery sowie das Accordion - bis auf eine Gallery-Seite - problemlos. Im Momnent suche ich noch die Ursache, wieso auf http://www.epoche-napoleon.net/reenactment/hollabrunn2007.html keine Bilder angezeigt werden. Vielleicht sind sie einfach nur zu groß? Schöne Grüße Micha ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Realurl und Realurl Management
Hallo zusammen, in einer alten TYPO3 4.2-Installation hatte ich sowohl * realurl * realurlmanagement * nfc_realurl_indiudual im Einsatz. Alles funktionierte zu meiner vollen Zufriedenheit. Im Rahmen eines Updates auf TYPO3 4.4.2 habe ich auch die o.g. EXT. auf den neuesten Stand gebracht. Das hat auch soweit gut und problemlos funktioniert. Aber nun zu meinem Problem: Im Punkt Pages von realurl management werden keine Seiten angelegt. Somit kann ich nun auch keine Links mehr indiviudell anpassen. Errorpages und Aliasse funktionieren jedoch problemlos. Neue Seiten und deren individuellen Links werden sowohl bei angemeldeten BE-User als auch bei abgemeldeten BE-User nicht angelegt? Die realurl management Konfiguration entspricht der des Handbuches, der BE-User hat Admin-Rechte. Beste Grüße Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] sql-query führt im Frontend zu an derem Ergebnis als über phpMyAdmin
On 22/10/10 08:28, Alisha wrote: ich habe in meiner FE-Extension eine Query eingebaut, die soweit auch funktioniert. Nur ist die Ergebnisliste im Frontend oft eine andere als als wenn ich die Abfrage direkt in phpMyAdmin ausführe. Im Frontend werden oft weniger Datensätze angezeigt. [...] Vielleicht ein Caching Problem? Die Ausgaben im FE werden ge'cached. Fuehrst du anschliessend Aenderungen in der DB aus (z.B. einen neuen Datensatz hinzufuegen) und rufst die Seite mit deiner Extension erneut aus, holt sich TYPO3 unter bestimmten Umstaenden die Daten aus dem Cache, anstatt die Query erneut auszufuehren und sich die aktuellen Daten aus der DB zu holen. Falls es das sein koennte, gibt's hier ein paar mehr Infos zu dem Thema: http://typo3.org/development/articles/the-mysteries-of-chash/ ...und/oder Google nach "TYPO3+USER_INT" oder "TYPO3+chash" fragen :-) HTH - Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] sql-query führt im Frontend zu ande rem Ergebnis als über phpMyAdmin
On 25/10/10 23:16, bernd wilke wrote: ...aber mit $GLOBALS['TYPO3_DB']->exec_SELECTgetRows - so wie in deinem Beispiel beschrieben, funktioniert es. Seltsam, aber so ist es. Die Parameter baue ich bei beiden Varianten gleich auf, daran kanns nicht liegen. du baust die Parameter auf, aber die werden erst noch weiter verarbeitet. und das ist nicht nur ein Aneinanderhängen. da kann noch mehr drin stecken. Deshalb kann dir nur eine Abfrage von $GLOBALS['TYPO3_DB']->debug_lastBuiltQuery zeigen welche SQL-Abfrage aus deinen Parametern zusammen gebaut wurde. Good point! Oder du aktivierst das logging direkt in MySQL (in der Datei "my.cnf" soetwas wie "log=/tmp/mysql.log"). Dann kannst du genau sehen, welche SQL statements wirklich von MySQL ausgefuehrt werden. Allerdings sollte man das MySQL logging nicht gerade auf einem Produktiv-Server laufen lassen :-) HTH - Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Extensions list automatisch aktualisieren
On 30/10/10 08:22, J. Schaller wrote: kann man Typo3 4.4.4 so einrichten, dass die Extension-Liste automatisch, z.B. per cron script, aktualisiert wird? Die Extension-List liegt als File "extensions.xml.gz" im typo3temp Verzeichnis. Wenn ein Admin im BE im Ext Manager unter "Import Extensions" den Button "Retrieve/Update" klickt, wird geprueft, ob eine neuere Version im TER verfuegbar ist und diese dann runtergeladen. Diese Aktion ersetzt das vorhandene File "extensions.xml.gz", entpackt es und importiert die Daten aus dem XML file. Das Runterladen und Ersetzen kannst du automatisieren, zum Beispiel per cronjob, wget und als --output-document den Pfad/Filename typo3temp/extensions.xml.gz Das importiert die Liste allerdings noch nicht und wirft auch nicht die Funktion "Check for extension updates" des Ext Managers an. Am Schönsten wäre dann natürlich noch eine Nachricht an den admin beim Einloggen, für welche Extensions Updates verfügbar sind. Nette Idee! Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Frontend user register - checkboxen
Hi Andreas,
da bisher noch niemand auf deine Frage geantwortet hat, mach' ich mal
einen Anfang :-)
On 08/11/10 19:17, Andreas Deitmer wrote:
Verwende die Typo3 frontend user rgister (sr_feuser_register).
Diese habe ich über den kickstarter um einige Felder erweitert.
Bedenke, dass wenn du Aenderungen in einer Extension ueber den
kickstarter machst, du in den Core der Extension eingreifst. Das heisst,
die geaenderte Extension ist nicht mehr "update-sicher" und es besteht
die Gefahr, dass du deine Aenderungen (z.B. aus Versehen) loeschst, wenn
du eine aktuellere Version der Ext aus dem TER einspielst.
Zusätzlich überprüfe ich mit einigen Hooks Falscheingaben der
nutzer (z.b. ist das Geburtsdatum gültig etc.)
Hooks oder Konfigurationen ueber TypoScript sind auf jeden Fall der
bessere Weg :-)
Habe eine Checkbox, mit der der Nutzer die agbs akzeptieren muss.
[...]
Habe es aber trotz längere suche nicht geschafft, den Wert unter
gewissen Bedingungen wieder zu deaktivieren/zurückzusetzen.
Ich bin mir nicht ganz sicher, aber kann man nicht in dem template file
von sr_feuser_register das input tag (die checkbox) editieren und dass
Attribut checked="..." ueberschreiben?
Eine andere Moeglichkeit (wohl eher ein Workaround): du entfernst den
Status der checkbox mit JavaScript. Zum Beispiel jQuery:
$('input#tx-srfeuserregister-pi1-agb').attr('checked', false);
HTH - Cheers
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] pagetree funktioniert nicht in neuer typo3 4.5beta2
On 02/12/10 16:33, Domi Garms wrote: ich bekomme einen Fehler angezeigt wenn ich die neue beta testen will: Ext Direct error in "t3lib_extjs_ExtDirectApi" with namespace: "TYPO3.Ajax.ExtDirect" [...] Bei mir funktioniert mitgelieferte Extension pagetree nicht, was vielleicht an dem oben genannten Fehler liegen könnte. Hi Domi. Der Fehler tritt auch auf, wenn ich die sysext "pagetree" nicht geladen habe. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Userrechte
On 10/12/10 00:26, Peter Reinboth wrote:
... Dieser Professor gehört in
die Gruppe "Professoren" - wie viele andere auch. Fazit: jeder kann den
Inhalt des anderen Professors einsehen und ändern, weil sie alle zur
selben Gruppe gehören [...]
Ich wuerde behaupten, das Ziel einer "Gruppe" ist, die Berechtigungen
mehrerer Benutzer zusammenzufassen. Sollte z.B. mehr als ein Benutzer
Zugriff auf eine bestimmte Funktionalitaet haben sollen (z.B. bestimmte
Seiteninhalte bearbeiten), kann man jenes in einer Gruppe abbilden.
Vergleichbar sind Gruppen auch mit "Rollen" und ein typisches Beispiel
in der CMS-Welt sind hier "Redakteure".
Dein Beispiel mit den Professoren, und dass jeder Professor seinen
Unterrichtsplan bearbeiten kann, wuerde ich eher auf einer anderen Ebene
abbilden: in TYPO3 kannst du jeder Seite im System einen Benutzer
zuordnen, sowie einer Gruppe (plus "alle anderen"). Dieses Prinzip hat
sich in der UNIX/Linux Welt bestens bewaehrt. Den drei Kategorieren kann
man Berechtigungen vergeben, wie beispielsweise "show", "edit", "delete"
usw. Dafuer ist das "Access" Module im BE zustaendig.
Show page: Show/Copy page and content.
Edit content: Change/Add/Delete/Move content.
Edit page: Change/Move page, eg. change pagetitle etc.
Delete page: Delete page and content.
New pages: Create new pages under this page.
Je nachdem, welche anderen Berechtigungen "Professoren" haben sollen,
wuerde ich wahrscheinlich die jeweiligen Seiten mit den
Unterrichtsplaenen den jeweiligen Benutzern zuordnen und "edit content"
Rechte einraeumen. "Group" und auf jeden Fall "others" haben keine
Schreibrechte auf diese Seiten.
Somit kann jeder Professor nur seine eigene(n) Seite(n) und somit
eigenen Unterrichtsplan bearbeiten und nicht in fremden Seiten
rumpfuschen. Man koennte jenes noch weiterfuehren, und dem angemeldeten
user nur die Seite(n) im BE anzeigen, die er auch bearbeiten darf ("show").
HTH - Cheers
Michael
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 4.5-Dev - Endlosscheife bei Taskcenter Installation ?
On 15/12/10 01:00, S.Korth wrote: habe gerade versucht die Sysext "Taskcenter" zu installieren. Diese will die Sysext "sys_action" installieren. Das Problem ist nur, die "sys_action" will das "Taskcenter" installieren... [...] Kann das mal jemand testen ? Kann ich bestaetigen. http://bugs.typo3.org/view.php?id=16743 - TYPO3 4.5-dev (svn revision 9766) - taskcenter version 2.0.0 - sys_action version 2.0.0 Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Typo3 4.5-Dev - Endlosscheife bei Taskcenter Installation ?
On 16/12/10 01:10, S.Korth wrote: Lol, das muss man erst mal sehen. Wusste nicht mal das beide Möglichkeiten existieren. Ich denke das wird in Zukunft für eine Menge Verwirrung sorgen. Hab' ich auch uebersehen :-) Ich bin mir nicht 100% sicher, aber "suggested" und "depends" gibt's schon laenger als Attribut in Extensions, soweit ich weiss. Vielleicht sollte man ueberlegen, die Darstellung waehrend des Installationsprozesses zu ueberarbeiten. Auf der anderen Seite: mit TYPO3 4.5 wird's sowieso einen neuen Ext Manager geben. Moeglicherweise erledigt sich die Verwirrung dann ja auch schon von selbst. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Dateiupload
On 23/12/10 22:31, Dennis wrote: Ich versuche eine Datei von etwas mehr als 5 MB größe übers Backend hochzuladen, nachdem die Datei zu 100% hochgeladen wurde läd sie die Ordneransicht neu aber die Datei die ich versucht habe hochzuladen ist nicht in dem Ordner, es gibt auch keine Fehlermeldung oder der gleichen. Berechtigungen des Zielordners richtig gesetzt (z.B. Schreibrechte fuer den apache-Prozess)? Eintraege in den Apache Logfiles kontrolliert? Ggf. PHP error log level anpassen. Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] t3designkit (Re: Template Engine)
On 29/12/10 02:19, JoH asenau wrote: [...] Es gab dazu bereits einen ersten Ansatz - vorgestellt auf den Developer Days 2009: http://typo3.org/extensions/repository/view/t3designkit/current/ [...] Jemand Interesse? Klingt nicht uninteressant. Gibt's irgendwo ein paar mehr Infos darueber? Bei dem Versuch, etwas mehr ueber das Projekt zu erfahren, fiel mir leider das nicht vorhandene manual im TER auf (Version 0.1.0 der extension) und die geparkte Domain "t3.designkit.org" :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:rsaauth / open_basedir ??
On 06/01/11 09:06, Michael Ludwig wrote: So, nun habe ich rsaauth mal installiert, und eben nach dieser Installation fragt mich die EXT nach einem temp-Verzeichnis (für den www-user beschreibbar) die per PHP-Einstellung "open_basedir" festzulegen sei. Dabei ist doch "open_basedir" seit PHP5.3 ebenfalls obsolet, oder?? [...] Und open_basedir gehört doch zum safe_mode, oder bekomme ich da jetzt etwas durcheinander?? Es stimmt zwar, dass die safe_mode Funktionalitaet von PHP ab Version 5.3 obsolete ist, aber "open_basedir" hat meiner Meinung nach nichts mit safe_mode direkt zu tun und ist auch nicht obsolute (auch nicht in PHP 5.3). Durch die PHP Konfiguration "open_basedir" kannst du einstellen (bzw. einschraenken), auf welche Verzeichnisse PHP (und somit der Webserver, also auch TYPO3) zugreifen darf. Bei rsaauth erzeugt TYPO3 fuer jeden Login ein public/private key pair. Der public key wird an den client gesendet, der private key wird in ein Verzeichnis auf dem Server abgelegt. Dieses Verzeichnis ist das besagte "temporaere" Verzeichnis und sollte natuerlich *NICHT* (z.B. per GET request) von jedem zugreifbar sein, da sonst die private keys offen liegen wuerden (obwohl, auch wenn, noch ein bischen mehr Aufwand erforderlich ist, um das dann auszunutzen). Um rsaauth in deiner TYPO3 Umgebung zu aktivieren, erstellst du also ein neues Verzeichnis im Idealfall ausserhalb deines DocRoots, stellst sicher, dass der Webserver Prozess darin lesen/schreiben kann (und NUR der Webserver Prozess) und gibst jenes Verzeichnis in der TYPO3-Extension-Konfiguration an. Sollte in deiner PHP Konfiguration "open_basedir" verwendet werden, muss dieses Verzeichnis dieser Konfiguration natuerlich hinzugefuegt werden, da sonst (wie oben erklaert) der Webserver nicht darin lesen/schreiben kann. Ob weitere Einstellungen erforderlich sind, wenn man safe_mode verwendet, kann ich gerade nicht sagen. "safe_mode" ist sowieso doof :-) und ab PHP 5.3 obsolete. In deinem typo3conf/localconf.php file findest du bei richtiger Konfiguration dann auch die folgende Zeile (oder aehnlich): $TYPO3_CONF_VARS['BE']['loginSecurityLevel'] = 'rsa'; Und/statt 'BE' (backend), ggf. auch eine Zeile fuer 'FE' (frontend), je nachdem, wo du rsaauth aktiviert hast. Ich hoffe, das oben beschriebene stimmt alles - wenn nicht: ich lasse mich gerne eines besseren belehren ;-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:rsaauth / open_basedir ??
On 07/01/11 02:56, Michael Ludwig wrote: [...] Nun habe ich testweise das besagte Verzeichnis angegeben und es lief überhaupt nichts mehr. Es gab nur noch Fehler vom Webserver, dass er dann auf überhaupt keine Verzeichnisse mehr zugreifen konnte. Jep, das ist auch voellig korrekt, sofern du NUR das besagte Verzeichnis in open_basedir angibst :-) Wenn open_basedir nicht gesetzt wird, heisst das, es gibt keine Einschraenkung; PHP darf also generell auf alle Verzeichnisse zugreifen (entsprechende Berechtigungen auf Filesystem-Ebene vorausgesetzt). Wenn open_basedir aktiviert ist, also ein Verzeichnis (oder mehrere) angegeben ist, darf PHP nur auf dieses Verzeichnis zugreifen, keine anderen. Bei dir bedeutet das nun wahrscheinlich, dass PHP ausschliesslich auf das temporaere RSAauth Verzeichnis zugreifen darf, welches du (als einziges) angegeben hast. Damit schliesst du natuerlich das komplette DocRoot aus, also das web Verzeichnis (in der Regel "htdocs"), in dem sich die TYPO3 Instanz befindet. Somit laeuft logischerweise gar nichts mehr :-) Die Loesung waere entweder, auf open_basedir zu verzichten (also "deaktiviert" lassen, wie es bei deinem System vorher der Fall war), und somit PHP nicht einzuschraenken - oder ALLE Verzeichnisse, auf die PHP Zugriff haben soll, in der open_basedir Konfiguration anzugeben. Mehrere Verzeichnisse werden jeweils mit einem Doppelpunkt voneinander getrennt, ausser bei Windows: dort werden Semikolon verwendet. Zum Beispiel (Debian/Ubuntu): open_basedir = "/var/www/htdocs:/usr/share/php5:/var/www/tmp:/var/www/rsaauth" Weitere Infos zu "open_basedir": http://php.net/manual/en/ini.core.php#ini.open-basedir Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] EXT:rsaauth / open_basedir ??
On 07/01/11 09:12, Michael Ludwig wrote: also kann für die EXT rsaauth ruhig die Variable open_basedir ungesetzt bleiben? Wenn PHP dann sowieso auf alle Verzeichnisse zugreifen darf, dann ja auch auf das rsaauth-temp - Verzeichnis. Richtig. rsaauth benoetigt nicht zwangsweise die open_basedir Konfiguration. Aber, WENN open_basedir verwendet wird, MUSS das temporaere Verzeichnis dort mit eingetragen sein. Oder macht es durchaus Sinn, die open_basedir Variable zu belegen? Das kommt auf deine Sicherheitsanforderungen an :-) Meiner Meinung nach macht open_basedir auf jeden Fall Sinn, besonders wenn mehrere virtuelle Hosts auf dem Server laufen und alle unter einem user (z.B. www-data). Ohne open_basedir kann unter Umstaenden ein PHP Script von virtualHost-1 Dateien von virtualHost-2 lesen. Hat jeder virtuelle Host seine eigene open_basedir Konfiguration kann man jenes unterbinden. Vielen Dank auf jeden Fall für Deine Mühen! Kein Problem :-) Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] OpenID und Frontend-Login
On 19/01/11 03:34, Michael Ludwig wrote: Da ich zum Thema irgendwie nicht das richtige finden kann, würde ich mich über einen Gedankenanstoss sehr freuen. Hi, ich habe OpenID bisher nur fuer den BE login eingesetzt (und das mit der sysext "openid"). Hast du mal die Ext naw_openid fuer's FE ausprobiert? http://typo3.org/documentation/document-library/extension-manuals/naw_openid/current Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] 4.5 RC1 -> broken rootline
On 24/01/11 21:47, Philipp Holdener wrote: Der Fehler kommt mir bekannt vor. Gehe mal ins install tool und mache dort einen db compare, danach dürfte der Fehler hoffentlich weg sein. komisch da ich das zwischen den Beta Schritten nie machen musste. Sollte mir das wohl angewöhnen :/ hmm... einen DB COMPARE sollte man auf jeden Fall nach einem major update machen. Fuer die 4.5 empfiehlt sich auch ein IMPORT: der neue Extension Manager nutzt die Tabelle "sys_ter" in der das "TYPO3.org Main Repository" steht. Ohne diesen Import hat der Extension Manager keine Repositories mehr (zumindest war das so in einer der 4.5-dev Versionen). Siehe: http://wiki.typo3.org/wiki/Upgrade#Upgrading_to_4.5_Long_Term_Support Cheers Michael ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
