Beiträge von Clemens-XS

Zitat von Stef

Na ja, ich bekam am Montag den 14. August, eine E-Mail vom Forum.....

Tja, das Forum hat wohl gesponnen.

Zitat

Ob es schlussendlich eine gute Idee war es zu melden ? Na ja…

Beleidigt? Hab nur gefragt, was dein Interesse ist.

Die Website soll noch nicht öffentlich sichtbar sein, da sie sich noch in Entwicklung befindet. Ist aber ganz einfach: Ich hab einfach nur eine index.html in das Root gelegt. Mit /index.php kämst du rein.

Aber was ist denn nach über 1 Jahr dein Interesse an meiner Website? Die am Anfang von mir gestellte Frage kann es ja nicht sein.

Danke für deine Antwort. Aber der Thread ist vom 09. August 2022.

Die seither gefundene und genutzte Anpassung in Verbindung mit YooTheme Pagebulder ist:

.uk-navbar-toggle {
    min-width: 50px;
}

Cassiopeia nutze ich seit Ende August 2022 nicht sondern baue meine Sites seither alle mit YooTheme Pagebuilder.

Indigo66 Danke für die Zusammenlegung. Das war mir noch gar nicht aufgefallen.

Ich habe inzwischen an dem Thema "Ausdrucken von Webseiten möglichst in Original-Screendesign" heftig weiter gearbeitet und ich möchte die Ergebnisse hier teilen, damit alle was davon haben.

Vorab: Generell führt die Nutzung eines Druck-Buttons in Verbindung mit URL-Ergänzungen wie &print=1 zu keiner besseren Darstellung des Layout, sondern verhindert lediglich, dass der Head und Footer sowie das Menü bei jeder Druckseite mit ausgegeben werden. Das von mir zitierte Script führt dazu, dass beim Neuladen der Seite in der das Script eingebettet ist, jedes Mal unerwünschter Weise der Druck aktiviert wird. Das Script ist also in dieser Form unbrauchbar. Ich nutze statt eines "Drcuk-Button" lieber die Druckfunktion des Browsers, zumal die meisten User das genau so machen würden. Alle Änderungen in der Druck-Darstellung definiere ich dann durch die "print.css" bzw. durch einen Abschnitt in der main.css mit der Media-Query @media print

Bei mir liegt das Logo und die Navigation in einem Bereich mit der Klasse uk-navbar. Also brauche ich die bloß auf display: none setzen und das Problem ist gelöst. Erstaunlicher Weise wird der Footer ohne weitere Definition nur am Ende aller Seiten ein Mal gedruckt, genau wie gewünscht. Evtl. hat hier YooTheme Pagebuilder bereits eine @media print Regel eingebaut.

Allerdings möchte ich schon, dass mein Logo auf der ersten Seite der Druckseiten erscheint. Dies habe ich versucht, mit folgender CSS-Definition zu erreichen:

@media print {
    @page :first {
    content: url('/images/grafik/mein-logo.png');
    margin-bottom: 100pt;}
}

Aber das Logo erscheint nicht. @page :first kann nur für das Setzen von margins usw. verwendet werden und nicht für weitergehende Definitionen. Daher versuchte ich es noch mal wie folgt:

