duplizierter Testshop (Dauerbetrieb) mit Plugins?

[301Moved]

Gibt es mittlerweile eine gängige Möglichkeit, sich selbst dauerhaft einen Testshop bereit zu stellen? In dem dann auch Plugins etc laufen?

Testen, Template-Änderungen, etc möchte man natürlich ungerne im laufenden Betrieb machen und aufgrund der u.a. Anforderungen lässt sich das nicht alles auf einem JTL Testshop umsetzen.

Aktueller Hintergrund:
- laufender Shop: 3.20 soll auf 4.03 geupdatet werden und das möglichst vorher getestet auf dem derzeitigen Server
- Plugins sollen geändert / erweitert werden
- Template soll angepasst werden

 

[css-umsetzung]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Unterverzeichnis einrichten in dem webspace der domain /developeblabla
Htaccess schützen,
Shop duplikat hinein kopieren
Db duplizieren

Benutzen und testen

 

[boaa-group]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Das ist aber keine laufend aktuelle Kopie. Der richtige Setup erfordert je nach Kulanz der Pluginhersteller doppelte Lizenzen und ein bisschen mehr Arbeit.
Ausserdem darfst du nach dem Kopieren ins Unterverzeichnis nicht vergessen die includes/config.JTL- Shop.ini.php anzupassen und eventuell die rewritebase in der .htaccess

Wir haben...

dev.viverni.com als Test und Entwicklungsumgebung (Zugriff nur aus dem Firmennetz und meinem privaten Netz dank statischer IPs)
> in der Wawi einen Shop "Viverni - DEV" (eigentlich mehrere aber um's einfacher zu erklären sagen wir es wäre einer) > erfordert Multishopmodul für die Wawi
von dev.viverni.com werden Änderungen am Dateisystem (Shop/Template) in einer Git-Repository erfasst.
Änderungen an Einstellungen können über ein eigenes Plugin vom Testshop in den Live-Shop übertragen werden.
Wenn ein stabiler Zustand erreicht ist, wird das Ganze dann via Jenkins auf den Live-Server veröffentlicht.

Die Systeme unterscheiden sich quasi nur in der URL (dev.viverni und www.viverni) und sinst ansonsten 99% identisch und erlauben eine konstante Test- und Entwicklungsumgebung in der nahezu alles vorab immer getestet werden kann. Die Einschränkung des Zugriff's auf bestimmte IPs macht das Testen mancher Zahlungsarten unmöglich aber mit dem Nachteil muss man leben.

Beide Server sind bei Cloud9 als Workspace eingerichtet. Gearbeitet wird 99% nur am Testsystem und dann eben über Git > Jenkins veröffentlicht. Bei kleineren Problemen wird direkt über der produktive Cloud9 server bearbeitet um den Fehler zu beheben > die Lösung dann aber dennoch im Testsystem erfasst.

Zugriff auf die Server nur via SSH mit Keyfile, kein FTP usw... und auch die Zugriffe via SSH sind nur von bestimmten IPs bzw. über die Clou9 oberfläche möglich.

Feinheiten:
Am Testserver ist Minify abgedreht damit man schnell die CSS/JS Datei findet in der man etwas anpassen muss.
Beim Veröffentlichen der Änderungen wird am Server ein Mal ein eigenens Minify Skript ausgeführt, dass dann alle CSS/JS für Template und Plugins komprimiert und in eine neue Datei schreibt.

Gibt da noch paar andere Dinge die wir gemacht haben, sprengt aber ohnehin schon den Rahmen. In meinen Augen ist dies aber wohl der effizientes um ein sauberes Testsystem zu haben. Allerdings steigt dadurch auch der Aufwand in der Wawi ein wenig da eben in der Wawi auch zwei Shops existieren. Andererseits kann man so auch einzelne Artikel testweise gezielt für den Testshop mit anderen Preisen/Beschreibungen/Bildern ausstatten um zu sehen wie es sich auswirken würde.

 

[css-umsetzung]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

meine Praxis tut es perfekt, ihm geht es ja nur darum das er sein Shop in einem updaten und mit allen Plugins testen kann und er möchte ja nicht in die Live Tabelle schreiben, wäre ja auch übel.
Wenn die Plugins extra installiert werden müssen und sich nicht nach den vorgaben "pfaden" vom Shop richten, dann wäre das aus meiner Sicht ein fehlerhaftes Plugin.

Du musst auch zwischen develope und Shop besitzer unterscheiden, und selbst ich mache das so mit "allen" Systemen die ich Supporte, da ich ja immer mehrere Entwicklungen gleichzeitig habe und auf meinem Server entwickle.

Konfig anpassen ist ja klar.

 

[boaa-group]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Ja, deine Praxis reicht in vielen Fällen aus (hattest nur den Hinweis auf die config.php vergessen). Allerdings mMn verdienen die Leute mit den Shops ihr Geld und wer das ernsthaft und effektiv machen möchte kommt über kurz oder lang über einen Setup ähnlich zum von mir erwähnten nicht rum. Ist aber off Topic wollte nur ein umfangreichere Alternative aufzeigen.


Gesendet von iPad mit Tapatalk

 

[hula1499]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Bei uns ganz banal, simple und einfach:

.) eigene Domain fürn Klon + SSL
.) FTP Ordner kopiert
.) DB komplett kopiert
.) Klon natürlich ständig im Wartungsmodus und alles im Wartungsmodus ausgeblendet was geht
.) die "wichtigsten" Pluginhersteller angeschrieben und gefragt nach einer nicht auslaufenden "Devlizenz" -> mit dem Versprechen, die Seite nie online zu schalten (da wir nur sehr sehr wenig Plugins einsetzen (bewusst) war das nur 1 SP )

