hi, i'm just wondering if it's possible to make an advanced slideshow without having to use imagefield/filefield? we already use FCKeditor and IMCE to do our file uploading, so we don't need help doing this. therefore, all we need, theoretically, is a string field instead, to tell ddblock where the image is, instead of an imagefield.

is this possible? if so, what would need to be changed? (we are following the tutorial, but are newbies to ddblock and the adv. slide show :)

the reason is that we are a multi-domain drupal installation (using Domain Access module at http://drupal.org/project/domain) because we are using one drupal for several separate departments in our School.

therefore, we set things up so that the files/ directory has subdirectories for each department.

therefore, using ImageField and FileField, in order to get them to store the image in the right place, (files/anthropology, or files/sociology) for each domain, the way we would have to do it with ImageField is to also load the token and token_custom modules, and set up a custom token for the current domain being used, and then enter that token into the "Path Settings" section, "File Path:" setting of the particular Image field we've added. This means adding four more modules, and we'd like to avoid it, since we already have another way to upload. Is there a way just to store the path of the image, i.e., "files/anthro/slideshow/picture01.jpg", instead of using an Image field?

thanks

CommentFileSizeAuthor
#5 template2.php_.txt6.98 KBjastern
#3 template.php_.txt6.62 KBjastern

Comments

ppblaauw’s picture

Status: Active » Postponed (maintainer needs more info)

You can make a text field in your content type where you put the path to the image.
Include this field also in the view.

Uncomment the drupal_set_message debug lines in the preprocess functions to see what the fieldname is created by cck/views

And change this in the preprocess function.
Instead of using the fid of the file to find the real filepath just use the field which contains the filepath directly.

Hope this helps you further, please let me know.

ppblaauw’s picture

Tried this on our test server, and have some more information.

1.) Using IMCE you can make a text area field in your content type. This field gets it's content with the IMCE widget.
In the IMCE cofiguration page you set the id of the field.

2.) Include this field also in the view.

3.) Uncomment the drupal_set_message debug lines in the preprocess functions to see what the fieldname is created by cck/views

And change this in the preprocess function.

Instead of using the fid of the file to find the real filepath just use the field which contains the filepath directly.

You can use:

    //  add slide_image variable 
    if (isset((isset($result->[name of IMCE Textare field])) {
        $vars['slider_item']['slide_image'] = $result->[name of IMCE Textare field];
    }
    else
    {
      original code for getting images
    }

This way it would get the image from the IMCE field when this is set otherwise from imagefield.
You can also delete the whole original code for image field functionality if you don't use it.

Hope this helps you further, please let me know.

jastern’s picture

StatusFileSize
new6.62 KB

hi, philip,

thanks for your quick responses.. we took a few days to work on it.. because the tutorial is long we kind of messed up in a few places and forgot things.. we did finally get it right.

we did create a text field we named "field_imagepath" (with the label, "Image Path")..

in the view, we changed it like the others, so it was plain text.

doing it this way, the fieldname created by cck/views came out as node_data_field_pager_item_text_field_imagepath_value

we like this way, because it is much simpler (we don't have to install other modules: ImageField, FileField, and ImageAPI). As I mentioned above -- in our case, to use the ImageField method, we also had to add Token and Token Custom modules, just to make sure that the images got uploaded to the correct subdirectory for each of our subdomains. So that was 5 more modules total.

i'm attaching our version of a working template.php.txt if it is of use to anyone. it is indeed very much like you suggested above: it accomodates both methods of getting the location of the image file: It will first look for our "field_imagepath" field. If it doesn't find it this way, then it will get the path of the image from the normal ImageField record -- your normal way of doing it.

thanks again for all your very helpful and speedy responses. our web designer totally loves ddblock, by the way :-)

ppblaauw’s picture

Title: possible to avoid use of imagefield? » Using filepath of images instead of using imagefield, filefield, imageAPI modules
Status: Postponed (maintainer needs more info) » Fixed
Issue tags: +content, +Advanced slideshow

Thank you for your feed back.
Changed the issue title
Added tags
Set status to fixed.

jastern’s picture

Title: Using filepath of images instead of using imagefield, filefield, imageAPI modules » possible to avoid use of imagefield?
Status: Fixed » Postponed (maintainer needs more info)
StatusFileSize
new6.98 KB

oh, one more thing -- this morning we discovered IMCEImage (http://drupal.org/project/imceimage) which allows us to create CCK content types with "IMCE Image" fields in them, containing essentially just a "path", but also allowing the IMCE interface to pop up for the end-user to choose (or upload) the file they want. This is better than using simple IMCE with a textarea field. It's more similar to ImageField, but we find IMCEImage is:

  • a better user interface than ImageField because
    • one gets a nice pop-up filebrowser from where one can see what has already been uploaded to the server, and
    • it draws the actual image for you once you've chosen it
  • simpler than ImageField, since it requires only 2 extra modules (IMCE, IMCEImage), not 3 (or 5, for multi-domain setups).
  • easier for multi-domain setups, since the subdirectories for file uploads for each domain can already be set up from within IMCE

to make this work,

  • Content Type: in our news content type, we can now choose to add an "IMCE Image" field. we did, and called it, "field_imce_imagepath".
  • View: we of course had to also add this to the view (instead of an ImageField), but no extra settings were required other than to add the field
  • template.php: with this new field added to the content type, the fieldname came out to be named, "node_data_field_pager_item_text_field_imce_imagepath_imceimage_path", quite long, but still, works. We took this name and changed our template.php. we're including this second version as an attachment. it will look first for an IMCEImage field, and, if it can't find it, then an ImageField field (as your tutorial defaults to). So this template.php will work with both setups.

it would be nice to see ddblock and the advanced slideshow tutorial change to accomodate IMCEImage module, since it's such a simple mod, and would get more (IMCE oriented) users over to using ddblock. This might not take much more than just updating the template.php.txt in your Export_files_V1.1.zip download file, to use this one (since it accomodates both methods in one file), and adding some short alternate instructions (like above) for those going the IMCE route. Let me know if you decide to go that way and would like some help doing stuff..

thanks again, philip..

jastern’s picture

oh, crud. i posted from an old window and it re-set some of your changes. sorry! :-) i'll try to set them back here..

ppblaauw’s picture

Title: possible to avoid use of imagefield? » Using IMCE modules instead of using imagefield, filefield, imageAPI modules
Status: Postponed (maintainer needs more info) » Fixed

Thanks for your write up.

Changed title again to make people aware that they can also use IMCE instead of Imagefield to provide the images for the dynamic display block slideshow.

Will have to think about how to add this option to the tutorials. Appreciate your offer to help. I think you did already a lot with your writeup.

Status: Fixed » Closed (fixed)
Issue tags: -content, -Advanced slideshow

Automatically closed -- issue fixed for 2 weeks with no activity.