Beiträge von Re:Later

Das global Checkin geht alle dATENBANKTABELLEN DURCH; also auch die von Dritterweiterungen: WEnn es ein Feld checked_out bzw. checked_out_time in der Tabelle gibt, werden nach Prüfung der INhalte beide auf NULL gesetzt.

Zitat von kbaerthel

Jedoch werden die Felder check_out_time im Format datetime auf "0000-00-00 00:00:00" gesetzt.

Wo werden die so gesetzt? In der Datenbank werden Sie auf NULL gesetzt. Das ist der STandardwert für diese Felder und Joomla setzt den auch beim Global chackin

Oder anders: DIe Joomla-mEThode würde ein "0000-00-00 00:00:00" eher auf NULL setzen als ein "0000-00-00 00:00:00" zu setzen.

Zitat von kbaerthel

Erwartet wird "1970-01-01 00:00:00" als Nullwert

Wer/was erwaretet das in welchm ZUsammenhang?

Vielleicht

div.blog-featured .item-content
{
background-color: yellow;
}

Zitat von Berndi

Wie behebe ich das Problem?

Per Ferndiagnose nur schwer, weil die Meldung halt so unspezifisch am Ende der Routine ist, aber firstlady hat ja schon einen Vielleicht-Riecher.

Für den Anfang kannst du probieren

div.com-content-article
{
background-color: yellow;
}

oder

div.com-content-article__body
{
background-color: yellow;
}

Letzteres umfasst tatsächlich nur den Text.

Ersteres wohl auch so Zeugs wie Schlagworte, Artikelinfos usw.

Dann muss man weitersehen, ob an zu vielen Stellen gelb wird bzw. irgendwas anderes wie im Bild....

Zitat von Berndi

aber dann werden doch dann keine Kontakte automatisch erstellt.

Hast ja nichts dazu gesagt, dass du Kontakte automatisch erstellen musst.

Zitat von Berndi

Ist Joomla 5 an dieser Stelle etwa noch buggy?

Bei mir, normale online-Seite funktioniert das.

Zitat von Berndi

Wo liegt das Problem?

Die Meldung, die du siehst, kommt an einer Stelle, die halt final abbricht, weil zuvor irgendwas nicht funktioniert hat beim Öffnen der Kontakttabelle, beim PHP-seitigen Zusammenstellen der Kontaktdaten, bei der Prüfung dieser zusammengestellten Kontaktdaten, beim Speichern der Kontaktdaten.

Kurz: "Unspezifisch pauschal" die Meldung, die du hast.

Zuerst würde ich versuchen einen Kontakt in der Kontaktkomponente anzulegen, ob das geht. Am besten gleich mit dem neuen User, der ja angelegt wurde. ALso inklusive der Verknüpfung mit diesem Benutzer im neuen Kontakt.

Sollte der Benutzer aber gar nicht angelegt worden sein, liegt das Problem sowieso schon vor dem KontaktCreator-Plugin. Das geht nämlich davon aus, dass der Benutzer fehlerfrei angelegt wurde. Und, wenn nicht, hat "irgendwas vergessen" da schon frühzeitig zu meckern und abzubrechen.

Deaktiviere das Plugin "Benutzer – Kontakterstellung"

Bei deinem Fund geht es um den Tag

<downloads>

in Updateserver-XML-Dateien. Dort gibt es eine <downloadurl> und/oder <downloadsource>, die einen type (und das format) haben. Wie ein type=patch abgewickelt wird, also von Joomla automatisch irgendwie, weiß ich aber auch nicht. https://docs.joomla.org/Deploying_an_Update_Server

Zitat von netzalben

Beim Durchsuchen des Codes habe ich noch die Variante method = "patch" gefunden.

Finde ich bei mir nicht als XML-Eintrag. Da wäre nett, wenn du sagst, wo du das gefunden hast.