@media print {
.cl-logo {
    content: url("https://meine-website.net/images/grafik/mein-logo.png");
    display: block;
}
@page :first {
    .cl-logo {
        display: block !important;}
}

Aber leider funzt auch das nicht und ich fand bis jetzt keine Lösung für das Einfügen des Logo nur im Kopf der ersten Seite. Vielleicht weiß hier jemand, wie ich das hinbekomme?

Und nun zu den weiteren Herausforderungen:

Das Hauptproblem liegt darin, dass die Browser hier scheinbar machen was sie wollen. Ich habe hier getestet mit Chrome / Brave, mit Firefox und mit Opera. Das beginnt bereits mit der Definition der Seitengröße eines DIN A4-Formats und deren Auswirkung auf das Rendern:

Bei meinen Websites führt das dazu, dass mit Chrome und Opera ein ab 640px Breakpoint zweispaltig angelegter Text einspaltig dargestellt wird. Nur Firefox stellt den Text zweispaltig dar.

Nun hätte ich gerne wenigstens dafür gesorgt, dass die Umbrüche das Layout nicht zerschießen. Eine ansprechend gestaltete Blockquote sollte nicht umgebrochen werden und ein Abschnitt in einem längeren Text möglichst auch nicht. Da ich ein Grid-Layout und kein Bootstrap verwende (YooTheme Pagebuilder) habe ich nach typischen CSS-Klassen gesucht, die ich dann mit page-break-inside: avoid; hindere, einen Umbruch durchzuführen. Jedes Mal wenn man eine "Section" in das Layout einfügt, wird die Klasse uk-container genutzt.

Damit gelang es mir, die zusammengehörigen Inhalte weitgehend ohne unerwünschte Umbrüche zu drucken.

Nun blieb noch der Fehler, dass die Zeilen eines Paragraph-Text bis ganz an den oberen oder unteren Seitenrand gedruckt wurden und zwar bei allen drei Browsern. Das sollte sich eigentlich mittels orphans und widows verhindern lassen. Diese Anweisungen wurden aber von allen drei Browsern ignoriert, obwohl caniuse.com zumindest Chrome und Opera besscheinigten, dass dies berücksichtigt wird. Firefox kann das bisher gar nicht. Auch das Einfügen von margin-top und margin-bottom brachte keine Verbesserung, wenn im Paragraph ein Umbruch erfolgt ist. Ansonsten aber wurde die Margin-Definition berücksichtigt.

Ich beobachtete, dass zuweilen bei Firefox sogar innerhalb einer Überschrift (h1 in diesem Fall) ein Umbruch erfolgte, wodurch die recht große Schrift "in der Mitte geteilt" wurde, also die Oberlängen auf dem letzten Teil einer Seite und die Unterlängen auf der folgenden. Ich versuchte es mit

h1, h2, h3 {
page-break-after: avoid;
}

Aber Firefox kann bis jetzt avoid in Verbindung mit page-break-after oder page-break-before nicht berücksichtigen. Eigentlich sollte bei Firefox das Problem der zerrissenen Überschrift gar nicht auftreten, da die Überschrift ja zu Beginn eines Containers steht und der Container erst beendet wird, sobald der Paragraph-Text endet. Und page-break-inside soll ja angeblich von Firefox berücksichtigt werden. Tja, "sollte!" und "eigentlich"!

Ein besonderes Problem ergibt sich, wenn ich den Druck von Bildern zulasse. Obwohl ich auch für Bilder in der print.css page-break-inside: avoid definiert habe und diese in der Regel Teil eines Containers sind, werden Bilder falsch positioniert oder zuweilen auch von Text überlappt. Da BIlder offensichtlich – zumindest in dem von mir genutzten Layout – Probleme bereiten und zudem wenig zusätzliche Information beinhalten, wenn sie mit ausgedruckt werden, habe ich Bilder generell in der print.css mit display: none unterdrückt. Leider bleibt der Platz, den die BIlder sonst benötigt hätten, als weiße Fläche im Ausdruck frei. Das stört natürlich gewaltig und führt wieder zu Papierverschwendung.

Resultat bis jetzt also:

• Das Logo im Kopf auf der ersten Druckseite konnte ich bis jetzt nicht einfügen.
• Um eine weitere Optimierung speziell der Druckausgabe beim Firefox bemühe ich mich nicht mehr. In diesem Punkt ist das Teil einfach Schrott!
• Ärgerlich ist, das die Definition für orphans und widows ignoriert wird, den das stört schon sehr in den Drucken.
• Durch das Zusammen-Halten der Container-Bereiche werden bei allen Browsern leider die noch freien Bereiche einer Druckseite falsch berechnet und oftmals unnötiger Weise der nächste Container-Bereich schon auf der nächsten Druckseite gedruckt, statt in dem durchaus noch verfügbaren Platz auf der vorigen Seite. Dadurch wird Papier verschwendet und der Besucher verärgert.
• Wenn ich den Druck von Bildern mit display: none verhindere, möchte ich eine Möglichkeit finden, dass der Platz, den die Bilder im Druck sonst eingenommen hätten, nicht frei gehalten wird.

Ich würde mich freuen, wenn jemand mir für den ein oder anderen Punkt aus der obigen Aufzählung eine Lösung nennen würde!

Jetzt bin ich ein Stückchen weiter gekommen mit der Druckfunktion, weil ich aus dem Support-Forum von YooTheme neue Infos gefunden habe. Zu meinen Fragen kommt nun eine betreffend Javascript hinzu. Zunächst hier der Link zu der im YooTheme-Forum gegebenen Info (nur zum Nachlesen bei Interesse): https://yootheme.com/support/question/144981

Gemäß dieser Info lege ich einen "Druck-Button" an, der die URL des zu druckenden Beitrags aufruft und an die URL anhängt:

&print=1

In den HTML-Code der Seite füge ich dann folgendes Script ein:

<script>
window.onload = function() { 
printUrl = new URL(location.href).searchParams.get('print');
if (printUrl) window.print(); 
}
</script>

Damit habe ich erreicht, dass ich einen Druck-Button ins Seitenlayout einbinden kann, der die Druckfunktion des Browsers aufruft, wobei das Seitenlayout bis auf die bisher schon hier aufgezählten Fehler beibehält.

Das Blockquote-Darstellungsproblem beim Drucken konnte ich lösen. Da hatte ich einen Denkfehler im HTML.

Da jetzt sowieso schon Javascript ins Spiel kommt, könnte nun die JS-Funktion erweitert werden aber auch gleichzeitig eben in der print.css die noch erforderlichen Änderungen vorgenommen werden.

Aktuell bestehen folgende Darstellungsprobleme beim Druck:

• Accordions werden nicht automatisch alle ausgeklappt, damit deren Inhalt gedruckt wird
  ist evtl. nicht so einfach, da die Accordion-Funktion anscheinend teils in Javascript gelöst wurde und tiefer eingegriffen werden müsste.
• Inhalts-Elemente, die breakpoint-abhängig gezeigt oder verborgen werden sollen, werden alle gleichzeitig angezeigt
  hierzu müsste der Seitenaufbau neu erfolgen und beim Abruf der Seite ein Smartphone im Hochformat simuliert werden. Evtl. per Javascript?

Hat mir jemand dazu noch einen Tipp?

Habe gerade vom YooTheme-Support betr. Accordion die Lösung bekommen. Auf diese CSS-Definitionen wäre ich wegen meiner geringen CSS-Kenntnisse nicht gekommen. In die @media print muss ich einfügen:

div.uk-accordion-content[hidden] {
    display: block !important;
    }

Die Klasse  uk-accordion-content wird bei geschlossenem Accordion auf hidden gesetzt. Mit display: block wird das wieder aufgehoben. Warum vor der Klasse ein div steht, verstehe ich nicht. Aber es funktioniert!

Vielleicht bekomme ich für die andere Frage ja auch noch eine Antwort von YooTheme. Ich halte euch hier auf dem Laufenden. Denn wer weiß, ob hier nicht auch paar Leute YooTheme Pagebuilder verwenden oder die CSS Definitionen nutzen können.

Die JS-Print-Funktion oben geht so nicht, weil ein bloßes Neuladen der Webseite dazu führt, dass automatisch die Browser-Druckfunktion gestartet wird und an die ULR &print=1 angehängt wird.

Ich verzichte auf den Button und das JS, wenn möglich.

Betr. der Blockquote, die zum überlappenden Druck führt habe ich doch noch keine Lösung. Es war nur Zufall, dass die Seitenumbrüche auf der Testseite günstig lagen. Versuche, vor der Blockquote ein clear: both und danach display: block einzufügen und am Ende nochmals ein clear: both brachten keinen Erfolg.

Vielleicht behebt sich der Ärger von selbst, wenn ich es erst mal schaffe, vom Layout für Smartphones im Portrait-Modus aus zu drucken.

Danke dir für deine Anregung! Inzwischen bin ich etwas weiter gekommen: Ich hab erkannt, dass die Ergänzung nach der URL nicht nötig ist. Ich kann ja das Logo in der print.css ausblenden. Dann bleibt aber am Ende des Drucks der Footer bestehen mit den von mir ja gewünschten Adress- und Kommunikationsdaten.

Das Chaos im Layout beim Druck wird hauptsächlich verursacht durch die Blockquotes, die ich in manchen Seiten habe sowie durch die Accordions, die allesamt geschlossen sind, somit deren Text auf hidden steht und nix im Druck dargestellt werden kann. Die Blockquotes haben anscheinend keinen richtigen Container, sodass im Druck sich diese über oder unter den nachfolgenden Container schieben.

Im YooTheme Pagebuilder habe ich die Möglichkeit, ganz bequem "Custom.css-Code" in ein Feld "Benutzerdefinierter Code" einzufügen. Und dann kann ich sofort die Wirkung der Änderung sehen. Durch Webrecherche und viel Ausprobieren habe ich aktuell die folgenden CSS-Definitionen erstellt:

/* PRINT CSS ############################ */
@media print {
/* Ausblenden des Logo */
    .uk-navbar {
        display: none !important;} 

/* Einblenden des Logo nur auf erster Druckseite __FUNZT NICHT__ */    
@page:first {
    content: url('/images/grafik/meine-website.png');
        margin-bottom: 100pt;
    }
/* externe Links URL einfügen */
    a[href]:after {
          content: " (" attr(href) ")";
    }
    
/* interne Links nicht einfügen  __FUNZT NICHT__ */
    a[href^="https://"]:not([href*="meine-website.net"]):after {
          content: " (" attr(href) ")";
    }

/* verhindert einen Seitenumbruch direkt nach einer Überschrift */
    h1, h2, h3 {
          page-break-after: avoid;
    }
    
/* verhindert, dass Aufzählungen oder Bilder im Umbruch landen __FUNZT NICHT bei Blockquote __ */
    ul, img, blockquote {
       page-break-inside: avoid;
    }

/* verhindert einen Seitenumbruch innerhalb eines Containers / Elements z.B. Tabelle __FUNZT NICHT bei Blockquote__*/
    figure {
      page-break-inside: avoid;
    }
    
/* wie viele Zeilen dürfen leer bleiben am Ende einer Seite (orphans) oder 
am Beginn einer Seite (windows), wenn ein Paragraph-Text auf zwei Seiten aufgeteilt wird */
    p {
          orphans: 2;
          widows: 0;
    }

}

Betreffend der Blockquotes habe ich bereits versucht, diese als "display: block" anzulegen und diesen Block dann auch mit "clear: both" abzuschließen. Das hat aber nix gebracht. Und warum die internen Links immer noch in das Drucklayout eingefügt werden, weiß ich nicht.

Die mir aktuell wichtigsten drei Dinge sind:

• Wieso wird das Logo nicht auf der ersten Druckseite oben eingefügt?
• Wie kann ich die Blockquotes so in der Webseite anlegen, dass sie auch im Druck als Container interpretiert werden?
• Wie kann ich dafür sorgen, dass das Accordion beim Drucken alle items geöffnet hat?

Mit großem Interesse habe ich diesen Beitrag gelesen: Drucken von Beiträgen

Leider bin ich in PHP JS usw. zu wenig gebildet, um zu verstehen, wie ich diese Anregungen in meinen neuen Websites umsetzen kann. Ich habe zwei alternative Ziele:

Entweder soll über die Browser-Funktion gedruckt werden (bevorzugt) oder über einen selbst erstellten Druck-Button auf der Webseite.

Meine J4 Websites sind mittels YooTheme Pagebuilder erstellt. Leider hat der Pagebuilder keine print.css – Nutzt man die Druckfunktion des Browsers, erhält man voll das Chaos. Aber immerhin kann man eine ansehnliche Ausgabe erhalten, wenn man an die URL der jeweiligen Seite ?tmpl=template anhängt. Und die darüber angezeigte Seite kann man schon relativ gut mit der Browser-Druckfunktion ausdrucken. Dabei wird offensichtlich überwiegend das Layout genutzt, das für große Screens gedacht ist.

Da ein Webbrowser nicht von selbst auf die Idee kommt, mit der Druckfunktion zusammen die URL um ?tmpl=template zu ergänzen, benötige ich wohl einen Druck-Button, der dann nicht nur die zu druckende Seite in eine brauchbare Form bringt, sondern der dann auch zugleich die Druckfunktion des Browsers auslöst, damit der Besucher nicht zusätzlich noch den Druck-Button des Browsers betätigen muss.

Frage: Wie muss der Code aussehen, den ich mit dem Button verknüpfe?

Eine weitere Schwierigkeit:

Meine Accordions sind bei Aufruf der Seite immer geschlossen. Und so wird der Copytext nicht mit ausgedruckt. Daher ich möchte eine CSS-Anweisung erstellen, die bei Nutzung der Print-Funktion bzw. bei Rendern der Webseite unter Anwendung von ?tmpl=template die Accordions allesamt ausklappen lässt. Auch da weiß ich nicht, wie ich das hinbekommen könnte.

Natürlich habe ich schon beim YooTheme Support nachgefragt. Aber von dort kam bisher keine Antwort.

In meiner neuen Website verwende ich den variablen Font "Dosis". Dessen font-weight ist zwischen 100 und 800 variabel. Ein Wert für "font-stretch" bei diesem Font ist mir unbekannt. Ich habe die variable Fontdatei von Google-Fonts herunter geladen und auf meiner Site installiert. Ich erhalten auch keinerlei Darstellungsfehler. Wohl aber erscheint ein- oder sogar mehrfach diese Fehlermeldung unten im Inspector:

downloadable font: fvar: 2 bytes unparsed (font-family: "dosis" style:normal weight:400 stretch:80..120 src index:0) source: https://meine-neue-website.de/templates/yootheme_extra/fonts/dosis/Dosis-VariableFont_wght.woff2

Die Font-Datei ist nicht defekt. In der CSS-Datei hatte ich sie zunächst wie folgt eingebunden:

@font-face {
    font-family: 'dosis';
    src: url('../fonts/dosis/Dosis-VariableFont_wght.woff2') format('woff2'),
    font-weight: 100 800;
    font-stretch: 80% 120%;
    font-style: normal;
}

Nachdem "font-stretch" ja angemeckert wurde, habe ich es einfach auskommentiert:

@font-face {
    font-family: 'dosis';
    src: url('../fonts/dosis/Dosis-VariableFont_wght.woff2') format('woff2'),
    font-weight: 100 800;
 /*  font-stretch: 80% 120%;  */
    font-style: normal;
}

Nach der Änderung kommt folgende Fehlermeldung:

downloadable font: fvar: 2 bytes unparsed (font-family: "dosis" style:normal weight:400 stretch:100 src index:0) source: https://meine-neue-website.de/templates/yootheme_extra/fonts/dosis/Dosis-VariableFont_wght.woff2

Die Fehlermeldung kommt also weiterhin, obwohl ich zusätzlich alle Caches usw. gelöscht hatte - auch den Browser-Cache.

Sollte ich die ignorieren oder weiter nach der Ursache suchen und wo könnte die Ursache liegen?

Natürlich beeinflusst das"hidden" bzw. display: none die Sichtbarkeit. Aber das war doch vor langen Jahren (Jahrzehnten?) der Trick, mit dem manche Webdesigner versuchten, das Google-Ranking auszutricksen, indem alle möglichen attraktiven Keywords in einem "hidden-Bereich" eingetragen wurden. Diese Form des Keyword-Stuffin wurde dann kurz darauf von Google hart abgestraft.

Und weil ich mich daran noch erinnern kann, frage ich hier, ob Google auch Texte und Links auswertet und im Ranking einbezieht, wenn diese in einem Bereich liegen, der versteckt ist / nicht angezeigt wird.

Zudem war meine Frage auch, welche Gestaltungsmöglichkeiten es noch gibt, einen Kategorieblog mit ca. 16 Beiträgen attraktiv für den Betrachter darzustellen. Einerseits sollte er den Überblick bekommen, welche Themen / Beiträge angeboten werden. Andererseits braucht der Besucher ja nur Sekundenbruchteile, um das ihn interessierende Thema auszuwählen. und dafür ist es es nicht nötig, alle Titel und Einleitungstexte gleichzeitig (!) zu präsentieren wie z.B. im üblichen Joomla-Standard-Layout oder in der Darstellung mittels Cards.

Beiträge dieser Kategorie werden voraussichtlich nicht in der Anzahl zunehmen und auch selten gegen andere Themen ausgetauscht. Sie sind de facto statischer Bestandteil der Website.

Falls die SEO-Problematik nicht zutrifft, wie ich oben beschrieb, dann habe ich aktuell folgende Lösungsideen:

1.) Accordion: Der Besucher bekommt alle Beitragstitel präsentiert. Da diese teils unvermeidlch lang sind, können sie auf diese Weise denoch gut dargestellt werden. Das Ganze ist zudem extrem platzsparend. Klickt der Besucher auf einen Titel im Accordion, erhält er den Einleitungstext und einen Link zum ganzen Beitrag. Somit belästige ich einen Besucher nicht gleich mit dem ganzen Beitragstext, wenn er sich evtl. nur eine Übersicht verschaffen wllte, worum es in dem Beitrag geht.

