CONTENIDO Forum

Hallo,

ich denke, ich bin auf einen Bug gestoßen, den es in der 4.9.3 nicht gab, in der 4.9.6 aber vorhanden ist.

Für meine Lightbox-Gallery bearbeite ich ein Bild mehrfach mit cApiImgScale.
Je nach Erfordernissen wird es im ersten Durchlauf verkleinert, dann ggf. durch erneutes Aufrufen mit cApiImgScale beschnitten.

Ist das Urdateiformat nun png und der Schalter für "keep file type" steht auf "true", dann schlägt die zweite Bearbeitung fehl und liefert keine Werte mehr. Die erste Bearbeitung liefert brav eine Datei in cms/cache/ mit der Endung png, aber diese wird dann offensichtlich nicht mehr korrekt weiter bearbeitet!
Stelle ich den Schalter für "keep file type" auf "false" und erwzinge damit als erstes Ergebnis eine JPG, dann klappt auch die Folgebearbeitung.

In der 4.9.3 hat das DEFINITIV noch mit PNG und "true" funktioniert, sonst hätte ich die Seite so gar nicht online gehen lassen können...

Könnt Ihr mal reinschauen?

EDIT: Der Bug lässt sich beheben, wenn man die Datei /contenido/includes/functions.api.images.php durch die Version aus CON 4.9.7 ersetzt. Dann läuft alles wie gehabt.

Kannst Du mir zum Testen Deinen Code mal an frederic.schneider@4fb.de zusenden? Dann schaue ich mir gerne an, ob/wo eine Fehlfunktion im CONTENIDO-Core vorliegt

Kurze Zusammenfassung nach Mailverkehr mit Frederic: In der Entwicklerversion 4.9.8 sei der Fehler nicht vorhanden. Ich selbst habe aber auch keine 4.9.7 zum Testen, da diese für mich aufgrund einiger Bugs derzeit für eine produktive Umgebung nicht einsetzbar ist.

Mein Fazig: Die cApiImgScale in der 4.9.6 spinnt, wenn das Ausgangsmaterial eine png ist und man den Dateityp beim Umwandeln behalten will.

Nimm ein Bild, weise es $image10 zu und lass es durch diese Routine laufen; hier sind nur die ersten Parameter für die Funktion gesetzt, und dadurch ist keepFileType = true. Das bringt jetzt Probleme mit sich, offensichtlich bei allen png als Ausgangsmaterial, egal ob transparent oder nicht :

Code: Alles auswählen

    $filesource   = str_replace($cfgClient[$client]["upl"]["htmlpath"], "", $imageSource10);
	$fileresized  = cApiImgScale($filesource, $rWidth, $rHeight, false, false) ; 
	$fileresized  = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $fileresized);
	$filecropped  = cApiImgScale($fileresized, $cWidth, $cHeight, true, true) ; 
    $filecropped  = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $filecropped);
	$filepopup    = cApiImgScale($filesource, $pWidth, $pHeight, false, false) ; print "x".$filecropped; 
	$filepopup    = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $filepopup);

Erweitert man die Funktionsaufrufe, insbesondere um den letzten Parameter "false" am Ende von cApiImgScale, dann funktioniert alles korrekt. Allerdings gehen dann natürlich ggf. Transparenzen der PNG verloren.

Code: Alles auswählen

    $filesource   = str_replace($cfgClient[$client]["upl"]["htmlpath"], "", $imageSource10);
	$fileresized  = cApiImgScale($filesource, $rWidth, $rHeight, false, false, 10, true, 75, false) ; 
	$fileresized  = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $fileresized);
	$filecropped  = cApiImgScale($fileresized, $cWidth, $cHeight, true, true, 10, true, 75, false) ; 
    $filecropped  = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $filecropped);
	$filepopup    = cApiImgScale($filesource, $pWidth, $pHeight, false, false, 10, true, 75, false) ; print "x".$filecropped; 
	$filepopup    = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $filepopup);

Schönen Abend homtata,
da ich heute mal in Leselaune bin

Wenn das eure wirklich eure Testreihe war, kann ich nur sagen elementarer Basic-Fehler.

Das gute, das Problem ganz einfach zu lösen.
Fehler sollte generell auch bei .jpg auftreten. Schon mal gefragt warum es immer genau beim 2. Schritt abbricht? Bei einem Core-Bug hätte es wahrscheinlich schon durch Zufall mal den 3. erreichen müssen.

Fehler liegt an:

Code: Alles auswählen

$fileresized  = str_replace($cfgClient[$client]["path"]["htmlpath"], "", $fileresized);

