Beiträge von paulchen

ja. danke für den anstoss

die länge der img-alt-texte wird unter varchar in den tabellen products_images und products_description eingestellt. die habe ich vorerst auf 254 verlängert.

nun gilt es nur noch, die anzeige des alt-textes im zoom zu verhindern und alles ist bestens.

den alternativen text (img alt="text"), welchen man in die produktbilder (u.a.) einfügen kann wird leider ab einer gewissen länge abgeschnitten.
hat hier einer eine ahnung, wo die entsprechende einstellung dazu lauert?

beste grüße

klar. auf jeden fall!

ich habe mal die komplettversion 2.0.11 getestet. diese scheint sehr geschmeidig zu funktionieren. prima!

da adoDB nun wieder entfernt wurde, funktioniert der shop auch wieder völligst reibungslos mit fastcgi und apc.
vielleicht kann man sich IRGENDWANN, bei sehr großen shops, auf mysql-pdo und innodb einigen? es läuft ja eh alles auf mysql.

in diesem zusammenhang:
wie läuft das denn nun weiter mit commerce-seo? wird das projekt an dieser stelle "sterben"? gibt es dann noch entwickler?

läßt sich das modul trotzdem installieren?

Zitat von admin

FP11 behebt den Fehler, den Du beschreibst. Mit den versankosten, hast Du im Modul auch Steuer eingestellt?

*kopfkratz* nein. war mein fehler sorry.

Zitat von jotest

Dies ist der Beitrag, der gerade geschrieben wurde:
***************
Haben das Problem gefunden (nur mit PHP5.3):
Suche in Datei admin/module_export.php:

Code:
---------
if (substr($key,'FILE') !== false)
$file=$value;
---------
Ersetze mit:

Code:
---------
if (strpos($key,'FILE') !== false) $file=$value;

Alles anzeigen

ok. habe es eingefügt und seo-url läuft nun fehlerfrei durch. danke!

funktioniert deine ssl-verschlüsselung?
hast du ein eigenes ssl-zertifikat?

welcher hoster? welches paket?

scheint nun zu funktionieren. aus irgend einem grund waren die paypal-api-daten nicht mehr im backend.
also alles nochmal einhämmern.

es ist btw. egal, ob man paypal-express wählt oder die normale paypal-kaufabwicklung. bei beiden erscheint die gleiche meldung.

in version 2.0.10 funktioniert paypal-normal sowie express ebenfalls nicht.

aktiviert man paypal im backend zur installation erscheint:

Zitat

Deprecated: Function mysql_list_tables() is deprecated in /pages/12/cd/d0007174/home/htdocs/111_testshop/includes/modules/payment/paypal.php on line 268

Deprecated: Function mysql_list_tables() is deprecated in /pages/12/cd/d0007174/home/htdocs/111_testshop/includes/modules/payment/paypal.php on line 280

Warning: Cannot modify header information - headers already sent by (output started at /pages/12/cd/d0007174/home/htdocs/111_testshop/includes/modules/payment/paypal.php:268) in /pages/12/cd/d0007174/home/htdocs/111_testshop/admin/includes/functions/general.php on line 130

irgendetwas mit der php-version 5.3.5?
wird denn mit adoDB die datenbank noch derart angesprochen?

also wieder auf fp7 downgraden?

mmh ... sch**** jetzt wo du es schreibst. bei mir ist das auch der fall. dabei nutzen das die leute sehr gerne. jetzt haben wir schon märz ... aiweia

Zitat

PayPal Express steht zur Zeit leider nicht zur Verfügung.
Bitte wählen Sie eine andere Zahlungsart
oder versuchen Sie es später noch einmal.
Danke für Ihr Verständnis.

ok. support hats gerichtet.
lt. auskunft läuft der shop nicht mit php im fast-cgi modus und/oder apc. php läuft nun im cgi-modus.
einiges ist noch nicht so ganz nachvollziehbar. da muss ich noch mal nachhaken.

die aktivierung der seo-url bringt fehler bzw warnungen auf weißer seite:

Zitat

Warning: substr() expects parameter 2 to be long, string given in /pages/12/cd/d0006853/home/htdocs/testshop/admin/module_export.php on line 48

