Hallo,
laut des Datenbankschemas der Version 4.3.2 Revision 27884 enthält die Tabelle oxarticles immernoch die Felder OXZOOM1 bis OXZOOM4. Diese sind aber in einer neu installierten Version nicht mehr in der Datenbank vorhanden.
Weiß jemand an welcher Stelle die Informationen über die Zoombilder jetzt gehalten werden?
Vielen Dank und viele Grüße,
Michael Schröck
Zoombilder gibt es nicht mehr.
Es gibt Master-Bilder, aus denen die Bilder berechnet werden.
Aber bei der Installation der Demo-Shopartikel gibt es z.B. die Kuyichi Jeans Mick
(Art.Nr.: 0802-85-823), welche 3 “normale” Bilder und 4 Zoombilder besitzt 
Hi,
ich hab kein zoom aber zoomactive und im Update gibts ausserdem den !!Cleaner!!
// cleaning oxzoom fields
if ( isset( $oArticle->{"oxarticles__oxzoom".$iIndex} ) ) {
$oArticle->{"oxarticles__oxzoom".$iIndex} = new oxField();
}
So long
tvtotal
Gibt es noch mehr Info’s zu diesem Beitrag?
Wie kann man denn Zoombilder händisch bzw. über den Import einbinden ?
Das ja merkwürdig gelöst worden ? Ich versteh irgendwie die Logik nicht wirklich.
Vorher habe ich die Bilder in der DB zugeordnet und gut is.
Lösungsansatz wenn man mit dem Import arbeitet:
Wenn man _p.jpg’s in der db zugeordnet hat, kann man den masterordner mit seinen Zoompics füllen (Bezeichnung muss ebenfalls mit _p.jpg erfolgen).
Gibt es noch mehr Info’s zu diesem Beitrag?
Wie kann man denn Zoombilder händisch bzw. über den Import einbinden ?
Da würd ich mir auch noch ein paar mehr Infos wünschen. Wir wollen auf die selbst erstellten Zoombilder nicht verzichten. Das Berechnen aus Masterbildern kommt für uns nicht in Frage, da der Shop bei der Bildberechnung nicht ansatzweise die Qualität hinbekommt die wir mit unserem Bildbearbeitungsprogramm erreichen.
Hallo,
hier sind nun Informationen zu dieser Thematik verfügbar (Englisch):
Sieht für mich recht schlüssig aus. Wird noch mehr benötigt?
Gruß
Hallo Marco,
was soll denn dieses Gimmick sein ? Der vorgeschlagene Austausch ist doch bei jedem Bild möglich, welches sich in einem Ordner befindet.
Grüße
Cutty
Hi Cutty,
[QUOTE=rubbercut;33675]was soll denn dieses Gimmick sein ? Der vorgeschlagene Austausch ist doch bei jedem Bild möglich, welches sich in einem Ordner befindet.[/QUOTE]
Kannst Du bitte etwas konkreter werden?
Danke und Gruß
Hallo Marco,
ich verstehe das unter "Now we will have a look at the picture upload without generate " so, dass man zuerst eine 12 in oxpicsgenerated eintragen muss (und das per Hand z.B. über phpmyadmin). Dann lädt man das Masterpic hoch, woraus im Falle einer eingetragenen 12 keine Bilder generiert werden.
Danach lädt man die anderen Bildchen per FTP hoch, die den vorgegebenen Namen und die Endung haben müssen, damit das System sie erkennt.
Wo ist der Vorteil gegenüber der normalen Generierung von Bildern (1-7). die dann auch per FTP ersetzt werden können?
Grüße
Cutty
Das Tutorial ist gut gemacht - und mit dem Eintrag der ‘12’ (kann man per Update fix über alle Artikel machen) sollte das Problem gelöst sein. Werde es mal testen wenn unser Shop auf 4.3x geht!
Bei mir funktioniert das mit der 12 nicht. Egal, ich hab`s eh anders gelöst.
Bei mir funktioniert das mit der 12 nicht. Egal, ich hab`s eh anders gelöst.
Würde mich interessieren: wie hast Du es gelöst?
Wir können auf unsere händisch erzeugten Zoompics leider auch nicht verzichten!
Ich habe es so gemacht, dass Zooms und Pics getrennt voneinander anzulegen und anzuzeigen sind.
Kannst Du im Demoshop sehen.
Ich erinnere mich nicht mehr in welchem PHP file dieser bug
https://bugs.oxid-esales.com/view.php?id=1807
“ge-fixed” war (laut svn info, nicht in oxpicturehandler, aber vielleicht oxarticles ?), aber ich kann nur sagen, dass das den ganzen zoom-picture-creation / deletion process erheblich beeinflusst hat, besonders, wenn du das bei einem Artikel mehrmals durchlaufen laesst. Ob das immer noch Einfluss hat auf oxarticle rows mit bilder uploads von 4.3.0 oder 4.3.1, weiss ich nicht.
Ein anderes Beispiel ist dieses Tutorial, das ebenfalls meiner Meinung nach mit 4.3.0 oder 4.3.1 bei wiederholten Artikel Bilder uploads nicht funktioniert haette. (siehe unten bei "public function genpics():
$oxph = oxPictureHandler::getInstance();
$oxph->deleteArticleMasterPicture( $oArticle, 1, false );
$oxph->generateArticlePictures( $oArticle, 1 );")
Ich habe fast die gleiche Funktionalitaet fur meine eigene picture upload/creation/deletion class im April entwickeln muessen, um genau diesen bug zu vermeiden.
CPJ
Habe die neue Funktion OXPICSGENRATED in Version 4.3.2 ausgiebig getestet und gestern das Tutorial Nr.12 dazu in Deutsch hochgeladen: http://wiki.oxidforge.org/Tutorials/de
Ja, ich stimme zu - es funktioniert in 4.3.2 aber nicht in 4.3.1 / 4.3.0
Meine Screen-Shots im Tutorial #12 stammen aus Version 4.3.1_27257 und 4.3.2_27884 habe ich auch getestet. Kein Unterschied: OXPICSGENERATED funktioniert in beiden Versionen einwandfrei.
HINWEIS: Es werden standardmässig nur max. 7 Master-Bilder autom. verarbeitet und Nr.8 bis 12 bleiben unberücksichtigt. Selbst wenn man in den Master-Ordnern 8-12 Bilder ablegt und deren Dateinamen in der Datenbank einträgt, passiert damit nichts. Wenn man in der DB manuell einen Wert einträgt, funktioniert auch die autom. Bilderzeugen bis zu diesem Wert nicht mehr, weil das Programm natürlich davon ausgeht, dass diese Bilder schon generiert sind. Also bei OXPICSGENERATED nichts manuell ändern.
S O R R Y, aber das stimmt nicht. Bsp: Wenn ich bei einem Artikel zunächst [B]nur[/B] das Pic 7 lade und später Pic 5, so werden auch bei 5 die Bilder generiert.
Hallo,
es gibt da noch einige Fehler (zumindest beim Shopupdate auf 4.32). Vielleicht möchte mal jemand versuchen, ein Bild mit der Endung _p1.jpg als Produktbild hochzuladen. Bei uns wird bei der Endung kein Icon generiert.
Grüße
Cutty