2.) Panel-Slider: Das läuft wie bei einem Card-Design, nur eben, dass alle Beiträge mit Titel und Einleitungstext nebeneinander und horizontal durchlaufend gezeigt werden. Nachteil ist, dass der Besucher nur ein bis drei Beitragsthemen präsentiert bekommt. Will er schnell weitere sehen, muss er navigieren bzw. mit dem Finger wischen. Vorteil ist, dass platzsparend alle Beitragsthemen in der Höhe von nur einer Zeile Cards gezeigt werden. Zudem können hier Bilder dazu gezeigt werden.

3.) feststehendes Card-Design, das aber ab Smartphone im Portraitmodus wechselt zum Accordion-Design genäß 1.) Denn sonst müsste der Besucher 16 Cards hinweg abwärts scrollen, bis er womöglich das letztangezeigte Thema für interessant findet. Ich glaube, so lange scrollt keiner. – Deshalb dann der Wechsel zum Accordion-Layout, wobei bei so schmalen Screen dann fast alle Beitragstitel bereits zweizeilig angezeigt würden.

Was tun? – Vielleicht doch Lösung 2.) wählen?

Bin immer noch an der Gestaltung meiner neuen Website. Da sind 16 Beiträge, die in der Blog-Ansicht angeboten werden. (Menüpunkt zeigt auf Kategorie und die darin enthaltenen Beiträge werden mit Titel und Einleitungstext mit max. 200 Zeichen angezeigt.)

