Wer kann ein vorhandenes Plugin untersuchen und einen Fehler finden ?

Shopware 5 Programmierung
1

Hallo,

folgendes Problem. Ich habe Artikel mit teilweise 200 Varianten. Ich habe schon alle Plugins gekauft / getestet, welche es für die Darstellung der Varianten auf der Detailseite gibt.

Leider waren fast alle angebotenen Plugins mangelhaft. Ich habe nur 1 Plugin welches mir sehr zusagt. Allerdings gibt es hier ein Problem. Artikel mit mehr als 50 Varianten laden dann ca. 8 Sekunden oder es kommt gar ein Fehler 505 wegen zu langer Wartezeit.

Ich habe den Hersteller des Plugins kontaktiert, er meinte damals mein Webhosting Paket sei zu schwach. Ich müsse die max_execution_time höher stellen, was ja eigentlich ohne Sinn ist. Das Problem ist ja nicht behoben, wenn ich dem Server noch mehr Zeit gebe eine Seite zu laden. 

Jetzt wo ich auf einen eigenen Managed Server bei All-Inkl. gewechselt habe funktioniert es aber immer noch nicht. Ich habe alle Einstellungen vorgenommen um den Shop schnell wie möglich zu machen und genug Power Reserven zu haben, aber wenn ich das Plugin aktiviere lädt es einfach ewig.

Ich gehe eher davon aus das es einen Fehler in seinem Plugin Code gibt. Kann jemand das Plugin checken, wenn ich es zusende ? Ich bezahle das natürlich auch.

2

Das Plugin hat mich 150€ gekostet. Mir wäre es nochmal 150€ wert, wenn jemand den Fehler findet.

3

Hallo,

der Hersteller wird da aber leider auch nicht Unrecht haben, da Server-Fehlermeldungen (wie 503-Fehlermeldungen) meist eben auch vom Server und nicht vom Plugin kommen und eben auch an zu niedrigen Server-Ressourcen liegen. Man kann sich aber durch die Shopware - Debug - Parameter (in der config.php - Datei) die „richtige“ Fehlermeldung hinter der Servermeldung ansehen: Debugging Shopware . Meist kommt dann aber die Meldung, das entweder die selbst gesetzte max_exection_time (maximale Skriptausführungszeit) des Servers überschritten wurde oder das memory_limit (Arbeitsspeicher) des Servers nicht ausreicht. Beides sind aber serverseitige Sachen und keine Plugin-Fehler (die Standard max_execution_time ist so und so sehr niedrig von Shopware gesetzt worden).

Da du sicher nicht der einzigste Käufer des Plugins bist und es bei allen anderen ja zu funktionieren scheint, wird es wohl (wie vom Hersteller erwähnt) an deiner Infrastruktur liegen. Hast du einfach einmal alle anderen Plugins außer dieses deaktiviert und es dann getestet? Jedes Frontend - Plugin muss natürlich auch „kompiliert“ werden, da können die Serverwerte schnell überschritten werden, wenn zuviele Plugins im Einsatz sind - gerade bei Shared Hostern.

Beste Grüße

Sebastian

1 „Gefällt mir“
4

Hallo,

erstmal vielen Dank für die ausführliche Antwort. Ich weiss es sehr zu schätzen.

Die Einstellungen sind bei mir wie folgt:

   php_value memory_limit 1024M
   php_value max_execution_time 60
   php_value upload_max_filesize 20M
   php_flag phar.readonly off
   php_flag magic_quotes_gpc off
   php_flag session.auto_start off
   php_flag suhosin.session.cryptua off
   php_flag zend.ze1_compatibility_mode off

 

Wie gesagt ich habe jetzt auch einen eigenen Managed Server den nur ich benutze. Deswegen weiss ich leider nicht warum da dann Power fehlen sollte. Ich habe aber von der Materie jetzt auch nicht die Mega Ahnung. Vielleicht liegt es ja auch nur an einer Servereinstellung.

 

5

Andere Plugins hatte ich alle mal deaktiviert, aber es hat nichts gebracht. 

6

hier mal meine komplette htaccess:



RewriteEngine on

RewriteCond %{HTTPS} !=on

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

#RewriteBase /shopware/

Https config for the backend

#RewriteCond %{HTTPS} !=on
#RewriteRule backend/(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteRule shopware.dll shopware.php
RewriteRule files/documents/.* engine [NC,L]
RewriteRule backend/media/(.*) media/$1 [NC,L]

RewriteCond %{REQUEST_URI} !(/(engine|files|templates|themes|web)/)
RewriteCond %{REQUEST_URI} !(/media/(archive|banner|image|music|pdf|unknown|video)/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ shopware.php [PT,L,QSA]

Fix missing authorization-header on fast_cgi installations

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]



# Block access to VCS directories

RedirectMatch 404 /\.(svn|git|hg|bzr|cvs)(/|$)

    # Restrict access to root folder files
    RedirectMatch 404 /(composer.(json|lock)|README.md|UPGRADE.md)$

