Re: [TYPO3-german] Typo3 9.5: Preview versteckter Seiten nur nach Eingabe der numerischen ID-URL und nur für bestimmte Benutzergruppen

2020-11-04 Diskussionsfäden Florian Heß

Hallo Mark,

genau das war es. Wehwehwehchen zur Anmeldung eliminiert - geht.
Alleine wär ich nie daraufgekommen. Danke dir!


Viele Grüße
Florian


Am 04.11.20 um 11:19 schrieb Mark Boland:

Das ganze kann schon passieren, wenn der Login über domain.tld und die Preview 
über www.domain.tld geschieht.

Cheers,
Mark

Am 04.11.20, 11:18 schrieb "li...@berlin-typo3.de" 
:

 Hallo Florian,

 Habe das gerade an einer 9.5.22 getestet.

 Wenn ich die gleiche Domain aufrufe, mit der ich eingeloggt bin, sehe ich 
versteckte Seiten beim Aufruf aus dem Backend (über den „Auge“ Button) mit ganz 
normaler URL.

 Rufe ich eine Seite auf mit einer abweichenden Domain ( bei mehreren 
Domains in einer Installation), sehe ich eine 404 Seite.


 Habt ihr Admpanel im Einsatz?
 Wenn ja, muss dort die Preview freigeschaltet sein.
 
https://docs.typo3.org/m/typo3/reference-tsconfig/master/en-us/UserTsconfig/AdmPanel.html


 Viele Grüße
 Birgit

 > Am 04.11.2020 um 09:56 schrieb Florian Heß :
 >
 > Hallo liebe Typo3-Benutzer,
 >
 > nach etwas Rumprobieren will ich nichts riskieren kaputtzumachen und 
möchte mich daher nach der richtigen Herangehensweise erkundigen, um das Problem 
zu lösen.
 >
 > Zunächst: Unsere Entwicklungsinstanz scheint von dem Problem nicht 
betroffen. Da lassen sich auch versteckte Seiten umstandsfrei betrachten. Nun muss 
ich also Differenzanalyse und Gedächtnisarchäologie betreiben.
 >
 > In unserem Typo3-System der Version 9.5.21 können wir keine versteckten 
Seiten, obwohl wir uns natürlich im BE angemeldet haben. FE-Login bieten wir 
generell nicht an.
 >
 > Es kommt die Meldung, dass die Seite nicht gefunden wird. Ich als 
Administrator und bestimmte Redakteure, mutmaßlich diejenigen mit erweiterten 
Rechten (ua. für Plain-HTML CE), können die Seite dennoch betrachten, indem wir in 
der URL die Seiten-ID angeben, also die nativen sprechenden URLs umgehen. Das gilt 
aber nicht für alle Redakteure. Selbst ich hatte diese Möglichkeit anscheinend nur 
für eine bestimmte Seite, bis ich den Typo3-Cache zurückgesetzt habe, danach bei 
allen Seiten.
 >
 > Also ein nicht ganz konsequentes Verhalten seitens Typo3, was auf einen 
Bug schließen lässt. Oder?
 >
 >
 > Viele Grüße
 > Florian
 > ___
 > TYPO3-german mailing list
 > TYPO3-german@lists.typo3.org
 > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

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


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


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

[TYPO3-german] Typo3 9.5: Preview versteckter Seiten nur nach Eingabe der numerischen ID-URL und nur für bestimmte Benutzergruppen

2020-11-04 Diskussionsfäden Florian Heß

Hallo liebe Typo3-Benutzer,

nach etwas Rumprobieren will ich nichts riskieren kaputtzumachen und 
möchte mich daher nach der richtigen Herangehensweise erkundigen, um das 
Problem zu lösen.


Zunächst: Unsere Entwicklungsinstanz scheint von dem Problem nicht 
betroffen. Da lassen sich auch versteckte Seiten umstandsfrei 
betrachten. Nun muss ich also Differenzanalyse und Gedächtnisarchäologie 
betreiben.


In unserem Typo3-System der Version 9.5.21 können wir keine versteckten 
Seiten, obwohl wir uns natürlich im BE angemeldet haben. FE-Login bieten 
wir generell nicht an.