config und htaccess anpassen ist sowieso klar -> fertig.

Klon läuft somit vollkommen autark.


Warum nicht auf Subdomain oder Unterverzeichnis? Das Klonsystem soll so nah wie möglich ans Echtsystem rankommen, es gibt die kuriosesten Bugs mit JTL, lieber ein Versuch einer 1:1 Umgebung.

 

[css-umsetzung]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Der Vorteil, wenn man es in einem Unterverzeichnis, hat ist beispielsweise:

• das man dann kein zusätzliches SSL Zertifikat benötigt, klar es gibt nun Let's Encrypt aber auch das möchte je nach Umgebung ständig aktualisiert werden
• das man alle Plugins die man gekauft hat normal benutzen kann ohne nach extra Lizenzen zu fragen
• man in der Wawi kein Multishop Modul benötigt udn alles mit einer Lizenz abwickeln kann
• mit den richtigen htaccess Einstellungen, habe ich auch nicht das Problem, dass ich von der subdomain auf einmal im live System lande wenn ich links im content klicke, da ich ja immer in der richtigen Domain bin
• JTL und auch alle anderen vernünftig Programmierte Systeme kommen damit klar

Nachteile:

wenn man zwischen dem DEV und Live System hin und her springt sorgt die Session in verschiedenen cms (auch JTL) dafür das man z.B. immer das Menü des anderen Systems sieht, dass sollte man dann natürlich in unterschiedlichen Browsern machen, wenn man beide Seiten gleichzeitig anschauen muss, vermutlich ginge es auch über die Cookie Einstellungen zu regeln, die der Shop bietet aber das war mir bisher egal.

man sollte sich bewusst sein, dass man bevor man etwas löscht, sich vergewissert, im richtigen System zu sein, bei Live Systemen habe ich dann immer oben eine fixe farbige Box im header anhand derer ich sehe ob ich im DEV System bin.

-----------------------------------------------------

ich mache das seit Jahren so, habe bei verschiedenen Pluginanbietern, meine Entwicklungsumgebung (jeweiliges-cmsystem.meinserver.de) auf die whitelist setzen lassen und bearbeite dann die jeweiligen cms in Verzeichnissen, die den Namen der Webseite haben.

Das mache ich so mit contao, shopware, JTL und allem was es da so gibt, und das seit Jahren, ich habe lange probiert was der beste Weg ist und für mich war es genau dieser, weil ich damit alle Probleme mit Lizenzen ausschließen kann.