Staging environment

#SetEnvIf Host „staging.test.shopware.in“ SHOPWARE_ENV=staging

Development environment

#SetEnvIf Host „dev.shopware.in“ SHOPWARE_ENV=dev
#SetEnv SHOPWARE_ENV dev

DirectoryIndex index.html
DirectoryIndex index.php
DirectoryIndex shopware.php

Disables download of configuration



# Deny all requests from Apache 2.4+.



Require all denied

    # Deny all requests from Apache 2.0-2.2.
   

Deny from all

Enable gzip compression



AddOutputFilterByType DEFLATE text/html text/xml text/plain text/css text/javascript application/javascript application/json





ExpiresActive on

ExpiresDefault „access plus 1 month“

   

Header append Cache-Control „public“

Header unset ETag

    FileETag None

Match generated files like:

1429684458_t22_s1.css

1429684458_t22_s1.js





Header set Cache-Control „max-age=31536000, public“

   

ExpiresActive on

ExpiresDefault „access plus 1 year“

Disables auto directory index



Options -Indexes



Options -MultiViews



php_value memory_limit 1024M

php_value max_execution_time 60

php_value upload_max_filesize 20M

php_flag phar.readonly off

php_flag magic_quotes_gpc off

php_flag session.auto_start off

php_flag suhosin.session.cryptua off

php_flag zend.ze1_compatibility_mode off

  AddType x-mapp-php7 .php

  AddHandler x-mapp-php7 .php



Header append X-Frame-Options SAMEORIGIN



mod_gzip_on Yes

mod_gzip_dechunk Yes

mod_gzip_item_include file .(html?|txt|css|js|php|pl)<br> mod_gzip_item_include handler ^cgi-script

mod_gzip_item_include mime ^text/.

mod_gzip_item_include mime ^application/x-javascript.

mod_gzip_item_exclude mime ^image/.*

mod_gzip_item_exclude rspheader ^Content-Encoding:.gzip.



AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/rss+xml

AddOutputFilterByType DEFLATE application/javascript

AddOutputFilterByType DEFLATE application/x-javascript


 

7

Hallo @jokerzeroneuss‍ . Das kann in der Tat an schlecht Programmierten Plugins liegen, test allerdings mal noch eine Sache: Verändere den Lagerbestand dieser Varianten auf 1 und die maximale Kaufzahl links neben „in den Warenkorb“ auf ca 10. Ändert sich hier die Geschwindigkeit? 

1 „Gefällt mir“
8

@brettvormkopp‍ krass :slight_smile: also ich kann die lagerbestände bei den artikeln nicht ändern sonst habe ich tage lange arbeit :slight_smile:

ich habe aber zum glück einen alten artikel aktivieren können. dieser hat ca. 150 varianten. ich habe den lagerbestand für alle varianten auf 1 gestellt und in den artikeleinstellungen die maximale abnahmemenge auf 10 gestellt. der artikel lädt tatsächlich jetzt innerhalb von 3 - 4 sekunden. es scheint also wirklich in die richtung zu gehen.

 

9

@jokerzeroneuss schrieb:

@brettvormkopp‍ krass :) also ich kann die lagerbestände bei den artikeln nicht ändern sonst habe ich tage lange arbeit :)

ich habe aber zum glück einen alten artikel aktivieren können. dieser hat ca. 150 varianten. ich habe den lagerbestand für alle varianten auf 1 gestellt und in den artikeleinstellungen die maximale abnahmemenge auf 10 gestellt. der artikel lädt tatsächlich jetzt innerhalb von 3 - 4 sekunden. es scheint also wirklich in die richtung zu gehen.

Hallo,

das Bestellmengen - Auswahlfeld von Shopware ist auch sehr „ressourcenfressend“ (da es in dem Sinne kein Select - Feld ist, sondern reines HTML), deshalb gibt es einige Plugins im Shopware Store, die dieses durch beispielsweise ein Eingabefeld ersetzen. Vielleicht kannst du so weiterhin große Mengen anbieten, aber die Geschwindigkeit etwas verbessern.

Beste Grüße

Sebastian

1 „Gefällt mir“
10

ja das war jetzt auch mein Gedanke. Ich habe Bestellmenge als Dropdown und in den Grundeinstellungen unter Artikeldetails Auswahlmenge 50 angegeben, damit der Kunde per Dropdown 50 Stück auswählen kann. 

Ich sehe aber gerade das das Varianten Plugin eigene Bestellmenge Pulldowns verwendet, da jede Variante direkt in den Warenkorb geschoben werden kann. Diese gehen bis 100 Stück.

Allerdings ist auch immer noch beim Hauptartikel selber der Pulldown mit der Bestellmenge aktiv. Quasi kann man den Artikel direkt mit Mengenauswahl in den Warenkorb verschieben und darunter sind dann auch nochmal die ganzen Varianten in einer Liste, auch nochmal jeweils mit Bestellmengenauswahl als Pulldown mit Warenkorbfunktion.

