Dec 13 2012
Dec 13

There are a lot of approaches for resizing images (ImageCache, Image, iMCE, and many others). However when building a site for a simple user (no previous web experience), I found that all of these approaches required too much effort on the part of the end user. Why can't a user just resize an image in their WYSIWYG, and not worry about the size of the image at all? That's the goal accomplished by the Image Resize Filter. Despite its extremely techie-sounding name, it's ridiculously easy to use. It provides inline resizing of images to match any tag in any HTML inserted in any Drupal textarea that supports filtering.

Apr 17 2012
Apr 17

Our online exhibits need an attractive home page. To make the view we decided upon Views Fluid Grid for the display (using imagecache of course to fix the width of the images). We use taxonomies extensively in our site to help create contexts among other things so using a term view to list all of our exhibits is a natural extension of the library philosophy. Since not all of our exhibits are hosted on the same site we added a term field to provide a space for a dedicated home page on each exhibit. We also used taxonomy image to make the page more attractive.

Views Fluid Grid Output

Views Fluid Grid Output

It’s a bit long winded at ~3 minutes, but hopefully thorough enough for anyone following along http://www.youtube.com/watch?v=j0fnqBOAj7k

As a result all our archivists must do to add a new exhibit to the home page is add a new taxonomy term to the archival taxonomy and the image and term description are posted to the fluid grid page.

Taxonomy term with a single term field

Taxonomy term with a single term field

The settings within the view itself are pretty straightforward -

Views Fluid Grid settings

Views Fluid Grid settings

and the main thing to remember is that you’ll want to go to imagecache and create a scaled and cropped fixed width preset- this keeps all your pictures the same size and works well with variable sized images.

ImageCache Presets scaled and cropped

ImageCache Presets scaled and cropped

and you’ll also want to change the link output to reference your term field.  Any questions or comments welcome, take care and have a great day.

Replace the link with your term field

Replace the link with your term field

Mar 21 2011
Tom
Mar 21

Yesterday I blogged shortly about the new Mobile Tools integration with Context.

I currently updated the support for Build modes, and would like to illustrate this with an example using ImageCache.

First of all if you want to use build modes, you have enable the Mobile Tools module to provide build modes:

Enable build modes

Let's say I have a content type for a Brand that contains an image and a logo.

The goal of this example is, to show the logo and image on both desktop and mobile site, but with different sizes. We will use ImageCache to resize the images for the different platforms.

First of all, have a content type that contains images.
Brand content type

Secondly create two mobile imagecache profiles. One for the logo and one for the image. In this case we just show the logo settings, where we set the image to have a max width of 100px

imagecache 2

So eventually you end up with two imagecache profiles
imagecache profiles

The next thing you need to do is to go to the configuration page of your content type and choose "Display Fields". Here you can configure which fields need to be displayed on the node page and which formatter you want to use.

Mobile Tools add two new display modes:

  • Mobile Groups: configure the fields per device group (iphone/android/ipad/...)
  • Mobile Type: configure the fields per device type (mobile/desktop)

Now you can easily select the mobile logo and mobile image in the dropdown boxes as default formatters for these fields on e.g. mobile devices.
content types build modes

After clicking save, you are all set!

Now you just have to look at your site from a desktop browser and a mobile browser.

Screenshot

The mobile version shows the smaller image... Simple and easy.

iphone screenshot

Note: For the mobile template I used the new Fusion Mobile template.

View the discussion thread.

Feb 24 2009
Feb 24

Image handling in Drupal is a hot topic. Most users agree that there should be a solution in core but there are so many different cases that it’s unlikely that one general solution is going to cut it. I’m not here to debate one way or another because I’ve built sites using Imagefield + Imagecache and others using just IMCE and TinyMCE, but one module that I haven’t explored for a very long time is the Image module.

When I started using Drupal in version 4.6, the Image module was pretty much the only solution. Since I couldn’t get it to work the way I wanted back then, I’ve pretty much avoided it since. When I decided to try it out again this week (because IMCE doesn’t yet work with the Wysiwyg API) I was pleasantly surprised. It integrates nicely with TinyMCE and works very well with Image Resize Filter. It also makes sense to store images as nodes when they’re added to the body text, especially for non-technical users (even when I thought it was a bad idea in the past).

