Hallo, ich bin bei Profihost und wir haben bisher unsere Cronjobs mit /home/haupbenutzer/verzeichnis && /usr/local/php5.4/bin/php shopware.php /backend/cron per Shell aufgerufen. Seit 4.2 läuft dieser Aufruf so niicht mehr. Hat jemand ähnliche ERfahrungen und Lösungen? Danke
Gleiches Problem! aufrufen geht: /usr/local/php5.4/bin/php shopware.php /backend/cron Ergebnis: leere Ausgabe
Habe gerade erfahren, dass es ein generelles Problem ist. Shopware arbeitet mit Hochdruck daran.
sehe gerade an meinem Ticket, dass es auf die 4.2.1 zugeordnet wurde (http://jira.shopware.de?ticket=SW-7882) Ps: darf ich fragen woher Sie erfahren haben das es ein generelles Problem ist?
Hier die Antwort von Shopware: ---- Hallo Herr Elchlep, Es hat sich mittlerweile herausgestellt, dass es sich um ein generelles Problem in Shopware 4.2 handelt… Wir bitten Sie daher noch etwas Geduld zu zeigen, wir arbeiten derzeit mit Hochdruck daran eine Lösung für dieses Problem bereitzustellen. Inwiefern und in welcher Form diese bereitgestellt wird muss noch entschieden werden. ---- Ich erwarte eine sehr kurzfristige Löusng, da beim Cronjobaufruf über http:// der Datenaustausch mit Plentymarkets nicht funktioniert!!!
1 „Gefällt mir“
das ist bei uns auch der Fall, allerdings bei einem anderen Provider. Hoffe das hier schnell eine Lösung gefunden wird, da die Kommunikation mit Plentymarkets dadurch nicht mehr funktioniert
Hallo Zusammen. Wir haben das Problem gefunden und auch eine Lösung für euch parat 
Bitte ersetzt in der Datei /engine/Shopware/Kernel.php Zeile 160 die Methode transformSymfonyRequestToEnlightRequest() durch folgende Version: /\*\* \* @param SymfonyRequest $request \* @return EnlightRequest \*/ public function transformSymfonyRequestToEnlightRequest(SymfonyRequest $request) { // Overwrite superglobals with state of the SymfonyRequest $request-\>overrideGlobals(); // Create englight request from global state $enlightRequest = new EnlightRequest(); // Set commandline args as requesturi. // This is used for legacy cronjob routing e.g: // /usr/bin/php shopware.php /backend/cron if (is\_array($argv = $request-\>server-\>get('argv')) && isset($argv[1])) { $enlightRequest-\>setRequestUri($argv[1]); } return $enlightRequest; } Über eine kurze Rückmeldung ob die Probleme behoben sind würde ich mich freuen. Dieser Fix wird so, oder Ähnlich in wenigen Tagen in der SW 4.2.1 verfügbar sein. Viele Grüße, Benjamin Cremer :shopware:
3 „Gefällt mir“
Scheint zu funktionieren, zumindest sieht es im log danach aus 
muß das ganze von Zeile 156 bis 169: [quote] /** * @param SymfonyRequest $request * @return EnlightRequest */ public function transformSymfonyRequestToEnlightRequest(SymfonyRequest $request) { // Overwrite superglobals with state of the SymfonyRequest $request->overrideGlobals(); // Create englight request from global state $enlightRequest = new EnlightRequest(); return $enlightRequest; }[/quote] Mit der neuen Version überschrieben werden oder nur die Zeile 160?
Es muß vom Beginn Zeile 156 bis zum Anfang wo der nächste Kommentar beginnt alles ersetzt werden durch den neuen Quellcode. Müsste Zeile 169 sein, wo es endet.
Wenn ich das so ändere, kommt im Backend folgende Fehlermeldung: [quote] Modul: Shopware.apps - HTTP-Fehlermeldung: Not Found Pfad der Anforderung: /backend/ - HTTP-Statuscode: 404 / GET [/quote] Und das Backend lädt sich zu Tode.
Hallo Jox, kannst es es bitte einmal mit der folgenden Version der Methode versuchen: public function transformSymfonyRequestToEnlightRequest(SymfonyRequest $request) { // Overwrite superglobals with state of the SymfonyRequest $request-\>overrideGlobals(); // Create englight request from global state $enlightRequest = new EnlightRequest(); // Set commandline args as requesturi. // This is used for legacy cronjob routing e.g: // /usr/bin/php shopware.php /backend/cron if (PHP\_SAPI === 'cli' && is\_array($argv = $request-\>server-\>get('argv')) && isset($argv[1]) ) { $enlightRequest-\>setRequestUri($argv[1]); } return $enlightRequest; } Viele Grüße, Benjamin Cremer :shopware:
Bei mir laufen jetzt alle Cronjobs Fehlerfrei - Danke. Bei der Ergebnisausgabe kommt jedoch als erste Zeile: — [2014-02-06 17:55:02] debug.INFO: Deprecated Shopware()->Log() call. Message: backend — Was greift da noch auf die alte Version zurück?
Der cron Aufruf per CLI läuft jetzt durch. Jedoch sind bei uns jetzt alle Produktbilder “weg”, sprich die Bilder sind nicht mehr unter in der DB eingetragen Pfad vorhanden… Ist das jetzt ein shopware oder PlentyConnector BUG?
Das hatte ich schon mal im Dezember 2013. Dachte das ist zwischenzeitlich gelöst. Die unendliche Geschichte…
Hallo Benjamin, mit der neuen Version kommt keine Fehlermeldung mehr. Muß allerdings erwähnen, dass ich keine Probleme mit den Cronjobs hatte. Hatte einfach mal diesen Thread aufgegriffen und mit der ersten Version geändert. Und da kam dann diese Fehlermeldung. Habe jetzt trotzdem meine sämtlichen aktiven Cronjobs vorgezogen und mit der neuen Version getestet. Es gab keine Fehlermeldungen und die Cronjobs wurden alle erledigt.
Es muss was mit dem Update und fehlenden Rechten zutun haben, denke ich… hab etwas in nem anderen Post zum Thema Plentyconnector gefunden: allgemein-f25/shopware-plentymarkets-t15165-130.html?hilit=plenty%20bilder#p74683 [quote] oder daran das unser Server mittels PHP-CLI kein fopen konnte(bei uns Hetzner), obwohl dies in der PHP Config aktiviert ist. dazu muss man den cronjob wie folgt anpassen: cd /usr/home/“euer pfad”/ && php54 -d allow_url_fopen=On shopware.php /backend/cron Außerdem ist es wichtig, dass er nun die Artikel neu einließt, [/quote] fuktioniert jedoch leider auch NICHT! hat jemand eine IDEE?
[quote=“transpal”]Der cron Aufruf per CLI läuft jetzt durch. Jedoch sind bei uns jetzt alle Produktbilder “weg”, sprich die Bilder sind nicht mehr unter in der DB eingetragen Pfad vorhanden… Ist das jetzt ein shopware oder PlentyConnector BUG?[/quote] Bei mir das gleiche Theater: Bei jedem Syncdurchlauf fehlen mehr Bilder… Der Connector schreibt in die Datenbank s_artilces_img und löscht dann die Bilder auf Dateiebene! Es ist eine Unverschämtheit - das hatte ich schon im Dezember 2013! Wann wird das endlich mal?
Macht es doch in Zukunft so, wie es größere Firmen auch machen. Eine X.0 Version kommt grundsätzlich nicht in den Produktiveinsatz, es sei denn, man hat ein Heer an Testern und Regressionstest-Szenarien, die dem Einsatz der Software weiterhin Unbedenklichkeit bei zusätzlichem Nutzen bescheinigen. Meist ist es dann aber so, dass genau diese Tests dazu führen, dass die Hersteller die ersten Patches rausbringen. Shopware geht hier mit den Betas und Release-Candidates schon den richtigen Weg, indem sie alle an den Tests beteiligen und so noch Fehler zu Tage treten, die bei den eigenen Tests nicht auffallen. Wie ihr aber seht, ist keine komplexe Software, die größere Änderungen unter der Haube erfahren hat, vor Fehlern gefeit. Hier tummeln sich viele ganz kleine Firmen, die zum Nulltarif oder für wenig Geld eine perfekt funktionierende Software erwarten, in die aber eine Firma wie Shopware viel Geld stecken muss, bis sie fertig ist. Die Vorteile nimmt man gerne mit, die Fehler werden nicht nur aufgezeigt, sondern geradezu angeprangert. Zitat Vorredner: “Unverschämtheit” usw. Schaltet doch einfach mal eurer Hirn ein und testet die Software selbst auf Eure Belange, bevor ihr sie in eurem Live-Shop zum Einsatz bringt. Natürlich nerven Fehler, aber doch hoffentlich nur euch im Test und keine Kunden im Livebetrieb. Es gibt gute Gründe, warum man die 4.2 in naher Zukunft testen sollte. Wenn ich mir aber Jira angucke, gibt es für den Ottonormalshopbeteiber kaum Gründe, in den kommenden Wochen auf die 4.2 im Livebetrieb zu wechseln.
[quote=“Lutz Elchlep”][quote=“transpal”]Der cron Aufruf per CLI läuft jetzt durch. Jedoch sind bei uns jetzt alle Produktbilder “weg”, sprich die Bilder sind nicht mehr unter in der DB eingetragen Pfad vorhanden… Ist das jetzt ein shopware oder PlentyConnector BUG?[/quote] Bei mir das gleiche Theater: Bei jedem Syncdurchlauf fehlen mehr Bilder… Der Connector schreibt in die Datenbank s_artilces_img und löscht dann die Bilder auf Dateiebene! Es ist eine Unverschämtheit - das hatte ich schon im Dezember 2013! Wann wird das endlich mal?[/quote] Das ist soweit ich das sehe eher ein Plenty Bug, ist bei mir auch so, aber nur bei den Artikeln die neu von Plenty an Shopware übertragen wurden. Meine Schnittstelle läuft mittlerweile überhaupt nicht mehr weil die Datenintegrität nicht stimmt, bereinigen lässt sie sich aber auch nicht. Ein Ticket an Plenty ist erfolglos, ist Open Source kümmer dich selber ist dann die Antwort die kommen wird, oder nimm dir eine Zertifizierte Agentur, falls überhaupt geantwortet wird. Was die Agentur dann da machen soll, wenn die Schnittstelle einen bug hat ist mir schleierhaft, so war übrigens auch die Aussage einer Agentur der ich das Problem geschildert habe. Wir haben leider den Fehler gemacht und den “Werbeversprechen” der Firmen zu glauben, eigentlich hätte man es besser wissen müssen.