Bei allen Erweiterungen, egal welcher Art, ist method="upgrade" empfohlen. Warum? Das weißt ja selber (siehe #1).

Natürlich kann es in Ausnahmefällen sinnvoll sein, zuerst eine Deinstallation zu fordern, damit aller Müll entfernt wird. Man kann sich so das Löschen unnötiger, verwaister Dateien z.B. durch ein zu pflegendes <scriptfile> sparen. Aber ich pflege lieber das $deleteFiles und $deleteFolders im ScriptFile von Anfang an, anstatt gemachte Einstellungen, Inhalte jedesmal neu anlegen zu müssen.

Übrigens könnte man auch ein method="tralalasonstwas" verwenden und das dann im eigenen Scriptfile irgendwie nutzen. Und an Joomla gibt man dann ein method=upgrade weiter oder so....

Wie es beliebt.

Du verwendest wohl nicht die aktuellste Version?

Release Release 4.1.0 · joomla-extensions/search

4.1.0 is designed natively for 4.0 and also fixes all styling issues from the development package

github.com

In der gibt es eine Zeile 44 gar nicht so.

Und generell kann man in der Joomla-Konfiguration Fehler berichten auf KEINE setzen, damit so Meldungen den Besuchern nicht angezeigt werden.

Zitat von WM-Loose

Verwende nicht das Modul Suche sondern Suchindex.

Da widerspreche ich ganz entschieden. Wer SUchindex nicht mag, sollte weiterhin die normale Suche verwenden. Nicht umsonst ist die nach wie vor verfügbar.

Die Häkchenfelder kann man auch deaktivieren, wenn man meint. In den Optionen/der Konfiguration der Joomla-Update-Komponente. Siehe Bild.

Bei Seiten, wo ich das nicht deaktivieren darf, habe ich nämlich auch jedes mal Probleme, die Häkchenfelder intuitiv zu erkennen. Hellgrau auf Dunkelweiß sozusagen

Was man im Bild sieht, sind Fehler der Updateserver, die keine Daten mehr ausliefern oder nur vorübergend.

Was schlicht daran liegen kann:

Bei den Erweiterungen sehe ich eigentlich nur welche, die man auch deinstallieren kann oder sogar sollte, wenn man sie nicht explizit in Anwendung hat. Das sind "Leichen".

Mach vorher Backup

Zitat von faro

bekomme ich einen "Fatal Server Error"

Ist dazu was bekannt?

Ich habe die Änderung mittlerweile bei 4 oder 5 4er-Seiten gemacht und es funktioniert.

Für Performance- und SEO-Nerds versus Ästhetik-Nerds.

Heise hat die Entdeckung gemacht, dass ein allgemein übliches

font-display: swap;

beim Abfragen von Webfonts u.U. die Seitenladung (Performance) unangenehm beeinflussen kann, so, dass die Google-Search-Konsole diesbzgl. schlechte Werte ermittelt.

Die Anweisung oben sorgt dafür, dass, wenn ein Webfont nicht sofort abgeholt werden kann, der Browser eine Fallback-Schriftart lädt, dann aber doch den Webfont nachlädt, wenn dieser bei weiteren Versuchen, die im Hintergrund stattfinden, erreichbar ist; was dazu führt, dass die WebSeite technisch ermittelt länger braucht, um fertig zu sein.

Eine Anweisung

font-display: optional;

kann das Problem vermeiden. Wenn der Font nicht abholbar ist, wird nicht mehr im Hintergrund nach ihm gesucht. Er wird nicht mittendrin nachgeladen und Fallbackschriftarten werden verwendet.

Selbstverständlich sind Aspekte wie Browser-/Server-Caches/Caches, in dem die Webfonts ggf. schon liegen, also gar nicht neu abgeholt werden müssen zu beachten, die den gefühlten und technischen Gewinn gegen 0 gehen lassen könnten, also schwer messbar und nachvollziehbar.

Nur nebenbei erwähnt: Der Satz "Da AMP mittlerweile keine Vorteile mehr bietet...". Es hatten also mal wieder die Recht, die sich ohne Hektik auf die stetige Weiterentwicklung der Webtechnologien (Hard- und Software) verlassen, als auf irgendwelche sonderlichen und arbeitsintensiven Erfindungen der Google-Kontrolleties (und dazu dient AMP).

Wie eine Zeile CSS den Cumulative Layout Shift bei 3700 URLs verbessert

Mit einer kleinen Anpassung im CSS reduzierten wir die Layout Shifts bei heise tipps+tricks drastisch. Eine Spurensuche enthüllte die Ursache.

www.heise.de

font-display - CSS: Cascading Style Sheets | MDN

The font-display descriptor for the @font-face at-rule determines how a font face is displayed based on whether and when it is downloaded and ready to use.

developer.mozilla.org

Zitat von Suche_Hilfe

Auf unserer Website gab es kein Kontaktforumular

Und es ist auch kein Kontakt angelegt, auch kein archivierter? Weil es dann ggf. Möglichkeiten gibt ein Kontaktformular "hinten rum aufzurufen". Einfachste Möglichkeit dann, die Kontakt-Komponente zu deaktivieren, falls man sie ansonsten nicht benötigt.

Du wirst wohl leider einen Override von JLayout layouts\joomla\content\tags.php anlegen müssen. Oder, falls so einer schon im Template existiert, halt umfrickeln.

Die Einstellungen gehören alle nicht zu Tags in Beiträgen.

So als schneller Ansatz: Innerhalb der foreach-Schleife (siehe auch Bild unten): Dann hast den Bildpfad.

if (!empty($tag->images))
{
    $tagImages = new Registry($tag->images);
    $image = $tagImages->get('image_intro', '');
    // ODER
    // $image = $tagImages->get('image_fulltext', '');
}

Zitat von rolli

Lässt sich denn diese Erweiterung mit dem Iframe formularen von Brevo verbinden?

Nein, weil das Newletter-Formular konfiguriert man ja wohl bei brevo.com, denke ich. Brevo kenne ich nicht.

Ich habe jetzt nicht alles gelesen oben. Vielleicht doppelt??

Das ist jetzt insofern doof, wenn man es genau nimmt, weil du eigentlich auch für dieses Formular erst eine Einwilligung deiner Besucher abfragen müsstest, weil es ja externen Kram in die Seite holt. Und dann noch dazu, ein Google-Zeugs lädt.

Beides müsste der Besucher also zuvor erfahren.

Ob du es genau nimmst, bleibt leider dir überlassen.

Es gibt Tools für Joomla, die so Abfragen "vor"die Iframes setzen können. Die Frage ist halt immer, wie genervt Besucher sind, dass sie da jetzt zusätzlich einwilligen müssen, nachdem sie blöden Datenschutzhinweis gelesen haben usw. usf.

Ich kenne das Problem von CleverReach. Da hat man dann aber wenigstens die Möglichkeit, den HTML-Code ohne IFRAME in die Seite einzubinden. Die haben leider auch ein Google-Captcha drinnen, das nicht deaktivierbar ist, selbst, wenn man wollte.

Aber der Besucher muss halt nur einmalig zu Beginn seines Besuches einwilligen, dass Google-Captcha geladen werden darf. Das geht einfach über das kostenlose "CookieHint and Consent"-Plugin. Wenn er da nicht eingewilligt hat, funktioniert auch Newsletteranmeldung nicht.

Aber siehe 2.Bild unten (da fehlt das Captche), der Besucher bekommt 2 Möglichkeiten genannt, wie er "reinkommt".

(Ich will dich nicht zu CleverReach locken! Ich schreib das nur, weil vielleicht kann man bei Brevo ja Ähnliches zusammenfrickeln; ohne Iframe. Und ja, bisschen Frickelei wars dann doch.)

Nur nebenbei: Ganz "modern" heißt es jetzt auch

... getApplication()->getInput()

statt

... getApplication()->input

Zitat von dirk63

s sind ja nur 6 Textblöcke mit Bildchen im Content der Seite. Kein Hinweis auf das Cubes-Modul...

Das meinte ich ja auch nicht. Das wirst da nicht finden, weils ja nach deiner Aussage gar keine solche Einstellung hast. Ich denke, dass du halt doch irgendwo anders so eine Einstellung hast, die man jetzt halt mühsam durchgehen muss.

Oder anders: Ich habe in meinem Joomla genau 2 Funde mit "noindex".

Zitat von dirk63

irgendwas mit com_content.article

Die kannst wahrscheinlich ignorieren, weil Tabelle _history(?). Trotzdem spricht das dafür, dass du in deinem Joomla Einstellungen mit "noindex" hast, weil sonst gäbe es sie auch nicht in history.

Nur um sicher zu sein:

In Post #7 zeigst du ja gar nicht den Reiter "Metadaten", den Stef meinte. Prüfen würde ich, falls noch nicht gemacht, die Menüeinträge mit ID 166 und ID 200. Die haben sicher "noindex".

Ich seh nach Durchforsten des Content Cubes-Particles-Codes eigentlich nix, was ein noindex setzen würde. Was mir halt auffällt, ist, dass auch die in den Particles verlinkten, cubes-losen Beiträge dann ein noindex haben?!?!?!

Kannst ja mal den Tipp mit der Datenbank probieren. Vielleicht. Nur vielleicht.

Siehe auch Bilder unten.

- Gehst in die Datenbank, wo alle Tabellen aufgelistet werden.

- Klickst oben "Suchen".

- Gibst "noindex" ein.

- "Alle Tabellen auswählen" nicht vergessen. Manchmal ist das schon, manchmal nicht.

- Suche starten mit "OK".

- Wenn was gefunden wird, sieht man einen "Anzeigen"-Link, der nach unten scrollt und die pro Tabelle gefundenen Einträge anzeigt.

- Je nachdem, kannst ja dann im Backend mal kontroliieren.

- Scrollst wieder hoch. Klickst den nächsten Link "Anzeigen"