Archive for 5. September 2015

Zumindest seit Shopware 5 reichen die in der Shopware Import-Dokumentation angegebenen Werte nicht mehr aus, um Artikelgewichte zu importieren oder zu aktualisieren (Stand Mitte 2016).

Wollt ihr eure Artikelgewichte / Produktgewichte aktualisieren, dann muss das Feld „tax“ für den Steuersatz des Artikel mit in der Importdatei enthalten sein, sonst läuft der Import in einen Fehler.

Also schnell den Steuersatz als Ganzzahlwert (int) hinzufügen und alles ist gut.  ;-)

NACHTRAG (Stand Januar 2017):

Die Shopware Doku ist grundlegend überarbeitet worden und nun gibt es auf dieser Seite (Import/Export) eine Minimalversion der möglichen Importdateien im XML

Wer in seinen Listing-Anzeigen in Shopware 5 die Topseller Reihe ausblenden möchte und bei Google danach sucht erhält in der Regel nur diesen Link (Topseller Widget im Kategorielisting optional ausblenden), der (mind.) seit Shopware 5 unnötig geworden ist.

Ein Klick im Backend, den Cache neu aufbauen lassen und alles ist gut.

Der Weg: Einstellungen -> Caches / Performance -> Reiter Einstellungen -> Unterordner Topseller -> Checkbox „Topseller im Shop anzeigen“ und schon werden keine Topseller mehr gezeigt.
Man findet dort auch noch einige nützliche Einstellungen zu Erstellung / Berechnung der Topseller.

Folgendes Fehlverhalten ist beim Bilderimport unter Shopware 5 festgestellt worden (Stand August 2015).

Der Shopware Bilderimport ist wirklich super dokumentiert (mag man denken).
Wenn es nur um Standardwerte bzgl. der Importfelder geht, dann ist da nicht viel falsch zu machen.

Problematisch wird es, wenn man einen Bilderimport mit Relationen von Artikelbildern zu verschiedenen Eigenschaften machen möchte z.B. unterschiedliche Farben. Funktioniert soweit problemlos, wenn die Farben „schwarz“, „rot“, „brau“ etc. heißen.
Interessant wird es schnell, wenn wir ein „grey/melange“ oder „summer green“ oder „attack-red“ bedienen wollen.

Ich habe wirklich immer Probleme bei der Notation bekommen, die

Hallo zusammen,

wer beim Shopware Artikel- oder eher noch Bilderimport vergeblich auf das Ende der „Ladebalken-Anzeige“ wartet, wartet wahrscheinlich vergebens. Wahrscheinlich wurde ein Fehler ausgegeben, den man im Backend nicht mitbekommt.
Den Fehler könnt ihr visualisieren, wenn ihr im Firefox (mit FireBug) auf der Konsole schaut. Meistens ist es ein Server Fehler und wird als ein falsch formatierter JSON-String ausgegeben.

Abhilfe können Conf-Einstellungen für FastCGI schaffen.

IdleTimeout 3600
ProcessLifeTime 7200
MaxProcessCount 64
DefaultMaxClassProcessCount 8
IPCConnectTimeout 300
IPCCommTimeout 7200
BusyTimeout 300

entweder unter

/etc/httpd/conf.d/fcgid.conf

oder

/etc/apache2/mods-enabled/fcgid.conf

(ggf. sind Wertename noch mit einem Prefix „Fcgid“ versehen)

Wen von Euch hat das nicht auch schon mal gestört? (Dich ganz bestimmt, sonst hättest Du es nicht gegoogelt und wärst nicht hier gelandet ;-) )

Man macht eine HTML-Mail fertig und testet das Layout auf verschiedenen Mailclients und viele glauben immer sie wären schlauer und wollen „nur“ helfen. Bei einer Telefonnummer kann das wirklich noch ganz nett sein, wenn man über tap auch direkt die Nummer anwählen kann, aber nicht jedes Datum soll ein Termin werden und nicht jede Adressangabe muss verlinkt werden.

Es werden unzählige Methoden im Netz genannt, wie

Wer TYPO3 per Installer auf einem Linux Webserver installiert, hat bestimmt schon die Fehlermeldungen im Schritt 1 gesehen. Zum einen stimmen upload_max_filesize und post_max_size nicht überein und zum anderen muss die max_execution_time etwas höher gesetzt werden (meist von 60 auf 240 Sekunden), in der php.ini oder im PLESK Backend lässt sich das gut machen.

upload_max_filesize=128M
post_max_size=128M
max_execution_time=240

Der andere Fehler besagt, dass das Root-Webverzeichnis zwar existiert, aber nicht beschreibbar sei.
Auch wenn der Benutzer und die Gruppe passen, bleibt der Fehler trotzdem noch.

Hier hilft (wobei sites/default dann das Webroot ist)

chmod a+w sites/default

Aber bitte am Ende

Wer es in Typoscript „verbockt“ hat, muss mitunter länger suchen, da es an unzähligen Stellen passiert sein kann. Aber selbst wer sich schön brav über Flexforms alles zusammenklickt und strickt logisch vorgeht, der landet fast gezwungenermaßen in diesem (offensichtlichen) Bug.

Wir haben ca. 3,5 Stunden in die erste Entwicklung mit anschließender Fehlersuche gesteckt, bevor ich diesen Artikel fand

http://www.npostnik.de/typo3/redirect-in-felogin-nach-anmeldung-funktioniert-nicht/comment-page-1/

und mit dem ich die Aufgabe dann in einer Viertelstunden abschließen konnte.

DANKE…. mehr will ich dazu nicht sagen.

Ideal für Einsteiger in die WordPress Entwicklung, hätte ich damals auch gern gehabt, und selbst jetzt ist es immer noch eine nette Referenz. Eine schnelle Übersicht über Funktionen, Standard WordPress-Dateien und deren Inhalte, Befehle rund um die Navigation und einiges mehr.

WordPress cheat sheet (PDF, 53KB)

Trotz korrektem Benutzernamen und Passwort lässt WordPress Euch nicht einloggen? Es kommt auch keine Fehlermeldung bzgl. falschem Benutzernamen oder Passwort? Cookies habt ihr schon gelöscht und den Browsercache auch? Query-String nach dem Redirect von wp-admin nach wp-login.php habt ihr auch schon gelöscht und erneut versucht (halte ich allerdings für Quatsch) und ihr kommt immer noch nicht ins Backend?

So ging es mir auch und dann habe ich den Tipp gefunden, dass man für einen neuen Versuch den Plugins-Ornder unter wp-content mal umbenennen soll, z.B. in „plugins_deactivated“.

Dann sollte es funktionieren und es

Wer den SVN Error E155021 in PHPStorm auf Mac OSX bekommt sollte auf jeden Fall mal diese Seite checken

http://andowebsit.es/blog/noteslog.com/post/how-to-upgrade-subversion-on-osx/

oder diese

http://blog.jetbrains.com/idea/2013/12/subversion-1-8-and-intellij-idea-13/

Wahrscheinlich funktioniert der svn-Client über die Konsole weiterhin, aber in PHPStorm eben nicht.
Der Fehler lässt sich recht schnell über die PHPStorm Einstellungen bzgl. der internen Nutzung der svn Binaries lösen.