THEMA:

Guten Abend allerseits

Habe ein wenig mit 4.0 experimentiert (Regenwetterbeschäftigung).

Ich habe versucht (in XAMPP mit PHP 8 ) eine 3.9.27 Seite via 3.10 auf J4 zu migrieren.
3.9.27 auf 3.10: funktioniert gut und die kritischen Erweiterungen werden auch aufgelistet. Diese habe ich alle deinstalliert (deaktivieren reicht nicht) und dann den Update auf 4.0 versucht. Das ging eigentlich ohne Fehlermeldung, aber das Backend von 4.0 wurde dabei irgendwie zerschossen und nichts ging mehr (500 Unknown column 'fp.featured_up' in 'field list').

Da aber 4.0 selber eigentlich gut funktioniert und ich keinen alten Ballast mitnehmen will (z.B. das alte Template oder Reste von alten Erweiterungen), habe ich versucht in eine J4 Installation die Kategorien und den Content via MySQL von 3.9.27 zu 4.0 zu kopieren. Ging für die Kategorien, aber beim Content bekomme ich nur 2 von 34 Artikeln angezeigt. Musste zuerst eine Kolonne ('xreference') entfernen, da diese in 4.0 nicht mehr vorhanden ist. In MySQL ist alles sichtbar, aber im J4 unter Content eben nicht. Und mir ist nichts aufgefallen, was die angezeigten Artikel von den nicht angezeigten unterscheidet. Neu hinzugefügte Artikel werden richtig angezeigt.

Dieses Vorgehen habe ich innerhalb der J3-Versionen schon erfolgreich gemacht um alte Seiten zu in einer sauberen Installation zu relaunchen. Darum dachte ich bei J3 zu J4 würde das auch gehen.

Mache ich da einen Denkfehler?
Müsste ich da auch andere Tabellen mitnehmen?
Habt Ihr schon ähnliches gesehen?

Vielen Dank schon mal und 
viele Grüsse
Urs
.

Hello again...

habe mal rumgesucht und das gefunden: www.eshiol.it/joomla/j2xml/j2xml37.html
Da wird angekündigt, dass es bald eine Version j2xml 3.9 geben wird. Damit soll dann ein derartiger Datenübertrag von 3 zu 4 möglich sein.

Anscheinend geht von 3 zu 4 nicht so einfach wie von 3 zu 3?

Viele GRüsse
Urs

Anscheinend geht von 3 zu 4 nicht so einfach wie von 3 zu 3?

Die Unterschiede in den DB-Tabellen  bei 3 auf 4 werden vermutlich grösser sein als von 3 auf 3
Aber wenn du komplett alle Abhängigkeiten und Referenzen der neuen DB-Strucktur berücksichtigst ist das sicher machbar. Fragt sich halt nur, ob sich der Aufwand lohnt.

Und genau das wäre jetzt ein gutes Beispiel, wieso es Webservices gibt und wozu sie gut sind:
Man könnte nun mit einem einfachen Script die Beiträge in der 3er Datenbank auslesen und pro Beitrag eine Webservice-URL aufrufen mit den (Beitrags-)Daten. Und das Speichern des Artikels selbst dem Content-Model der 4er Installation überlassen. Ganz korrekt und mit allen anderen nötigen (DB-)Abhängigkeiten. Entweder einmalig als Import oder regelmässig aufgerufen als fortlaufende, automatische Synchronisation.

Das ist im Grunde ähnlich, wie wenn man das Formular um einen Beitrag zu erstellen (oder editieren) ausfüllt und speichert. Nur halt ohne Formular
Auch von Server zu Server.

Cheers
Roger

Ich habe versucht (in XAMPP mit PHP 8 ) eine 3.9.27 Seite via 3.10 auf J4 zu migrieren.
3.9.27 auf 3.10: funktioniert gut und die kritischen Erweiterungen werden auch aufgelistet. Diese habe ich alle deinstalliert (deaktivieren reicht nicht) und dann den Update auf 4.0 versucht. Das ging eigentlich ohne Fehlermeldung, aber das Backend von 4.0 wurde dabei irgendwie zerschossen und nichts ging mehr (500 Unknown column 'fp.featured_up' in 'field list').

Da aber 4.0 selber eigentlich gut funktioniert und ich keinen alten Ballast mitnehmen will (z.B. das alte Template oder Reste von alten Erweiterungen), habe ich versucht in eine J4 Installation die Kategorien und den Content via MySQL von 3.9.27 zu 4.0 zu kopieren. Ging für die Kategorien, aber beim Content bekomme ich nur 2 von 34 Artikeln angezeigt. Musste zuerst eine Kolonne ('xreference') entfernen, da diese in 4.0 nicht mehr vorhanden ist. In MySQL ist alles sichtbar, aber im J4 unter Content eben nicht. Und mir ist nichts aufgefallen, was die angezeigten Artikel von den nicht angezeigten unterscheidet. Neu hinzugefügte Artikel werden richtig angezeigt.

.

Salü Urs,

Ich hab mich daran noch nicht versucht, aber hätte eher folgendes gemacht:
3.9.27 nach 3.10 und dann ab 3.10 deine beschriebenen Versuch via SQL, hätte da ein besseres Resultat erwartet, aber ev. hast du das auch schon durch

Hoi Roger und RePao

Vielen Dank für Euren Input.