Es kommt die Meldung, dass die Seite nicht gefunden wird. Ich als 
Administrator und bestimmte Redakteure, mutmaßlich diejenigen mit 
erweiterten Rechten (ua. für Plain-HTML CE), können die Seite dennoch 
betrachten, indem wir in der URL die Seiten-ID angeben, also die nativen 
sprechenden URLs umgehen. Das gilt aber nicht für alle Redakteure. 
Selbst ich hatte diese Möglichkeit anscheinend nur für eine bestimmte 
Seite, bis ich den Typo3-Cache zurückgesetzt habe, danach bei allen Seiten.


Also ein nicht ganz konsequentes Verhalten seitens Typo3, was auf einen 
Bug schließen lässt. Oder?



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

Re: [TYPO3-german] Warum geht manchmal der Aufruf der Homepage ins Leere?

2019-06-24 Diskussionsfäden Florian Heß

Hallo Birgit,

wir haben uns zunächst mit einem temporären Work-around beholfen 
(Weiterleitung auf Apache-Ebene). Umstrukturierungen des Seitenbaums 
können wir uns zur Zeit nicht leisten. Wenn wieder Zeit und Personal da 
ist, schauen wir erneut auf das Problem.


Bisher hat es ja funktioniert. Wir haben keine Ahnung, warum es 
plötzlich nicht mehr bzw. nicht immer tut. Wenn irgendwelche Faktoren an 
der Auflösung oder Nichtauflösung von /home beteiligt sind, sollte das 
Phänomen dann nicht seit dem Update auftreten und nicht erst ein paar 
Monate danach, spekuliere ich mal so. Hast du vielleicht Links, die den 
Hintergrund von "Root soll kein Shortcut mehr sein" erläutern? Meine 
Suche danach war ... bestimmt nicht richtig durchgeführt.


Domain-Datensätze: Versteh nicht ganz, was damit gemeint ist. Könnte es 
sein, dass wir gar keine haben? Schließlich haben wir nur eine Domain 
und überdies ein Update von 7.6 auf 8.7 durchgeführt.


Leider kann ich Antworten auf diese Mail erst in ein paar Wochen lesen.


Viele Grüße
Florian Heß

Am 18.06.19 um 15:56 schrieb Birgit:

Ist Root auch die Startseite der Website (Seiteneigenschaften -> ist Anfang der 
Website) und die Seite, in der der Domaindatensatz liegt (muss in der Startseite 
der Doamin liegen)?

Ab TYPO3 8.x darf die Startseite kein Shortcut mehr sein - sondern vom Typ 
‚Standard‘.


Es gibt eigentlich kein endloses Pingpong, nur 2 URLs. Und je nachdem, welche 
zuerst aufgerufen und bei realURL eingetragen wird, gewinnt diese - und die 
andere erzeugt einen Fehler.

Aber hier scheint eher der Shortcut das Problem zu sein.



Am 18.06.2019 um 15:40 schrieb Florian Heß :

Hallo Birgit,

danke für deine Antwort.

Am 18.06.19 um 15:27 schrieb Birgit:

Ich richte deswegen immer eine 301 Weiterleitung in der .htaccess ein von /home 
auf die baseURL.


So ergibt es eine endlose Ping-Pong-Weiterleitung zwischen baseURL und /home, 
oder verstehe ich falsch? Der Seitenbaum ist bei uns ja so gestaltet:

Typo3 Site
- [>] Root
-- Homepage
-- Themenseite 1
-- Themenseite 2

Root ist also eine Verknüpfung zur Homepage.


Viele Grüße
Florian
___
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] Warum geht manchmal der Aufruf der Homepage ins Leere?

2019-06-18 Diskussionsfäden Florian Heß

Hallo Birgit,

danke für deine Antwort.

Am 18.06.19 um 15:27 schrieb Birgit:

Ich richte deswegen immer eine 301 Weiterleitung in der .htaccess ein von /home 
auf die baseURL.


So ergibt es eine endlose Ping-Pong-Weiterleitung zwischen baseURL und 
/home, oder verstehe ich falsch? Der Seitenbaum ist bei uns ja so gestaltet:


Typo3 Site
- [>] Root
-- Homepage
-- Themenseite 1
-- Themenseite 2

Root ist also eine Verknüpfung zur Homepage.


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

[TYPO3-german] Warum geht manchmal der Aufruf der Homepage ins Leere?

2019-06-18 Diskussionsfäden Florian Heß

Hallo,

