OXID 4.9: kein Admin-Login mehr möglich über SSL-Proxy!?

Nee :slight_smile:
Du machst einen Fork für das gesamte Repo. Per default wird der Master-Branch (dev-ce) für die Bearbeitung angeboten, dort sollen auch die PRs hin und wir verteilen dann auf die anderen Branches falls möglich/notwendig.
In der README steht, welcher Branch wofür ist.

Gruß

Ich denke das musst du jetzt nicht ändern, falls ja wird dir das schon jemand sagen. Die readme kannst du beim Projekt lesen: GitHub - OXID-eSales/oxideshop_ce: OXID eShop CE component

Ich kann dir nur sagen wie ich das mache (bin aber kein Git-Experte). Ich verwende den Client von Github, der ist sehr übersichtlich und einfach zu bedienen. Von da aus kann man auch die Shell aufrufen, die brauche ich nur um das Repo zu aktualisieren, und zwar folgendermassen:

Ich gehe auf meinen Fork bei Github zu b-dev-ce und klicke auf den grünen Button. Dann sehe ich:

There isn’t anything to compare. OXID-eSales:b-dev-ce is up to date with all commits from leofonic:b-dev-ce
Das bedeutet, dass das eigene Repo NICHT up-to-date ist.

Also rufe ich den lokalen Github Client auf und bringe das Repo auf den neuesten Stand. Das geht in 3 Schritten, den ersten muss man nur einmal machen:

  1. Remote einrichten: Configuring a remote repository for a fork - GitHub Docs
  2. Änderungen abholen: Syncing a fork - GitHub Docs
  3. Änderungen zum Github-Fork pushen: Pushing commits to a remote repository - GitHub Docs

Allerdings verwende ich statt “merge” “rebase”, weil ich bei “merge” eine zerschossene History hatte obwohl ich den b-dev-Zweig nie angefasst habe, und pushe dann mit dem Parameter -f, weil sonst die Änderungen von “rebase” nicht übernommen werden: git - How do I update or sync a forked repository on GitHub? - Stack Overflow

Dann schaue ich wieder auf die Compare-Seite:

There isn’t anything to compare. OXID-eSales:b-dev-ce and leofonic:b-dev-ce are identical.
Voila, das bedeutet mein Fork ist up-to-date.

Jetzt erstelle ich im Github Client einen eigenen Branch für die Änderungen, mache dort die Änderungen, also nicht direkt im b-dev-ce Zweig, der ist quasi immer das Original, synche den neuen Branch mit Github und mache einen Pull-Request. Wenn der neue Zweig nicht mehr benötigt wird (Pull-Request angenommen/abgelehnt) kann man ihn einfach löschen.

Danke leofonic, das ist super zusammengefasst! Ich komme also um den Client wohl nicht herum, okay, hoffentlich stört das aber mein TortoiseSVN nicht (welches mir lieber und wichtiger ist). Aber das ist ja alles relativ OT, also werde ich es hier mal nicht weiter vertiefen. An Github-Dokus mangelt es ja wahrlich nicht, man muss es eben nur mal ausführlich nutzen bis man Übung hat. Schade, dass ich noch nicht dauerhaft genug Zeit für OXID habe, sondern zwischendrin immer wieder ganz andere Projekte. Github verbreitet sich aber derart rasant, dass man eh nicht drum herum kommt, und die Entscheidung seitens OXID war sicherlich nicht verkehrt…

Tja, blöde Sache: nun wurde mein Bugeintrag und der PR als “nicht reproduzierbar” abgelehnt bzw. geschlossen. Dabei ist das Problem doch offensichtlich, wenn man sich mal den Code anschaut (dachte ich zumindest). Und schlimmer noch: nun hat es der Bug durch die letzten Updates auch in alle anderen Versionen geschafft! :eek:
Genau dies hätte ich gerne vermieden gewusst, aber scheinbar konnte ich es nicht sauber auf den Punkt bringen. Leider fehlt mir nun die Zeit (und auch etwas die Geduld und gutes Englisch), um das Ganze weiter aktiv voran zu treiben. Mag nicht jmd. anderes dies übernehmen? :wink: Oder wie wäre nun das effektivste Vorgehen?

Ich habe zwar bereits 2 weitere Hotfixes für 4.7.14 + 4.8.8 parat (dort aber ohne Berücksichtigung der relativen Pfade, da ich eh nicht weiß, wann die auftreten können), die ich auch gerne anhänge, aber das darf nur eine temporäre Lösung bleiben, denke ich…

Hab mal nen Kommentar auf Github abgegeben.

Ok, prima, mal sehen obs hilft. Und sollte man nun den Bug reopen, und kann nur ich dies tun? Müsste es für die anderen Versionen nochmal getrennt gemeldet werden und bräuchte es auch entsprechend weitere pull-request? Das schreckte mich halt etwas ab und evtl. längere Debatten…

Hab ich schon auf meiner Todo-Liste für die nächsten Tage

Gruß

[QUOTE=Mitmacher;151986] nun hat es der Bug durch die letzten Updates auch in alle anderen Versionen geschafft! :eek:…
Ich habe zwar bereits 2 weitere Hotfixes für 4.7.14 + 4.8.8 parat…[/QUOTE]
Wie das, welche anderen Versionen? Den Bug gibt’s doch nur bei 4.9 oder sehe ich das falsch?

Den Bug gibt’s doch nur bei 4.9 oder sehe ich das falsch?

Yep, leider wurde der Bug back-ported in die letzten Patches. Dort zwar etwas anders strukturiert, aber letztlich mit demselben (falschen) Ergebnis. Ich füchte also, dies dürfte nun auch vermehrt anderen Betreibern auffallen, die eben noch nicht auf 4.9 updaten können/wollen.
Aber es kam eben schon die Info vom Entwickler, dass es nun doch reproduziert werden konnte, also geht es wohl jetzt seinen Gang. Ich werde aber noch einen Kommentar ergänzen wg. der anderen Versionen…