&gt;&gt; So, yes, we definately need to keep the option to let people place media anywhere. And yes, that needs to hook into WYSIWYWFU interfaces. But, no, this is not as badly needed as Simple Inline Media Handling. We need both, we need the flexibility, but IMHO an automatic-no-clutter solution should be the default. In core.

<br><br>I'm with Ber most of the way here, having struggled with some heavy image requests in a rather rigid templating evironment before.&nbsp; <br><br>First, some discussion thread voting!<br><br>+1 for files as an abstract data type full of rich, creamy metadata.&nbsp; 

<br>+1 for image nodes (as a content type that exploits file uploads).<br>+1 for browsing/creating images while creating other nodes. <br>+1 for attaching files to user profiles.<br>+1 for upload once, use many times.<br>

-1 for inline tokens [that's why we have HTML/PHP in posts!]<br>-1 for requiring theme editing to handle file/image presentation.<br><br>Here's what I'd recommend (humbly) for Drupal.<br><br>Do not rely on theming to handle variation of presentation -- if advanced users want to do theme backflips, let them, but &quot;normals&quot; need nice file handling too.

The default presentation of media that are attached /associated with nodes should be handled via /admin as part of content configuration.&nbsp; Some needs from an admin perspective: 1) Some node types might not accept any media attachments.&nbsp; Some might accept all.&nbsp; Admins should be able to decide based on what files users can upload.

<br><br>2) Placement of attachments (by type) with relation to the body of the node should be set muich like custom blocks are set now.&nbsp; <br><br>3) I would even propose that attachments hook into the new (4.7) region system rather than the standard content system. (I'm writing a custom block right now that does this by reading the file extension of objects added to a given node via the attachment module.)

<br><br>4) If attachments are not treated as blocks, placement of attachments within the body of the content might be done like teasers are defined now (insert photo 1 at character 400; photo 2 at character 1200; insert PDFs at node end; etc.).&nbsp; (This is the code I had to write in the other system).&nbsp; 

<br><br>4a) Be prepared to handle multiple objects of the same data type.&nbsp; There may be, say three ways to handle groups of photos.&nbsp; Option 1: Load one photo and link to the group as a separate node; Option 2: Load all in a region of the page; Option 3: Use AJAX or similar code to dynamically rotate pix on command.&nbsp; 

5) Access control for attachments would define which roles could override the default placement of attachments using a token syntax (which, on general principle, I oppose, but will agree to include if others like it).

The bottom line is this: a system like teasers, where the site admin sets the defaults, with an allowed override for advanced users.&nbsp;  And while I would agree that WYSIWYG is not necessary, point-and-click setup by admins (rather than theme editing) is.

<br><br>(And, for the record, my clients all want to be able to layout their pages with photo 1 at graph 1, align right; photo 2 at graph 6 align, left; with a big fat ad space between graphs 3 and 4,)<br><br>--<br>Ken Rickard

<br>agentken<br><br>