Die BC Breaks oder Probleme, deren ich mir bewusst bin sind folgende:
- Es wird mindestens PHP 5.3 benötigt, da die vorigen Versionen keine Namespaces unterstützen
- xtc_db_data_seek gibt es nicht mehr, ich hab aber allen code der die Funktion genutzt hatte umgeschrieben
- Die service_xtc_db_* Funktionen im admin wurden entfernt, das sie nirgends verwendet wurden und genau das gleiche machen wie die Funktionen ohne das service_ prefix
- Die Funktion xsb_db_query aus dem xsbooster macht keine retries mehr, wenn die DB Verbindung futsch ist
- Die Funktion xsb_db_affected_rows wurde entfernt, weil sie an der Stelle, an der sie verwendet wurde jetzt unnütz war
- Die Funktion xtc_db_fetch_fields wurde entfernt, da sie ungenutzt war und nicht so einfach nachzubilden ist
- Sollte ein Modul die mysql_ Funktionen anstatt die xtc_db_ Funktionen nutzen, gibt es Probleme.
Nummer 1, 2, 4 und 6 sind entweder nicht oder nur schwer anzupassen, so das es keine BC breaks gäbe.
Nummer 3 und 5 wären leicht anpassbar, falls wirklich ein Modul sie benutzt.
Nummer 7 sollte im Modul gefixt werden und nicht in xtc.
Wenn man die xtc_db_ Funktionen nutzt, kann man weiterhin auf die DB zugreifen, wie man es gewohnt ist.
Wenn man sich über xtc_db_get_conn() das Doctrine Objekt holt,
kann man damit die Prepared Statements nutzen und auch alles andere was Doctrine DBAL unterstützt. (NICHT Doctrine ORM!!! ORM mit normalen SQL Zugriffen mischen geht meistens schief!)
Und ja, du darfst fragen
Ich muss oft mit modified eCommerce Shopsoftware arbeiten und mir gingen einige Sachen schon lange auf den Senkel.
Dementsprechend hab ich meinem Chef vorgeschlagen, wenn ich etwas Luft hab, diese Dinge zu ändern.
Wenn das Team hier meine Änderungen übernimmt... gut, wenn nicht... können wir Sie intern trotzdem weiter nutzen.
Er war einverstanden und dementsprechend hab ich damit angefangen.
Ein weiterer Grund ist, das wir jetzt ein Grund Repo haben, von dem wir die einzelnen Projekte Forken können und somit Updates leichter einzupflegen sind. (Da es ja leider kein offizielles offenes Repo gibt)
Und falls es noch jemanden interessiert:
Der Grund für die Twig Integration war z.B. das wir Twig auch für unsere Symfony Projekte nutzen und es weniger anfällig für XSS Angriffe ist.
Der Grund für Doctrine anstatt mysqli waren die Prepared Statements, um SQL Injections vorzubeugen.
Edit:
Drei Ideen die ich noch gerne umsetzen würde, aber nicht weis ob ich das in der begrenzten Zeit schaffe und ob es Sinn macht (z.B. weil es BC Breaks geben könnte) sind folgende:
- Alle Übersetzungen in ein System zusammenfassen (keine Defines mehr und evtl ein schöneres Format als die .conf files) und symfony/translaton dafür nutzen, so wie es in Twig schon der Fall ist (BC Breaks nicht vermeidbar)
- Das Product/Category Listing umbauen, so das man verschiedene Module schreiben kann, die die Logik bestimmen. Beispielsweise ein Modul, das alle Produkte aus allen Subcategories anzeigt und die Kategorieauswahl das nur einschränkt. Oder ein Modul, das die Subcategories auflistet und für jede Subcategory die X topseller anzeigt, usw. (BC Breaks kaum vermeidbar)
- Ein echtes Plugin System mit event dispatcher und so. Damit nicht überall im Core die Codefetzen von irgendwelchen Modulen rumfliegen. (Schwierig das gut umzusetzen und würde ich nicht gerne alleine machen, sondern sollte von mehreren schlauen Köpfen zusammen geplant werden, damit nichts wichtiges übersehen wird. Nachträgliche Änderungen bei Plugin Systemen sind nicht so toll...)