ich oder andere rufen manchmal unsere mit Typo3 8.7 betriebene Seite 
auf, ohne Pfadteil d.h. einfach "/", und bekomme die Meldung, dass die 
Seite (/home) nicht gefunden werden konnte. Nachdem ich sie einmalig per 
ID (/?id=9) aufgerufen oder mich im Backend angemeldet habe, 
funktioniert sie auch wieder normal ohne diese ID. Was könnte da los 
sein? Andere URL funktionieren, unabhängig davon.


Ich vermute ein Problem mit RealURL. Da vor dem Zurücksetzen des 
URL-Caches gewarnt wird von wegen Beschädigung der Typo3-Installation 
(?), zunächst meine Frage, warum ist das so?


Das Problem ist seit etwa einem Monat aufgetreten, so frei nach dem 
Motto: "Du bist heute einer schwarzen Katze begegnet. Korrigiere ein 
Problem und gehe zwei Felder zurück." oder "ich habe nichts gemacht".


Vielen Dank im Voraus für Debugging-Vorschläge. Wir haben leider keinen 
Schimmer.



Viele Grüße
Florian

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Typo3 7.6.13: Speichern heißt das neue Verlieren ;-/. Eingaben verschwinden

2017-02-03 Diskussionsfäden Florian Heß

Am 03.02.2017 um 10:15 schrieb Mikel:

Hallo Florian,

ich vermute, es gab auch ein Update der SQL-Version, richtig?


Richtig, vo 5.5.53 auf 5.7.14. Also kann gut sein, dass der Default in 
der Version 5.6 geändert wurde.


Vielen Dank für deine Hilfe. Die Lösung funktioniert.


Viele Grüße
Florian


Dann liegt es wahrscheinlich am Strict-Mode der SQL-Version. Ab Version
5.5 (oder vielleicht war es auch 5.6) wurde der Strict-Mode zum Default
gemacht.

Du kannst dies nun global ändern (in der MySQL Konfiguration) oder in
der LocalConfiguration im SYS-Array folgenden Wert setzen:

'setDBinit' => 'SET SESSION sql_mode=\'\'',

Ich hoffe, ich konnte helfen.

Mikel



Am 03.02.2017 um 09:42 schrieb Florian Heß <h...@ub.uni-heidelberg.de
<mailto:h...@ub.uni-heidelberg.de>>:

Liebe Liste,

ich habe nach dem Update von 7.6.10 auf .13, zugleich Update von
Ubuntu 12.04 auf 16.04 (LTS), gibt es leider ein Problem mit dem Frontend.

Wir können zwar Seiten anlegen. Wollen wir sie dann mit Inhalten
befüllen und den Datensatz speichern, sind die Eingaben aber wieder
verloren.

Versuch ich es dann noch einmal und gebe probeweise etwa nur die
Überschrift ein, erscheint folgende Fehlermeldung rot am Kopf der Seite:

"2: SQL error: 'Field 'irre_parenttable' doesn't have a default value'"

Diese Fehlermeldung deutet auf einen Folgefehler hin. Im alten System
gab es das Tabellenfeld irre_parenttable ebenfalls mit NOT NULL +
DEFAULT NULL und da gab es ja keine Probleme damit. Daher gehe ich
davon aus, dass die Usache tatsächlich auf höherer Ebene liegt als an
irren Elterntabellen. Der Speichervorgang scheint das Setzen von
Werten wie irre_parenttable zu vergessen. Leider gibt er keine
diesbezügliche Fehlermeldug aus. Erstmalig bzw. einmalig nach "Clear
all cache" im Install-Tool führt das Speichern wie gesagt einfach ganz
ins Leere: D.h. die Eingabemaske wird offenbar einfach neu geladen.

Bevor ich zunächst wieder unsere alte Typo3-Instanz aktiv schalte, um
in Ruhe das Problem zu finden, ohne dass die Arbeit von Kollegen
dadurch blockiert ist: Habt ihr vielleicht eine Idee, woran es liegen
könnte?


Danke für eure Zeit,

Viele Grüße
Florian Heß




--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Typo3 7.6.13: Speichern heißt das neue Verlieren ;-/. Eingaben verschwinden

2017-02-03 Diskussionsfäden Florian Heß

Liebe Liste,

ich habe nach dem Update von 7.6.10 auf .13, zugleich Update von Ubuntu 
12.04 auf 16.04 (LTS), gibt es leider ein Problem mit dem Frontend.


Wir können zwar Seiten anlegen. Wollen wir sie dann mit Inhalten 
befüllen und den Datensatz speichern, sind die Eingaben aber wieder 
verloren.