Nun ist ja bekannt, dass die Aufmerksamkeitsspanne der Besucher sehr kurz ist und dass zudem jede "Überflutung" als Überforderung abgelehnt wird, indem zu anderen Seite oder Website gesprungen wird. Präsentiere ich also alle 16 Beiträge auf einem Grid als Card mit Titel und den ersten 200 Zeichen des Beitragstexts, dann ist die Webseite optisch übervoll und muss sogar in der breiten Desktop-Ansicht vertikal gescrollt werden. Und beim Smartphone hochkant wird eine richtige Scroll-Orgie daraus.

So kam ich auf die Idee, die Titel der Beiträge als Titel in einem Accordion anzeigen zu lassen. Das ist kurz und übersichtlich. Klickt man auf einen Accordiontitel, werden nur die ersten 200 Zeichen des Beitrags gezeigt und dann der Link zum ganzen Beitrag. So weiß der Besucher konkreter, was im Beitrag kommen wird und kann neu entscheiden, ob er sich den ganzen Beitrag "antun" will.

Nun sind aber alle Accordion-Teile zugeklappt und die Links zu den einzelnen Beiträgen sind somit genau so, wie die 200 ersten Zeichen auf "hidden" gesetzt. Und deshalb befürchte ich, dass Google alles, was auf "hidden" gesetzt ist, nicht erfasst / auswertet und somit keiner der Beiträge von Google gefunden / gerankt wird.

