I'm trying to use the CCK playlist feature.
I've put a filefield into a node type that I'm calling "slideshow", that allows multiple instances. The filefield is itself set to the "image" type, and its path is set to "images/slides", to correspond to the fixed path set in swftools of "sites/default/files/images/slides". I have further set the full node display mode of that field to "SWF Tools - playlist."

When I upload a set of images and try to view the node, the images fail to show... firebug reveals that the path that is being examined for my images is of the form:

http://mysite.com/sites/default/files/images/slides/images/slides/slide1...

As you can see, the fixed path is being appended to the filefield-specific path. This would appear to be something to do with this bit of code here, from the simpleviewer.module, starting and line 134:

    // Strip default sites path if it is present
    if (strpos($details['filename'], file_create_path()) === 0) {
      $details['filename'] = str_replace(file_create_path() . '/', '', $details['filename']);
    }

It's as if the strip isn't occuring at all. The resultant playlist file winds up looking like this:

<?xml version="1.0" encoding="UTF-8"?>
<simpleviewerGallery maxImageWidth="600" maxImageHeight="400" textColor="0xffffff" frameColor="0xffffff" frameWidth="0" stagePadding="0" thumbnailColumns="4" thumbnailRows="1" navPosition="bottom" title="" imagePath="/sites/default/files/images/slides/" thumbPath="/sites/default/files/images/slides/" enableRightClickOpen="" backgroundImagePath="">
    <image>
      <filename>images/slides/slide1.jpg</filename>
      <caption></caption>
    </image>
    <image>
      <filename>images/slides/slide2.jpg</filename>
      <caption></caption>
    </image>
</simpleviewerGallery>

and you can see that the filename somehow gets that path in front of it.

I've tried directly editing that code to make it stop doing that, to no avail. Which baffles me even more.

Comments

datawench’s picture

Update: I've coded a small workaround in the module itself, that strips out the offending path info. I hadn't been able to see it before because my browser was caching more thoroughly than I knew. As far as I can tell, the underlying issue still exists, though.

escoles’s picture

Sounds like a duplicate of related to this:
http://drupal.org/node/401140

(Thinking the actual error is before the individual modules.)