Es sei denn ich änder halt wie von @brettvormkopp‍ vorgeschlagen die maximale Abnahme z.B. auf 10 Stück, dann scheint es zumindest schon fast doppelt so schnell zu laden wie vorher.

 

11

1186×903 92 KB

12

Hallo,

naja wenn du dir einmal das Auswahlfeld in einem Konsolenprogramm deiner Wahl ansiehst wirst du sehen, wieviel HTML für jeden einzelnen Auswahlwert erzeugt wird. Rechne das dann mal je Variante und Auswahlfeld und du siehst, wieviel HTML da zusätzlich generiert werden muss. Das ganze braucht dann natürlich verständlicherweise entsprechende Ressourcen und Zeit.

Beste Grüße

Sebastian

1 „Gefällt mir“
13

@brettvormkopp‍ dein erster Tip hatte ja direkt funktioniert. Hast Du eine Idee woran es jetzt liegen könnte ? Oder was ich noch tun kann ?

14

Das liegt an der Menge des Quellcodes. Wenn du 3 Zeilen pro Einheit rechnest, hast du bei einem Artikel 150 Zeilen. Bei 150 Varianten hast du dann 150*150 Zeilen Quellcode. Da steigt dann einfach der Browser aus.

Wie Sebastian schon schrieb, müsstest du die Dropdowns durch Eingabefelder erstezen.

1 „Gefällt mir“
15

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍ ich hatte jetzt so ein plugin für das manuelle mengeneingabefeld gekauft und installiert. Leider ersetzt es nur das Mengen Dropdown Feld im Hauptartikel, das Plugin nutzt ja die eigenen Dropdown Menge bis 50. Ändern lässt sich das in der Plugin Konfig nicht. 

Das Problem an der ganzen Sache ist auch das der Hersteller ja sagt das es bei allen anderen Kunden einwandfrei und schnell funktioniert, wohl auch bei mehreren hundert Varianten.

@brettvormkopp‍ hatte ja schon den richtigen Lösungsansatz. Die Frage ist nur wie ich den Fehler letztendlich behebe. 

16

@jokerzeroneuss schrieb:

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍ ich hatte jetzt so ein plugin für das manuelle mengeneingabefeld gekauft und installiert. Leider ersetzt es nur das Mengen Dropdown Feld im Hauptartikel, das Plugin nutzt ja die eigenen Dropdown Menge bis 50. Ändern lässt sich das in der Plugin Konfig nicht. 

Das Problem an der ganzen Sache ist auch das der Hersteller ja sagt das es bei allen anderen Kunden einwandfrei und schnell funktioniert, wohl auch bei mehreren hundert Varianten.

@brettvormkopp‍ hatte ja schon den richtigen Lösungsansatz. Die Frage ist nur wie ich den Fehler letztendlich behebe. 

Hallo,

prinzipiell kannst du ja einfach den Code des Mengeneingabefeldes an die Stelle kopieren, wo das Auswahlfeld für die Varianten steht. Das dürfte, soweit von den Plugin-Herstellern vorgesehen und gewollt, auch updatesicher möglich sein. Im Standard kann das Plugin für das Mengeneingabefeld die anderen Auswahlfelder ja gar nicht kennen und somit ersetzen, wenn es nicht vom gleichen Hersteller ist oder zu dem Plugin kompatibel gemacht wurde.

Beste Grüße

Sebastian

1 „Gefällt mir“
17

gerade auch mit All-inkl. gesprochen, an der Serverleistung liegt es auf jeden Fall nicht.

was mir noch einfällt: Ich hatte damals bei Shopware 4 ein Variantenplugin das war echt top. Es hat den Artikel fast ganz ohne verlängerte Wartezeit geladen. Leider war dieses seit Shopware 5 nicht mehr verfügbar. Damals hatte ich auch noch ein Webhosting Paket.

18

das komische ist ja wirklich (wie von @brettvormkopp‍ angenommen) das ich den lagerbestand bei allen varianten auf 1 stelle und die maximalabnahme auf 6, das das schon die ladezeit mindestens halbiert hat. ich kann es halt nur bei dem testartikel machen. bei den anderen artikeln würde es ewig dauern die lagerbestände wieder alle einzugeben.

19

Also, es liegt nicht nur an der Darstellung im Frontend. Diese jquery fancy select ist zwar echt ultra der abturn, aber alleinig darin liegt es nicht. Es liegt auch entweder am plugin oder wie auch immer die Varianten durchgezählt werden, wir hatten ein ähnliches Problem vor zwei Jahren gehabt. Ich kann mich nur nicht mehr an die Lösung erinnern.

1 „Gefällt mir“
20

@brettvormkopp‍ trotzdem schonmal vielen Dank. Ich beschäftige mich jetzt schon Ewigkeiten mit dem Thema und habe überall gefragt. Ich brauche so ein Variantenplugin unbedingt und bin auch langsam am Ende weil ich alle Plugins ausprobiert habe. Dein Tip war auf jeden Fall schonmal der größte Fortschritt um den Fehler zu finden.