Meine Frage:

Welche betr. SEO unproblematische Lösung und zugleich benutzerfreundliche Gestaltung gibt es für solch einen Kategorie-Blog-Layout?

PS: Eine ähnliche Frage habe ich heute morgen in der Rubrik SEO eingestellt, dabei allerdings beschränkt auf die SEO-Problematik bei Text und Links als "hidden".

Bin immer noch an der Gestaltung meiner neuen Website. Da sind 16 Beiträge, die in der Blog-Ansicht angeboten werden. (Menüpunkt zeigt auf Kategorie und die darin enthaltenen Beiträge werden angezeigt.)

Nun ist ja bekannt, dass die Aufmerksamkeitsspanne der Besucher sehr kurz ist und dass zudem jede "Überflutung" mit Angebot als Überforderung abgelehnt wird, indem eine andere Seite besucht wird. Präsentiere ich also alle 16 Beiträge als Card mit Titel und den ersten 200 Zeichen des Beitragstexts, dann ist die Webseite übervoll und muss sogar in der breiten Desktop-Ansicht vertikal gescrollt werden. Und beim Smartphone hochkant wird eine richtige Scroll-Orgie daraus.

So kam ich auf die Idee, die Titel der Beiträge als Titel in einem Accordion anzeigen zu lassen. Das ist kurz und übersichtlich. Klickt man auf einen Accordiontitel, werden nur die ersten 200 Zeichen des Beitrags gezeigt und dann der Link zum ganzen Beitrag. So weiß der Besucher konkreter, was im Beitrag kommen wird und kann neu entscheiden, ob er sich den ganzen Beitrag "antun" will.