@Roger:
Bei der Verwendung von Webservices gibt man aber die Daten (inkl. Metadaten) an andere Dienstleister weiter (Sicherheitsaspekte und zusätzliche Aufrufe). Und trägt damit möglicherweise auch zur ungewollten Datensammlung bei? Vermutlich bin ich da etwas zu misstrauisch..... Aber ich werde mich doch mal damit auseinandersetzen.

@RePao:
Du hast recht, ich habe die MySQL-Tabellen aus J3.9.27 exportiert und nicht aus 3.10. Habe irgendwie 3.10 nicht als Zwischenschritt, sondern als Bestandteil der Migration zu mit 4.0 gesehen und damit für den Transfer der Tabellen ausgeblendet. Das werde ich umgehend testen.

Vielen Dank und
viele Grüsse
Urs



 

Nein. Ganz im Gegenteil, da hast du irgendwo einen Denkfehler:

Der Webservicezugriff kann und wird (eigentlich meistens) durch Authentifizierung geschützt. Das heisst es kann nur mit ausdrücklicher Erlaubnis darauf zugegriffen werden.

Die Webseite selbst (das HTML) oder auch RSS-Feeds davon lassen sich hingegen jederzeit und problemlos anonym (und auch automatisiert) auslesen.
(z.B von.Such-Bots und andere Datenkraken). Die Webseite selbst ist also vielmehr eine 'Datenschleuder' als Webservices.

Und das muss nicht immer zwingend ein externer Dienstleister sein, du kannst Webservices auch nur für dich alleine nutzen, z.B. für Datenimport/-Export, Synchronisation, Migration, Multisites, usw.

Dies nur zu deinem Verständnis, nicht damit du voreilig eine Technologie 'verteufelst'  

Hoi RePao

Ich habe soeben versucht die Tabelle aus dem Update auf 3.10 zu übertragen. Gleiches Resultat: im MySQL sind die Daten alle korrekt gelisted, aber die Content Liste im Backend von J!4.0 ist nach wie vor leer.
Werde mal weiterpröbeln und grübeln. Falls ich Erfolg habe, melde ich mich mit der Lösung. Wenn's dann nichts bringt, habe ich mindestens was gelernt.

Dank und Gruss
Urs

Guten Morgen

Nun habe ich es geschaft den Content an eine saubere J!4 Installation via Tabellentransfer in MySQL zu übergeben.

So habe ich es gemacht:

• Update von J!3.9.28 auf 3.10 gemäss: www.joomla.org/announcements/release-new...lpha-7-are-here.html >
• Nach Schritt drei dieser Anleitung alle Erweiterungen die moniert wurden deinstalliert (da hat es z.T. uralten Schrott drin, der nur noch durch komplettes Löschen aus der Datenbank entfernt werden kann).
• Dann mit Schritt vier bis zur Version J!4 verfahren.
• Fehlermeldung und zerschossene Darstellung ignoriert und direkt zu MySQL-Datenbank gegangen. Dort die Tabellen prefix_assets, prefix_categories und prefix_content in die Datenbank der sauberen Neuinstallation von J!4 importiert (die entsprechenden der J!4 vorher gelöscht und dann die prefixe der importierten angepasst).
• in der sauberen Version ins System Dashboard gewechselt und in der Gruppe 'Maintenance' bei 'Global Check-in' alles eingecheckt und dann bei 'Database' mit dem Cursor auf das rote Feld 'Problems' gefahren.
• Im erscheinenden Popup werden die Abweichungen in der content Tabelle angezeigt: Typen-Abweichungen bei einigen (nicht allen!) Datumsfeldern
• Diese in MsSQL in der Tabelle entsprechend geändert (bei mir den Typ von VarChar auf DateTime geändert und die Längenangabe im nächsten Feld komplett gelöscht)
• Sodann die Datenbank mit 'Update Structure' von J!4 gefixt und die Contents werden alle sauber gelistet.

Somit kann ich erste Schritte auf J!4 mit richtigen Daten machen. Vor allem mit dem neuen Template Cassiopeia (vielleicht wird es auch zu meinem Lieblingsausgangspunkt wie einst Protostar).

Eure Inputs haben mich alle irgendwie in die richtige Richtung geführt. Vielen Dank nochmals an alle!

Viele Grüsse
Urs

Guten Morgen

Es hat doch noch versteckte Probleme. Irgendwie sind einige weitere Formate in den Datenbanktabellen umdefiniert worden, die nicht so einfach wie im letzten Post beschrieben, angezeigt werden.
z.B. Können keine freien Module zum Laufen gebracht werden, es werden Datenbankfehler angezeigt: 1292 Truncated incorrect DOUBLE value: 'lft'  (ohne den transferierten Datensatz problemlos möglich!).

Der gewählte Weg ist also doch nicht so zielführend wie angenommen.

Trotz Regenwetter ein schöner Tag!

Urs


 

Guten Tag

Ich war wohl einfach zu früh dran.

Mit dem nightly build 4.0.0-rc5-dev hat es weitgehend funktioniert.
Die Migration läuft. Es hat nur einige Fehler im Backend (z.B. geht der Link zum Kontrollzentrum nicht).
Und vor allem: die Datenbank wird, soweit ich es bis jetzt sehe, tadellos transferiert.

Das Problem ist somit für mich gelöst.

Vielen Dank und Gruss
Urs