Wenn man einen Shopware Shop hat, dann hat man später locker 10 oder mehr gekaufte Lizenzen, sich da für jeden Kunden, mit den Pluginprogrammieren auseinanderzusetzen ist vom Aufwand einfach zu heftig.
Shopware selbst gibt eine Lizenz nach vielem Bitten befristet auf 10 Tage raus, das ist definitiv zu wenig.

Habe ich einen Shop und bin Einzelkämpfer, ist das was anderes aber wenn ich viele Webseiten betreue , muss ich sehen das ich den unkompliziertesten Weg gehe um auch die Kosten gering zu halten.
Einem Webseitenbesitzer der im Jahr 100000ende Umsatz macht ist das wohl egal, der kauft auch einfach mal alle Lizenzen doppelt aber der Großteil hier wird wohl nicht diese Umsätze generieren und eher versuchen sein Geld zusammen zu halten.

 

[hula1499]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Ich wollte jetzt deinen Weg gar nicht schlechtreden, du bist SP und wirst schon wissen was du machst. Nochdazu sind unsere beiden Anwendungen (wir ein/unserer Shop -> du diverse Kundenshops) und auch der technische Wissensstand ein ganz anderer (damit mein ich NICHT, dass meiner höher wäre ).

SSL ist nun wirklich kein Kostenfaktor: Let´s Encrypt oder der import eines eigenen 5 USD SSL Zerti mit Nutzung via SNI...
Plugins -> hast nat. recht - aber eben für die eigenen Shops hält sich der Aufwand doch sehr in Grenzen.

Der Nachteil bezüglich Session/ Cache ist einfach zu dramatisch. APC etc. ist NICHT nutzbar via subdomain/Verzeichnis. Testet man mit 2 Templates, hast ständig das Template vom andren Shop wahlweise drinnen.

Wir sind zwar kein Einzelkämpfer, haben auch 2 sehr fähige SP an der Seite, ich finde jedoch - für uns - ist wirklich diese autarke Kloninstallation das sinnvollste (wir betreuen ja nur unsere Shops ).

 

[301Moved]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Danke für euer vielfältiges Feedback!

Mir geht es tatsächlich darum - abgesehen vom Update auf Shop4 testen jetzt - dass man auch mal ein Plugin testet, ein paar Design-Korrekturen vornimmt, etc, um zu gucken, wie sich das auswirkt. Das möchte ich natürlich ungerne stetig im Live-Betrieb machen.

Das mit dem Unterverzeichnis klingt erstmal ganz sinnvoll, wenn das mit den Lizenzen von Shop/Plugins auch so hinhaut. Dafür n eigenen Browser zu verwenden ist ja an sich nicht das Problem... wenn es aber mit den Plugin-Herstellern und ner Dev-Lizenz läuft, dann wäre das vielleicht noch geschickter. Einmal die Shop-Lizenz dazu holen ist ja jetzt nicht das riesige Problem. Hmmmm

 

[ag-websolutions.de]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

dass man auch mal ein Plugin testet,

Das ist von Plugin-Hersteller zu Plugin-Hersteller verschieden.
Bei unseren Plugins kann du einerseits jedes Plugin auf ejder Domäne für 10 Tgae testen.
Wenn das nicht ausreicht, dann schalten wir gerne die Testphase auch länger frei.
Wenn es dauerhaft sein soll, dann sind wir auch gerne ebreit (sofern aus der URL ersichtlich ist, dass es sich um eine Test-URL handelt), ein Plugin dauerhaft frei zu schalten.

Einfach ein Ticket bei uns eröffnen und die Anforderung formulieren.

Wie gesagt, das gilt bei uns - andere Plugin-Hersteller arbeiten/entsheiden ggfls. auch anders.

 

[301Moved]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Ah cool, danke auch mal für das Feedback seitens Plugin-Hersteller

Ich kann auch total verstehen, wenn es da Bedenken gäbe, dass das ausgenützt würde. Sowas sollte nicht sein und ein fairer Umgang ist da mMn eh selbstverständlich.

