Beiträge von Pest

Moin

Ohne jetzt den Pagebuilder und die genaueren Umstände zu kennen, würde ich mit PHPMyAdmin in die Datenbank schauen und dort im Feld "extensions" nach der Domain suchen. Die wird wahrscheinlich irgendwo in den Parametern abgelegt worden sein. Kannst Du dann per "Edit" oder "Suchen und Ersetzen" austauschen lassen. Vorherige und vollständige Sicherung muss ich wohl nicht extra erwähnen.

Falls Du dort nicht fündig wirst, hatte ich die Domain schon mal in einem Plugin zum Builder / Template hinterlegt. Exotische Situation, kam bisher auch nur einmal vor.

Gruß Jan

Moin

Ich werfe hier mal eine gehörige Portion "Pragmatismus" in den Raum. Wir sprechen hier von einem winzigen Projekt mit insgesamt fünf (!) Unterseiten, inklusive der Startseite. Ich habe in meiner Datenschutzerklärung mehr Inhalte als diese Seite insgesamt.

Curitasnetworks

Lege die per FTP gesicherten Inhalte beiseite und bau das Projekt schnell mit einem aktuellen Joomla 4 nach. Den Aufbau der Seite und die Texte kannst Du über das Webarchiv aufrufen. Das Gefummel mit lokalen Server, Fehlersuche, Migration usw. lohnt sich einfach nicht.

Startseite

Gruß Jan

Moin

Falls möglich, lade Dir die (Server) Log-Dateien Deiner Seiten herunter und durchsuche Sie nach den Zugriffen der Google Adsense Crawler. Gibt es Fehlercodes wäre es hilfreich, kommen sie nicht über die Startseite hinweg wäre es ebenfalls ein Ansatzpunkt. Testweise kannst Du auch einen Wechsler für den Browser-Agent installieren, Scripte abschalten und Dich als Adsense Crawler ausgeben um zu sehen was er zu sehen bekommt. Die unterschiedlichen Kennungen findet Du unter diesem Link: https://developers.google.com/…/overview-google-crawlers

Gruß Jan

Moin

Einfach nur die sinkenden Zahlen anstarren ändert nichts. Meiner Meinung nach gibt es zwei mögliche Fehlerquellen, welche mit diesem Problem in Verbindung stehen könnten.

1. Der Wegfall der Meta-Keywords in Joomla 4. Für Google selbst eventuell wirklich nicht mehr von Belang, könnte es noch einen Einfluß auf den Crawler von Google Adsense haben. Der schickt nämlich seinen eigenen Bot los um die Inhalte zu erfassen und zu kategorisieren. Ist zu wenig Inhalt auf der Seite und fehlen dann auch noch die Keywords, wird Google wohl nur noch gemeinnützige Anzeigen einblenden. Und sind Seiten so beschaffen wie die in Deinem Footer verlinkte "Liquidlights.eu" Kike , dann halte ich das für nicht unwahrscheinlich. Es müssen also relevante Texte auf die Seiten.

2. Es gibt ein Problem mit dem Template und dem bereits benannten Verschiebungen im Layout. Wie weit Google das bei seinen Anzeigen wirklich berücksichtigt kann ich nicht sagen, aber es sollte kein Problem sein mal eben auf ein anderes Template zu wechseln und die Veränderung in den nächsten 4+ Wochen zu beobachten. Steigen die Einnahmen, ist der Fehler wahrscheinlich gefunden. Falls nicht, kann man diesen Punkt abhaken und die nächste Option prüfen.

Gruß Jan

Zitat von Kallle

Wo siehst Du denn den Unterschied zwischen "SP Transfer" und "SP Upgrade"? Wann würdest Du das eine oder andere bevorzugen?

Mit SP Transfer bleibt die ursprüngliche Seite unangetastet, die Komponenten übertragt die gewünschten Daten manuell und wandelt sie passend um. Du hast quasi beliebig viele Versuche für eine "Migration" und kannst die Bestandteile die übertragen werden selbst bestimmen. Zu SP Upgrade kann ich nichts sagen, da ich es nicht benutze.