Versuch ich es dann noch einmal und gebe probeweise etwa nur die 
Überschrift ein, erscheint folgende Fehlermeldung rot am Kopf der Seite:


"2: SQL error: 'Field 'irre_parenttable' doesn't have a default value'"

Diese Fehlermeldung deutet auf einen Folgefehler hin. Im alten System 
gab es das Tabellenfeld irre_parenttable ebenfalls mit NOT NULL + 
DEFAULT NULL und da gab es ja keine Probleme damit. Daher gehe ich davon 
aus, dass die Usache tatsächlich auf höherer Ebene liegt als an irren 
Elterntabellen. Der Speichervorgang scheint das Setzen von Werten wie 
irre_parenttable zu vergessen. Leider gibt er keine diesbezügliche 
Fehlermeldug aus. Erstmalig bzw. einmalig nach "Clear all cache" im 
Install-Tool führt das Speichern wie gesagt einfach ganz ins Leere: D.h. 
die Eingabemaske wird offenbar einfach neu geladen.


Bevor ich zunächst wieder unsere alte Typo3-Instanz aktiv schalte, um in 
Ruhe das Problem zu finden, ohne dass die Arbeit von Kollegen dadurch 
blockiert ist: Habt ihr vielleicht eine Idee, woran es liegen könnte?



Danke für eure Zeit,

Viele Grüße
Florian Heß

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Voreingestelltes Datum in einer Extension-Tabelle

2016-11-21 Diskussionsfäden Florian Heß

Hallo Liste,

wir benutzen als Blogkomponente die Extension T3ExtBlog. Diese Extension 
bringt ihre eigenen Felderdefinitionen mit, u.a. ein Feld "Datum" der 
Veröffentlichung von Blogposts. Teil ist auch eine Defaulteinstellung:


https://github.com/fnagel/t3extblog/blob/master/Configuration/TCA/tx_t3blog_post.php#L175

Dies interferiert leider mit unsem System-Cache. Das heißt, wenn man 
einen neuen Blogartikel erstellt, steht da immer das Datum des letzten 
System-Cache-Resets. Wäre das voreingestellte Datum das aktuelle, so 
bräuchte man es im Normalfall nicht anfassen. Kann ich das ohne Hacks 
irgendwie selbst erreichen oder lohnt sich ein Issue auf Github?



Viele Grüße
Florian Heß

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Template durch Redakteur bearbeiten

2016-06-16 Diskussionsfäden Florian Heß

Am 16.06.2016 um 13:53 schrieb Helmut Hummel:


Ich würde an dieser Stelle noch mal gerne auf etwas hinweisen, nur für
den Fall, dass das nicht bekannt sein sollte.

Wer Redakteuren Zugriff auf TypoScript gibt, gibt ihnen damit
Voll-Zugriff auf das System:

Beispiel:

1. PHP Datei, die einen Admin User in der Datenbank erzeugt (class
AdminUser, function create) als "create-admin.txt" in fileadmin hochladen
2. Folgendes TypoScript einbinden:

page.1 = USER
page.1.includeLibs = fileadmin/create-admin.txt
page.1.userFunc = AdminUser->create

Fertig ist der administrative Zugang.



Mea culpa, daran habe ich ja gar nicht gedacht! Zugegeben, ich habe 
nicht mal gewusst, dass man so mir nichts dir nichts beliebigen PHP-Code 
via TypoScript linken kann. Der PHP-Code könnte eben mal eine Shell 
öffnen oder andere feine Dinge tun. Gut zu wissen, wenn auch in meinem 
Fall - zum Glück - jetzt keine eklatante Sicherheitslücke zu stopfen 
ist, da wir Redakteuren nur einen Zweig von fileadmin/ freigeben, wovon 
wir natürlich nix includen.


Also, bitte meinen Tipp vergessen ... sorry. *pfeif*


Viele Grüße
Florian



Viele Grüße,
Helmut



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

Re: [TYPO3-german] Template durch Redakteur bearbeiten

2016-06-09 Diskussionsfäden Florian Heß

Am 08.06.2016 um 20:11 schrieb Hugo Merstein:

Hallo,

kann mir jemand kurz sagen, wie ich ein einzelnes Typoscript Template
zur Bearbeitung durch einen Redakteur freigeben kann?

Welche Seiteninhalte muss ich in der Backendbenutzergruppe freigeben?



Hallo Hugo,