Siehe API: @param string $sImg Path to upload image
str_replace macht wohl oder übel das was es soll den htmlpath durch "" ersetzen.

somit wird aus dem PATH nur "image/xxx.png"

Im 2. Bearbeitungsschritt fehlt somit also die Source...
Kleiner Trost: Alle weiteren Schritte würden übrigens durchlaufen, da $cfgClient[$client]["upl"]["htmlpath"] im dann neunen String nicht mehr gefunden(ergo nicht ersetzt) werden kann.

(getestet unter 4.9.7)
Hier noch ein Fix erstelltest Testmodul:

Code: Alles auswählen

<?php

/**
 * description: Testmodul -->Base@standard image
 *
 */

defined('CON_FRAMEWORK') || die('Illegal call: Missing framework initialization - request aborted.');
$imageSource = "CMS_IMG[1]";
$imageDescription = "CMS_IMGDESCR[1]";
if (cRegistry::isBackendEditMode()) {
    $imageEditor = "CMS_IMGEDITOR[1]";
}
if (0 < strlen($imageSource)) {
    $clientConfig = cRegistry::getClientConfig(cRegistry::getClientId());
    $filename = str_replace($clientConfig["upl"]["htmlpath"], $clientConfig["upl"]["path"], $imageSource);
    list($imageWidth, $imageHeight) = getimagesize($filename);
    $image = new stdClass();
    $image->src = $imageSource;
    $image->alt = $imageDescription;
    $image->width = $imageWidth;
    $image->height = $imageHeight;
} else {
    $image = NULL;
}
if (cRegistry::isBackendEditMode()) {
    $label = mi18n("LABEL_IMAGE");
} else {
    $label = NULL;
}

//Edit Start -->
$fileresized = $image->src;
$filesource   = str_replace($cfgClient[$client]["upl"]["htmlpath"], "", $fileresized);
echo '<br/>Richtig: '.$fileresized.'<br/>Falsch: '.$filesource.'<br/>';

for ($i=0; $i<=2; $i++) { 
	$imageWidth = $imageWidth/2;
	$imageHeight  = $imageHeight/2;
   
   $fileresized  = cApiImgScale($filesource, $imageWidth, $imageHeight, false, false) ;
	echo '<img src='.$fileresized.'/>'.'<br/>'.$fileresized.'<br/>';
}
//Edit <-- End
?>

Wenns dennoch Probleme geben sollte kannst du mich auch gerne anschreiben.

Beste Grüße,
Benjamin

Hallo Benjamin,

danke für deine Ausführungen, aber sie helfen leider nicht.

- Wie ich geschrieben hatte, ist der Fehler unter 4.9.6 da (unter 4.9.3 war er definitiv NICHT da, da hab ich das nämlich genauso im Einsatz). Dies mit einem Test in 4.9.7 zu vergleichen, hilft mir leider nicht.
- WÄRE es ein Pfadproblem, dann würde die gepostete Alternative mit den erweiterten Funktionsaufrufen um die 4 zusätzlichen Parameter nicht funktionieren. Und ich HABE es intensiv getestet für verschiedene Dateitypen, und Fakt ist: Ist das Quellbild ein JPG, funkionieren alle Aufrufe in der kurzen Form, wie sie das schon immer tun. Bei PNG tuts hingegen nicht.
- Die von dir ersetzten Pfade sind in meinem Fall Käse. Im ersten Schritt wird das Bild nur verkleinert. Das produziert ein Bild im Ordner /cache.. also NICHT im upload-Ordner. Das Cache-Bild wird danach weiter bearbeitet und beschnitten. Ich kenne noch keinen Weg, das Bild in EINEM Rutsch sowohl zu skalieren wie auch zu beschneiden. Warum sollte ich also den html-Pfad durch den Upload-Pfad ersetzen, wo das Bild gar nicht liegt?

Alle Tests in der 4.9.6 zeigen: es IST ein Bug im Umgang mit PNG als Quelldatei. Alle meine Bildergalerien, die in allen Versionen bis 4.9.5 im Einsatz waren, scheitern lediglich an den PNG-Dateien, nicht an reinen JPG-Dateien.

LG
Viktor

Hallo,
ja leider kann ich nur einen Test unter 4.9.7 bieten und hab auch keinen vergleich zur 4.9.3
...für mehrfache Schritte ist der Cache (Temporär) gedacht! Benutze bitte mal mein oben eingefügtes Modul und vergleiche die echo Ausgaben der Urls
Die Pfade kannst du selber bestimmen wenn du dem Modul eine Source zuweist. Kannst ihn gerne an deine Bedürfnisse anpassen oder einfach die Logik übernehmen.