Nun sind aber alle Accordion-Teile zugeklappt und die Links zu den einzelnen Beiträgen sind somit genau so, wie die 200 ersten Zeichen auf "hidden" gesetzt. Und deshalb befürchte ich, dass Google alles, was auf "hidden" gesetzt ist, nicht erfasst / auswertet und somit keiner der Beiträge von Google gefunden / gerankt wird.

Meine Frage also betr. SEO:

Ist meine Annahme richtig, dass Google die Beiträge bei der oben beschriebenen Lösung nicht finden / nicht ranken wird, weil die wichtigen Dinge auf "hidden" stehen?

Die ebenfalls hier in der Luft liegende Frage, wie ich denn das vorbeschriebene Problem am besten lösen kann, sodass der Besucher nicht überflutet und abgeschreckt wird, wenn ihm eine Blog-Ansicht mit so vielen Beiträgen zur Auswahl gezeigt wird, stelle ich dann noch an geeigneterer Stelle im Forum neu.

Gerade habe ich auf Joomla 4.3.3 upgedatet. Bei einer Website lief alles glatt durch, bei einer anderen, die weitestgehend die gleichen Extensions installiert hat, kamen die im Bildanhang zu sehenden Fehlermeldungen. Allerdings wurde dennoch das Update anscheinend korrekt auf 4.3.3 vollzogen, wie die Versionsnummer zeigt. Und die Website läuft im Backend und Frontend anscheinend einwandfrei.