keine Ahnung, ob das eleganter geht, aber du kannst Typoscript-Dateien 
in fileadmin/ hinterlegen, wo sie auch von Redakteuren bearbeitet werden 
kann. Dann kannst du sie z.B. im TSConfig via INCLUDE einbinden: "You 
can also add include-instructions in TypoScript code. Availability 
depends on the context, but it works with TypoScript templates, Page 
TSconfig and User TSconfig." -- 
https://docs.typo3.org/typo3cms/TyposcriptSyntaxReference/Syntax/Includes/



Viele Grüße
Florian


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



--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-23 Diskussionsfäden Florian Heß

Am 20.05.2016 um 20:58 schrieb Philipp Gampe:

Hi Florian,

Florian Heß wrote:


bedeutet das, Englisch muss immer =0 sein und Deutsch =1, damit das
funktioniert? Wenn ja, kann man das nachträglich ändern, und zwar
robust, schnell und einfach?


Nein, damit hat dies nichts zu tun! Für das Frontend kannst du frei
definieren, welche Locale es haben soll.

Aber in den Sprachdateien muss die "Default"-Datei (z.B. locallang.xlf)
immer Englisch sein. Localisierungen kannst du dann mittels lang.datei im
gleichen Ordner machen (z.B. de.locallong.xlf) oder du registriest die
Übersetzungen wie in der API beschrieben:
https://docs.typo3.org/typo3cms/CoreApiReference/Internationalization/Translation/Index.html#custom-translations

D.h. die Ausgangsprache muss in den Sprachdateien immer Englisch sein. Was
du dazu im Backend für die Spach-ID 0 ("Null"=Default Sprache) definiert ist
dir überlassen. Das kann Englisch sein, muss es aber nicht.



Hallo Philipp,

danke dir! Wenn ich die Datei homepage.xlf und de.homepage.xlf habe, in 
ersterer source-language="en" und nur source-Tags mit der englischen 
Version der Schnipsel, in letzterer source-language="en", 
target-language="de" und dann dementsprechend mit source- und 
target-language, dann funktioniert alles, wie es soll.



Viele Grüße
Florian


Grüße




--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-20 Diskussionsfäden Florian Heß

Am 20.05.2016 um 16:11 schrieb Dr. Dieter Porth:



Am 20.05.2016 um 14:26 schrieb Florian Heß:

Kann auch nicht, der Default muss in TYPO3 immer Englisch sein.


Hallo Phillip,

bedeutet das, Englisch muss immer =0 sein und Deutsch =1, damit
das funktioniert? Wenn ja, kann man das nachträglich ändern, und zwar
robust, schnell und einfach?

Dieters Tipp mit source-language="de" target-language="de" habe ich
probiert, leider ohne Erfolg. Ich warte jetzt auf Erkenntnis von
etwas, das ich bisher bloß übersehen habe.


Viele Grüße
Florian



Grüße


Hast du probiert, in der localLang.xlf . die source-Angaben in englisch
und die target-Angaben in Deutsch zu setzen, selbst wenn die
Defaultsprache für deine Frontend-Ausgabe deutsch ist.

Bei "source-language="de" target-language="de" bin ich mir nicht sicher,
ob die von TYPO3 überhaupt ausgewertet werden.

Dieter





Hallo Dieter,

jep, siehe meine Antwort an Ralf-René. :-) Hat leider nix gebracht, die 
target-Angaben werden schlicht ignoriert, sowohl für deutsch als auch 
für englisch gilt dasjenige im source-Tag.



Viele Grüße
Florian

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-20 Diskussionsfäden Florian Heß

Hallo Ralf-Rene,

basierend auf deiner Antwort habe ich also en.homepage.xlf probehalber 
gelöscht. In homepage.xlf habe ich geändert zu source-language="en" 
target-language="de", trans-unit id="more", source more und target Mehr 
-> führt weiterhin stoisch zu "more" sowohl in der deutschen als auch in 
der englischen Sicht.


Nun, vielleicht sollte ich erst mal aktualisieren von 7.6.4 auf .7 ...

Viele Grüße
Florian

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-20 Diskussionsfäden Florian Heß

Kann auch nicht, der Default muss in TYPO3 immer Englisch sein.


Hallo Phillip,

bedeutet das, Englisch muss immer =0 sein und Deutsch =1, damit das 
funktioniert? Wenn ja, kann man das nachträglich ändern, und zwar 
robust, schnell und einfach?


