$_POST ohne Inhalt im Bestellprozess

Wie im Titel beschrieben versuche ich in Schritt 4 (Bestellung prüfen und ggf. absenden) des Bestellprozesses, die $_POST-Daten aus Schritt 3 zu lesen. Allerdings erhalte ich einen leeren Array.

Wie kann das sein? Werden die Daten vorher abgefragt und anschließen gelöscht :confused:

[QUOTE=j0ker;33238]
Wie kann das sein? Werden die Daten vorher abgefragt und anschließen gelöscht :confused:[/QUOTE]
Keine Ahnung.

Man kommt aber trotzdem an die Werte.

oxConfig::getParam(‘parametername’);

Vielen Dank :slight_smile:

Habe das gleich versucht:

Mein Formular-Feld hat den Namen “dynvalue[Kartennummer]” (ein Input-Feld welches in der payment.tpl vorkommt und in der order.tpl ausgegeben werden soll). Also habe ich in order.tpl geschrieben [B]<?php echo oxConfig::getParam(‘dynvalue[Kartennummer]’); ?>[/B] und eine Fehlermeldung bekommen, dass ich vermutlich keine Zugriffsrechte habe. Also habe ich versucht das ganze als Modul zu basteln.

Die view/order.php wurde überladen mit

class MyTestClass extends MyTestClass_parent {
	
    protected $kartennummer = null;
	
    public function render()
    {
        parent::render();
        $this->kartennummer  = oxConfig::getParam('dynvalue[Kartennummer]');
        return $this->_sThisTemplate;
    }
}

Im Adminbereich wurde das Modul bekannt gegeben: [B]order =>testordner/mytestclass[/B]
Jetzt folgte die Fehlermeldung “[B]Fatal error: Call to undefined method oxConfig::getParam() in…[/B]”

Also habe ich im Adminbereich [B]oxorder =>testordner/mytestclass[/B] zusätzlich eingetragen.
Auch hier wieder eine Fehlermeldung "[B]Function ‘getDelAddressInfo’ does not exist or is not accessible! (mytestclass)[/B] ".

Ich wäre froh wenn ich das Oxid-System langsam mal verstehen lerne. Wenn man nach jedem Schritt ewig hängen bleibt geht einem irgendwann die Lust flöten :wink:

…zum mäuse melken!

Ups, mein Fehler.

oxConfig::getParameter(‘parametername’); ist richtig.

In Smarty schaltet man nach PHP anders.


[{php}]
//phpcode
[{/php}]

dynvalue[Kartennummer] ist ein Arrayelement. Du kannst aber nur das ganze Array bekommen.

[{php}]
print_r(oxConfig::getParameter('dynvalue'));
[{/php}]



> 
> Ich wäre froh wenn ich das Oxid-System langsam mal verstehen lerne. Wenn man nach jedem Schritt ewig hängen bleibt geht einem irgendwann die Lust flöten ;)

http://docu.oxid-esales.com/CE/sourcecodedocumentation/

GENIAL!

Vielen Dank :slight_smile:

Kommentar am Rande - php im template ausführen ist eine totsünde und das schlimmste was man überhaupt machen kann, dafür gibt es Module. Ich würde raten lies dir mal das neue Tutorial im Wiki durch.

[QUOTE=aggrosoft;33296]Kommentar am Rande - php im template ausführen ist eine totsünde und das schlimmste was man überhaupt machen kann, dafür gibt es Module. Ich würde raten lies dir mal das neue Tutorial im Wiki durch.[/QUOTE]
Warum soll das eine Todsünde sein??

Wer sagt das?

Mit welchem Recht?

Ich empfinde eher die Verwendung von zig Modulen als problematisch.

Da besteht die gute Chance, seinen Shop erfolgreich auf’s Kreuz zu legen.

Mit einem kleinen PHP-“Hook” an der richtigen Stelle kann man viele Probleme sehr einfach lösen, wofür man u.U. ziemlich aufwändige Modul-Programmierung betreiben muss.

Wenn ich alle die funktionellen Verbesserungen und Erweiterungen, die ich mittlerweile für OXID habe, als Module implementiert hätte, hätte ich sicher schon lange den Überblick verloren.

So hat man alles schön gesammelt an den Stellen, wo es wirken soll, und gut ist…