Moin

In ganz schweren Fällen greife ich auf die Erweiterung "SP Transfer" zurück um die Daten manuell zu übertragen. Kann keine Wunder vollbringen und man muss die Struktur der Seite sehr gut kennen. Aber wenn weiss was man dort macht, kann es sehr viel Zeit sparen und man lässt verkorkste Altlasten zurück. Letztlich sind das aber alles nur Werkzeuge, kannst Du einen Schraubendreher nicht bedienen, dann bringt Dir auch der beste Schraubendreher der Welt nichts. Recherche für Dritterweiterungen sind aber grundsätzlich Pflicht.

Gruß Jan

Moin

Manche Browser und Passworttresore gleichen die gespeicherten Zugangsdaten mit einer öffentlichen Datenbank ab, in denen gehackte Daten gespeichert sind, die im Internet verkauft wurden. Gut möglich das dies eine Warnung ist, dass dein Benutzername / eMail / Passwort in einer dieser Datenbanken aufgetaucht ist. Ich würde die Zugänge alle ändern um auf der sicheren Seite zu sein.

Das hier ist der bekanntestes dieser Dienste.

https://haveibeenpwned.com/

Gruß Jan

Moin

Ich spiele mal kurz den Spielverderber.

1. Bei dem Beispiel hinter dem Link handelt es sich um eine Videoplattform der man explizit eine Anweisung mitgeben kann keine Cookies zu setzen. Bei einer "normalen" Seite in einem iFrame wäre das wohl meistens nicht der Fall.
2. Lösungen die auf einem Javascript basieren, laden im schlimmsten Fall die Seite wenn im Browser Javascript deaktiviert ist (z.B. wegen einem prominenten Plugin wie "NoScript").
3. Frames die ich mit einem "display: none" ausblende, werden im Hintergrund trotzdem geladen und können dann selbstverständlich auch einen ungewollten Cookie setzen.

Den Lösungsansatz von Re:Later ausgenommen, also wenn der Frame per Script geladen und nicht einfach nur ausgeblendet wird. Dann sollte es die oben genannten Probleme nicht geben.

Moin

Ein iFrame ist eine direkte Verbindung die der Browser des jeweiligen Besuchers aufruft. Da die Cookies von einer fremden Domain gesetzt werden, hat Deine Seite keinen Einfluß darauf. Die einfachste Option währe wohl den Aufruf des iFrames von einer Zustimmung abhängig zu machen und bis dahin zu unterdrücken. Aber fertige Plugins habe ich hierfür noch nicht gesehen. Eventuell hat einer der Anderen hier einen Tipp.

Gruß

Jan

Zitat von outdoorfriend

ich denke wenn man ein Update auf 3.5 hinbekommt, dann geht der Rest ja - nachdem was ich gelesen habe - wieder automatisch.

Leider nein, der Schritt von 3.x auf 4.x ist wieder eine Migration für sich, die ganz eigene Probleme macht (z.B. sind praktisch alle Templates inkompatibel und müssen zwingend in einer Version für Joomla 4 vorliegen). Je nach eingesetzten Erweiterungen / Module / Plugins ergeben sich zusätzliche Baustellen die eigene Recherchen / Alternativen notwendig machen. Das Thema wurde hier schon einige Male besprochen.

Zitat von zero

Das wäre mir neu? Es gibt noch zahlreiche Seiten, die ohne SSL Zertifikat laufen, dann steht halt im Firefox unsichere Verbindung bzw. das Symbol, aber die Seite funktioniert zumindest.

Wenn Deine Seite auf ein Zertifikat konfiguriert ist, das es nicht (mehr) gibt, hagelt es Warnmeldungen in jedem mir bekannten modernen Browser. Kein normaler Besucher klickt sich durch diese Warnmeldungen oder erstellt aktiv eine Ausnahmeregel um trotzdem auf die Seite zu kommen.

Logischer Schluss --> Dein "Fallback" ist keines.

