Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By alexn on
Strange that "general discussion" seems to be the only appropriate forum for this post.... no user forums?
Anyway, the lack of out-of-the-box image support for content and posts in Drupal is a complete showstopper for me, and probably most people who just want to set up a decent looking site. I understand there are modules to do this, but I am not interested in any "content management system" that is unaware of images and unable to create documents with embedded images. I have also read too many nightmares about installation of these modules to even want to try.
Mambo makes it easy, even if not ideal. When you are creating content, select an image from a path in the install - with a nice little preview, select left/right/center alignment, and click a button to insert a tag.
Without this feature, it's just too much work to make decent image containing content. That probably explains why almost no drupal sites use images effectively in content, and they all look pretty uninteresting because of that.
I see adding decent looking content to a site easily and without techinical knowledge as one of the basic benefits of this new wave of CMSs. Drupal lacks this basic feature.
If I've missed something, please educate me.
Comments
Modules
In Drupal, modules are first-class citizens. Many of the core features are implemented as modules, and integrate completely together without duplicating functionality or having separate UIs.
For example, you can already attach files and images through the standard upload.module, but there are more advanced image-oriented modules available in the contributions repository. For example, the inline module allows you to place image attachments easily into a piece of text using a simple tag. And James Walker is also working on improving the current image.module to provide common services for image handling. This will allow a bunch of separate methods for using images (in a gallery, in a post, ...) to be implemented without duplicate code.
I've heard that Mambo's module system is a lot worse than Drupal's (see also the recent topic that compares Mambo and Drupal). Perhaps this explains your issue against modules?
Many Drupal sites use images. We use them ourselves on the Drupal Conference page. The most image-oriented site is probably Terminus1525 which is a community of graphical artists. If you take a closer look at Drupal, I'm sure you'll revise your view.
--
If you have a problem, please search before posting a question.
Well said
I have yet to find anything in Drupal that could be classed as a "showstopper". If you approach Drupal with few preconceived notions, you'll get a lot out of it. Usability is one area of ongoing focus and discussion for the developers. I find it more clean, uncluttered, intuitive and configurable than most web-based software I've used ... and it only gets better with each iteration.
Brian.
--
Brian.
Modules
Modules may be first-class citizens from a code perspective but, from what I've seen, from a quality perspective there is a reason that some are listed in the modules area and not included in the Drupal distribution with "core" modules. That is not to say that optional modules are substandard but there are some modules which certainly would be included in the core set if they were good enough and I think that an image module is certainly one of those.
While we may be proud of Drupal's many strengths I think we should not be defensive about its weaknesses and instead work on fixing them.
of course
but many modules are of good quality. And for others, as module quality improves features that are consistently used get implemented into core as hooks for better module development. The modules allow for the introduction of new idea's and methods. To test improvements for potential additions to core. Isn't that how the core menu module came to be when the 4.4 Contribute menu module had it's features rolled into core?
Other modules are very good but are not needed for a lot of sites. Why have OC module or dsKopedia or ecommerce in core when half the sites don't need it? They are important to some as enhancements, but if I don't need it, then I don't want to download it.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I looked at the inline
I looked at the inline module. It allows me to UPLOAD and inline images. I would like my images in a gallery directory (in my case, also managed by the Gallery application). I do not want to upload the images individually like this.
I don't see any module that allows me to easily browse, maybe preview, and insert an image that is already on the server.
I just want to create a kind of photojournal. I have uploaded and managed my images with Gallery. In Mambo, I just sim-linked the gallery directory into the installation, and voila, I can easily add an image to content. No node generation to deal with. No database "pointers".
Why is this so diffiicult with Drupal? Is there any easy way to do this?
well, you need some modules
You need the image module (it has a gallery) and you will also need the img_assist module. The img_assist puts a link on each chosen node that allows you to browse you gallery (or file system so you could probably do it without the image module but I haven't used it that way) and insert images into nodes. You can use the gallery thumbnail or resize them just for the node.
There is no current integration with Gallery (you are welcome to write a module for it butfolks so far would rather spend time on one built for Drupal). You can however have gallery on the same server and reference pictures in the file system with html links too.
-sp
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I also looked at img_assist.
I also looked at img_assist. It looks pretty cool, but according to the docs, I need something that:
1. Stores images as nodes
2. Creates a database table called 'image' with at least the following column names:
* image_path: the path to the image from the Drupal root.
* width: image width
* height: image height
* nid: the node id of the image. Images must be nodes.
Every image must be a node. So this still requires database pointers and nodes.
For images like logos, banners, etc, I'm happy to upload them into the CMS and have the benefits of versioning, etc (do I get that in this case?). But for image content, etc. that is managed by another piece of software, accessing images on the file system without a database pointer would greatly simplify things.
It seems like img_assist might work for me if it could dynamically create a node when I add an image to a another node. Otherwise, it seems like I have to upload all my images using the module or similiar, which is very inconvenient for a number of reasons I won't get into here.
I seen other sites that just
I've seen other sites that just link to their outside images (no spiffy gui) but have never needed that myself. I suspose you could use image assist as a posible template for creating a module as you describe. Never having had a need for it. There is also a fliker module (still in development) that pulls pictures from flicker that may be adaptable as well (I don't have it, not having a picture blog).
I use the img_assist to manage pictures in my image module. I suspose I will have to test the other style of pictures.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
A mix of modules
I've got it working both ways on my site.
Sometimes I want to make articles that talk about images in an image gallery. For that, I make the gallery first (image module) and then I make the article, using the img_assist module to slide in my thumbnail links. (As an example of a story including a thumbnail link off to the image gallery, http://etmeli.us/node/108.)
If I just want a picture to be a part of an article, then I use the inline module and the upload module. It sounds more complicated than it is. When both modules are enabled, you have a few more related options on the story writing page. You can upload related files at the same time as you are writing the text, and the inline tags let you refer to them easily. I really think that might be what you are looking for. (As an example, http://etmeli.us/node/122. Note that the inline filter wraps the image with an "inline" class. I used CSS to float the image off to the right. You will have to use CSS to decide how you want it to show up, and then it will show up the same in every use. I just threw a feature request into the inline project to ask for a class option.)
Steve
--
http://etmeli.us/ - photos, commentary, occasional sarcasm
Adding images to posts for people who don't know html
I'm interested to see or read about the improvements being made to the image.module, particularly
these changes sound exciting. I just wrote some ideas up about how people who don't know any html and don't want to see any either might find adding images easier. I've been training some folks on adding images to pages using image.module and img_assist. Here are some thoughts:
I've been thinking about the best way for a Drupal-based website to handle images. A lot of this depends on for who the Drupal site is handling the images. The key needs I've seen are the ability to add photos in bulk, pull images that are already in the gallery and put then in a page you are editing, or upload an image while you are creating a new page or an existing page, without having to go to 'create content' and create the new image node that way. To say this another way, a user should be able to either add an image into the gallery by creating a new image node through the create content > image step, but also should be able to add a new image on the fly through a pop-up window or section on a 'create new page' or 'new story', etc. page itself.
Many of our smaller clients simply want to put images in content pages, and easily change images on pages at later dates. This could be done easily with something like inline module, or the htmlarea image insert. But then what? The image link is added onto the page, but the actual file for the image falls into the abyss of the files directory which an administrator may not ever see again. The image gallery offers a good way to know what images are uploaded onto the site and any administrator can see and edit photos without much expertise.
Setting a default thumbnail size for images which are added to the gallery is helpful so that when an administrator is adding a photo to a page, they do not need to resize it, and insead just use the thumbnail. When you have HTMLarea turned on, and you insert an image from the gallery with the image_assist module, you can see the photo immediately in the page. You can also click and drag the photo to move it around, but this tends to make HTMLarea create extra tags, break up paragraph text, and ruin the layout of text. If HTMLarea is turned off, the user will see the code that image_assist creates. I've watched people try and copy and paste this code. Even though it is simple, just select everything between the div tags, it's not simple for someone who doesn't know html and what happens when you don't select the entire code snippet.
All this makes me think about an ideal way to do images on a site with many static pages and then news pages on which the admins will want to insert pictures. Not sure how possible it is.
The idea would be to use the image module
(built into the core)and the image assist module or something like it, and something that could create variables for inserting images into pages.1) The ability to add images (which are nodes) into a new or existing node (like a page) while editing or creating that page for the first time...this could be done in a pop-up window or a frame?
2) Then, open up image_assist (all while still creating or editing the page) and select what image you want to put in the page. This tool will let you determine how to align the image. Border, Vert and Horz space could all be predefined to simplify things.
3) Here's the part I dont know if is even possible - The image_assist create a variable for that particular image and the code that says how it should be aligned, and maps this in the database, saying
<div class=image><img src=xxxx/xxxx/xxx /></div>is equal to variable $image0001, and a filter is used to insert the image, which is a variable like [image:image0001] and this is the "code" that the administrator sees when inserting an image into their page. A lot less to copy and paste, a lot harder to miss part of the code when cutting and pasting. But is this even possible, or would it really be easier?You'd then have an overview where you could see all image to filter relations on the website. And all your images would be stored in a graphical gallery for easy viewing and editing if need be.
What do people think? Is there some way to accomplish #3 and would it be worth it?
I responded to this on my
I responded to this on my blog, and sent you a link via email, because I couldn't post a comment on the site.
Short answer: HTMLArea plus the UploadImage plugin already do this, but I have some more suggestions at the end of the blog post.
which version of "walkah" image module?
There is one image module in the sandbox from about 2 months, and another from 5 weeks that is labled "45," which one should be used for 4.5? My image module was working, but since I switched over- to the "45" one I get the dreaded "unable to create thumbnails" even though convert is set correct.
RE: 3)
imgage assist could be modified to work this way as well; insert a variable and use a filter to parse in the html code at page-serve time. This would, however, make the administration of image assist significantly more complicated as a filter would have to be configured.
- Robert Douglass
-----
visit me at www.robshouse.net
Look at the wiki way
Look at how wikis do it. In Drupal, any web address (e.g. http://google.com ) will be parsed as a hyperlink to a web site. Wikis do this too. It's a standard function.
But get this... In wikis, any web address ending in .bmp, .gif, or .png will be rendered as an in-line image. I'm suprised that Drupal does not do this out of the box, and that some kind of module is needed.
But if the module is easy to install... nevermind ;-)
http://undertheoak.net/images/matthew199x199.jpg
I like that idea
That just sounds like a simple filter type thing.
(goes off to investigate...)
done
Just did a small module that does just that. It was easy to adapt the urlfilter.module.
I have called it the image_url_filter.module
...so if anyone is interested, let me know.
I'm interested!
Wow. The lack of in-line images was a complete show-stopper for my adoption of Drupal. But if you just fixed that, then that leaves me free and clear to use it! (well... if I can find a template I like)
Thanks! How do I get a copy of the module? What does it do? Did you catch the discussion at the end of the thread re: concern for images too large for the page breaking the page?
Either way, this module sounds great. How can I get a copy and install it?
Image URL Filter
You can find it here:
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/image_url_fil...
I think it's a neat idea, simple and handy, and it doesn't interfere with anything else.
About the large image issue, it's not an issue, just put a link in (using the <a> tag, or brackets, or whatever you use for a link (except it does - obviously - override the automatic linking from urlfilter.module).
Thank You!
I just tested this and it works great! Thank you very much for creating this and sharing it. It's MUCH more easy to install than the image module.
If you are interested in adding to this, I'd recommend looking at the patterns for treating images here - http://pmwiki.org/wiki/PmWiki/ImagesInWikiPages - things like wrapping text around the image and embedding linsk in images would be basic enhancements.
other ways
by the way...
there are also a number of other ways to have inline images in posts, so to say there is a "lack of in-line images" in Drupal, is not correct - as I'm sure you have now discovered.
how?
Are you talking about the vanilla install? How do you do it? Do I have to write code to do it? Is the way to do it so easy that it can be made common to non-technical writers?
Well noted
I agree that the lack of integrated image support remains a major shortcoming of Drupal. One has only to note the total lack of images on drupal.org to see this lack in action. It is true that there are ways of integrating images through - now various - modules. But there are shortcomings to all of these modules. And they provide a patchwork--depending on what type of functionality one wants, one may have to install and configure multiple image modules--and even then, likely, manually edit a theme or themes to actually see the images (if, e.g., what you want is images associated with taxonomy terms).
What image support there is in core is uneven. There is a 'picture' field for user atavars, but this is not mirrored for other object types (e.g., nodes, taxonomy terms, vocabularies).
The continued lack of image support may reflect an overall conservativism in the project, partly resulting from an insular culture. Only three individuals actually decide on new changes to the Drupal core; certain others are 'trusted' by these three and so have influence. The emphasis of keeping a slim core has, in many instances, led to what would be expected functionality not making its way into core. While it can be spliced on through modules, the module development process - largely, haphazard and with few guiding principles and no formal mechanisms for prior peer review and approval - leads to unevenness and, in any case, can't make up for the lack of core support.
It's good to see people are
It's good to see people are mostly in agreement. I understand the concept of modules being "first class citizens." That's great as long as their quality is trusted, and their code is as well written as the container. But it takes a long time to decide, "hey I trust these Drupal people to write good stable code." I don't want to have to go through the same process for every little piece of functionality.
I was a software developer for a long time, and I strongly believe in good architecture, and simplicity first. Perhaps Drupal is just not mature yet, since it still lacks core support for primary requirements.
Note that by "core," I mean in the core code or modules widely trusted enough to be included in the distribution and ubiquitously used. As a user, I don't care if it's a module or really core, as long as it works, and as long as I don't have to spend 36 hours of my time evaluating and comparing different image modules and browsing forums for environment variable tweaks to get it working. I've already gone through a painstaking evaluation process of CMS software. I don't mind evaluating for unusual features that you can't expect to be core, but this doesn't fall into that category. Something as essential as image support MUST be included in the distribution to be a viable install-and-use CMS solution - like its rivals Mambo, etc.
About the modules
I am another avid Drupal user/administrator who is rather frustrated with the image options to date. I've found it almost easier, and more flexible, to simply upload an image and use its resulting path in an image tag right in the html of the text body. I'm delighted that improved image handling is in store for future Drupal releases.
I would like to add, though, that the modules on the Downloads page are overally very solid. Some you may install and decide they're not for you, but you're not likely to break anything with an installed module. (The only exception would be HTMLarea, with which I would urge caution. It is a very aggressive module in net effect, for it rewrites all existing text blocks and can mess up your site, requiring some remedial formatting cleanup of some things already posted.)
In general, I tend to trust any of the modules on the Downloads page as being essentially part of the core release, only optional.
--
mediagirl.org
Good to hear
Nice to hear that the modules can generally be trusted. For me, it's hard to tell if that page (or two pages really, the Downloads page and the Modules page) includes alpha, beta, etc software. Perhaps a sourceforge style rating system for stability would be in order.
DrupalForge?
Perhaps it's time to open a DrupalForge? After all, Mambo manages all of its modules (some of which it also calls components, and Mambots) using MamboForge. Or at the very least, we should look at extending project.module to implement some of the handier features of the SourceForge system, such as classifying our modules according to stability, genre, etc.
Actually, come to think of it, all that needs to be done is creating some new (taxonomy) vocabularies on drupal.org, and then classifying module nodes according to their terms. But whatever the method, clearly we need some way of sorting the stable and reliable modules, from the unstable and insufficiently tested ones.
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
Taxonomy to Organize Modules
A beginning list of vocabulary for the modules was submitted --- comments and help would be appreciated.
I think the goal is to increase module visibility via improved accessibility to users with the use of an organizational scheme.
htmlarea, much like image module
these two modules show that drupal is more for coders than content creators. Without a mature WSIWYG editor that includes image handling, drupal will lag behind Mambo and other user-friendly systems. Tackling these two module should be a first priority for a CMS since the ultimate goal is for any end user to easily add content. While adding tags may seem basic to most of us, it is not to others who aren't up on net syntax and is just confusing. We have to remember that most people don't know how to create a link, let alone include an image.
The problems with these two modules can be a showstopper for those catering to a less tech saavy audience.
The other showstopper is the node creation interface which is getting a much needed workover.
Quicktags stopgap
I was delighted to see the quicktags module appear. This is a stopgap that can really help those who are not code savvy. It's not wysiwyg, but at least it makes the code. I'm looking forward to implementing it with my 452 upgrade (which is waiting upon the new box, which sould arrive any day so I can get off of this clunky old NT machine with a fleabite of ram).
--
mediagirl.org
I'm largely in agreement with your gripe
I think that our beloved image.module has had a long hard road, many contributers (more than your average contrib module), and has spawned some pretty important related work (the file-handling API which is now in core). It has also shown its limitations and that is why there is development going on to replace it. Many of the features or promises of the new image module in development are targeted at lessons learned with the current version. I suppose that the best thing developers can do at the moment is to download the image.module from Walkah's sandbox and start sending him patches against it. When it is finished, well tested and mature, I'm sure there will be a strong movement to have it in the core distribution. It is, as you said, basic CMS functionality.
- Robert Douglass
-----
visit me at www.robshouse.net
File management
As of Drupal 4.5, Drupal core offers an upload module that lets you upload images (or files in general) and use them in your posts. Clearly, a step in the right direction. However, it does not mean all file management issues are suddenly dealt with. To make a long story short: we should continue to improve Drupal's file handling. To that extend, I welcome patches that help improve core's file management.
I think there are plenty of
I think there are plenty of options in Drupal to deal with images, but nothing is perfect.
I think the ideal would be to have a feature that does the following:
1. Button (like the upload or image.assist) on the create node page will take you to a pop-up.
2. In this pop-up you can either select from the gallery of images (like image.assist) or upload a new one (like upload).
3. Once the image is selected or uploaded you could set it's size from a list of predefined sizes or custom size.
4. You could select from a list of style options. Such as frame/no frame and align left, right or center.
5. The image gets phisically resized and the code for the image gets inserted into the post.
6. At the end of the post you would have a summary of the attached image (as upload) where you can see all the settings, such as size and style.
7. You could click the images on the bottom to edit their options and they can be reinserted to the node with the new options.
8. In preview mode you would see the node in action.
9. The list of attached images will not be visible to the readers, only the images that are inline with the text.
10. Happiness! :D
It's basically an improved image_assist.module with upload capability and real resize function.
---
http://creativebits.org
an easy way
Check out how http://pmwiki.org treats images. Excellent. Makes it easy to do inline images by simply authoring content with a URL to an image within it, word wrapping by positioning the image URL along side the text, and hyperlinking the image by embedding it within the link (reference) syntax.
If this behavior was the
If this behavior was the default then how would a user link to an image that they do not want to appear inline (e.g. a large image that would break the layout of the webpage)?
use syntax for that in the reference
You would simply not display it inline on the page, using syntax for that in the link reference...
[[http://www.example.com/image.gif"alt text"]] or
[[Attach:image.gif"My Image"]]
This follows from the "anything in double brackets is a link" rule --
thus these become links instead of being inlined.
Obscure syntax
This method requires that the user be familiar with the rule. Consequently ignorant users would be allowed to include inline images, either intentionally or not, which break the page layout. This doesn't seem like a very desirable solution.
We already know what a link looks like. It might be nice to have another syntax (like your double brackets) which identifies an inline image but that should not be the default.
I agree
I agree. Either way would be fine. I figure that by the time someone knows how to put a .jpg on a page to get a photo, that requiring some simple additional syntax would be just as easy, like using a double bracket to turn on the in-line-ness of the URL.
Such capability would make images abound in Drupal. And if I understand right, it wouldn't even drag on the site's bandwidth, unless linking to a file that is hosted on the site.
not an issue
see my comment above:
http://drupal.org/node/15877#comment-29393
try it out.
PagEd a GPL application module accomplish what is desired above
PagEd a news content module for PostNuke and MDPro seems to accomplish what you described to see post above.
Drupal does not provide the same logic of functionality with the same features at this moment, instead it requires combination of modules (image.module, img_assist.module, TinyMCE.module, img_inline.module, imageattach.module and others and that seem to confuse many ordinary folk without demanding to how to deal with this confusion or understand a piece of code, from the masses. (people minus geeks/code gurus) :)
current solutions would be no problem for admins with coding experience but we can not expect it from larger user community who uses Drupal based sites. And Drupal can not fullfil the slogan 'community plumbing' for the masses and many greatness of the Drupal solution will not reach to larger pool of users -imho
I could not find a online demo to to point to you PagEd. You need to install into a PostNuke or MD Pro to experience.
Would be nice if PagEd ported to Drupal maybe the Code browser would be useful for someone who wishes to port it to Drupal or to combine current modules to achive the smilar functionality.
That would be great addition to Drupal and attract many people to Drupal
PagEd features:
http://canvas.anubix.net/modules.php?op=modload&name=PagEd&file=index&pa...
PagEd code browser:
http://canvas.anubix.net/modules.php?op=modload&name=PostWrap&file=index...
I must admid that PagEd
I must admid that PagEd rules (if you use MDpro / Postnuke). I have asked the developer to take a look at Drupal and to see if he would like to port the system to Drupal. Have not heard anything back yet.
But I think it can be accomplished by building a custom node-type. I am not a programmer, so I can't do it. But if anybody want's to give it a try, I am more than willing to test ;-)