Warning: substr() expects parameter 2 to be long, string given in /pages/12/cd/d0006853/home/htdocs/testshop/admin/module_export.php on line 48

Warning: substr() expects parameter 2 to be long, string given in /pages/12/cd/d0006853/home/htdocs/testshop/admin/module_export.php on line 48

Warning: substr() expects parameter 2 to be long, string given in /pages/12/cd/d0006853/home/htdocs/testshop/admin/module_export.php on line 48

Warning: Cannot modify header information - headers already sent by (output started at /pages/12/cd/d0006853/home/htdocs/testshop/admin/module_export.php:48) in /pages/12/cd/d0006853/home/htdocs/testshop/admin/includes/functions/general.php on line 130

es scheint aber trotzdem zu funktionieren.

bestellung ändern funktioniert.
bei änderung der versandkosten, werden diese jedoch bei der USt NICHT berücksichtigt!

ich warte erstmal auf fixpack 11 und teste das dann wieder in einer testumgebung.

gibt es denn die spalte "bc.categories_id" in deiner datenbank?

wo wird der shop gehostet?
php-modus und version?

all-inkl + ssl-proxy tuts nicht. wurde im forum schon etliche male durchgekaut.

ist hier nicht so. dann deaktiviere levenshtein erstmal.

der märz-bug ist meines wissens im quickfix 10.1

anhand der bug-nummer KÖNNTE man schauen, woher dieser kam. dazu fehlt jedoch die berechtigung.

nach aussage des teams gab es einen 4-wöchigen beta-test.

der cache ist IMMER aktiv. auch wenn du ihn deaktiviert hast.

ich würde das mit einem shell-script lösen:

aus einer datenbank-tabelle die zuweisungen alter-bildname -> neuer bildname extrahieren.

dann jeweils vorher ein "mv" einfügen (in tabellenkalkulation ö.ä.). dabei entstehen zeilen nach folgendem schema:
1.zelle: mv 2.zelle: alter bildname 3.zelle: neuer bildname (bildnamen wegen google am besten mit bindestrich anstand unterstrich formatieren) etc.

dann als text abspeichern (dateien-umbennen.sh). darin steht dann
mv product_1.jpg neuer-bildname1.jpg
mv product_2.jpg neuer-bildname2.jpg
etc.pp

das dann als auf einer unix-/linux-shell in eine ordner-KOPIE(!!) des bild-ordners packen, ausführbar machen (chmod 7xx)
./dateien-umbennen.sh
fertig.

das geht sicher auch bedeutend eleganter

die umstellung der dateinamen in der datenbank wird wieder in der tabellenkalkulation vorgenommen und als csv-file importiert.

hi datenknecht,
ich kann deine verwirrung verstehen. die im fixpack enthaltenen änderungen kannst du hier einsehen: http://bugtracker.commerce-seo.de/changelog_page.php

zur moderation: für grundlegende und im forum mehrfach redundante sachen brauchen sich die entwickler eigentlich nicht kümmern - es sei denn, sie haben mal langeweile oder wollen einfach nur freundlich sein. dafür gibt es dann die community. plötzliche fehler wie z.b. der märz-bug werden meist sehr zeitnah behoben, bzw. tipps gegeben, wie diese behoben werden können. das ist natürlich nur mein persönlicher eindruck.

der fp10 ist, meiner laienhaften meinung nach, ein sehr ehrgeiziges projekt, welches auch inhalt eines major-updates hätte sein können. aber vielleicht war es workflow-technisch einfach sinnvoller die änderungen eben jetzt anzubringen.

ja. scheinbar liegts am server. support ist aktiviert. mal sehen, was dabei herauskommt

der fixpack ist einfach zu heftig

wobei ich dem support auch nicht verübeln könnte, wenn die nadel im heuhaufen nicht gefunden wird.

in xt-commerce war adoDB auch schon drin, oder?

hi jotest,
habe das nochmal wie oben beschrieben getestet. keine änderung (funktioniert nicht).

das einspielen von 2.0.10 full + quickfix würde demzufolge reichen.

bei mir läuft der shop (natürlich ohne rewrite) übrigens auch ohne .htaccess