Home » Groups » Slideshow

The future of slideshow.module

kkaefer@drupal.org's picture
public
group: Slideshow
kkaefer@drupal.org - Mon, 2007-05-14 20:20

I want to share my plans for slideshow.module with all module users and get their opinions on some of the topics.

  1. Make slideshow.module dependent on imagecache.module
    Since slideshow.module frequently resizes pictures, I think it's easier to "trust" that task to a dedicated module which is a lot more stable than slideshow.modules built-in file manipulation options.
    This means that the size dropdown for each slideshow will disappear in favor of a imagecache profile selector dropdown, meaning that you can't have ultra-flexible sizes anymore but can select among multiple administrator defined choices.
    imagecache.module is widely used, not that complex and will most likely be available for future Drupal version rather soon since the only thing to port is the UI which is rather simple.
    Probability that this will happen: 80% (if nobody comes up with convincing arguments against it).

  2. Make slideshow a CCK field type
    This is probably a controversial step since it will make slideshow.module dependent on CCK. But since CCK is scheduled to move into Drupal core and already used on most sites anyway, I think I can risk this move.
    While moving the module to CCK provides much flexibility, it also requires a rather drastic change: So far, slideshow.module uses core's upload.module to manage the uploading process and just takes files attached to a node and shows them as a slideshow. This is a pretty straightforward approach that hardly can be beat in terms of simplicity.
    However, there are certain features that upload.module and its file management lacks: First, it's not possible to reorder slides and secondly, it makes it impossible to attach images to a slideshow.
    While I feel that I have to do that step eventually, I'm not sure if it's already the right time for this move. Please post your opinions.
    Probability that this will happen: 30%

Feel free to post further feature requests.


» Login or register to post comments
 

On the CCK question, a big

TKS - Thu, 2007-05-17 15:36

On the CCK question, a big plus in favor of turning slideshow into a fieldtype is the theming flexibility this would provide. That's a problem for my site right now (see http://drupal.org/node/143961), and I'd think there are plenty of others who'd value the ability to "hard-code" the slideshow location somewhere other than above/below $body.

Of course, that flexibility can probably be managed with the current version of slideshow.module, too, with a bit of well-crafted php. (I'd welcome any helpful hints on that front -- I'd be happy to test/experiment and share what I come up with if kkaefer or others can point me in the right direction.) But there are other benefits of going the CCK, route, I think -- easy integration with Views, for example.

So assuming that the upload process could stay just as simple from a UI standpoint -- as CCK's imagefield does, for instance -- I'd vote yes on making slideshow a CCK field type.

On the imagecache question, I'm basically agnostic. Let me throw out another possibility, though: I you do decide to go the CCK route, you might want to look at piggy-backing on both CCK and its imagefield.module.

No idea how practical it would be to "slideshow-ify" the display of imagefield images, but I do know that imagefield.module allows for multiple values, resizes uploaded images to a max resolution set for that field/nodetype combination, and offers both Alt & Title fields that could presumably be used for the caption.

I don't think it would easily allow for re-ordering of slides, though, so that might be an issue. But since it sounds like you want to minimize both dependencies and function redundancy, it's something you might want to consider. Just my two cents...

Thanks again for all the work you've already done on this module. And if there's anything I can do to help (probably in the testing/documentation areas... my php "skills" are not a pretty sight), please let me know.

TKS

Login or register to post comments

I’d think there are

kkaefer@drupal.org's picture
kkaefer@drupal.org - Thu, 2007-05-17 17:35

I’d think there are plenty of others who’d value the ability to “hard-code” the slideshow location somewhere other than above/below $body.

Actually, it is possible to supply an arbitrary position within the node’s body field by using the [slideshow] tag and selecting “Tag” as the slideshow position in the advanced config options.

So assuming that the upload process could stay just as simple from a UI standpoint — as CCK’s imagefield does, for instance — I’d vote yes on making slideshow a CCK field type.

The last time I checked, imagefield.module didn’t support inline uploading like upload.module does. I think that’s a killer feature as it speeds up the uploading process enormously.

