CONTENIDO Forum

Vielen Dank!

Hallo Bodil,

kurzer Feedback zu TinyMCE 3 und den kaputten blauen Icons.

Die WYSIWYG-Editor Dateien wurden überarbeitet, auch die von TinyMCE 3, nun sollte auch der Bereich kompatibel mit PHP 8 sein, falls es nicht vorher schon der Fall war.

Das mit den blauen Icons ist korrigiert. Es gab letztens Änderungen in dem Bereich, in Verbindung mit der Versionierung. Da wurden letztens die Formulare (Inhalte Bearbeiten & Versionierung) zusammengeführt und deshalb hat ein Klick auf den Icon die falsche Aktion ausgeführt.

Danke fürs Bescheid geben.

Gruß

Murat

Hi Murat!
Ich bin leider heute erst zum Testen gekommen, aber alles funktioniert wieder wie gewünscht. Vielen Dank! Der Tinymce3 lief vorher schon unter PHP8, das hätte ich vielleicht erwähnen sollen, der hatte vermutlich auch nur das Problem mit dem blauen Button.
Liebe Grüße!
Bodil

Mir ist gerade noch eine C-Problematik aufgefallen: Im SEO-Tab der Artikel hat der Meta-Tag-Bereich einen eigenen grünen Häkchen-Button. Ich verstehe den Sinn des neuen Hakens nicht, aber er hat denselben Accesskey wie der zweite Haken: »s«. (Und so weit ich sehe macht er nichts anderes als der andere Haken ) Das Problem dabei: wer die SEO-Einstellungen mit Shift+Alt+s zu Speichern glaubt, gibt dem ersten der beiden Buttons lediglich den Fokus, gespeichert wird nichts ...
Beheben lässt sich das Problem indem man im Template template.con_meta_edit_form.html in Zeile 198 den Button wieder rausschmeißt (falls er wirklich nichts anderes tut als der 2. Button) oder einen anderen Accesskey einträgt. (Z. B. ein »m« – wie Metatag ).

Aber apropos Metatags:
Wenn ich da einen Metatg eintrage mit Name und Wert, erscheint eine neue Zeile mit Name und einem leeren Input-Feld. Da kann ich einen Wert eintragen und kann den auch speichern. So wie ich das Formular verstehe, könnte da auch gleich der eingegebene Wert gespeichert werden. Aber auch das: eine C-Problematik ...

Hallo Bodil,

die zwei Hacken machen beide dasselbe und haben also kein unterschiedliches Verhalten, sogar das accesskey-Attrubut ist identisch.

Ich habe den zweiten Button aus folgenden Gründen eingebaut:

• Der einzelne Button zuvor war bei den Meta Tags, rechts vom [+] (Plus-Button). Das ist etwas irreführend, da man das Gefühl hat, damit die Meta Tags zu speichern.
• Normalerweise haben alle Formulare immer am Ende eine Button-Leiste mit einem oder mehreren Buttons. Im SEO-Tab ist da noch eine Zeil "HTML-Ansicht"

Eigentlich braucht man nur einen, ich weiß aber nicht, warum der Button damals bei den Meta Tags angebracht wurde und nicht ganz zum Schluss. Daher habe ich am Ende nochmal eines hinzugefügt.

Du hast recht, ein accesskey-Attribut mit "m" für den Metatag-Button würde das jetzige Problem lösen.

Meiner Meinung nach sollte der Button am Ende ausreichen, das ist das übliche Verhalten und das, was die Benutzer erwarten und kennen. Außerdem speichern beide Buttons immer das ganze Formular und nicht wie suggeriert wird, die Meta Tags und das SEO-Formular separat.


Beim Erstellen eines neuen Meta Tags wird das Feld "Meta Attribut" mit dem Wert "name" vorbelegt. Es funktioniert ähnlich wie ein placeholder-Attribut.
Klickt man rein, wird es entfernt, verliert das Feld des Fokus und ist leer, wird es wieder mit "name" belegt.
Vermutlich ist die Idee dahinter, hier das Feld mit für die Bezeichnung des "name"-Attributes vorzubelegen, weil die meisten Meta Tags dies haben. Es darf auch nicht leer sein, sonst wird kein neuer Metatag-Eintrag angelegt. Das gilt wohl auch für den Inhalt des Feldes "Attribut Inhalt", ist der leer, wir auch kein Metatag-Eintrag angelegt.

Das Vorbelegen mit "name" scheint eine gute Lösung zu sein. Vermutlich würden ohne eine detaillierte Erklärung viele nicht verstehen, was sie da eingeben sollen. Andererseits wird das Ganze verständlicher, wenn man sich die " HTML-Ansicht" der Meta Tags anzeigen lässt.

Ich denke, die Funktionalität ist folgendermaßen.
Meta Tags haben den Aufbau: Mit "Meta Attribut" gibt man das Attribut "name" an, das kann aber auch "http-equiv" oder "property" (für Open Graph) sein.
Mit "Attribut Inhalt" gibt man den Inhalt des "name" Attributes an, siehe Platzhalter "[description]"
Dann kann man in der Liste der benutzerdefinierten Meta Tags, den Wert für das Attribut "content" eintragen, siehe Platzhalter "[value]".