Die Zuweisung zum Zertifikat müßtest Du manuell in der Domainverwaltung lösen, aber dann kannst Du auch gleich ein neues Zertifikat erstellen. Bemerkst Du es nicht zeitnah, gibt es die oben genannten Warnmeldungen.

Zitat von WM-Loose

Überlege gerade, ob ich nicht bei github einen issue melden soll.

Was meinst du Jan?

Ich hab den Fehler auf der Seite nicht gesehen, sollte es wirklich ein Problem mit dem UIKit sein, dann müsste es wieder auftreten wenn Du jetzt noch einmal (testweise) die Domain umstellst. Mein Tipp wäre aber eher ein alter Eintrag im Cache (Joomla oder ein Plugin wie JCH).

Moin

Solche Probleme treten auf wenn man (egal wo in Joomla) absolute Pfade setzt. Bleibt man bei den Angaben immer relativ, kann man mit Joomla Domains tauschen so viel man möchte. Das trifft dann selbstverständlich auch auf Slider und die meisten anderen Erweiterungen zu.

Zitat von zero

Was mich ja ein wenig stört bei beiden Varianten, wenn das SSL-Zertifikat ausfällt (passiert sehr selten, aber ist möglich), dann geht die Webseite gar nicht mehr, also eine Art fallback auf http://... wäre da praktisch, um zumindest die Erreichbarkeit zu erhalten.

Dein "Fallback" bringt Dir leider überhaupt nichts, da kein moderner Browser mehr Seiten ohne SSL unterstützt sondern dann nur noch eine Warnmeldung ausgibt.

Gruß Jan

Zitat von Stef

Das wäre für Joomla sicher auch eine gute Idee !

Vorsicht Offtopic! Also ich habe es schon mehrmals erlebt, daß sich potentielle Anwender wegen genau dieser integrierten Kommentarfunktion für ein Wordpress entschieden haben. In Kombination mit dem deutschen Plugin Antispam-Bee sogar datenschutzkonform und ohne Abfrage fremder Datenbanken.

Zitat von scoutrz

Dabei enthält die Seite dich zurzeit überarbeiten möchte k2 als Erweiterung.

Um auf die ursprüngliche Frage hier im Thread zurückzukommen. Die Artikel die Du jetzt in Deinem K2 hast, kannst Du mit einem kleinen Plugin zu Joomla-Artikel umwandeln lassen und dann in Dein neues Joomla 4 migrieren. Stammt von JoomlArt und ist kostenpflichtig.

K2 to com content migration plugin | JoomlArt

Zitat von firstlady

Ich glaub, das wurde früher von Agenturen gemacht, für die es nicht vorstellbar war dass etwas ohne Erweiterung geht

Moment, man muß dazu sagen das K2 zu seiner Zeit Funktionen lieferte, die in Joomla erst Jahre später umgesetzt wurden. Zum Beispiel ein richtiges Redaktionssystem mit Arbeitsabläufen, Extrafeldern, unterschiedlichen Ansichten die sich ohne (!) Overrides sehr flexibel und für mobile Geräte sogar gesondert konfigurieren ließen, eine Reihe optisch sehr ansprechender Module, Kommentarfunktion, Schlagwörter, Einblendung thematisch passender Artikel usw. . So gesehen war K2 in seinen Funktionen Joomla damals um Meilen voraus. Erst als diese dann in den Joomla Core wanderten, wurde K2 quasi obsolet. Deine Aussage konnte ich so also leider nicht stehen lassen.

Moin

Zuerst einmal würde ich alles entfernen das aus externen Quellen geladen wird. So lange die Seite auf die Daten fremder Quellen warten muss, bekommen wir wahrscheinlich keine echten Werte geliefert.

https://piwik.phrixos-it.de/piwik.js
https://www.gstatic.com
https://liberapay.com

Dann sind auf der Seite 26 (!) Javascripte bei insgesamt 33 Anfragen. Entweder ist das ein Grab suboptimal zusammengestellter Erweiterungen / Plugins, oder ein Entwickler hat jedes Problem mit einem Script zu lösen versucht. Da muss mal so richtig ausgemistet werden.

