Re: [TYPO3-german] [Typo3 7.6.x] ke_search und MASK
Ich hab da leider auch keine Idee, aber das Thema interessiert mich grundsätzlich auch sehr! Wäre schön wenn dazu jemand ein Beispiel parat hätte! Am 23.11.17 um 10:49 schrieb Dave Zen: Hat keiner Idee wie man hier vorzugehen hat? Ich habe mir auch mal die Extension DCE angeschaut, da es dafür einen Hook gibt um mit ke_search die Inhalte dieser Contentelemente zu indexieren. https://bitbucket.org/ArminVieweg/dce/src/72e9dcc3d2c1da0067ff47c844bdc0c02bcef598/Classes/Hooks/KeSearchHook.php?at=develop&%3Bfileviewer=file-view-default&fileviewer=file-view-default Leider weiß ich noch nicht, wo man hier Anpassungen vorzunehmen hat damit dies mit MASK funktioniert... ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Form: Fehlermeldungen wie anzupassen?
Hallo meine lieben Freunde! Ich habe folgendes Problem: System: Typo3 8.7.8 auf Apache gehostet von world4you.com! Ich habe ein Kontaktformular mit der vorinstallierten Extension "form" ein Kontaktformular erstellt! Nach Eingabe von richtigen Daten werden alle gewünschen Aktionen wie erwartet durchgeführt! Nun habe ich 2 Probleme: 1. Dateitypen als Anhang werden nur *.dib akzeptiert 2. Fehlermeldungen nach klicken auf "Absenden" sind alle in Englisch, wie kann ich diese Meldungen anpassen (TypoScript?)? Danke euch schon mal für die Mühe! MFG Michael Florian Zobl Freiwilliger Pannen- und Störungsdienst ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Update auf 7.6.6: Backend zeigt nur Menü
Quote: Carsten Lukowitz (luko72) wrote on Mon, 13 November 2017 15:43 Hallo zusammen, ist zwar schon etwas älter das Thema, aber ich hatte heute genau das selbe Problem. Ich habe ein funktionierendes Live-System (TYPO3 7.6.22) vom Webserver auf den lokalen Rechner gezogen (WAMP). Im Backend wurde nur das Menü auf 100% Breite angezeigt, kein Content. Klicke ich auf einen Menüpunkt, öffnet sich die entsprechende Seite im ganzen Fenster. Lösung bei mir: im Install-Tool die Debug-Settings von 'Live' auf 'Debug' umgestellt -> BE ist normal verfügbar. Setze ich die Einstellung wieder zurück, sehe ich wieder nur das Menü. Grüße luko72 Nachtrag: 'BE/debug' => '1' reicht aus, das ist der Knackpunkt ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] mal wieder CKEditor
Hallo Birgit,
danke, das müsste via Constants mal ausprobiert werden. Solang sich das
im Backend regeln lässt und nicht in den Serverdateien fest eingetragen
werden muss (also bei Updates wieder weg wäre und dann als
nachzuarbeitendes Detail ggf. übersehen wird), ist das sicher einen Test
mit passenden Größen wert.
Ich bin in der Hinsicht halt sensibilisiert, weil ich mit diesen
max-Wert-Geschichten schon anderweitig Probleme hatte.
Momentan kann ich sagen, dass die alten News ihre Bilder in der
eingestellten Größe verarbeiten und anzeigen. Das liegt zum Einen daran,
dass die meisten Bilder auf die Größe hoin vorbearbeitet waren und nur
noch zu ausgelesen werden müssen. Anbsonsten hatte ich anfangs Probleme,
es aber entsprechend irgendwie hinbekommen, dass CK_Editor die DB-Felder
vollständig ausliest. Weiss nicht mehr, wie ich das bei den Bildern
gemacht habe. Es hatte glaub ich mit den Modulen für den Bildeinbau zu
tun. Das war ja nicht von Anfang an als Modul vorhanden.
Hab grad nochmal ein neues Bild versucht und habe im BE alles klar, im
FE wird es aber nur mit 300px ausgegeben. Das passt zusammen...aber war
das nicht neulich auch im BE so ? Kurios...
Cu, Steffen
Am 24.11.2017 um 10:37 schrieb Birgit:
Hallo Steffen,
hast du den Tip von Christian Hackl am 16.11. mal gecheckt?
In den TypoScript Constants steht in fluid_styled_content standardmäßig (TYPO3
8.7):
styles.content {
textmedia {
maxW = 600
maxWInText = 300
}
}
Das setzt auch alle Bilder in Text/Bild Elementen auf die maximale Breite von
300px.
In css_stxled_content sieht das per default so aus (TYPO3 8.7):
styles.content.imgtext {
maxW = 600
maxWInText =
}
styles.content.textmedia {
maxW = 600
maxWInText = 300
}
Der Wert muss also bei Umstellung von css_styled_content auf
fluid_styled_content ggf. neu gesetzt werden.
Wenn du den Wert geändert hast, kannst du in einem NEUEN Element testen, ob das
was bringt.
Alte Elemente musst du evtl. öffnen und neu speichern, wenn die 300px in der DB
im RTE-Feld gespeichert sind.
Was ich nicht weiß, weil ich grundsätzlich keine Bilder im RTE zulasse.
Wenn die Formatierung nicht in der DB gespeichert ist, müsste es reichen, alles
aus dem „Prozessed“ Ordner zu löschen, damit der sich neu aufbaut.
ImageMagic greift standardmäßig nur dann ein, wenn das verwendete Bild größer
ist als die erlaubte Maximalgröße.
Viele Grüße Birgit
Am 23.11.2017 um 22:33 schrieb Steffen Liebig :
Ergänzung: "für diesen Zweck" meint die News grundsätzlich, wobei ich das Ganze
für Bilder anderswo auf der Seite nicht ausprobiert habe. Wir haben die meisten Bilder in
den News. Da mir das aber im Editor passiert, befürchte ich, dass es auf dem Rest der
Seite genauso laufen würde. Ob das dann wirklich am Editor liegt oder an der internen
Behandlung von Bildern im Typo3, ist eine andere Frage. Ich habe es halt im Editor
bemerkt, weil ich damit die Texte bearbeite, wo dann die Bilder drin sind.
Am 23.11.2017 um 22:27 schrieb Steffen Liebig:
Da ist was durcheinandergeraten.
Das Problem im CK-Editor hat mit dem elektronischen Archiv nix zu tun. Der
CK-Editor stutzt mir enfach ALLES auf 300 px Breite zurecht und lässt mich in
den Bildgrößen zu den Einzelbildern auch nichts Größeres zu. Das ist ziemlich
schlecht für die Optik spätestens auf einem auf einem großen Bildschirm. Wobei
der Bildcschirm bei 300px schon fast egal ist. Eine News, die layoutbedingt
(z.B. in der Einzelansicht) in eine große Mittelspalte geladen wird...da machen
so kleine Bilder einfach einen schlechten Eindruck.
Das elektronische Archiv (also NICHT das Newsarchiv auf der Liveseite) liegt
extern auf meinem Rechner. Das ist nur ein Ordner mit derselben Struktur wie
ind er Newsabteilung unter Fileadmin, in dem die News als Einzeldateien im
HTML-Format liegen. Also nix weiter als aus dem Browser kopierter
Hintergrundcode incl. der Links zu den Bildern und Dateien. Aus den Links wird
nur der Teil, der zur Online-Seite führt, gestrichen, damit die Sachen nicht
aus Typo3, sondern vom Rechner (wo auch immer das dann liegen mag) geholt
werden.
Das Ergebnis mit einem processed-Ordner dazwischen kann man sich vorstellen -
entweder für jede Datei noch extra den Pfad anpassen oder ständig hinterher
sein und den Unterordner mit auf den eigenen Rechner kopieren. Dann habe ich
aber alles im selben Ordner und darin einen Haufen Unterordner, mit denen
niemand was anfangen kann, weil die Bezeichnungen (vor dem Runterladen)
automatisch von Typo3 angelegt wurden.
Summa summarum scheint es also für diesen Zweck sinnvoller zu sein, ohne diese
Automatik zu arbeiten. Zumal ich auf das elektronische Archiv nicht verzichten
kann...das soll nämlich bei Bedarf auch mal an unseren Referenten fürs Archiv
weitergereicht werden können, damit man die News auch nach Typo3 (was immer das
heißen mag) noch hat. Eine Art Sicherheitskopie aus archivarischen Grün
[TYPO3-german] Kategorien zu Dateien in einer Dateiliste ausgeben
In einem Fluid Template für die Auflistung von Dtaeien möchte ich auch die
Kategorien ausgeben, die der jeweiligen Datei zugeordnet sind. Ich dachte, das
kann ja nicht so schwer sein, ist es aber wohl doch. bei meiner Suche habe ich
nur {file.properties.categories} gefunden und das gibt mir leider nur die
Anzahl der zugewiesenen Kategorien aus.
jetzt versuche ich mit TS die Kategorien auszulesen. Ich habe folgendes
Typoscript:
lib.fileCategories = CONTENT
lib.fileCategories {
table = sys_category
select {
pidInList = root
selectFields = sys_category.uid
join = sys_category_record_mm on sys_category_record_mm.uid_local =
sys_category.uid
where.field = recordUid
where.wrap = sys_category_record_mm.uid_foreign=|
}
renderObj = COA
renderObj {
1 = TEXT
1 {
field = uid
stdWrap.noTrimWrap = | cat-||
}
}
}
Das Fluidtemplate auf das Problem reduziert sieht so aus:
Die Kategorien sind ja direkt bei den Dateien in der Fileadmin vergeben.
Es gibt leider keine Ausgabe. Wo könnte der Fehler liegen und warum ist das so
kompliziert?
Freue mich über jeden Hinweis, danke!
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Fehler "The PackageStates.php file is either corrupt or unavailable"
Hallo Christian,
kann es sein, dass Du Deine eigentliche Installation umgehst und direkt im
Core-Verzeichnis aufrufst?
Ich kenne Deine Verzeichnisstruktur nicht. Der Core ist in deinem webroot
„versymlinkt“. Verwendest Du diesen Pfad? (z.B. web/typo3/cli_dispatch.phpsh)
Mikel
> exec("php70 ./typo3_src-8.7.8/typo3/cli_dispatch.phpsh scheduler",$ausgabe);
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] mal wieder CKEditor
Hallo Steffen,
hast du den Tip von Christian Hackl am 16.11. mal gecheckt?
In den TypoScript Constants steht in fluid_styled_content standardmäßig (TYPO3
8.7):
styles.content {
textmedia {
maxW = 600
maxWInText = 300
}
}
Das setzt auch alle Bilder in Text/Bild Elementen auf die maximale Breite von
300px.
In css_stxled_content sieht das per default so aus (TYPO3 8.7):
styles.content.imgtext {
maxW = 600
maxWInText =
}
styles.content.textmedia {
maxW = 600
maxWInText = 300
}
Der Wert muss also bei Umstellung von css_styled_content auf
fluid_styled_content ggf. neu gesetzt werden.
Wenn du den Wert geändert hast, kannst du in einem NEUEN Element testen, ob das
was bringt.
Alte Elemente musst du evtl. öffnen und neu speichern, wenn die 300px in der DB
im RTE-Feld gespeichert sind.
Was ich nicht weiß, weil ich grundsätzlich keine Bilder im RTE zulasse.
Wenn die Formatierung nicht in der DB gespeichert ist, müsste es reichen, alles
aus dem „Prozessed“ Ordner zu löschen, damit der sich neu aufbaut.
ImageMagic greift standardmäßig nur dann ein, wenn das verwendete Bild größer
ist als die erlaubte Maximalgröße.
Viele Grüße Birgit
> Am 23.11.2017 um 22:33 schrieb Steffen Liebig :
>
> Ergänzung: "für diesen Zweck" meint die News grundsätzlich, wobei ich das
> Ganze für Bilder anderswo auf der Seite nicht ausprobiert habe. Wir haben die
> meisten Bilder in den News. Da mir das aber im Editor passiert, befürchte
> ich, dass es auf dem Rest der Seite genauso laufen würde. Ob das dann
> wirklich am Editor liegt oder an der internen Behandlung von Bildern im
> Typo3, ist eine andere Frage. Ich habe es halt im Editor bemerkt, weil ich
> damit die Texte bearbeite, wo dann die Bilder drin sind.
>
> Am 23.11.2017 um 22:27 schrieb Steffen Liebig:
>> Da ist was durcheinandergeraten.
>>
>> Das Problem im CK-Editor hat mit dem elektronischen Archiv nix zu tun. Der
>> CK-Editor stutzt mir enfach ALLES auf 300 px Breite zurecht und lässt mich
>> in den Bildgrößen zu den Einzelbildern auch nichts Größeres zu. Das ist
>> ziemlich schlecht für die Optik spätestens auf einem auf einem großen
>> Bildschirm. Wobei der Bildcschirm bei 300px schon fast egal ist. Eine News,
>> die layoutbedingt (z.B. in der Einzelansicht) in eine große Mittelspalte
>> geladen wird...da machen so kleine Bilder einfach einen schlechten Eindruck.
>>
>> Das elektronische Archiv (also NICHT das Newsarchiv auf der Liveseite) liegt
>> extern auf meinem Rechner. Das ist nur ein Ordner mit derselben Struktur wie
>> ind er Newsabteilung unter Fileadmin, in dem die News als Einzeldateien im
>> HTML-Format liegen. Also nix weiter als aus dem Browser kopierter
>> Hintergrundcode incl. der Links zu den Bildern und Dateien. Aus den Links
>> wird nur der Teil, der zur Online-Seite führt, gestrichen, damit die Sachen
>> nicht aus Typo3, sondern vom Rechner (wo auch immer das dann liegen mag)
>> geholt werden.
>> Das Ergebnis mit einem processed-Ordner dazwischen kann man sich vorstellen
>> - entweder für jede Datei noch extra den Pfad anpassen oder ständig
>> hinterher sein und den Unterordner mit auf den eigenen Rechner kopieren.
>> Dann habe ich aber alles im selben Ordner und darin einen Haufen
>> Unterordner, mit denen niemand was anfangen kann, weil die Bezeichnungen
>> (vor dem Runterladen) automatisch von Typo3 angelegt wurden.
>>
>> Summa summarum scheint es also für diesen Zweck sinnvoller zu sein, ohne
>> diese Automatik zu arbeiten. Zumal ich auf das elektronische Archiv nicht
>> verzichten kann...das soll nämlich bei Bedarf auch mal an unseren Referenten
>> fürs Archiv weitergereicht werden können, damit man die News auch nach Typo3
>> (was immer das heißen mag) noch hat. Eine Art Sicherheitskopie aus
>> archivarischen Gründen halt.
>>
>> So viel mal für den Fall, dass sich noch jemand am Thema beteiligen möchte.
>> Wenn sich per Mail was ergibt, landet das ebenfalls hier.
>>
>> Am 17.11.2017 um 21:30 schrieb Christian Hackl:
>>> Ich denke mit einem eigenem Page object in dem du das originale
>>> reinkopierst und dann vielleicht ein eigenes Template dafür erstellst,
>>> macht es dir einfacher.
>>> Du kannst dann in deinem extra archive_template dafür sorgen das nur
>>> original Bilder von der original Source ausgegeben werden ohne das du die
>>> eigentliche Webseite für alle normalen User angepasst oder geändert werden
>>> müsste - vorteil für beide Seiten, schnelle ladezeiten und für das
>>> jeweilige Endgerät angepasste Bilder und gleichzeitig für das Archiv die
>>> unangepassten original Dateien. :)
>>> Hast ne Mail :)
>>
>>
>
> ___
> 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-bi
