Posts by Chefpraktikant

Ich hab's auf Mac jetzt hinbekommen.

Erster Fehler: Man darf die https://xxx.de/webEdition/davfs.php nicht im Browser öffnen (dann rennt man in die htaccess-Abfrage), sondern muss die URL im Finder über "Mit Server verbinden" eingeben.

Dann liefert der Finder bei mir zwar ein Login-Fenster, doch die Eingabe von Benutzer und Kennwort (beides von meinem Admin-Account in webEdition) wird nicht akzeptiert - das Login-Fenster kommt immer wieder.

Ursache (laut Claude und nach Verbindungsversucht mit Curl übers Mac Terminal): "Apache streift den Authorization-Header ab, bevor er ihn an PHP weitergibt. Das passiert häufig bei PHP als CGI/FastCGI (was auf den meisten Shared-Hosting-Umgebungen der Fall ist)."

Ich habe also in der .htaccess in der Root von webEdition folgende zwei Zeilen vorangestellt. Die "stellen sicher, dass der HTTP Authorization-Header (z. B. für Basic-Auth oder API-Token) von Apache an PHP weitergeleitet wird":

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Jetzt sehe ich im Finder die gewünschten Verzeichnisse documents, template, weTags, etc.

Ich wollte mich mal mit der Möglichkeit beschäftigen, Vorlagen mittels WebDAV zu bearbeiten. Ich scheitere aber schon am ersten Schritt:

Quote

Damit webEdition über webdav benutzt werden kann ist es nötig sich in webEdition anzumelden. Derzeit kann dies aus Sicherheitsgründen nur mit einem Administrator-Account gemacht werden. Anschließend kann man die Verknüpfung https://xxx.de/webEdition/davfs.php öffnen. Nach Eingabe von Benutzername und Passwort öffnet sich eine Verzeichnisansicht mit den Verzeichnissen

Leider erscheint trotz Eingabe des richtigen Benutzers/Passworts immer wieder die htacess-Loginabfrage. Getestet in zwei Browsern mit zwei unterschiedlichen Projekten (we 9.x und we 10.x). Jemand 'ne Idee?

Das Komische ist, dass ein Klick auf den Link "HTTP-Pfad" im Reiter "Informationen" die PDF-Datei korrekt in einem neuen Tab im Browser öffnet (der Link ist ein direkter Link auf die PDF-Datei)

Dagegen bekomme ich trotz Content-Type-Deklaration in der .htaccess beide Links im Reiter "Vorschau" nicht zum Laufen. IMMER wird ein Download initiiert (die Links sind beide identisch mit Aufruf von /webedition/we_cmd.php/...)

Hat sonst niemand das Problem oder nutzt das niemand? Bisher ging (auf dem gleichen Webserver mit identischer htaccess) eine PDF direkt im Reiter "Vorschau" auf.

Hab's in die Bugbase eingetragen.

Wir haben ein Projekt auf webEdition 9 upgedated und der Kunde hat folgende Dinge bemerkt, die ihn gegenüber der 8er-Version stören:

Eine Vorschau von PDF-Dateien funktioniert nicht mehr direkt im WebEdition-Fenster "Vorschau". Dort gibt es jetzt zwei Möglichkeiten "Vorschau in einem neuen Browserfenster" und "Download". Allerdings initiieren – tatsächlich auch bei uns – beide Links nur die Downloadmöglichkeit. Müsste man extra einen PDF-Viewer als Browser-Extension einrichten oder so? Oder wurde für PDFs der Content-Type geändert?

Vielen Dank für Eure Rückmeldungen.

Wir werden den einfachsten Weg wählen, das Einfügen eines bedingten Trennstrichs als Zeichen (das holen wir uns per Copy-Paste als "roten Punkt" aus der HTML-Ansicht eines TinyEditors).

Die Branche eines Kunden bringt sehr lange Begriffe mit sich, die wir in der Navigation mit bedingten Trennstrichen (soft hyphens) ­ trennen. Bisher wurden die nicht angezeigt, mit Update auf Version 9.3.1 sind sie aber plötzlich überall auf der Website zu sehen – siehe Screenshot.

Wir nutzen im Navigationsmodul beide Felder "Name" und "Darstellung", letztere eben mit den eingebauten ­. Warum werden diese HTML-Entities nicht mehr verarbeitet, sondern als Klartext ausgegeben?

Wir sind derzeit am Bugfixing der Kundenwebsite für Version 9 und können noch nicht auf wE 10 gehen. Vielleicht werden die ­ ja in einer höheren Version wieder korrekt verarbeitet?

Mit Update auf wE9 gibt <we:img only="src"/> die Bild-URL nun mit dem Parameter m=123456 aus, was es in wE8 und niedriger nicht tat.

Ist bei alten Kundenprojekten von uns ein Problem wegen einer alten Lightbox, die mit Parametern nicht klarkommt. Jetzt hatten wir in PHP extra einen Workaround gebaut und stoßen heute in einem anderen Projekt auf ein <we:img only="path"/>. Diese Schreibweise ("path" statt "src") gibt die Bild-URL wie gewünscht ohne den Parameter aus, juhu.