Du wirst über die die Funktion cApiImgScale, auf dem aktuellen Stand, niemals ein Cache-File im upload-Ordner erzeugen. Dazu genügt ein Blick in die Php-Core:
RETURN wirt immer ein $webFile = $frontendURL . 'cache/' . $cfileName; sein!!!
Mit deinem str_replace in der Stapelverarbeitung wirst du auch weiter deinen String abschneiden und nach dem 1. Durchlauf stranden...lass es einfach weg

Code: Alles auswählen

// http://php.net/manual/de/function.str-replace.php
// Liefert: <body text='schwarz'>
$bodytag = str_replace("%body%", "schwarz", "<body text='%body%'>");

Es spielt keine rolle ob ohne oder extra Parametern - Ergebnis ist das gleiche!
Nur für dich auf Basis des vorigen Postes. - Alles vor der Schleife.

Code: Alles auswählen

$fileresized = $image->src;
$filesource   = str_replace($cfgClient[$client]["upl"]["htmlpath"], "", $fileresized);
echo '<br/>Richtig: '.$fileresized.'<br/>Falsch: '.$filesource.'<br/>';

   $fileresized  = cApiImgScale($filesource, $imageWidth, $imageHeight, false, false, 10, true, 75, true) ; 
   $filecropped  = cApiImgScale($fileresized, $imageWidthh, $imageHeight, true, true, 10, true, 75, true) ; 
   $filepopup    = cApiImgScale($filesource, $imageWidth, $imageHeight, false, false, 10, true, 75, false) ; echo "x".$filecropped;

Warum sollte ich also den html-Pfad durch den Upload-Pfad ersetzen, wo das Bild gar nicht liegt?---> Nach der ersten Bildbearbeitungsfunktion liegt dein Bild nur noch im Cache $cfgClient[$client]['cache']['path'], sonnst nirgends...das original haste noch im upload aber das interessiert nicht.

Wie das ganze unter 4.9.3 mit dem Code laufen soll ist mir ein Rätzel?! - sonnst bleibt immer noch nen Update auf 4.9.7

Grüße

Benjamin,

bitte hör auf, zu diesem Thema zu posten. Weder hast du meine Posts korrekt durchgelesen/verstanden, noch hast du meine Quellcodes (die ich stundenlang durch Ausgabe der Pfade überprüft habe) selbst in 4.9.6 ausprobiert, noch ist es hilfreich zu behaupten, Dinge "dürften nicht gehen" oder "hätten nie gehen dürfen" oder "müssen zwingend im zweiten Durchlauf abbrechen", wenn sie das nachweislich nicht tun. Das alles hinterlässt den Eindruck, als würde etwas in der Programmierung nicht stimmen, obwohl dies (auch von Frederic bestätigt) nicht das Problem ist - es liegt definitiv ein Fehler in der PNG-Bearbeitungsroutine vor, und ich wollte das lediglich dokumentieren.

Die str_replace-Befehle sind übrigens schon immer unumgänglich.
Szenario wie in meinem Codebeispiel: ich möchte ein Bild erst verkleinern, dann beschneiden.

- Nach dem ersten Durchlauf wird ein Bild in /cache erzeugt (hatte ich ja auch so geschrieben, wenn du das richtig lesen magst), allerdings kommt der Pfad aus der Umwandlung mit dem vollen HTML-Pfad, also ist das Ergebnis der Verkleinerung: http://www.domain.de/cms/cache/wilderbildername.typ
- Diese absoluten Namen kann man NICHT direkt in die nächste cApiImgScale schicken, zuvor ist das erneute str_replace nötig, damit als relativer Pfad übrig bleibt: cache/wilderbildername.typ

Ich mach das ja jetzt auch nicht erst seit gestern.
Also bitte jetzt nicht mehr antworten, sondern das einfach so stehen lassen, damit die Menschheit weiß, dass speziell in der 4.9.6 cApiImgScale beim Einsatz von PNG vorübergehend spezielle Dinge zu berücksichtigen sind. Getestet. Bestätigt. Ist leider so.

Viktor

Gelöst:

Wie im ersten Post ergänzt, ist folgende Datei mit der Version aus CON 4.9.7 zu ersetzen, dann läuft auch die PNG-Umwandlung wieder korrekt:

/contenido/includes/functions.api.images.php

CONTENIDO Forum

[BUG 4.9.6] GELÖST: cApiImgScale und png

[BUG 4.9.6] GELÖST: cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] cApiImgScale und png

Re: [BUG 4.9.6] GELÖST: cApiImgScale und png