Dieters Tipp mit source-language="de" target-language="de" habe ich 
probiert, leider ohne Erfolg. Ich warte jetzt auf Erkenntnis von etwas, 
das ich bisher bloß übersehen habe.



Viele Grüße
Florian



Grüße




--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-20 Diskussionsfäden Florian Heß

Am 11.05.2016 um 18:42 schrieb Dieter Porth:

TYPO3-Bug
https://forge.typo3.org/issues/74380

setze in der defaultdatei locallangxlf  und . 
muss die Englischen Begriffe enthalten  die Deutschen

Dann funktioniert alles ganz gut. Die anderen Sprachen sind von diesem
Bug nicht betroffen.
Besser wäre natürlich, wwenn du einen Patch zu dem Bug anbieten
könntest. Ich habe die Logik damals leider nicht wirklich verstanden.


Hallo Dieter,

entschuldige bitte die Verzögerung, ich war im Urlaub.

Für einen Patch reichen meine Typo3-Kenntnisse bedauerlicherweise auch 
nicht aus.


Also in homepage.xlf (oder ist es wichtig, dass die Datei locallang.xlf 
heißen muss?) habe ich jetzt geändert zu: [XML-Klammern und schließende 
Tags dazudenken, weil s.u.]

file source-language="en" target-language="de"
. trans-unit id="more"
.. source More
.. target Mehr

Die Datei en.homepage.xlf im selben Verzeichnis scheint aber vollkommen 
ignoriert zu werden. Leider wird jetzt sowohl bei der deutschen, als 
auch bei der englischen Ansicht die englischen Zeichenfolgen ausgegeben.






Dieter

P.S. Wenn du schon Nachrichten per Mail schickt, dann achte auf Tags. Im
Forum sieht deine Mail unlesbar aus.



So? Ich habe mich in der Sache mal an den Kontakt der Seite gewendet, da 
es sich in meinen Augen eher um einen serverseitigen Fehler handelt.



P.P.S Du musst ich in jeder übersetzten xlf-datei noch mal im
-Tag den dt. Originaltext wiederholen, damit du in jeder Datei
weisst, welche Übersetzungen du zugrunde gelegt aktuelle hast
(Dokumentation) damit du Dateivergleiche zwischen default und
Übersetzten Dateien durchführen kannst, um gegebenenfalls zu prüfen,
welche Änderungen erfolgt sind. (Validierung) damit du den Bug in TYPO3
umgehen kannst (siehe oben).


Danke, das ist verständlich! :-)



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



--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Lokalisierung: Texte der Nicht-Default-Sprache werden nicht gefunden

2016-05-11 Diskussionsfäden Florian Heß

Liebe Liste,

mein Typo3 7.6.4 greift auch in der englischen Ansicht auf die deutschen 
Strings zu. Was habe ich vergessen?


fileadmin/i10n/homepage.xlf:
--8<


  

  
 Mehr
  
  
 Wir auf
  
  
 Impressum
  

  


fileadmin/i10n/en.homepage.xlf:
--8<---


  original="messages" date="2012-10-17T17:55:17Z">


  
Mehr
More
  
  
 Wir auf
 Find us on
  
  
 Impressum
 Imprint
  

  


Im Fluidtemplate z.B.:
8<






Dass die deutschen Originaltexte tatsächlich aus obiger Datei geholt 
werden, konnte ich schon mal verifizieren, indem ich den System-Cache 
zurückgesetzt habe, dazwischen die Textstrings abgeändert habe.


Noch ein Verständnisfrage: (Warum) muss ich in der Übersetzung noch mal 
im -Tag den dt. Originaltext wiederholen? Das habe ich daher: 
https://docs.typo3.org/typo3cms/CoreApiReference/Internationalization/Introduction/



Viele Grüße
Florian Heß

--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] index.php?id=...=...

2016-04-14 Diskussionsfäden Florian Heß

Am 14.04.2016 um 11:51 schrieb Bernd Wilke:

Hallo Bernd,

danke! Diese Lösung erscheint mir vielversprechend. Nur wie bzw. woher
Typo3, dass es in Object "page100" die Konfiguration findet, die bei
=100 gelten soll? Wo muss ich das definieren?


das passiert durch das "typeNum = 100"
das legt fest dass dieses Object für die Ausgabe gerendert wird wenn in
der URl ein paramter "=100" vorhanden ist.

