I want to build a custom block in Drupal 7 that instead of the standard title/text-format contains a single image field. It will be used on the front-page and allow a non-HTML-speaking editor to easily upload and update the big front image that will be shown there. Since there will be only one block I feel a block is more appropriate than a content type. I've built a bunch of custom blocks for Drupal 6, but they were all textfield-based, and I'm not sure how I should approach the problem now that I need a image-upload-field. Does anyone want to point me in the right direction? How do I build the image field from within hook_block_view?

  • Why not use some Rich text editors to upload and display images ?
    – GoodSp33d
    Jun 14, 2012 at 12:05

3 Answers 3


You could create (anyway) a content type and use the module Node Blocks. Every content you create with this content type are automatically available as block. Maybe a bit overhead if you just need to create one.

Another solution may be the BEAN Module. But just dropping the module name, never worked with it.


If you've made blocks before (in code). Make a block in code that pulls an uploaded image from the site to display within your frontpage block.

Then make an admin menu item / page for your user, with a simple FAPI form that uses the managed_file element type to allow them to upload an image.

Then in the form_submit function save the fid of the uploaded image using like variable_set('mytheme_frontpage_image', $form_values['values']['fid']).

It's not tons of code: hook_block ... you can use image_styles if you want, hook_menu and FAPI for the admin form.


After some research I stumbled upon the Image Block-module which solved the problem for this time though I'm not totally sold on the UX. But it has some advantages over the suggested solutions:

  • It provides a single image-field without the possibility to screw it up by accidently enter other text (as would be the case with a regular text-field+wysiwyg solution)
  • It gives the editor the ability to reach the edit screen when he/she can change the image via a context-menu attached to the image itself: no need for a settings page somewhere else in the system, and easy to remember.
  • It doesn't rely on a content-type, which I feel would be a bit over the top (as suggested) since I would just have needed one node.

Thanks for all the suggestions though!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.