I don’t think it would easily allow for re-ordering of slides, though, so that might be an issue.

Optionally, we could also improve imagefield.module to support reordering the items. Maybe this can even be implemented in an even more generic way directly into the CCK multiple values framework so that other fields also profit.


Login or register to post comments

The last time I checked,

TKS - Fri, 2007-05-18 14:21

The last time I checked, imagefield.module didn’t support inline uploading like upload.module does.

It's actually gotten much better on that front -- see this screenshot: http://newamerica.net/files/imagefield_screenshot.png

The allow multiple values option is turned off for the field in this example, but it is allowed in the module's 5.x version. Imagefield was a little rough in its early incarnations, but seems to have gotten much better in the last couple months. And the idea of providing for re-ordering in a more-generic, CCK-wide way strikes me as a great idea -- if CCK is indeed the way slideshow ultimately goes.

...it is possible to supply an arbitrary position within the node’s body field by using the [slideshow] tag

I've played with that feature on a personal site, and it works great -- but if a site's CCK node-types don't have a $body, you're out of luck. (That's an argument in favor of preserving the core body structure, I know -- for this module and many others -- but....)

I guess what I'm saying is that it would be nice to have a middle ground, even if you do have the body field: The ability to custom-theme the location of the slideshow so that it's someplace other than above or below the body, but then have that placement consistent on every node -- as opposed to allowing/requiring the user to place the tag into the body content each time.

Again, the CCK approach would do this, but I'm hoping there's a fairly easy way to do it with the current module. (The service_links.module, for example, keys off the body or links sections by default. But it also includes two short code snippets -- one for the node tpl file, and one for template.php -- that let you drop the "service links" anywhere in the page you'd like. That allowed us to place them in our "shoulder box," along with the pullquote and selected taxonomy links: http://newamerica.net/publications/articles/2007/pop_up_cities_5264)

Sorry, I don't mean to go on and on about the specific need of one site -- just trying to explain my thinking on the value of an in-the-template call.

Login or register to post comments

> Sorry, I don't mean to go

kkaefer@drupal.org's picture
kkaefer@drupal.org - Fri, 2007-05-18 16:11

> Sorry, I don't mean to go on and on about the specific need of one site -- just trying to explain my thinking on the value of an in-the-template call.

I always look for ways how people are using my module. Sometimes, they try to achieve things I have never thought of. Knowing all the use cases allows me to make the module more generic, which is obviously a good thing.

And I definitely have to check out imagefield again. Looks like it has evolved a great deal since I tried it last time.


Login or register to post comments

TKS, I agree with a lot of

ac@drupal.org - Thu, 2007-05-17 16:13

TKS,
I agree with a lot of what you are saying. We used imagefield with slideshow module here for the reasons you outlined at the start of your post. We also removed imachecache (which was running on the imagefield images) as it became redundant.

I would like to see slideshow.module as a cck field with a dependancy on imagefield and an option to use imagecache if it is enabled.

Thank you to Konstantin, the slideshow module is great. We are happy to give you any of the code if you want. There is not much to it but its there if you need it.

Login or register to post comments

Hmm...

NancyDru's picture
NancyDru - Tue, 2007-05-29 00:16

You must be reading something I haven't seen. From what I've seen, CCK is NOT moving into core - at least not in 6.x. Some small parts of it are already in 5.x, but the rest remains an add-on.

I am currently responsible for maintaining 16 sites and not one has CCK. As a matter of fact, were it not for other modules forcing it, none would have Views either. Neither module is universal, nor even close. I would encourage you to rethink this change - at least for now.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database


Login or register to post comments

CCK for slideshows -

amitaibu's picture
amitaibu - Mon, 2007-06-25 17:54

CCK for slideshows - actually, now there is this module:
http://drupal.org/project/slideshow_creator

What will be the main difference between both modules?

Also, check this feature (to be)- Slideshow from Views, which I believe will make a difference.


Login or register to post comments

Any news?

expat9@drupal.org - Wed, 2008-08-27 07:54

Hello there,
Any news regarding slideshow + cck?
This would be very handy :):)
Thanks,
Expat9

Login or register to post comments