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.
Gruß Jan
Moin
Ich spiele mal kurz den Spielverderber.
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
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.
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.
Ü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.
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
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.
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.
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.comDann 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.
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?
Was sagt das Problem wenn du den PHP-Handler von Nginx auf FastCGI umschaltest?
Moin
Läuft diese Seite mit PHP 8 ? Falls ja, bitte mal testweise auf PHP 7.4 herunter stellen und schauen ob der Fehler dann verschwindet. Außerdem würde ich einen genaueren Blick in die Log-Dateien werfen, ob sich eventuell schon vorher Probleme abzeichnen.
Gruß Jan
Geh bitte noch einmal beim JCE in das entsprechende Profil, beim Reiter oben auf "Editor Parameter", dann links auf "Typography" und auf den Punkt "Editor Styles". Dort bitte bei "Editor Styles" das Dropdown von "Inherit" auf "Add" wechseln und speichern.
Ok, hatten wir da nicht erst so eine Geschichte mit Sonderzeichen in Dateinamen? Wäre es möglich das dieses Problem noch in anderen Feldern / Verknüpfungen vorkommt?
Nachtrag: Erscheinen die verschwundenen Artikel in der Datenbank?