Hi
can anybody give me some hints how i can realize a 2 column layout with contentpart images?
is it possible to rewrite a template file, so that every 2nd image has another style or something else?
I've tried to write an own RT, but i can't find in the database the image, there is only in tab article_content the image description in field article_form.
Hallo,
ich benötige ein 2spaltiges Layout für den Contenpart Images, habt Ihr dazu eine Idee? Leider kann ich nicht HTML/Wysiwig nehmen, da die späteren User kein HTML können.
Kann man ein Template File so stricken, das z.B. bei jedem 2ten Bild ein anderes Layout genommen wird?
Ich habe schon probiert mir einen eigen RT zu schreiben, allerdings finde ich in der DB nirgendswo das dazugehörige Image.
regards randy
Contentpart Image 2 Column Layout
Hast du die Version 1.2.5-DEV...
dieses Problem mit den Bildern trat bei der alen Version immer dann auf, wenn du das selbe Bild, zum Testen, mehrfach eingegeben hattest..
In der neuen Version klappt das allerings mit der mehrspaltigen Anordnung einwandfrei!
http://peperkorn-online.de/bilderreihen.phtml
dieses Problem mit den Bildern trat bei der alen Version immer dann auf, wenn du das selbe Bild, zum Testen, mehrfach eingegeben hattest..
In der neuen Version klappt das allerings mit der mehrspaltigen Anordnung einwandfrei!
http://peperkorn-online.de/bilderreihen.phtml
nö, benutze 1.25, allerdings tritt der effekt, den du auf deiner website schilderst nicht auf.
ist allerdings auch egal, trotzdem vielen dank für deine bemühungen, ich mußte auf das orginal bild verlinken und nicht auf eine kleingerechnete kopie und habe mir deshalb einen rt geschrieben, der das jetzt für mich macht. (sowohl 2 spalten, also auch link auf orginal bild)
da die website größtmöglich barrierefrei sein soll, konnte ich auch keine tabellen nehmen, bzw. nur wenige.
ist allerdings auch egal, trotzdem vielen dank für deine bemühungen, ich mußte auf das orginal bild verlinken und nicht auf eine kleingerechnete kopie und habe mir deshalb einen rt geschrieben, der das jetzt für mich macht. (sowohl 2 spalten, also auch link auf orginal bild)
da die website größtmöglich barrierefrei sein soll, konnte ich auch keine tabellen nehmen, bzw. nur wenige.
regards rasta
Okay, ich benötige ein zweispaltiges Design mit Ausgabe von Thumbnails zur besseren Übersicht, bei Klick auf das Thumbnail soll das Original Bild geöffnet werden, diese sind für Printzwecke gedacht und können entweder eine hohe ppi-Zahl haben, oder eine riesige Breite, da die gd-lib ein paar Schwierigkeiten hat (mit so hohen Werten), sind die Bilder i.d.R auf 1024 px (in der Breite beschränkt haben dafür aber dann ein Auflösung von 200ppi) . Die Bilder haben alle unterschiedliche Breiten und Höhen und es kommt hinzu, das die Personen, die den Content pflegen, es so einfach wie möglich haben, d.h. u.a. kein HTML.
Wenn ich unter dem Contentpart Bilder keine def. max Breite eingebe, dann zerschießt es mir das Layout, gebe ich bei Klick vergrößern an, dann kommt immer die Standardeinstellung von 538, das ist wie oben schon erwähnt allerdings für den Druckbereich nicht ausreichend. Erst wenn ich a) eine hohe Breite angebe, kann die Druckerei ggf. auf 304ppi raufrechnen und dabei das Bild verkleinern, oder ich gebe gleich eine hohe ppi-Zahl an.
Oben drein, soll die Website möglichst barrierefrei sein, sprich Tabellen sind nicht erwünscht, es soll neben dem alt-Tag noch der title-tag ausgegeben werden, hinzu kommt es soll XHTML sein. Daher habe ich mir folgende RT geschrieben, nicht schön, aber ich muss nächste Woche fertig sein, und daher reicht es.
Wenn jemand mag, so kann er weitere Features (z.B. Paginierung) einbauen, oder sonstiges damit machen, evtl. Fehler bereinigen. Der Code basiert z.T. auf Leistungen anderer Leute, u.a. das sei hier nur der Vollständigkeit halber erwähnt, u.a. deshalb, weil ich erst seit 14 Tagen mich mit phpwcms ernsthaft auseinander setze.
Falls es eine Lsg. gibt, die den Tag nicht benötigt (da er beim nächsten Update, ja wieder eingespielt werden muss) her damit.
Vielleicht hast Du ja noch eine Idee.
Wenn ich unter dem Contentpart Bilder keine def. max Breite eingebe, dann zerschießt es mir das Layout, gebe ich bei Klick vergrößern an, dann kommt immer die Standardeinstellung von 538, das ist wie oben schon erwähnt allerdings für den Druckbereich nicht ausreichend. Erst wenn ich a) eine hohe Breite angebe, kann die Druckerei ggf. auf 304ppi raufrechnen und dabei das Bild verkleinern, oder ich gebe gleich eine hohe ppi-Zahl an.
Oben drein, soll die Website möglichst barrierefrei sein, sprich Tabellen sind nicht erwünscht, es soll neben dem alt-Tag noch der title-tag ausgegeben werden, hinzu kommt es soll XHTML sein. Daher habe ich mir folgende RT geschrieben, nicht schön, aber ich muss nächste Woche fertig sein, und daher reicht es.
Code: Select all
function show_gallery($id,$db)
{
$CNT_TMP = '';
$template_default = $GLOBALS["template_default"];
// print_r($template_default);
$sql = "SELECT * " .
"FROM " . DB_PREPEND . "phpwcms_articlecontent " .
"INNER JOIN " . DB_PREPEND . "phpwcms_article ON " . DB_PREPEND . "phpwcms_article.article_id = " . DB_PREPEND . "phpwcms_articlecontent.acontent_aid " .
"WHERE acontent_aid = " . $id . " " .
"AND acontent_visible = 1 " .
"AND acontent_trash = 0 " .
"AND " . DB_PREPEND . "phpwcms_article.article_deleted=0 AND ".DB_PREPEND."phpwcms_article.article_begin < NOW() " .
"AND " . DB_PREPEND . "phpwcms_article.article_end > NOW() ".
"ORDER BY acontent_sorting, acontent_id";
if($cresult = mysql_query($sql, $db) or die("error retrieving article from database"))
{
$i=0;
$CNT_TMP .= '<div style="width: 400px;">';
while($crow = mysql_fetch_array($cresult))
{
//TITLE
//$CNT_TMP .= $crow['article_title'];
// Space before
if($crow["acontent_before"])
{
$CNT_TMP .= '<div style="margin:' . $crow["acontent_before"] . 'px 0 0 0; padding:0 0 0 0; clear:both;"></div>';
}
//include content part code section
if($crow['acontent_type'] == 0)
{
include("include/inc_front/content/cnt" . $crow["acontent_type"] . ".article.inc.php");
}
if($crow['acontent_type'] == 2)
{
$aImage = unserialize($crow['acontent_form']);
$aThumb_Image = get_cached_image(array(
"target_ext" => $aImage['images'][0][3],
"image_name" => $aImage['images'][0][2].'.'.$crow['acontent_form']['images'][0][3],
"max_width" => $aImage['images'][0][4],
"max_height" => $aImage['images'][0][5],
"thumb_name" => md5($aImage['images'][0][2].$aImage['images'][0][4].$aImage['images'][0][5].$GLOBALS['phpwcms']['sharpen_level'])));
/*$zoominfo = get_cached_image(array(
"target_ext"=>$aImage['images'][0][3],
"image_name"=>$aImage['images'][0][2].'.'.$crow['acontent_form']['images'][0][3],
"max_width"=>$GLOBAL['phpwcms']['img_prev_width'],
"max_height"=>$GLOBAL['phpwcms']['img_prev_height'],
"thumb_name"=>md5($aImage['images'][0][2].$GLOBAL['phpwcms']['img_prev_width'].$GLOBAL['phpwcms']['img_prev_height'].$GLOBALS['phpwcms']['sharpen_level'])));
*/
if($aThumb_Image != false)
{
//Der Hash wird mit microtime verschlüsselt daher dieses
$sql = "SELECT * FROM ".DB_PREPEND ."phpwcms_file Where f_name='".$aImage['images'][0][1]."'";
if($result = mysql_query($sql,$db) or die("error db/sql"))
{
if($row = mysql_fetch_array($result))
{
$sHash_Normal_Image = $row['f_hash'];
$sExt_Normal_Image = $row['f_ext'];
$sNormal_Image = $sHash_Normal_Image.".".$sExt_Normal_Image;
$sFSize = fsizelong($row['f_size']);
}
mysql_free_result($result);
}
$sThumb_Img = '<a href="'.PHPWCMS_FILES.$sNormal_Image.'" target="_blank">';
$sThumb_Img .='<img src="'.PHPWCMS_IMAGES.$aThumb_Image['0'].'" alt="'.$aImage['images'][0][6].'" title="'.$aImage['images'][0][6].'" border="0"'.$aThumb_Image[3].' /></a>';
if($i%2<>0)
{
$CNT_TMP .= '<div style="float:right; width:200px;"><p>'.$sThumb_Img.'<br />';
$CNT_TMP .= $aImage['images'][0][6].'<br />'.$sFSize.'</p></div>';
} else {
$CNT_TMP .= '<div style="width:200px;"><p>'.$sThumb_Img.'<br />';
$CNT_TMP .= $aImage['images'][0][6].'<br />'.$sFSize.'</p></div>';
$CNT_TMP .= '<div style="clear:both;height:1px;font-size:1px;border:0px none;background:transparent;"> </div>';
}
}
}
//check if top link should be shown
if($crow["acontent_top"])
{
if($template_default["article"]["top_sign_before"].$template_default["article"]["top_sign_after"])
{
$CNT_TMP .= $template_default["article"]["top_sign_before"];
$CNT_TMP .= '<a href="#top">'.$template_default["article"]["top_sign"].'</a>';
$CNT_TMP .= $template_default["article"]["top_sign_after"];
} else {
$CNT_TMP .= '<br /><a href="#top">' . $template_default["article"]["top_sign"] . '</a>';
}
}
// Space after
if($crow["acontent_after"])
{
$CNT_TMP .= '<div style="margin:0 0 ' . $crow["acontent_before"] . 'px 0; padding:0 0 0 0; clear:both;"></div>';
}
$i++;
} // End While
}//End if $cresult
$CNT_TMP .='</div>';
//$CNT_TMP .= '<div style="clear:both;height:1px;font-size:1px;border:0px none;background:transparent;"> </div>';
return $CNT_TMP;
} //Eofunc
if( ! ( strpos($content["all"],'{GALLERY:')===false ) )
{
$content["all"] = preg_replace('/\{GALLERY:(.*?)\}/ie', 'show_gallery("$1",$db);', $content["all"]);
}
Falls es eine Lsg. gibt, die den Tag nicht benötigt (da er beim nächsten Update, ja wieder eingespielt werden muss) her damit.
Vielleicht hast Du ja noch eine Idee.
regards rasta
Also,wenn du die Bilder zum Downloaden anbieten willst... würde ich das so machen:
Ein Thumbnail 200 x150px mit popup-Window auf 600x600px mit Hilfe eines BILDER ContentParts einbauen.
Wer dann - nach der 1. Prüfung - das Bild runterladen will... der bekommt noch ein zusätzlich ContentPart Dateiliste angeboten, mit dem er dann das Bild in gezipten Zustand herunterläd und dann zuhaus "auspackt"!
So würd' ich's machen... allerdings hab ich keine Probleme mit "nicht validem Code"....
Aber dann ist ein CMS, egal welches, sowieso nicht die richtige Lösung für dich
Denk nur mal an die WYSIWYG Editoren von phpWCMS... die versuen sowieso alles, oder ?
Oder... schau dir mal das an: http://weitzelmedia.de von unserem Freund cyrano... besser kannst du keine Bilder "verkaufen"
Ein Thumbnail 200 x150px mit popup-Window auf 600x600px mit Hilfe eines BILDER ContentParts einbauen.
Wer dann - nach der 1. Prüfung - das Bild runterladen will... der bekommt noch ein zusätzlich ContentPart Dateiliste angeboten, mit dem er dann das Bild in gezipten Zustand herunterläd und dann zuhaus "auspackt"!
So würd' ich's machen... allerdings hab ich keine Probleme mit "nicht validem Code"....
Aber dann ist ein CMS, egal welches, sowieso nicht die richtige Lösung für dich
Denk nur mal an die WYSIWYG Editoren von phpWCMS... die versuen sowieso alles, oder ?
Oder... schau dir mal das an: http://weitzelmedia.de von unserem Freund cyrano... besser kannst du keine Bilder "verkaufen"
Hi pepe,
es handelt sich hier nicht um einen verkauf von bilder, sondern die angebotenen bilder sind zwar für die presse bestimmt, allerdings als service bestandteil. die bildergalerie ist nur ein kleiner bestandteil der website.
die gallerie von cyrano habe ich mir angesehen, sieht gut aus. vielleicht für das nächste projekt.
zu den wysiwig-editoren muss ich dir allerdings recht geben. da bin ich anderes gewohnt, imho muss für eines der nächsten releases von phpwcms das filehandling dringend geändert werden. als vorbild sollte da typo3 dienen. filemanagement und editor "greifen" auf die selben ordner/dateien zu. das kann man zwar dem fckeditor auch im phpwcms beibringen, durch die verschlüsselung/umbenennung macht es allerdings keinen sinn, da man dort nur kryptische dateinamen sieht.
es handelt sich hier nicht um einen verkauf von bilder, sondern die angebotenen bilder sind zwar für die presse bestimmt, allerdings als service bestandteil. die bildergalerie ist nur ein kleiner bestandteil der website.
die gallerie von cyrano habe ich mir angesehen, sieht gut aus. vielleicht für das nächste projekt.
zu den wysiwig-editoren muss ich dir allerdings recht geben. da bin ich anderes gewohnt, imho muss für eines der nächsten releases von phpwcms das filehandling dringend geändert werden. als vorbild sollte da typo3 dienen. filemanagement und editor "greifen" auf die selben ordner/dateien zu. das kann man zwar dem fckeditor auch im phpwcms beibringen, durch die verschlüsselung/umbenennung macht es allerdings keinen sinn, da man dort nur kryptische dateinamen sieht.
regards rasta
So ganz bin ich nicht deiner Meinung...
Die Verwendung der WYSIWYG-Editoren widerspricht im Prinzip doch absolut dem CMS Gedanken!
Die vorgegebenen Formate aus der css sollen doch automatisch dem Content - entsprechend des benutzten Conten-Parts - zugeordnet werden.
Nur so ist ein vollständig "automatischer" Ablauf in Hinblick auf ein saubere und konsequente Design-Umsetzung sichergestellt.
Insbesonder, wenn viele Redakteure an einem System arbeiten, macht da sonst jeder was er will, da kannst du noch so dicke Bücher an CD Richtlinien verteilen...
Mal am Rande:
Ich mußte mal innerhalb von 2 Wochen ein ca. 1200! Seiten starkes "Handbuch" aus dem Boden stampfen... mit 10 technischen Redakteuren. Jeder bekam einen speziellen Bereich zugeordnet und eine ausführliche Formatierungsanweisung!
Der Termin wurde eingehalten, aber das Layout war eine absolute Katastrophe... hätte ich da nur ein CMS "ohne WYSIWYG" gehabt. Wie schön hätte man da zum Schluß innerhalb eines Tages die komplette Formatierung reinbekommen können
Wenn wir Admins nun das phpWCMS als DESIGN-Werkzeug "vergewaltigen" liegt der Fehler eigentlich bei uns...
Warum sollte OG sein Dateisystem in 4 verschiedene Editoren einbinden... da hätte er viel zu tun
Und bei jedem EDITOR Update ginge es von Vorne los! Besser er arbeitet an wichtigen Dingen....
Setz doch einfach das Script so ein, wie es gedacht ist...
WYSIWYG-Editoren für Texte und die Bilder aus dem vorhandenen Dateimanager
Also mit ein wenig Übung hat's bei mir bisher ganz gut geklappt.
Und ein weiterer Vorteil:
Wenn du nachträglich Elemente in deine Artikel einbauen willst/mußt...
Hast du deine unterschiedlichen "Bausteine" schön in einzelne Contentparts verpackt, ist so eine Erweiterung ein Kinderspiel
Ich habe bei den von mir umgesetzten phpWCMS Sites nur den FCKeditor im Script... das Bilder Icon ist abgeschaltet, ebenso die Möglichkeiten für Schriftart und Schriftgröße nur die Auswahlmöglichkeit für Styles ist aktiviert und die Styles sind "von mir" vorgegeben...
So halten sich die "Experimente" der Redakteure in Grenzen und die Sites sind ganz erträglich.
Die Verwendung der WYSIWYG-Editoren widerspricht im Prinzip doch absolut dem CMS Gedanken!
Die vorgegebenen Formate aus der css sollen doch automatisch dem Content - entsprechend des benutzten Conten-Parts - zugeordnet werden.
Nur so ist ein vollständig "automatischer" Ablauf in Hinblick auf ein saubere und konsequente Design-Umsetzung sichergestellt.
Insbesonder, wenn viele Redakteure an einem System arbeiten, macht da sonst jeder was er will, da kannst du noch so dicke Bücher an CD Richtlinien verteilen...
Mal am Rande:
Ich mußte mal innerhalb von 2 Wochen ein ca. 1200! Seiten starkes "Handbuch" aus dem Boden stampfen... mit 10 technischen Redakteuren. Jeder bekam einen speziellen Bereich zugeordnet und eine ausführliche Formatierungsanweisung!
Der Termin wurde eingehalten, aber das Layout war eine absolute Katastrophe... hätte ich da nur ein CMS "ohne WYSIWYG" gehabt. Wie schön hätte man da zum Schluß innerhalb eines Tages die komplette Formatierung reinbekommen können
Wenn wir Admins nun das phpWCMS als DESIGN-Werkzeug "vergewaltigen" liegt der Fehler eigentlich bei uns...
Warum sollte OG sein Dateisystem in 4 verschiedene Editoren einbinden... da hätte er viel zu tun
Und bei jedem EDITOR Update ginge es von Vorne los! Besser er arbeitet an wichtigen Dingen....Setz doch einfach das Script so ein, wie es gedacht ist...
WYSIWYG-Editoren für Texte und die Bilder aus dem vorhandenen Dateimanager
Also mit ein wenig Übung hat's bei mir bisher ganz gut geklappt.Und ein weiterer Vorteil:
Wenn du nachträglich Elemente in deine Artikel einbauen willst/mußt...
Hast du deine unterschiedlichen "Bausteine" schön in einzelne Contentparts verpackt, ist so eine Erweiterung ein Kinderspiel
Ich habe bei den von mir umgesetzten phpWCMS Sites nur den FCKeditor im Script... das Bilder Icon ist abgeschaltet, ebenso die Möglichkeiten für Schriftart und Schriftgröße nur die Auswahlmöglichkeit für Styles ist aktiviert und die Styles sind "von mir" vorgegeben...
So halten sich die "Experimente" der Redakteure in Grenzen und die Sites sind ganz erträglich.
>>Die Verwendung der WYSIWYG-Editoren widerspricht im Prinzip doch absolut dem CMS Gedanken!
da bin ich nicht Deiner Meinung, ein CMS erleichtert Nicht-Administratoren die Pflege von Content, es soll Ihnen ohne Codierung möglich sein, Abschnitte Fett oder Kursiv zu setzen, oder ähnliches. Wie das Ganze hinterher auf der Website dargestellt wird (Fett und Rot und an einer bestimmten Stelle), jepp, das ist mein Problem. Für mich gehört daher ein Editor einfach dazu. (aber ich möchte mich nicht mit Dir streiten und toleriere daher Deine Antwort, ist halt Ansichtssache.)
>>Die vorgegebenen Formate aus der css sollen doch automatisch dem Content - entsprechend des benutzten Conten-Parts - zugeordnet werden.
s.o.
>>WYSIWYG-Editoren für Texte und die Bilder aus dem vorhandenen Dateimanager
da wird es bei der Website darauf hinaus laufen.
>>Warum sollte OG sein Dateisystem in 4 verschiedene Editoren einbinden... da hätte er viel zu tun Und bei jedem EDITOR Update ginge es von Vorne los! Besser er arbeitet an wichtigen Dingen....
wie ich schon erwähnte, bin ich noch nicht allzu vertraut mit dem System und der Community. Ist es so wie ich es verstehe? Oliver betreut das System komplett alleine? Puh! Ich arbeite normalerweise mit Typo3, habe mich aber wegen div. Gründen diesmal nicht dafür entschieden. Da läuft es so ab, das nicht nur Kasper Skaarhoj alles macht, die Last ist also auf mehrere Schultern verteilt (siehe dazu u.a. die Extensions), dem entsprechend, ist eine Anpassung natürlich auch viel leichter.
da bin ich nicht Deiner Meinung, ein CMS erleichtert Nicht-Administratoren die Pflege von Content, es soll Ihnen ohne Codierung möglich sein, Abschnitte Fett oder Kursiv zu setzen, oder ähnliches. Wie das Ganze hinterher auf der Website dargestellt wird (Fett und Rot und an einer bestimmten Stelle), jepp, das ist mein Problem. Für mich gehört daher ein Editor einfach dazu. (aber ich möchte mich nicht mit Dir streiten und toleriere daher Deine Antwort, ist halt Ansichtssache.)
>>Die vorgegebenen Formate aus der css sollen doch automatisch dem Content - entsprechend des benutzten Conten-Parts - zugeordnet werden.
s.o.
>>WYSIWYG-Editoren für Texte und die Bilder aus dem vorhandenen Dateimanager
da wird es bei der Website darauf hinaus laufen.
>>Warum sollte OG sein Dateisystem in 4 verschiedene Editoren einbinden... da hätte er viel zu tun Und bei jedem EDITOR Update ginge es von Vorne los! Besser er arbeitet an wichtigen Dingen....
wie ich schon erwähnte, bin ich noch nicht allzu vertraut mit dem System und der Community. Ist es so wie ich es verstehe? Oliver betreut das System komplett alleine? Puh! Ich arbeite normalerweise mit Typo3, habe mich aber wegen div. Gründen diesmal nicht dafür entschieden. Da läuft es so ab, das nicht nur Kasper Skaarhoj alles macht, die Last ist also auf mehrere Schultern verteilt (siehe dazu u.a. die Extensions), dem entsprechend, ist eine Anpassung natürlich auch viel leichter.
regards rasta
rasta, du hast recht, ich habe mich da nicht präzise ausgedrückt..
Klar soll da ein WYSIWYG editor vorhanden sein... aber nicht für den Einbau von Bildern, die doch mit WYSIWYG nichts zu tun haben!
und... streiten tut sich hier doch niemand, oder?
Ausserdem ist das nur meine Meinung und jeder der Forumsmitglieder hat sicher eine abweichende
Was die Art der Entwicklung angeht...
Typo3 ist das Eine und phpWCMS das Andere.
Beide Systeme haben ihre Vor- und Nachteile, beide ihre Berechtigung und beide ihre "Liebhaber".
Wer wenig Geduld mitbringt... sollte sich's überlegen! Aber es entgeht ihm ein "feines" Werkzeug mit vielen Möglichkeiten.
Ich halte es so.
Anstatt mich zu ärgern, "warum geht das denn nicht wie bei Typo3" benutze ich einfach die "Fähigkeiten" von phpWCMS
Das kostet kaum Nerven... und mit dem Ergebnis bin ich recht zufrieden.
Klar soll da ein WYSIWYG editor vorhanden sein... aber nicht für den Einbau von Bildern, die doch mit WYSIWYG nichts zu tun haben!
und... streiten tut sich hier doch niemand, oder?
Ausserdem ist das nur meine Meinung und jeder der Forumsmitglieder hat sicher eine abweichende
Was die Art der Entwicklung angeht...
Typo3 ist das Eine und phpWCMS das Andere.
Beide Systeme haben ihre Vor- und Nachteile, beide ihre Berechtigung und beide ihre "Liebhaber".
Wer wenig Geduld mitbringt... sollte sich's überlegen! Aber es entgeht ihm ein "feines" Werkzeug mit vielen Möglichkeiten.
Ich halte es so.
Anstatt mich zu ärgern, "warum geht das denn nicht wie bei Typo3" benutze ich einfach die "Fähigkeiten" von phpWCMS
Das kostet kaum Nerven... und mit dem Ergebnis bin ich recht zufrieden.