I don’t want to fuel any debates about which image solution is the best, but if you haven’t checked out the Image module in a while it’s probably worth your time. Drupal has come a long way and modules that you might have sworn never to use again back then may have also changed a lot as well.

Jan 07 2009
krs
Jan 07

When you using imagecache on the $user->picture, many people have noticed 1 small problem. If someone uploads a new picture, everything appears to work fine, but the user photo stays the same!

What's going on? When a user uploads a picture, it gets renamed to a specific filename - doesn't matter the name of the file you uploaded. Imagecache then makes a copy of that file to display. (Technically this doesn't happen until the first time the image is viewed with a particular preset). When the new user image is uploaded, it gets the very same name as the previous one, again regardless of the actual filename that was uploaded. Now imagecache will think it already has a cached version of that image, because it just checks the filename and sees that it exists!

So I was all about to post on how to fix that, basically by linking to Nate Haug's excellent post on how to do just that - but the Imagecache module maintainers have just made a new release (for Drupal 5) that includes a fix for the issue! So the new solution is - download the latest version of the Imagecache module!

Jun 23 2008
Jun 23

Today I needed to get Drupal's ImageCache module to regenerate a bunch of resized images. ImageCache doesn't create the images until a browser requests them and at that point the new image is saved to the disk for future use.

One way to generate the images would have been to just click my way through every page on the site but I'm way to lazy for that. So I used wget:

wget -r -nd --delete-after http://example.com

By using the recursive (-r) and --delete-after switches I was able to have it crawl the site and get all the images generated. Bonus points for running in on the server so that the transfers were via the loopback interface so the transfer didn't count against the monthly bandwidth limit.

May 12 2008
May 12

Install ImageAPI before upgrading to ImageCache 2.x!!

I'm finally comfortable enough with my Image* namespace to have official releases of the 2.x series of ImageField and ImageCache + ImageAPI...

I'd like to extend thanks to everyone who has filed issues and submitted patches, especially Drewish and Quicksketch.

Now that my 2.x's are out I can start on the 6.x ports. ImageAPI already has a working port in HEAD, but needs some bug fixes ported from 5.x-1.x. There is a patch for ImageCache pending in it's queue and it should be a trivial port.

ImageField will be the first to see an official release, since it will be needed to test the ImageCache port.

I will be developing a core compatible file api for imagefield and filefield to consolidate specialized functions used by both to maintain path correctness, implement hook_file, and hide a few messages from some of the chattier core file functions.

This will delay D6 ImageField development a little. Since CCK is still at alpha I don't see it delaying and official ImageField release. I will also probably be getting back to the CCK issue queue so I can get my D6 ports out and stable. /me waves to KarenS and Yched.

--outta the weeds
.darrel.

Mar 31 2008
Mar 31

I had a great time at DrupalCampNYC....

I stuck myself in the Hack Shack, where I should probably keep myself as jaded as I've been lately. Ate me some tasty Bagels and got to help a few folks out... I even gave a presentation on workflow in Drupal 5 (Yes I occasionally show for my sessions.).

I think the best part was actually getting to work first hand with a difficult imagecache permissions issue Nat Meysenburg from OpenFlows was having... There are a slew of things that can go wrong working with imagecache... Apache's Rewrite Rules, Permissions, Drupal Files Config, corrupt images, lock files.... I always have a difficult time divining what problems people are having from my issue queue... It always ends up being a long round of question and answer before I figure out an issue if I ever do...

In my on going frustration with supporting imagecache. I added a few permissions fixes to get a 1.4(borked) and 1.5 out. I started thinking ImageCache 1.x is *really* crufty compared to 2.x. It's just a little bit cleaner than the proof of concept it originally started as. So I've taken the last two days to back port the Header responses from 2.x, add a lot more watchdog calls, fix up the lock file handling, and remove some of the stuff that I look at now and go, "what was I thinking?".

After releasing a broken 1.4, I'm a little gun shy about rolling 1.6 right now from 1.x-dev. I would love some brave souls to check out the DRUPAL-5 branch or wait till tomorrow and test out the snapshot As soon as I get 3-4 not brokens I'll go about a release...

.darrel.

Feb 22 2008
Feb 22

I have a client whose sysadmin is adamant about using Lighttpd as a webserver, whose site also uses imagecache.

There are some major differences in Lighttpd's rewrite system compared to Apache's rewrite system. The difference that is most important is the lack of the file exists check provided by the -f flag to apache's rewrite conditions.

The way imagecache works is to dynamically generate images that don't exist when they're requested from it's url namespace. So if you request http://example.com/files/imagecache/thumbnail/myimage.jpg and it doesn't exist the url rules rewrite it as http://example.com/index.php?q=files/imagecache/thumbnail/myimage.jpg
and drupal passes the request to imagecache. If the file does exist Apache just serves it directly.

Since Lighttpd's rewrite rules do not support this file exists flag they are unsuitable to solving our problem. I tried setting up several different variations of rewrite rules, specialized 404 handling.

So after installing mod_magnet, and editing the url prefixing for my local installation everything works wonderfully...

While everything is working I still have some concerns that make me want to do some benchmarks against lighthttpd and apache.

My concern is that mod_magnet seems to have a heavy performance cost, like 25% less requests per second according to the Benchmarks section of http://nordisch.org/2006/10/6/dr-magneto-vs-mr-404-handler.

When I consider it in light of the performance benchmarks at http://blog.kovyrin.net/2006/08/28/ruby-performance-results/,
I start wondering if lighttpd + mod_magnet +fcgi really has a performance advantage over apache2 + fcgi + mod_rewrite.

I would expect lighttpd to have a smaller memory footprint, but a minimally configured apache + fcgi has a pretty small memory footprint compared to running mod_php....

Now that I have a working lighttpd install I may try to do some benchmarks to ease my mind.

Nov 29 2007
Nov 29

using the term "content management system" to describe the drupal cms understates it's full potential. i prefer to consider drupal a web-application development-system, particularly suitable for content-heavy projects.

what are the fantastic four?

drupal's application development potential is provided in large-part by a set of "core" modules that dovetail to provide an application platform that other modules and applications build on. these modules have become a de-facto standard: drupal's fantastic four. our superheros are cck, views, panels and cck field types and widgets. if you are considering using drupal to build a website of any sophistication, you can't overlook these. note that cck field types and widgets isn't a real module, but rather a set of related modules.

flying with the four

getting a feel for how these modules work and interact isn't trivial, so i'll give you a brief introduction to the super-powers of each of them, and then take you step-by-step through an example, with enough detail that you can easily get it working on your system. or, if you want to see a professional implementation built on the same principles, check out the zicasso photo competition.

meet our heros

the content construction kit or as it's more commonly referred to, cck, provides point-and-click attribute extensibility to drupal's content-types. for example, if you site is about photography, you could define a type of page on your site called "photograph" and then add typed attributes to it, shutter-speed (integer), flash (boolean) etc. cck then automagically creates forms for you (or your users) to create and edit these types of pages, providing suitable validation, gui controls etc.

the cck fieldtype modules each define a new type of field that can be used in your cck content types. one example is the imagefield module, allowing your cck types to have fields of type image. this allows your "photograph" page to contain the actual photograph itself. there are many more types that you can find in the cck modules download area.

the views module allows simple point and click definition of lists of drupal nodes, including your cck nodes. you can control not only what is in the list, but how the list is displayed, including sorting, pagination etc. these lists can be conveniently displayed as blocks, full blown pages or even rss feeds. for example, you could define a list of photographs that had been highly rated by users on your photography site.

the panels module allows you to create pages divided into sections, each section containing a node, block, view or any custom content. so without any knowledge of html or css you can create complicated and powerful layouts. for example, you could create a page with two views, one showing a list of recently submitted photographs and one showing a list of highly ranked photographs. this module is currently undergoing a huge facelift and panels2 is in alpha at the time of writing

an example

to illustrate how the fantastic four can be put to good use, let's continue with our photography theme and create a simple photo-competition application. this application (shown to the right) allows the creation of a simple photo competition entry using a form. the main page shows two lists, one of recent entries and of "featured" entries. the application also has a detail page for each photograph where anonymous users can leave comments.

step one - install the modules

i'm going to assume that you've got a basic drupal install up-and-running. if you haven't, please refer to one of my previous blogs, easy-peasy-lemon-squeezy drupal installation on linux. once you've done this, you should install 6 modules. cck, views, panels2, imagefield, email field and imagecache. on linux, you can do this as follows. cd to your drupal directory (the one containing cron.php etc.), create the directory sites/all/modules if necessary, and download the modules:

# wget http://ftp.drupal.org/files/projects/panels-5.x-2.0-alpha14.tar.gz \
http://ftp.drupal.org/files/projects/views-5.x-1.6.tar.gz \
http://ftp.drupal.org/files/projects/cck-5.x-1.6-1.tar.gz \
http://ftp.drupal.org/files/projects/imagefield-5.x-1.1.tar.gz \
http://ftp.drupal.org/files/projects/imagecache-5.x-1.3.tar.gz \
http://ftp.drupal.org/files/projects/email-5.x-1.x-dev.tar.gz

then unzip them and set the permissions properly:

# for file in *.gz; do tar xvfz $file; done
# chown -R www-data.www-data *

now to to the administrative interface, http://example.com/drupal/admin/build/modules and enable the modules in question.

finally, now go to http://example.com/drupal/admin/user/access and grant access to the panels and views module features to the role you are using e.g. "access all views" to "authenticated user" and "administer views" to your "developer" or "admin" roles. also grant "post comments without approval" and "post comments" and "access comments" to the anonymous user.

note we're using the alpha panels version, panels2. it's not quite ready for prime time, but it's hard to resist. it kicks ass.

step two - create a new content type

now it's time to create a new content type. navigate to the content types page at http://example.com/drupal/admin/content/types, and create the "photo competition entry" as shown below.

now let's add two new custom fields to our photo competition type: email and photograph. these fields make use of the new cck field type modules we just installed.

create the email field as follows:

create the photograph field as follows:

now go to http://example.com/drupal/admin/user/access and allow anonymous users to "create photo_entry content" and "edit own photo_entry content"

step three - setting our themes

because i'm bored with garland, let's change the default theme to "minnelli" in http://example.com/drupal/admin/build/themes, change the administratin theme http://example.com/drupal/admin/settings/admin back to garland.

step four - create some content

now that we've defined our new content type, we can go ahead and create some new content. navigate to http://[...]/node/add/photo-entry and fill out a few entries. you can see your new create form in action, complete with validation (shown to the right).

it's best to do this as the anonymous user to see the usual user experience. it's convenient to stay logged in as admin and use another browser e.g. internet explorer (bleah) for your regular (anonymous) user.

step five - configure imagecache

the imagecache module allows you to define an arbitrarily large number of image transformations (presets) including scaling, resizing and cropping. let's define two transformations, one preview to create a 200px wide scaled down preview. the second transformation, thumbnail is slightly more complex, and creates a square image, 120px by 120px that is a scaled, centered crop of the original. rockin.

create the thumbnail preset as follows:

create the preview preset as follows:

you should now be able to test your presets with the content you created e.g. if you uploaded an image called myImage.jpg, you can view your transformed images at:

step six - create our views

the views module allows you to create lists of nodes. we're going to create two views:
  1. recent_photo_entries, a list of the five most recently submitted entries. the list shows a thumbail of the image and the email address of the creator.
  2. featured_images, a list of the two most recently commented on images. this list shows a preview of the image, the image title and the email address of the creator.

create the recent view as follows:

create the featured view as follows:

step seven - create the panel page

the last step is to create the panel page to host our content and views. go to http://example.com/drupal/admin/panels/panel-page and create a new "two column stacked" layout, as shown below:

put custom content in the top panel, your recent view in the left panel and the featured view in the right panel. for the views, be careful to select a "view type" of block.

the following image shows the custom content you should create in the top panel:

the final image shows the configuration screen for the recent view (left panel). the right panel is very similar:

finally go to the "site information" administrative section: http://example.com/drupal/admin/settings/site-information and set your new panel as the home page i.e. put "photo-competition" in the default front page box.

you are done and your site should look something like:

further work

there is a lot that you could simply do to enhance this example, for example:
  • installing the jrating or fivestar module and allowing users to vote on photographs using a nice javascript control.
  • creating a view that implements an rss feed for photo competition entries.
  • using css to style your views and nodes.

check out a professional drupal photo competition based on these same principles at zicasso

tech blog

if you found this article useful, and you are interested in other articles on linux, drupal, scaling, performance and LAMP applications, consider subscribing to my technical blog.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web