In der webEdition-Tag-Referenz ist "path" aber nicht als Parameter von <we:img/> aufgeführt (obwohl es prima funktioniert). Meint Ihr, wir können dabei bleiben oder sollten wir lieber zukunftssicher den Parameter auf diese Weise entfernen?

<we:img name="NewsImage" only="src" thumbnail="thumb-maxres" to="global" nameto="imageURL"/>
<a href="<?php parse_url($GLOBALS['imageURL'], PHP_URL_PATH); ?>" class="imagelightbox">…</a>

Uiuiui, ist ja wirklich ruhig hier. Sind wohl alle beschäftigt...

Ich bin unkompliziert. Das heißt, wann immer und wo immer: Ich bin dabei und komme überall hin. Mal raus aus den 4 Wänden... Im Spessart war es immer schön, aber alle paar Jahre eine neue Umgebung bringt sicherlich frischen Wind rein!

Danke an den Vorstand, dass Ihr das in die Hand nehmt und uns was Schönes organisiert!

Aaaah, jetzt habe ich meinen Denkfehler gefunden!

Nicht im Stylesheest muss man statt .listcheck besser ul.listcheck { } definieren. Es geht um die Schreibeweise innerhalb von "classes" in der Textarea:

<we:textarea classes="ul.listcheck"/>

oder nach Geschmack <we:textarea classes="Liste mit Abständen:ul.listcheck"/>

Danke Stefan für den Link auf https://qa.webedition.org/tracker/view.php?id=13429

Noch ein Kniff, den ich gerade gefunden habe: Formate wie "größerer Text" oder "rote Schrift" will man ja flexibel an alle möglichen HTML-Elemente dranhängen können (<p>, <ul>, <li>, <pre>, etc.). Hierfür kann man ein Sternchen einsetzen: <we:textarea classes="*.bigtext"/>.

Dann wird die CSS-Klasse "bigtext" immer schön an das umgebende HTML-Tag gehängt (welches auch immer es ist) und es wird nicht ein blödes <span class="bigtext"> eingefügt!

Hey, Danke für Eure schnelle Reaktion. Hier meine Antworten:

• Bei diesem Projekt verwenden wir Version: 9.1.5 Barrhorn (9.1.5.0, Revision: 14299)
• Die im Editor verwendbaren Klassen sind definiert über <we:textarea classes="listcheck,listspace,minitext,…"/>
• Die "Benennung" von kryptischen Klassen funktioniert, behebt aber nicht das Problem.
• Habe die webEdition-Voreinstellung von "css > around" in Verbindung mit einem speziellen wysiwyg.css auf "css > all" umgestellt. Ändert auch nichts an der Problematik.

Stefan, bei Dir funktioniert das mit dem Auswählen eins HTML-Elements und Dranhängen der Klasse? Seltsam, vielleicht schießt bei uns ja noch irgendwas ganz anderes quer? Oder ich steh auf dem Schlauch!? Vielleicht können wir mal zoomen?!

Und Tipp, Stefan: Wenn Du die Sonderheadline definieren willst, schreib im CSS statt .sonderheadline konkret h5.sonderheadline { … }. Dann sollte das im Dropdown besser aussehen (die Klasse dort also nicht angewendet werden).

In der we:textarea von webEdition 9 kann ich nicht mehr wie früher gezielt CSS-Klassen an HTML-Elemente wie <ul> <li> oder <a> setzen.

In we8 konnte man (Redakteur) z.B. den Cursor in der Textarea in eine Textliste setzen und in der Statusleiste (unterhalb der Symbolleiste angezeigt als "Pfad:") das "ul" oder das "li" auswählen. Hat man dann im CSS-Dropdown der Symbolleiste eine Klasse gewählt, wurde diese an das jeweilige Element gesetzt. Funktionierte perfekt und wurde in der Statusleiste sichtbar gemacht als "Pfad: ul.listcheck li".

In we9 gibt es im TinyMCE auch eine Statusleiste (am unteren Rand), wo man zwar "ul" oder das "li" auswählen kann. Aber die anschließend im CSS-Dropdown ausgewählte Klasse wird immer als z.B. <span class="listcheck"> eingebaut. Das verhindert das individuelle und einfache Stylen von HTML-Elementen im TinyMCE mittels Klassen. Und baut man im HTML-Quellcode des TinyMCE die CSS-Klassen per Hand ein, wird dies in der Statusleiste des TinyMCE nicht wie früher (s.o.) angezeigt. Dort steht weiterhin nur "ul » li".

Im alten Forum hatte ich gelesen, dass es ginge, wenn CSS-Definitionen in der CSS-Datei nicht sehr global z.B. ".listcheck" angegeben würden. Schriebe man gezielt "ul.listcheck" oder "li.listcheck", würde das wie früher funktionieren. Das kann ich aber nicht nachvollziehen.

Hat dieses Problem sonst niemand? Formatiert bei Euch oder Euren Kunden kein Redakteur Texte auf diesem Weg? Wie setzt Ihr gezielt Klassen an HTML-Elemente? Einem Kunden kann ich nicht das Arbeiten im HTML-Quellcode zumuten.

Wir nutzen immer Usercentrics. Teils sogar die im eRecht24-Paket enthaltene kostenlose Version. Cookiebot wurde kürzlich von Usercentrics gekauft.