endereco / endereco-oxid6-client Goto Github PK

Wenn das Module endereco-oxid6-client aktive ist und eine 404 Seite im OXID Shop aufruft.
Kommt in den Logs ein fatal Error.
Wird ausgelöst durch application/views/agent-include.tpl weil eine 404 Seite keine Controller ist $oView->getClassName() daher ein null zurück gibt.

Generell ist es nicht gut in der OXID welt mit oxid_include_widget zu arbeiten.
Vielleicht finden wir einen gemeinsamen Weg.
Was wollt ihr denn machen ?

PHP Fatal error: Declaration of Endereco\Oxid6Client\Migrations\Version202
10614111035::preUp(Doctrine\DBAL\Schema\Schema $schema) must be compatible
with Doctrine\Migrations\AbstractMigration::preUp(Doctrine\DBAL\Schema\Sche
ma $schema): void in source/modules/endereco/endereco-oxid6-client/migration/data/Version
20210614111035.php on line 12

// is
public function preUp(Schema $schema)
// should be:
public function preUp(Schema $schema): void

same goes for up() and down() functions, ": void" must be added to get rid of the errors.

public function up(Schema $schema): void
public function down(Schema $schema): void

Um die Performance von dem Onlineshop zu verbessern, soll geprüft werden, ob die zwei Widgets, die wir aktuell einsetzten, durch Smarty Plugins ersetzt werden können. Eventuell auch die Initialisierungsaufrufe für Services mit "sprechenden" Funktionen ersetzten.

Vorteile:

• Eventuell schnellere Ladezeiten des Onlineshops
• Einfachere Integration
• Einfachere Dokumentation

Weitere Infos:

• https://docs.oxid-esales.com/developer/en/6.1/modules/skeleton/metadataphp/version21.html#smartyplugindirectories
• Vorgeschlagen von https://github.com/TumTum

Anlass

Es gab Beschwerden darüber, dass wir im Endereco\Oxid6Client\Installer\Installer in onDeactivate den Cache Ordner machen. Angeblich würde diese Methode bei jeder Backendänderung aufgerufen, was die Performance vom Shop beeinträchtigt und automatische Deploy-Prozesse verlangsamt. Wir sollen sie entfernen.

Wieso ist das wichtig?

Der Entwickler des Kunden ist unglücklich. Wir sollen außerdem keine sinnlosen Operationen in unserem Modul machen, da es einerseits keinen Mehrwert bietet, andererseits zu unerwarteten Problemen führen kann.

Wie sieht die gewünschte Lösung aus?

Wir entfernen die Methode clearTmp() aus unserem Installer.

Anmerkungen seitens Entwicklung

Es wäre zu prüfen, ob ältere Versionen des Shops den /tmp Ordner selber löschen. Falls es ab 6.0 geht, dann kann die clearTmp überall gelöscht werden. Falls nicht, sollen wir clearTmp nur in den Versionen vom Shop aufrufen, wo sie gebraucht ist.

In der OXID v6.3 wird guzzlehttp/guzzle 7.3.0 genutzt.

Problem 1
- oxid-eshop/oxideshop-metapackage-ce is locked to version v6.3.0 and an update of this package was not requested.
- endereco/endereco-oxid6-client 4.2.1 requires guzzlehttp/guzzle ^6.3 -> satisfiable by guzzlehttp/guzzle[6.3.0, ..., 6.5.5].
- You can only install one version of a package, so only one of these can be installed: guzzlehttp/guzzle[v1.0.3, v1.0.4, v2.0.0, ..., v2.8.8, v3.0.0, ..., v3.8.1, 4.0.0-rc.1, ..., 4.2.4, 5.0.0, ..., 5.3.4, 6.0.0, ..., 6.5.5, 7.0.0-rc.1, ..., 7.3.0].

Problembeschreibung:

Laut Kundenmeldung funktionieren unsere Anpassungen in Installer.php in MariaDB 10.4. Somit wäre unser Modul nicht nutztbar, ausser man macht die Anpassungen manuell.

Code:

\OxidEsales\EshopProfessional\Core\DatabaseProvider::getDb()->select("DESCRIBE oxuser;");

Fehlermeldung lautet:

Function select is only for read operations select or show {"0":"[object] (InvalidArgumentException(code: 0): Function select is only for read operations select or show at /var/www/loberon/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php:601)

Wieso ist das wichtig?

Die jetzige Lösung würde in Shops mit Maria DB 10.4 nicht gehen.

Gewünschte Lösung

1. Datenbank Anpassungen auf Migrations umstellen.
2. Die jetzige Lösung so umzuschreiben, dass sie sowohl in MySQL, als auch in MariaDB geht.

We are using a custom theme and are using icheck for better looking checkboxes across devices and browsers.
Since there is a hook on the checkboxes change event to decide if delivery address needs to be validated/suggestions are made or not, the delivery address in our shop will not validate an there is no suggestions. ICheck uses the event ifChanged instead of changed.

You can see the problem here: https://www.gutschild.de

Since there is only a uglified version of the java script file I couldn't figure out how to bind the needed calls to iChecks ifChanged event.
Can you please assist me on how to get this done or provide another solution?

If you klick fast enough, maybe the iCheck initialisation isn't finished yet, to extend the delivery address, then it work's. I don't know why?

Was genau ist das Problem

Aktuell wird doAccounting erst beim erfolgreichen speichern des Kunden ausgelöst. Falls ein Kunde jedoch einen Validationsfehler in seiner Eingabe hat - welches nichts mit Adresse zu tun hat -- wird er auf die gleiche Seite weitergeleitet. Endereco JS generiert bei erneuten Laden der Seite eine neue Session ID. Da die Adresse allerdings nicht mehr geändert wird, wird bei erfolgreichen Absenden die ursprüngliche Session verloren - obwohl die Adresse eigentlich erfoglreich geprüft und gespeichert war.

Wieso soll das geändert werden

Aktuelle Lösung des erfolgsbasierten Abrechnens funktioniert so nicht korrekt.

Wie kann man das Problem reproduzieren

Eine Form so ausfüllen, das serverseitige Validation nicht bestanden wird. z.B. ein bereits eingesetzte E-Mail verwenden. Nach dem Absenden wird kein doAccounting gemacht und man kommt wieder auf die gleiche Seite um den Fehler in der Email zu beseitigen. Ist das erledigt kann die Form erfolgreich abgesendet werden, jedoch produziert das erneute Absenden kein doAccounting.

Lösung

doAccounting soll im Controller porduziert, sobald er die abgesendete Daten erhält, jedoch vor der Validation. Somit wird eine geprüfte Adresse abgerechnet. Falls ein Validationsfehler auftritt wird der User wahrscheinlich nichts mehr an der Adresse machen und somit entsteht kein extra doAccounting für den Shopbetreiber.

Aktuell markieren wir nicht gefundene Adressen mit orangenen Umrandung von Eingabeelementen. Das kann unauffällig oder nicht verständlich für den Käufer sein.

Das Modul soll so angepasst weren, dass bei einer nicht gefundenen Adresse ein Modal mit einem Hinweistext kommt und der Käufer direkt zum Bearbeiten der Adresse kommen kann. Der Käufer soll jedoch die Möglichkeit behalten seine ursprünglich Eingabe zu behalten. Diese Möglichkeit soll optisch weniger gewicht haben, als die Bearbeiten Möglichkeit.

$this->getPayment() can be null

Possible fix

if (('0000-00-00 00:00:00' === $oUser->oxuser__oxregister->rawValue)
    && ($payment = $this->getPayment())
    &&('oxidpaypal' === $payment->getId())
    && $bCheckExistingPayPalExpress
) {

Bei relativ langsamen Internetverbindung wird manchmal das Standardland gesetzt, obwohl ein Land davor schon ausgewählt war.

Das liegt daran, dass die Prüfung ob ein Land ausgewählt ist gegen AdressObject läuft und zeitlich vor dem Auslesen des Wertes in HTML Element geschieht. D.h. für die Standardland Prüfung ist kein Land gesetzt, obwohl dieser einige Millisekunden später gesetzt wird.

Aktuell zeigen wir das Korrekturmodal bei jeder Änderung der Adresse.

Es soll so sein, dass kleine und unwichtige Anpssungen automatisch übernommen werden. Zum Beispiel Groß-undKleinschreibung, Hinzufügen oder Entfernen von Strichen/Punkten, Normierung der Schreibweise.

Anlass

Aktuelle Lösung für die Anpassung der DB hat Performanceprobleme bei automatischen Buildsystemen, da dort angeblich bei jeder Änderung die Methode onActivate() augerufen wird.

Wieso ist das wichtig?

Jetzige Lösung verlangsamt ein Deploy-System.

Gewünschte Lösung

Ab 6.2.2 hat Oxid Migrationen. Es soll möglich sein das automatische Update der Datenbanken zu deaktivieren, damit man zukünftig diese Aufgabe mit Migrationen erledigen kann.
Die MIgrationen sowie eine Dokumentation dazu sollen im Modul mitgeliefert werden.