Mit dieser Erweiterung verkürzen Sie den Checkout im Shop auf eine Seite! Kasse, Versand und Bestellbestätigung zusammengefasst. Die Reihung der einzelnen Bereiche können im Adminbereich kompfortabel per Drag and Drop eingestellt werden. http://www.indiv-style.de/onepagececkout-fuer-gambio-gx2-ab-v2010-bis-v20142.html
So weit: PHP: -------------INSTALLATION:-------------1. Inhalt new_files in den Root kopieren.2. Die Datei install.ajax_checkout_process.php ausführen und danach löschen. Beispiel: http://www.IhreShopadresse.de/install.ajax_checkout_process.phpDamit werden die Datenbankerweiterungen vollzogen.3. Änderungen:in checkout_payment.php, checkout_confirmation.php, checkout_shipping.php, checkout_shipping_address.php, checkout_payment_address.phpnach:include ('includes/application_top.php');einfügen:if (CHECKOUT_AJAX_STAT == 'true') {xtc_redirect(xtc_href_link('checkout.php', '', 'SSL'));} nur die Änderungen in den 5 PHP-Files gehen noch nicht updatessicher! Aber da sich die gesuchte Zeile immer oben befindet, ist das schon fasst Idiotensicher.....
Auch das kann man updatesicher machen.... Indem man die "ApplicationTopExtender" überlädt... Und dort das aktive Skript überprüft, und wenn es eines der genannten ist, dort das "Redirect" macht..... Um das Ganze völlig updatesicher zu machen, sollte man die Funktionalität in die "checkout_ajax.php" verlagern, auf die man auch in dem neuen Overload "redirected"... Oder, noch besser: man macht das "redirect" in der ".htacces", dann wird das sofort gemacht, und die "application.top" muss nicht extra durchlaufen werden....
Das wieder so ne unsitte die htaccess für jeden Mist zu misbrauchen Gibt ja auch andere Webserver als den lahmen Apache
Was ist daran "Unsitte", was ist daran "Mist"??? Eine updatesichere Lösung ist sicher kein Mist, und wesentlich schneller als eine updatesichere Lösung durch Überladung ist das auch allemal.
Updatesicher aber eben NUR auf Apache Servern und auch NUR wenn der Serveradmin dir erlaubt alles in dieser UNTER-Konfigurationsdatei zu machen. Klar nen 301 und co. kannst bei fast allen Servern machen, aber nicht alles und die htaccess ist nicht gedacht um das Shopsystem anzupassen sondern um den Server zu konfigurieren. Die unsitte das für die website konfig zu nutzen hat sich halt eingebürgert. Aber was machen leute die keinen Apache als Webserver haben? Die schauen dann sofort in die Röhre und müssen erst mal Fehler suchen. Daher ist sowas keine saubere Lösung in meinen Augen da es nicht jeder nutzen kann.
Nicht zu vergessen: das "SEO-Boost"-Gedöns, ein wesentlicher GAMBIO-Bestandteil basiert auch auf "mod_rewrite"... Das ist keine Server-Konfigurierung, sondern ein bequemer Weg anwendungsunabhängig dem Programm gewünschte Funktionen zu verpassen. Wozu hätte man das sonst erfunden???
nginx z.b. kennt keine htaccess dateien sondern nur die Konfig dateien. Da mussten wir schon alle rewrites des seo boost und von steffens blog umschreiben damit das überhaupt lief. Hier hab ich das schon mal gepostet wie so ne konfig dann aussieht. (Link nur für registrierte Nutzer sichtbar.)
Also das fällt dann m.E. in die Kategorie "selbstverschuldetes Einzelschicksal" Und wer sich diesen Server selbst installiert wird auch wissen (müssen), wie das dann dort umzusetzen ist. Dem stehen aber Zillionen Shared-/Root-/Managed-Hosting-Anwender gegenüber, für die das prima passt.
tja dieses einzelschicksaal erlaubt uns aber nen echt flotten server zu betreiben und du glaubst gar nciht wie viele websites darauf laufen. WEIL das Teil einfach viel schlanker und schneller läuft. Nur mal so (Link nur für registrierte Nutzer sichtbar.) Das also nicht wenige oder? und insgesammt das heißt 35% sind für dich einzelschicksaale?
Wie gesagt, wer sich so einen Server selbst installiert wird auch wissen, wie das "mod_rewrite"-Zeugs umzusetzen ist. Muss er bei Gambio eh' wissen/machen wg. SEO-Boost. Aber die Vorteile dieser Lösung überwiegen m.E. doch so stark was Implementierung und Geschwindigkeit angeht, dass ich sie vorziehe. 5 weitere updatesichere Programme sind das allemal wert. Man kann ja alternativ auch die angesprochene Überladungslösung verwenden, die ja auch schnell gemacht ist (so in 5 Minuten).... Die hat halt den großen Nachteil, dass sie (wie auch die direkte Modifikation der 5 Programme) erst greift, wenn die "application_top" durchlaufen ist, die ja viele Module und das komplette Gambio-Framework (völlig unnütz) lädt... Und dann einen kompletten Server-Roundtrip macht, um die "checkout.php" zu laden. Über "mod-rewrite" wird derselbe Aufruf server-intern(!) einfach intern geändert....
Server hin oder her, ich habs bei uns in der .htaccess drin. Aber dann geht das dekativieren des OPC im Adminbereich nicht mehr. Ich weis nicht ob man diese Funktion nun unbedingt benötigt aber die htaccess-Lösung ist für mich die optimalere. Werde das mal in die Install aufnehmen.
Beim SEO-Boost muss man das ja auch separat in die htaccess aufnehmen.... Mit einer Anleitung schafft das sicher jeder...
Es gibt noch einen anderen Aspekt: mit dem "xtc_redirect" kann man keine POST-Variablen weiter leiten. Die werden ja evtl. aber benötigt.
Mhh. dat ist richtig! Gerade bei Zahlungsabbrüchen von BillSafe oder so, kommen ja die Error als GET mit! ABER schon in der ersten Version des OPC auf reifen24.de hatte ich das gelöst und sollte eigentlich im jetzigen funzen.... Auch mit den POST!
Wichtiger erscheint mir da die js aus dem Ordner /lib besser zu implementieren oder besser gesagt weg zu rationalisieren. Dat muss noch werden...
Wäre es nicht besser, den Text in "ajax_checkout_modal_message.php" als Content-Manager-Text zu definieren, und den dann mit PHP: <a class="lightbox_iframe" target="_blank" href="popup_content.php?lightbox_mode=1&coID=xxxxxx"> in einem Lightbox-Popup auszugeben?