Vollständige Sicherung des Projekts und dann alle Komponenten und Plugins die zusätzlich installiert wurden, aber nicht aktiv genutzt, komplett deinstallieren. Nicht nur deaktivieren, sondern wirklich komplett runter. Template könnte man testweise auch einmal umschalten um Inkompatibilitäten aus dem Weg zu räumen. Und bitte schauen welche Dateien (JS / CSS) diese riesigen Leerräume in den Quelltext bringen lassen.

Ein lokaler Test auf XAMPP wird Dir nicht viel bringen, weil diese Umgebung weit entfernt von realen Bedingungen ist. Du bekommst das Geschehen damit in keinen Kontext gesetzt. Du brauchst einen Ausgangspunkt der garantiert sauber konfiguriert und performant ist. In schwierigen Fällen ziehe ich Projekte auf eine Subdomain in mein eigenes Paket und lasse die Tests dort laufen. Außerdem habe ich dann mehr Möglichkeiten für die Fehlersuche, komme selbst an alle relevanten Log-Dateien usw.

Kurz gesagt, Du solltest sicherstellen das die Basis sauber läuft bevor Du Dich intensiver an die Fehlersuche machst.

Zitat von Micki

Würde ein "Aufbohren" des Datenbankservers Sinn machen?

Die echten Werte wirst Du erst im produktiven Betrieb sehen. Ein angemessenes Hosting welches sich nach der Größe des Projekts richtet, sollte wohl selbstverständlich sein. Joomla.org auf einem 5-Euro-Shared-Hosting würde auch abschmieren. Generell kannst Du schon viel mit der Verwendung des Cache regeln. Der fängt die immer wiederkehrenden Datenbankabfragen ab und nimmt sich in der erweiterten Fassung auch die Module vor. Hast Du Zeit und Lust kannst Du hier auch einen Redis einbinden und Dein Joomla noch weiter entlasten. Bieten aber nicht alle Hoster an und der Redis muss separat konfiguriert werden.

Läuft das Projekt aber schon mit z.B. 500 Beiträgen in einer Testumgebung ohne Traffik langsam, hast Du wahrscheinlich ein strukturelles Problem oder der Server trägt zu viel Grundlast.

Moin

Problematisch wird es dann, wenn viele Inhalte dynamisch geladen, sortiert und kombiniert werden müssen. Neben der Abfrage aus der Datenbank, kommt dann eben noch die Verarbeitung vor der Ausgabe hinzu. Auch wenn ich bisher keine Probleme feststellen konnte, bin ich deshalb bei der Verwendung von z.B. Dynamic Content von YOOtheme eher vorsichtig.

Theoretisch könnte man ähnliche Probleme auch mit massenhaft eingebauten Custom Fields auslösen. Ein sehr "breiter" Datensatz, könnte dann in Kombination mit sehr "großen" Datensätzen zu einem Flaschenhals werden. Natürlich immer auch davon abhängig wie potent der MySQL-Server und das Hosting ausgelegt sind und die Daten liefern können. Pauschale Aussage in der Art: "Ab X Beiträgen gibt es in Joomla Probleme" sind nicht haltbar.

Gruß Jan

Ich kann Dir nicht sagen wie viele CSS-Dateien beim Astroid benutzt werden, aber Du könntest Sie (die mit den für Dich wichtigen Typographien) von Hand in den JCE einbinden. Die Stelle dazu hast Du ja schon gesehen, direkt unter dem Dropdown für den Editor-Style. Eine bessere Idee fällt mir im Moment leider auch nicht ein.

Wenn die anderen Seiten mit genau dieser Konstellation von Komponenten / Template funktionieren, muss es einen Unterschied in der Konfiguration oder den Einstellungen des Webpakets geben. Daher die Fragen nach der PHP-Version und dem Handler. Diese Werte würde ich mal mit einem funktionierenden Projekt abgleichen. Liegen die Seiten denn alle auf dem gleichen Server, beziehungsweise sind sie beim gleichen Hoster?