Was haben diese Fehler zu bedeuten und sollte ich etwas unternehmen, um die Stabilität der Website sicher zu stellen?

Danke für deinen Tipp. Ja mit der Modalbox würde es wahrscheinlich schon deshalb einfacher, weil dort im Link das Video-Tag genutzt wird. Aber die Modalbox hat erhebliche Probleme mit der automatischen Anpassung der Abmessungen an die Screen-Abmessungen. Und relative Abmessungen können nicht im Link übergeben werden wie z.B. Prozentwerte oder vw-Werte.

Das hat die UK-Lightbox aber bereits per Script integriert. Nur wenn Iframes in die Lightbox geladen werden sollen, dann hat man dort das gleiche Problem.

Die Idee, sich in die bereits von UiKit genutzten events "reinzuhängen" hatte ich auch schon, weiß aber nicht, wie das zu machen geht. (Wie gesagt, von JS usw. habe ich keine Ahnung und habe auch keine Zeit, mich dort einzuarbeiten.

Wenn ich in der o.g. Webseite in die geöffnete Lightbox mit dem Inspector rein gehe, sehe ich mehrere events. Wie könnte ich mich da "reinhängen"?

Hab ich jetzt an verschiedenen Stellen versucht, das onclick="alert..." einzufügen, aber ohne Erfolg. Entweder zeigt es sich noch bevor das Video zu spielen beginnt oder gar nicht. Danach habe ich es sofort mit dem Matomo-Code versucht, da ich dann sofort in den Netzwerkprotokollen den Aufruf zu Matomo sehen könnte. Aber nix da!

Das ist das HTML dazu:

VARIANTE 1
<div uk-lightbox="animation: fade" video-autoplay="" onclick="matomoeventtracking('video', 'playing', 'Video: Supervideo');" onclose="matomoeventtracking('video', 'ended', 'Video: Supervideo');">
    <a href="images/supervideo.mp4" title="Video: Supervideo">
        <img src="images/grafik/play-circle-white-150" alt="" />
    </a>
</div>

VARIANTE 2
<div uk-lightbox="animation: fade" video-autoplay="" onclick="matomoeventtracking('video', 'playing', 'Video: Supervideo');">
    <a href="images/supervideo.mp4" title="Video: Supervideo" onclose="matomoeventtracking('video', 'ended', 'Video: Supervideo');">
        <img src="images/grafik/play-circle-white-150" alt="" />
    </a>
</div>

Ich glaube mittlerweile, das krieg ich auf diese Weise nicht hin.

Wenn die Lightbox geöffnet ist, sehe ich mit dem Inspector einen container mit der Klasse html.uk-lightbox-page. Darin befindet sich der Container mit der ID und Klasse:

ul id="uk-lightbox-panel-*** uk-lightbox-items

Und an dritter Stelle sehe ich darin einen Container mit den Klassen uk-active uk-transition-active

Vielleicht kann ich in der custom.css eine dieser Klassen oder die ID mit dem event "onclose" irgendwie verknüpfen? Besonders die ID könnte dazu geeignet sein, denn die ID erhält eine von einem Script eingefügte Kennung, wo ich die Sternchen hingesetzt habe.

Als Alternative könnte ich statt der Lightbox die Modalbox von YooTheme bzw. Ui-Kit verwenden, weil dort das Video Tag verwendet wird und dieses einfacher zu tracken ist. Die Modalbox hat aber Probleme mit der automatischen Größenanpassung der Videos an Höhe und Breite des Bildschirms, sodass das ausscheidet. Die Nachteile sind zu groß gegenüber dem Vorteil, feststellen zu können, wie viel von dem Video angeschaut worden ist.

Betr. der rechtlichen Tracking-Problematik sehe ich keine Probleme, da ich alle Daten ohne Cookies erfasse und diese sämtlich noch vor der Ablage in der Datenbank von Matomo anonymisiert werden. Und damit sind es keine personenbezogenen Daten im Rechtssinne des TTDSG (= Telekommunikations- und Telemedien-Datenschutz-Gesetz) und auch nicht im Sinne der DSGVO mehr. Zusätzlich habe ich ein berechtigtes Interesse im Sinne des Besuchers, die Website technisch ständig zu optimieren und die Inhalte gemäß der sich zeigenden Interessen zu optimieren. Und als Luxux biete ich demnächst noch ein OptOut an.

onclose="...." ist sicher eine gute Idee. Aber wo im HTML setze ich das hin? Ich habe den Eindruck, dass das HTML, in den ich onclose="..." setzen will, dynamisch generiert wird.

Vielleicht ist es doch hilfreich, wenn ich meine Website nenne, auf der solch eine Lightbox mit Video eingesetzt ist. Es ist schon auf der Homepage zu sehen.

Mit dem Inspector des Browsers ist leicht erkennbar, wie der Link zum Start der Lightbox aufgebaut ist einschließlich des Tracking "onclick="...."

Und wenn ich mit dem Inspector auf den Bereich der geöffneten Lightbox gehe, in dem der Klick zum Schließen funktioniert, dann kann ich nirgends einen Ansatz dafür erkennen, wo ich das "onclose="...." im HTML hinsetzen sollte.

firstlady Ich danke dir für dein Verständnis!

Na toll.... Ist mir das peinlich!!! In PHP-myAdmin gibt es über der Liste mit den Zeilen / Tabellen ein Häkchen für Seite 1, Seite 2 usw. wenn die Zeilen nicht alle auf den Bildschirm passen. So hatte ich den Eindruck, dass die Hälfte der Datenbank verloren gegangen sei!

Denn die Datenbank der neuen J4-Installation hat natürlich bei Weitem nicht so viele Einträge und passt daher noch auf eine Bildschirmseite.

Jetzt konnte ich auch den Eintrag finden und auch das fehlende Häkchen bei der Null-Checkbox setzen. Und die Welt ist wieder in Ordnung!

Sorry für den Wirbel, den ich hier verursacht habe. Aber ich bin nun mal Anfänger mit dem Zeugs. Mein Fachgebiet ist ganz wo anders!

Die DB-03 ist die einzige, in der categories, content usw. als Zeile / Tabelle zu sehen sind.

Wie ich gerade im Web erfuhr, lässt sich aus einem AkeebaBackup mit der Pro-Version die Datenbank als Dump extrahieren. Müsste ich kaufen. Aber ob ich damit Erfolgschancen habe???

Der Ärger ist leider noch größer! Eine andere Website, die ich vor drei Wochen fertig gestellt hatte und seitdem online ist, hat den gleichen Datenbank-Fehler. Ich habe jetzt noch mal Screenshots angefertigt: DB-03 ist eine frische Joomla-4-Installation, DB-06 und DB-09 sind die beiden von J3 migrierten Websites.

Da fehlt ja gehörig was!!! Ich verstehe nicht, wieso die Sites bis jetzt dennoch funktionieren! Die mit der DB-06 hat beim Anlegen, Ändern oder Löschen von Menüs, Beiträge oder Kategorien noch keine Probleme gezeigt!

Ich hatte Akeeba Backups erstellt. Da ist ja die Datenbank mit drin. Allerdings würde ich ja die ganze Arbeit verlieren, die ich seit 4..3.2 investiert habe. Und das sind fast 14 Tage.

Lassen sich denn die aktuell fehlenden Zeilen / Tabellen einzeln aus einem Backup extrahieren und in die derzeit laufende Datenbank "installieren"?

Es existieren 14 Kategorien, davon sind 11 aus der Joomla 3-Site übernommen worden, davon drei gelöscht worden und der Rest neu angelegt.