Natürlich soll man da keine langen Programme einbauen…

aber eine kleines

[{PHP}]include('my_extensions/my_extension.php')[{/PHP}]

in einer Template-Datei schadet sicher nicht.

Aber das muss jeder für sich entscheiden, wie er das handhaben will:

ob er wegen “der reinen Lehre” umständlich oder doch lieber effizient arbeiten will.

Diese Vorgehensweise hat einen anderen nicht zu unterschätzenden Vorteil:

Man hat innerhalb des Templates an einer Stelle Daten im Zugriff, die u.U. in verschiedenen Modulen entstehen, so dass man über eine Modulprogrammierung evtl. mehrere Module überladen müsste…

[QUOTE=avenger;33311]

[{PHP}]include('my_extensions/my_extension.php')[{/PHP}]

in einer Template-Datei schadet sicher nicht.
[/QUOTE]
Ist unelegant, Smarty kann das von sich aus besser.
http://www.smarty.net/manual/de/language.function.include.php.php

Aber wenn man unbedingt Funktionen braucht kann man diese auch mit /modules/functions.php einbinden.

… und trotzdem, nur um zu schauen, ob was im Template ankommt, benutzte ich [{php}]. Zum testen ein Modul oder Plugin oder Funktion zu definieren ist ein wenig übertrieben,

@Oxid: Bitte eine oxsmarty-Klasse einführen, die mit oxnew initiert wird, dann kann man diese überladen und eigene Plugin-Verzeichnisse definieren.

[QUOTE=avenger;33311]
Aber das muss jeder für sich entscheiden, wie er das handhaben will:

ob er wegen “der reinen Lehre” umständlich oder doch lieber effizient arbeiten will.[/QUOTE]

Was hat das denn bitte mit reiner Lehre zu tun, einen include zu verwenden der irgendeine PHP Datei anspricht die nicht mit dem Framework verzahnt ist führt sicher nicht immer zu mehr effizienz - und ein Modul als umständlich zu bezeichnen, naja … Wenn ich den Shop erweitern möchte dann sollte ich mich auch am Framework orientieren und nicht irgendetwas selbst gebackenes bauen, sonst sind wir ganz schnell wieder da wo wir mit xtc3 aufgehört hatten.

[QUOTE=aggrosoft;33322]Was hat das denn bitte mit reiner Lehre zu tun, einen include zu verwenden der irgendeine PHP Datei anspricht die nicht mit dem Framework verzahnt ist führt sicher nicht immer zu mehr effizienz - und ein Modul als umständlich zu bezeichnen, naja … Wenn ich den Shop erweitern möchte dann sollte ich mich auch am Framework orientieren und nicht irgendetwas selbst gebackenes bauen, sonst sind wir ganz schnell wieder da wo wir mit xtc3 aufgehört hatten.[/QUOTE]
Wieso sollte man da das Framework umgehen??

Man hat ja [B]alle [/B]Objekte wunderbar im Zugriff…

Ich muss sagen, dass viele Tutorials als “Newbie” nur schwer nachvollziehbar sind. Es gibt zu wenig Anlaufstellen bzw. gute, verständliche Tutorials, die auch gut beschrieben sind.

Somit bin ich dem Tip von Avenger dankbar und werde mir zukünftig besser überlegen mit welchem Shop-System ich meine Projekte umsetze.

[QUOTE=j0ker;34333]Ich muss sagen, dass viele Tutorials als “Newbie” nur schwer nachvollziehbar sind. Es gibt zu wenig Anlaufstellen bzw. gute, verständliche Tutorials, die auch gut beschrieben sind.
[/quote]
Die meisten Tuts stehen doch im Wiki.
Auch wenn die Jungens von der Wikipedia anderer Meinung sind, aber ein Wiki ist dafür da, dass man mit etwas schlechten Text anfängt und jemand anders dies nach und nach verbessert.

Also, wenn Du ein Tut abgearbeitet hast und Du der Meinung bist, dass einige Stellen nicht gut sind, verbessere diese, dann ist wenigstens den nächsten geholfen.
Aber nur beschweren, das würde mich als Tut-Ersteller davon abhalten zukünftig so etwas zu machen.

Das ist wohl wahr. Wenn ich etwas Zeit finde vermerke ich die kritischen Punkte!