die Benamung 'page100' ist willkürlich, aber da das default page object
(=0 oder gar keine Angabe) normalerweise 'page' heisst (es gibt
extensions, die das in ihrem Typoscript voraussetzen :-( ) weiss ich
(oder ein anderer Admin) mit 'page100', dass es sich a) um ein
page-Object handelt, b) dass es für den Type 100 definiert ist



Hallo Bernd,

vielen Dank für deine Erklärung. Habe überlegt, ob die Objekt-ID 
"noFeedAvailable" oder so nicht für den Zweck geeigneter wäre, aber ist 
ja dann auch egal, wie es heißt, TypoScript lässt sich ja auch mit 
entsprechenden Kommentaren dekorieren.


zu page100 habe ich dann noch definiert:
page100 = PAGE
page100 {
typeNum = 100
config.disableAllHeaderCode = 1
config.additionalHeaders = HTTP/1.1 404 Not Found
10 = TEXT
10.value = 404 Not Found: Parameter =100 nicht mehr 
unterstützt (UB/Verantwortl. + Datum)

}

Eine ganz leere Seite würde begünstigen, dass sich irgendwer, wenn nicht 
gar ich selbst, später nen Wolf sucht.



Viele Grüße
Florian


PS: Du willst lt. Header, dass ich auch nach "typo3.german" poste. Macht 
mein Thunderbird nicht mit, weil es sich nicht um eine gültige 
Mailadresse handelt. Daher habe ich diesen Empfänger entfernt.



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



--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] index.php?id=...=...

2016-04-14 Diskussionsfäden Florian Heß

Am 14.04.2016 um 10:02 schrieb Bernd Wilke:

aber zur Not kannst du natürlich auch ein page-objekt für den Type 100
erstellen.

dort kannst du dann alles machen. natürlich auch einen responsecode 404
ausgeben:

page100 = PAGE
page100 {
typeNum = 100
config.disableAllHeaderCode = 1
config.additionalHeaders = HTTP / 1.1 404 Not Found

// oder auf die fertige 404-Seite redirecten:
config.additionalHeaders = Location: /404.html


Hallo Bernd,

danke! Diese Lösung erscheint mir vielversprechend. Nur wie bzw. woher 
Typo3, dass es in Object "page100" die Konfiguration findet, die bei 
=100 gelten soll? Wo muss ich das definieren?


An dieser Stelle auch vielen Dank an *Peter* und *Renzo* für ihre 
Antworten. Die Idee mit .htaccess bzw. der Webserverkonfiguration ist 
auch gut, nur zeigt sie bei mir keine Wirkung. Wo auch immer das Problem 
liegt, das bekommen wir bestimmt auch noch raus. :-)


RewriteEngine On
RewriteCond %{QUERY_STRING} /\btype=100\b/
RewriteRule (.*)$ - [R=404,L]


Viele Grüße
Florian


--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] index.php?id=...=...

2016-04-13 Diskussionsfäden Florian Heß

Guten Tag,

wir haben ein Webangebot samt Domain von anderer Seite übernommen, 
layoutmäßig und inhaltlich generalüberholt und hosten es nunmehr unter 
Typo3 7.6.4.


Wir bekommen recht oft, wahrscheinlich von einem RSS-Feed-Aggregator 
Requests nach /index.php?id=194=100 herein. Da sprechende URLs 
verwenden, handelt es sich anscheinend um Requests an das System vor dem 
Relaunch. Die bezeichnete Ressource gibt es nicht mehr, id=194 selbst 
jedoch schon. Ich würde nun gerne die Massen identischer Logzeilen 
vermeiden wollen, da die wirklich relevanten Meldungen darin untergehen. 
Hier ein Beispiel:


Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1294587217: 
The page is not configured! [type=100][]. This means that there is no 
TypoScript object of type PAGE with typeNum=100 configured. | 
TYPO3\CMS\Core\Error\Http\ServiceUnavailableException thrown in file 
.../typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php 
in line 2592. Requested URL: .../index.php?id=194=100.


Kann ich Typo3 via TypoScript, vermutlich via TSConfig auf der Seite ID 
194 anweisen, ordentlich HTTP 404 zurückzugeben? Oder sieht jemand eine 
andere Möglichkeit?


Ich bin erst seit kurzem mit Typo3 überhaupt zugange und würde mich 
daher über möglichst einfach gehaltene Erklärungen sehr freuen. :-)



Viele Grüße
Florian Heß




--
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german