Vorgefertigte Download-Pakete für das Testen von Fehlerbehebungen

    Lassen sich die Patches wie Erweiterungen auch wieder deinstallieren?


    Und muss man die Prozedur mit allen Patches einzeln durchgehen, die man testen möchte? Oder gibt es eine Möglichkeit, mehrere Patches gleichzeitig auszuwählen und die betroffenen Dateien in einem Rutsch zu downloaden?

    Zitat von JoomlaWunder

    Lassen sich die Patches wie Erweiterungen auch wieder deinstallieren?

    Jein. Du kannst auf ein aktuelles Nighly Build aktualisieren, dann hast du wieder die aktuellste Entwicklungsversion.


    Wenn es dir darum geht, die Deinstallation durchzuführen, um ein anderes Patch zu testen, dann ist das nicht notwendig. Wenn du die die Zip des anderen Installationspaketes installierst, wird das vorhergehende gleichzeitig überschieben.

    Zitat von JoomlaWunder

    Und muss man die Prozedur mit allen Patches einzeln durchgehen, die man testen möchte? Oder gibt es eine Möglichkeit, mehrere Patches gleichzeitig auszuwählen und die betroffenen Dateien in einem Rutsch zu downloaden?

    Das geht leider nicht. In erster Linie geht es darum, eine Fehlerbehebung unabhängig von anderem zu testen und so zu beurteilen, ob dieses Patch fehlerfrei ist und in den Code integriert werden kann/soll. Aber du hast recht. Manchmal gibt es Wechselwirkungen zu anderen Patches und man möchte die zusammen ansehen.

    Hallo Astrid,

    Zitat von astrid

    Es gibt seit Anfang April eine neue Möglichkeit Fehlerbehebungen zu prüfen.

    Endlich :) Hatte diesbezüglich wegen NPM etc. schon etliche Diskussionen auf Github & auch Mails an bestimmte Developer. Diese haben sicher dann öfters: :rolleyes: gezeigt.

    Es ging mir darum, dass ich oft (wieder) ein komplettes fully (nightly) installieren musste. Da die Update Packages ja nicht immer die erforderliche SQL Daten enthielten.


    Zu dem da Frage(n):

    Zitat

    Es ist nicht erforderlich den Patch Tester zu verwenden oder dich mit NodeJs oder Composer herumzuschlagen. Es ist einzig und allein notwendig, dass du ein Konto bei Github anlegst und dich dort anmeldest.

    Den normalen Patch Tester (auf 4.0.0 upgedated) habe ich sowieso. Brauche eigentlich nur Methode 3?


    Diesen "custom update server" habe ich auch schon vor ein paar Tagen eingetragen.

    Sollte eigentlich genügen, glaub? Beim nächsten PR Test werde ich es ja merken.


    Vielleicht eher OT, aber ev. doch zusätzliche Info, wegen Github Konto.


    Voriges Jahr bekam ich u.a.:

    Zitat

    You recently used a password to access an endpoint through the GitHub API using PatchTester/3.0. We will deprecate basic authentication using password to this endpoint soon:

    https://api.github.com/rate_limit

    We recommend using a personal access token (PAT) with the appropriate scope to access this endpoint instead. Visit https://github.com/settings/tokens for more information

    Später dann nochmals, andere, aber ähnliche Meldung. Hab dann einen Token erschaffen. Den hab ich mir wo aufgehoben, weil nach jeder neuen Fully (nightly) Installation, musste ich den wieder eingeben.


    Danke für Deine Infos!


    Liebe Grüße

    Christine

    Hallo Astrid,

    vielen Dank für die Erklärung! Das ist auf jeden Fall eine gute Sache und macht die Schwelle, Patches zu testen, wieder ein Stückchen niedriger. Was mir bei deiner Anleitung aufgefallen ist: Du schreibst, dass die Update-Packages nur innerhalb eines Versionsstrangs (3 oder 4) funktionieren. Kann man nicht auch ein Update-Paket für Version 4 auf eine Version 3 aufspielen? Dann kommt man natürlich auf V4 raus, aber gerade für Änderungen am Datenbankschema müsste man das wahrscheinlich so machen, da diese nur für Updates von 3 auf 4 und bisher nicht von 4 auf eine spätere 4 ausgelegt sind. Oder setzen die Update-Packages bei einem bestimmten Stand von Version 4 an?


    Viele Grüße

    Constantin

    Zitat von Harmageddon

    Was mir bei deiner Anleitung aufgefallen ist: Du schreibst, dass die Update-Packages nur innerhalb eines Versionsstrangs (3 oder 4) funktionieren.

    Danke für deinen Hinweis. Das habe ich nicht genau genug beschrieben. Gemeint habe ich folgendes: Wenn du eine Joomla 3 Installation hast und hier ein Patch von Joomla 4 einspielst, dann passt die Datenbank nicht. Du installierst dann Änderungen für Joomla 3 in eine Joomla 4 Datenbank. Das passt nicht.

    Zitat von Harmageddon

    Kann man nicht auch ein Update-Paket für Version 4 auf eine Version 3 aufspielen? Dann kommt man natürlich auf V4 raus, aber gerade für Änderungen am Datenbankschema müsste man das wahrscheinlich so machen, da diese nur für Updates von 3 auf 4 und bisher nicht von 4 auf eine spätere 4 ausgelegt sind.

    Ich glaube nicht, dass man ein Update-Paket für Version 4 auf eine Version 3 aufspielen kann. Wenn es um das Testen des Updates von joomla 3 auf Joomla 4 geht, dann ist es meist so, dass dies in der Testbeschreibung genauer erklärt ist. Zum Beispiel in diesem PR: https://github.com/joomla/joomla-cms/pull/28495
    Man soll dann also joomla 3 installieren, danach das Patch installieren und am Ende das Update durchführen. Dann ist man auf Joomla 4.

    Ich hoffe das ist verständlich.

    Zitat von christine2

    Es ging mir darum, dass ich oft (wieder) ein komplettes fully (nightly) installieren musste. Da die Update Packages ja nicht immer die erforderliche SQL Daten enthielten.

    Das wird sich mit dieser Neuerung leider nicht ändern.

    Wenn die Datenbank bei einem Patch geändert wurde, dann musst du diese nach dem Test wieder "zurücksetzten". Dazu musst zum Beispiel mit einem Nighly Build eine neue Installation durchführen.
    Ein weiter Punkt der beachtet werden muss: Wenn bei einem Patch eine Datei umbenannt, gelöscht oder hinzugefügt wurde funktioniert das "Nacheinandertesten" auch nicht korrekt. Konkret: Wenn bei einem Patch eine Datei hinzugefügt wurde und du das nächste Patch hinzufügst, dann wird die hinzugefügte Datei unter Umständen nicht gelöscht. Hier ist der Patch Tester klar im Vorteil. Der kann mit geänderten Dateinamen umgehen.

    Der Vorteil der dieser Methode ist, das sie npm und composer unnötig macht.

    So, die ersten highlights habe ich schon. Der Reihe nach:


    Wollte diesen PR machen: https://issues.joomla.org/tracker/joomla-cms/28612 > werde dazu Christiane anpingen. Da ich dort keine Fehlermeldung (Warning) bekam/bekomme. Dachte mir, jetzt versuchst es gleich mit dem "neuen Patchtester".


    1) Bin dort auf Github auf dieses "Download Package" gegangen:

    https://ci.joomla.org/artifact…ev/28612/downloads/31081/


    2) Auch https://ci.joomla.org/artifact…wnloads/31081/pr_list.xml beim Server eingetragen.


    3) Paket Update (siehe Punkt 1)

    1. Versuch war: ERROR: AJAX Loading Error.

    2. Versuch ging dann durch: Your site has been updated. Your Joomla version is now ‎4.0.0-beta1-dev+pr.28612


    4) Dann bekam ich:

    Zitat

    Warning: session_start(): Failed to initialize storage module: user (path: /xxx/.xxx/tmp) in /xxx/xxx/xx/xxx/libraries/vendor/joomla/session/src/Storage/NativeStorage.php on line 478 Warning: mysqli::prepare(): invalid object or resource mysqli in /xxx/xxx/xx/xxx/xxx/libraries/vendor/joomla/database/src/Mysqli/MysqliStatement.php on line 137 Warning: mysqli::prepare(): invalid object or resource mysqli in /xxx/xxx/xx/xxx/libraries/vendor/joomla/database/src/Mysqli/MysqliStatement.php on line 137

    Oops! An Error Occurred

    The server returned a "500 Whoops, looks like something went wrong.".

    Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused. Warning: mysqli::prepare(): invalid object or resource mysqli in /xxx/xxx/xx/xxx/libraries/vendor/joomla/database/src/Mysqli/MysqliStatement.php on line 137 Warning: session_write_close(): Failed to write session data using user defined save handler. (session.save_path: /xxx/xxx/xx/xxx/tmp) in /xxx/xxx/xx/xxx/libraries/vendor/joomla/session/src/Storage/NativeStorage.php on line 114

    5) Datenbank Check: DB: There are tables not up to date > Update.


    6) Result OK:

    4.0.0-2020-03-25

    ‎4.0.0-beta1-dev+pr.28612


    Das war's :) Den PR kann ich noch (nicht) als successful machen, da ich diese "Warning" nicht habe.
    Versuche es dann nochmals.


    Liebe Grüße

    Christine

    So, neuester Stand, betreffend dem obigen PR 28612


    Danke an Harmageddon für die Info, dass die Tabellenspalte "protected" in die Datenbank reingekommen ist.


    Konnte das jetzt auch hier sehen: https://github.com/joomla/joom…nts/com_admin/sql/updates



    also Pech gehabt. https://github.com/joomla/joom…esql/4.0.0-2020-03-25.sql


    Knapp verfehlt das Datum :) Meine Seite ist vom 26.03. Heißt: Werde komplett neu installieren (müssen).


    Liebe Grüße

    Christine

    Zitat von christine2

    Nun denn, die Neuinstallation wäre doch nicht notwendig gewesen. Weil es die gleiche Datenbankversion zeigt, Nämlich: 4.0.0-2020-03-25 -- 4.0.0-beta1-dev

    Patchtester: 4.0.0-rc2


    Ich weiß, was du meinst. Dieses elendige Neuinstallieren ist lästig. Ich weiß aber aus Erfahrung, dass man sich viele Probleme erspart, wenn man im Zweifel neu installiert.


    Ich glaube, du hattest bei dem beschriebenen PR zu Beginn nicht die neueste Developer-Version von Joomla 4 auf deinem Rechner. Deshalb war die Spalte protected nicht vorhanden.


    Da im betreffenden PR nur Änderungen in einer PHP-Datei vorgenommen wurden, wäre dieser PR einer von denen, die mit der hier im Zweig beschriebenen Weise installiert werden und später mit einem anderen überschreibbar sind. Weil: Der Patch beinhaltet weder eine Datenbankänderung und es wird keine Datei hinzugefügt, umbenannt oder gelöscht.


    Fazit: Hier hatte ein sauberes System zu Beginn Ärger erspart. Korrekt?


    Nebenbei ist möglich, dass ein Test ein falsches Ergebnis bringen, wenn man ihn auf einer veralteten Joomla Developer Version ausführt.

    Zitat von astrid

    Ich glaube, du hattest bei dem beschriebenen PR zu Beginn nicht die neueste Developer-Version von Joomla 4 auf deinem Rechner. Deshalb war die Spalte protected nicht vorhanden.

    Kann schon sein, aber:

    Zitat von astrid

    Der Patch beinhaltet weder eine Datenbankänderung und es wird keine Datei hinzugefügt, umbenannt oder gelöscht.

    eben.

    Zitat von astrid

    Fazit: Hier hatte ein sauberes System zu Beginn Ärger erspart. Korrekt?

    Nebenbei ist möglich, dass ein Test ein falsches Ergebnis bringen, wenn man ihn auf einer veralteten Joomla Developer Version ausführt.

    Na ja, sooooooo veraltet war sie nicht :) Wie ich schon schrieb: Meine "alte" vom 26.03. bzw. "neue" von gestern, 11.04. zeig(t)en:


    4.0.0-2020-03-25 -- 4.0.0-beta1-dev

    Bekam halt keine "Notice" (vor dem Patch) trotz Developer/Debug ON.


    Mittlerweile hat sich das eh erledigt. Heutige Info von Christiane auf Github:

    Zitat
    finally after new clone, deleting the database and re-builing the whole environment - the notice has gone.

    Liebe Grüße

    Christine