im augenblick linkt image.show immer auf "edit", wenn der nutzer editier-rechte hat. ich habe es so geaendert, dass es fuer alle anderen auf "main" linkt. ich haette gerne noch einen optionalen parameter, um diese links zu unterdruecken. frage ist, wie soll der heissen?

ausserdem wird "main" (d.h. image/main) fuer alle sichtbar sein. gibt es dazu bedenken?

Wenn man den image-manager kriegt, dann kriegt man eh auch das grosse bild (indem man vom thumbnail-filename hinten das "_small" entfernt. Und ansonsten kommt man auch nicht unbedingt aufs grosse. Ich habe also keine Bedenken, dass man image/main sehen kann, und ich glaub es braucht auch nicht unbedingt ein Attribut um den Link zu unterbinden, oder?

PS: cool!

in der bisherigen funktion linkt das bild immer auf edit, auch wenn ich schon auf der edit-seite bin. mein "main" macht das genauso und ich will das mit einer option verbieten. aus dem bauch heraus wuerde ich ausser what="thumbnail" noch what="nolink" zulassen. aber ich kenne eure benamungsvorschrift nicht. vielleicht gibt es was aehnliche woanders.

und das bild in main linkt auf main? das ist doch sowieso umsonst, oder? wozu?

stimmt auch wieder!

ich bin dafür, es weiterhin hardgecodet zu lassen bei welchem wert auch immer es jetzt ist. 20 glaube ich.

es war mal 20, aber jetzt ist nur noch 10. wenn ich das hochsetzen koennte, haetten wir im handumdrehen (ein wenig an den templates drehen) ein uebersichtliches alo-archiv mit thumbnails.

für dich wenn es wieder 20 wären?

bei eleph sind 10 okay. bei alo haette ich gern 50 oder gar 100. dort wuerde ich auch nur bilder auf die seite packen wollen. text und makro gibt es ja bei edit bzw. main.

wo ist das problem dabei? ich meine, ich mache die arbeit.

Es geht nicht um die Arbeit, es geht drum, keine Einstellungen zu haben, die 98% der User nicht brauchen (aus dem gleichen Grund kann man auch nicht die Anzahl der Stories pro Storymanager-Seite einstellen). Daher von meiner Seite:

-1 für einstellbare Anzahl von Images pro Seite

+1 für 20 statt 10 Images pro Seite.

(Anm: wenn robert und tobi +1 für flexible Anzahl von Bildern geben bin ich überstimmt.)

selbst wenn wir eine einstellbare anzahl von bildern im imagepool einbauen wuerden, waere das trotzdem ein "hack" weil der imagepool ja eigentlich nur auf den weblogs, die "offen" (= alle koennen contributen) sind, frei zugaenglich ist, bzw. auch dann nur wenn der user auch eingeloggt ist, d.h. er ist und war eigentlich nie als "archiv" gedacht.

so, my votes: -1 fuer einstellbare anzahl von images +1 fuer 20 statt 10 images pro imagepool- bzw. goodiepool-page

+1 von mir.

Hey, eventuell könnte man sich die stories auf ALO damit sparen! Nur mehr Bild-Upload, auf der frontpage ein <% weblog.imagelist %> macro... Hmmm!

als frontpage kann ich es mir nicht vorstellen, aber zwei alternative pages mit 5x5 (fuer modem-nutzer) und 10x10 thumbs (fuer allessehenwoller) waeren doch cool.

ich frag mich obs nicht sinnvoller waere, image- und goodiepool um zwei neue actions zu erweiten ("archive.hac"), die einfach den betreffenden pool public rendern (mit einem dazupassenden archive.skin, ev. auch fuer image/goodie). waer eine sauberere trennung zwischen management und archiv.

Ich glaube nicht, dass alle standardmässig die Bilderliste sehen sollen, sondern nur die, die jetzt auch das Bildarchiv sehen können (sprich Leute, die contributen dürfen). Dass der Image-Manager im Prinzip ein Ort für an sich nicht publizierte Grundbausteine ist soll so bleiben, IMHO.

Ich würde sagen: Klick aufs Bild/Thumbnail führt zu image/main, und zwar für alle. Falls man darf kriegt man daneben ein edit-Link (Bilder editieren tut man selten! Was es aber wirklich bräuchte wäre die Möglichkeit, ein neues Bild raufzuladen!!!)

Ich sehe da auch keinen Unterschied in der Funktionalität, der für eine zweite Bilderliste sprechen würde (keine Edit-Möglichkeiten?)

wenn ich so macro habe, dann kann kann ich das auch bei anderen leuten im forum posten und so alle hochgeladenen bilder sehen. ist das fuer irgendwen ein problem?

weil in comments und stories nur bestimmte macros erlaubt sind (du wirst/solltest also nur was sehen a la "[macro not allowed in sandbox]"). sollte also secure sein.

vielleicht haben wir uns missverstanden. ich will ein makro basteln, dass mir eine tabelle von x mal y thumbs (mit popup-link) anzeigt. cool waere wenn ich das anfangsbild optional definieren koennte, denn dann koenne man ganz fix eine galerie zusammenzaubern. daher muss das makro in stories funktionieren.

ganz versteh ich das jetzt zwar nicht (was an der letzten nachtschicht liegen duerfe), aber wurscht. jedenfalls kein problem dieses macro nur in stories zu erlauben, und in comments nicht.

wenn ich's nur in kommentaren sperren kann, dann ist ja alles schoen.

sorry fuer das "condensed" posting ;-) zur erklaerung: welche macros derzeit in stories und comments erlaubt sind, findest du in story/securityFunctions.js (in der function allowTextMacros()). da ein comment eine "erweiterung" von story ist, gelten diese einschraenkungen auch fuer comments. ist aber kein problem, die function in comment/securityFunctions.js zu kopieren und anzupassen.