Gruß
Murat

Hallo,

We sieht es jetzt mit einer neuen, auf PHP 8 laufenden, Version von Contenido aus?

Gibt es einen geplanten Veröffentlichungstermin?
Arbeitet überhaupt jemand daran?

TSK

tsk hat geschrieben: Fr 21. Apr 2023, 09:21We sieht es jetzt mit einer neuen, auf PHP 8 laufenden, Version von Contenido aus?

Die Developer Version läuft schon mit PHP 8.1
https://github.com/CONTENIDO/CONTENIDO/ ... evelop.zip

Gibt es einen geplanten Veröffentlichungstermin?

Geplant leider noch nicht, das liegt in der Hand von 4fb.

Arbeitet überhaupt jemand daran?

Es wird ständig daran gearbeitet.

Hallo Faar!

Faar hat geschrieben: Sa 22. Apr 2023, 09:17
Die Developer Version läuft schon mit PHP 8.1
https://github.com/CONTENIDO/CONTENIDO/ ... evelop.zip

Wenn ich von 4.10.1 das Update machen möchte, wie sieht der Ablauf aus?
Wie gehabt Dateien in die jeweiligen Ordner entpacken/überschreiben und anschließend Setup ausführen?
Anschließend, wenn alles geklappt hat die Module überprüfen auf php8 Funktionalität.

mattmarr hat geschrieben: So 23. Apr 2023, 07:44 Wie gehabt [...]

Ja. Vorher ein Backup machen macht immer Sinn.

mattmarr hat geschrieben: So 23. Apr 2023, 07:44 Hallo Faar!
Wenn ich von 4.10.1 das Update machen möchte, wie sieht der Ablauf aus?
Wie gehabt Dateien in die jeweiligen Ordner entpacken/überschreiben und anschließend Setup ausführen?
Anschließend, wenn alles geklappt hat die Module überprüfen auf php8 Funktionalität.

Das läuft wie üblich ab, es ist ja wie eine normale Version.
Zuerst sollte man sich die Daten sichern, am besten alle Dateien im Contenido-Web Verzeichnis und auch die Datenbank, sicher ist sicher.
Damit keine Altlasten übrig bleiben, sollte man unbedingt vorher die /Contenido, /docs, /setup und /test Verzeichnisse in _old oder so ähnlich umbenennen oder sogar löschen.
Im /data Verzeichnis stehen die wichtigen Config-Daten für das System und im /cms (oder eigene Benennung) Verzeichnis stehen die Daten für die Webseite.
Die nicht löschen, sondern nur überschreiben. Die Module und die config im /cms werden beim UPDATE nicht mehr erzeugt und nicht folglich überschrieben. Beim /data sieht es etwas anders aus, da auch beim Update die Config.php erzeugt wird (bin mir gerade nicht sicher) und hier sollte man dann herunterladen angeben statt überschreiben. in der config.php des /data Verzeichnisses könnten einige Pfade anders sein als üblich, wenn man z.B. das Setup in /domain/setup macht aber der Zugang zum Backend über z.B. backend.domain.tld läuft und https und http Pfade bestehen.
Das Setup übernimmt dann die Daten der bestehenden config.php und die muss man dann nicht wieder mühsam heraussuchen und eintippen.

Jedenfalls sollte das Backend danach funktionieren, da es ohne Frontend läuft.
Das Frontend kann jedoch eine weiße Seite darstellen, weil irgendwas einen fatalen Fehler erzeugt und PHP stoppt.
Meistens Module, die nicht mehr kompatibel zu erneuerten Funktionen in Contenido sind.
Falls alles läuft, kann man danach auf PHP 8.1 hochschalten und schauen, was alles angemeckert wird.

In den Logfiles vom /data/logs Verzeichnis steht dann vermutlich so einiges.
Und je mehr man die Seite durchklickt, falls sie läuft, umso mehr steht da drin.
In dem Fall sind es eher nur Warnungen, weil fatale Fehler das Programm stoppen würden.
Eventuell sind die Warnungen unterdrückt worden, dann sollte man sich hiermit mal befassen.
https://www.php.net/manual/de/errorfunc ... -reporting
Mit Beispielen hier:
https://www.php.net/manual/de/function. ... orting.php
In der config.php steht dann sowas wie:

Faar hat geschrieben: Mo 24. Apr 2023, 08:27 ... Falls alles läuft, kann man danach auf PHP 8.1 hochschalten und schauen, was alles angemeckert wird.

Also kann ich in aller Ruhe erst mit PHP 7.4.x auf die DEV updaten, dann testen und erst später einfach den PHP von 7.4.x auf PHP 8.x Switchen?

mattmarr hat geschrieben: Mo 24. Apr 2023, 11:49 Also kann ich in aller Ruhe erst mit PHP 7.4.x auf die DEV updaten, dann testen und erst später einfach den PHP von 7.4.x auf PHP 8.x Switchen?

Ja.