Aber da hat ja auch jeder Nutzer andere Anforderungen. Ich finde die Idee eines "dauerhaften" Testshops gerade ganz gut und mal ein Plugin testen, dafür reicht natürlich eine beschränkte Testlizenz, aber ein "dupliziertes" System macht in vielerlei Hinsicht ja auch Sinn. Ich bin auf jeden Fall gerade schon mal ein Stück weiter.

 

[css-umsetzung]

AW: duplizierter Testshop (Dauerbetrieb) mit Plugins?

Die global Player werden alle die Möglichkeiten haben whitelisten zu führen oder einem Shopbesitzer das auch für den Testbereich dauerhaft zu aktivieren, bei den kleinen könnte das schon eher ein Problem sein und ein Plugin
das nicht die vom Shop vorgegebenen root und web Pfade nimmt würde ich eh nicht installieren, da es fehlerhaft ist

 

[301Moved]

Hallo allerseits,

ich hab es jetzt mit einer Subdomain und einem Unterverzeichnis probiert - dazu die Datenbank komplett dupliziert und die Daten per FTP hochgeladen. Aber bei beiden Varianten bekomme ich nur eine weiße Seite. Es kommt auch keine Fehlermeldung dazu. Die config...php hab ich angepasst auf neue Datenbank und den Verzeichnispfad.

Hab ich vielleicht etwas übersehen, das noch wichtig wäre? Vielleicht hat einer eine Idee Danke!

 

[css-umsetzung]

Templates_c im Admin und Hauptpfad löschen.
wenn es in einem Unterverzeichnis läuft, kann es je nach Webspace / Server sein das der Rewritebase in der .htaccess, um das Unterverzeichnis erweitert werden muss in der Kopie.

und dann tausche mal in der /includes/config.JTL-Shop.ini.php das hier

//enables printing of warnings/infos/errors for the shop frontend
    define('SHOP_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the dbeS sync
    define('SYNC_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the admin backend
    define('ADMIN_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the smarty templates
    define('SMARTY_LOG_LEVEL', 0);
    //excplicitly show/hide errors
    ini_set('display_errors', 0);

gegen das hier aus

$show_error=true;
if($show_error) {
    define('SHOP_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
    define('SYNC_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
    define('ADMIN_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
    define('SMARTY_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);
    ini_set('display_errors', 1);
} else {
    //enables printing of warnings/infos/errors for the shop frontend
    define('SHOP_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the dbeS sync
    define('SYNC_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the admin backend
    define('ADMIN_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the smarty templates
    define('SMARTY_LOG_LEVEL', 0);
    //excplicitly show/hide errors
    ini_set('display_errors', 0);
}

spaeter, wenn die Fehler behoben sind, machst du aus dem true dann einfach ein false

$show_error=true

 

[301Moved]

Also manchmal... braucht es einfach. Es war der php handler in der htaccess.

Danke aber dennoch!

 

[Marktwert]

Also manchmal... braucht es einfach. Es war der php handler in der htaccess.

Danke aber dennoch!

Hallo, was bedeutet "ES WAR DER PHP HANDLER IN DER .HTACCESS" und was tut man dagegen. ich habe das gleiche wie du gemacht und auch diese weise Seite.

 

[301Moved]

Du musst die richtige PHP-Version in der htaccess (oder im Backend deines Anbieters) anpassen...

 

[Marktwert]

die PHP-Version vom Produktivsystem und Testsystem ist gleich (habe von Produktiv nach Test kopiert) beim Provider.

in der htaccess steht nix von einer php version bei mir.
Wie müsste da der Eintrag aussehen.

Wenn ich diese Error-logs mache, zeigt er auch eine weiße Seite an, schreibt er diese logs in irgendein File?

 

[301Moved]

Ne, den musst du musst du eintragen, der steht da nicht drin. Oder eben alternativ im Backend deines Anbieteres (wenn es denn überhaupt diesen Punkt betrifft, aber das war das Problem bei mir)

Da suchst du dir vermutlich am besten eine Anleitung per Suchmaschine und dann natürlich die passende PHP-Version zur Shop-Version (dazu gibt es irgendwo ein Übersicht bei JTL) ... Suchbegriff: PHP Handler htaccess