Posts by WBTMagnum

Hey,

Kannst du mal im Errorlog und in der Browser Console schauen ob dort Fehler ausgegeben werden?

Liebe Grüße,
Sascha

Quote from Finn

Wir müssen dringend an diese Doku ran...

Ich habe jetzt mal den Eintrag CLI aktivieren aktualisiert. Hoffe das passt so.

HTH,
Sascha

Quote from sommers

Finn das stimmt.
Übrigens ist auch die "durchsuchbare" Versionshistorie auf dem Stand von Version 9.3.1 (Cardada) eingefroren https://www.webedition.org/de/dokumentati…ie/show-all.php
Weiß nicht wie das umgesetzt wurde, und ob es da vielleicht nur eines Rebuild bedürfte?

Die aktuellen Versionen sind schon drinnen, sh. https://www.webedition.org/de/dokumentati…%20(Doldenhorn)

Das Problem ist, dass sie falsch einsortiert werden (kein natural Sort).

Liebe Grüße,
Sascha

Hallo Timo,

Ich würde hier einfach ein entsprechendes Metadatenfeld ergänzen und bei der Ausgabe - je nach Anwendungsfall - folgendes ergänzen:

• Overlay
• Hinweis im ALT-Attribut
• Hinweis in der Bildunterschrift

Wasserzeichen könnte man ggf. über einen Hook lösen.

Just my 2 cents,
Sascha

Hallo Michael,

Frag mal, ob sie das Privileg "FLUSH_TABLES" zuweisen können. Dort bleibt er ja lt. Stack Trace hängen.

Liebe Grüße,
Sascha

hey,

schau dir mal folgenden beitrag von Lukas in der Bugbase an: https://qa.webedition.org/view.php?id=14343#c56863. dort ist dokumentiert, wie mehrere klassen zugewiesen werden können.

hth,
sascha

Hallo Kay,

Ich denke du musst auch den type angeben:

<we:var type="global" name="AlbumID" />

HTH,
Sascha

Hallo Heiko,

Ich hatte jetzt auch erst mal an Hooks gedacht. Ist nur die Frage, ob du das zum gewünscht Zeitpunkt die Blöcke einfügen kannst.

Du kannst dir aber auch mal das Attribut `<we:block start="">` anschauen. Damit kannst du festlegen wie viele Blöcke initial angezeigt werden sollen. Das könnte pro Dokumenttyp festgelegt sein. Dh. wenn du erkennst, dass ein neues Dokument angelegt wird, inkludierst du die entsprechenden Blöcke. Vielleicht ist das ja ein Ansatz.

Liebe Grüße,
Sascha

Hallo Kay,

Schwer zu sagen, ob das ein Bug ist. Wir haben keine 10er Version am Laufen, wo ich das nachstellen könnte.

Beim Blick in die Bugbase ist mir noch die Vorschlag untergekommen einen Rebuild durchzuführen. Das wäre ev. noch einen Versuch wert.

Falls das auch nicht hilft, kannst du das Problem ja mal in die Bugbase eintragen.

HTH,
Sascha

Quote from stemmer

Hi Sascha, ich denke du bist auf einer falschen Fährte. Das hier funktioniert ja korrekt:<we:field name="Bezeichnung" alt="we_path" hyperlink="true"/>

Diese Info hast du uns aber vorher auch noch nicht gegeben. Ist daher schwierig hier auf einer "Fährte" zu sein ;-).

Liebe Grüße,
Sascha

Hallo Kay,

Noch zwei weitere Fragen:

• Wird bei den betreffenden Objekten im Tab "Eigenschaften" der SEO URL korrekt angezeigt?
• Sind in der Klasse Arbeitsbereiche definiert?

Liebe Grüße,
Sascha

Das mit der PHP Version ist eher umgekehrt:

Quote from Versionshistorie Version 9.0.0 (Barrhorn)

Achtung: ALLE Updates auf eine Version 9.1.x müssen zwingend unter PHP 7.2, 7.3 oder 7.4 durchgeführt werden. Darüber hinaus muss das WE-Sessionmanagement aktiviert und "Sitzung für jeden Benutzer verschlüsseln" auf "Transparent" eingestellt werden!

Wenn das Update hängen bleibt, kannst du an folgenden Stellen schauen:

• webEdition Errorlog
• Errorlog des Webserver
• Browser Console

An einer der Stellen sollte sich die Ursache finden, warum das Update hängen bleibt.

HTH,
Sascha

Hallo Kay,

Das schaut mal gut aus. Was hast du bei der Klasse bei den Eigenschaften unter SEO-URL eingestellt?

Liebe Grüße,
Sascha

Hey,

Welche wE Version hast du da am Laufen? Was hast du bei den SEO-Settings eingestellt?

Liebe Grüße,
Sascha

Hallo Kay,

Wir haben dafür folgendes in Verwendung:

<a href="<we:field name="WE_PATH"/>">LINK</a>

HTH,
Sascha

Wir haben auch die Erfahrung gemacht, dass - gerade bei älteren Auftritten - das Charset Thema bei Updates immer wieder hochbrodelt. Letztens aber auch bei einer Datenbankumstellung durch den Hoster (MySQL -> MariaDB). Da war dann der Verbindungszeichensatz falsch. Hat sich aber zum Glück rasch beheben lassen.

Ich denke hier gibt es einfach zu viele mögliche Fehlerquellen. Da kann man nicht alles durchtesten und abdecken.

Hallo Markus,

Ich könnte mir vorstellen, dass das mit der neuen "No Page reload" Funktion zusammenhängt. Schau mal ob die aktiviert ist und deaktiviere sie ggf. mal.

HTH,
Sascha

Danke für die Rückmeldung. Wenn das nur Deprecation Notes sind, dann passt es in den Systemvoraussetzungen so wie es ist.

Weil ich auch gerade von einem Kunden bzgl. PHP 8.4 gefragt wurde, hänge ich mich mal hier an. Wie ist denn hier der Status? Wenn ich das in der Bugbase richtig sehe, dann wird PHP 8.4 zumindest für wE<=9.x nicht unterstützt. Wie schaut es mit wE10 aus?

NilSole  haydi Kann das in die Systemvoraussetzungen aufgenommen werden?

Quote from christobal

Code

Exception
str_replace(): Argument #3 ($subject) must be of type array|string, null given
SECURITY_REPL_DOC_ROOT/webEdition/liveUpdate/classes/liveUpdateResponse.class.php

Der Stacktrace wäre hier noch interessant.

Ich habe kurz nachgesehen. In liveUpdateResponse.class.php gibt es eigentlich nur zwei `str_replace()` Aufrufe. Kann es sein, dass der Installer keine Schreibrechte hat? Wie schaut es mit dem Speicherplatz auf dem Host aus?

Liebe Grüße,
Sascha