| Project: | Image Assist |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Cross-posting:
[snip]
I'm currently investigating, if image.module is needed at all in future. Basically, Image module provides nothing more than a node with one image attached. In contrast, that's basically a custom content-type with just one imagefield.
So I've (dirty) hacked Img_assist a bit - just to see, if it could be an Imagefield_assist module, too. Guess what? It basically worked out.
[/snip]
see: http://drupal.org/node/119539#comment-305464
I wonder why there is no such issue in this (quite long) queue yet. ;) However, as contents become more and more CCK content-types, the chance of having all images in image.module based nodes decreases with each new feature in Imagefield (v5.x-2.x is right on the way with several great enhancements like ajax upload). Img_assist should therefore open the doors to re-use images of imagefields.
Comments
#1
I suppose all image related modules (or all modules that work with "image nodes") should have the ability to work with both Image nodes and node types that have an image field. This would apply to Image assist, Image gallery, Image attach etc. I'm imagining a setting where you can choose what node types you want to include in Image assist.
Keeping compatibility with both Image and Imagefield would be a big challenge though. It could easily turn into a real hack fest. :) I suppose we could maintain two separate versions of Image assist, of maybe have two different sub modules that take care of the integration with each image solution.
This is all very interesting, but I don't personally have any real nead for this. So I guess an effort like this would have to be done by someone other than me for the most part. I would be interested in seeing it happen though.
By the way, it's very cool that you already have a working example for Imagefield integration, although I haven't tested it myself.
#2
Hey Daniel -
I just wanted to mention how great it is that you're tackling this issue... thanks a ton for this and all your other contributions to Drupal :)
Lately I've been growing fond of Image Assist as compared to the other methods of handling images in Drupal (seems the most "usable" for end-users), but wished it could do the same for all my CCK types with Imagefields + Image cache scaling/cropping... and lo and behold (haha) here it is already on the way :)
Again thanks, and I'll try to help in any way I can (testing for bugs once you release it, etc).
#3
The patch doesn't work on the latest release of Image Assist (surprise surprise). Has anything else come of the patch? I'm actually a big fan of trying to spin off a separate module for Image Assist for Image Field Nodes.
#4
sun has some great ideas about what should be done with this module in terms of refactoring, splitting it's different functionalities into separate modules etc. Only question is, who will do it, and when?
#5
Me and another developer here are going to start working on generalizing Image Assist to support CCK nodes that have Image Fields. Hopefully this can be useful to everyone as Image Assist incrementally moves towards where sun envisions it going.
#6
So I've got an update to the work sun did before to integrate imagefield support. The patch needs to be reviewed, and I'm sure there are issues I haven't thought of and we haven't tested yet. It will add the following features (all options in the 'other options' area of the image_assist settings):
- support for imagefield (enabled optionally in the 'other options' area)
- you can choose which content type to use that contains an imagefield, only one can be used
- you can choose another CCK field to get the description
- the add node functionality when inserting an image works - you'll have the option to add a node of the content type chosen
Some things this doesn't do...
- resize each image - you are stuck with the original size image, it is just displayed at the asked for size in the html
Where this might break:
- I don't know the complexities of CCK that well. Things get strange in the CCK tables when a field is used in multiple content types and I haven't tested this.
- What will happen to Image node support? I'm fairly sure everything will work fine and did a bit of testing. But it should be tested more since our main environment doesn't use the Image node.
Hope this is useful to people.
#7
Sorry, Michael, but 90% of your patch are completely unnecessary or unrelated (tab-) changes. No one is able to review what you've actually changed. Please re-roll.
[EDIT]
See:
- http://drupal.org/coding-standards
- http://drupal.org/patch/create
#8
Sorry - I hadn't realized eclipse had decided to tabify every function I touched. This should be cut down to the actual changes and in space, not tab format. Also note that the patch is off the 5.x-1.x-dev tree, not the head (contrary to the version in this thread).
#9
Looks better. However:
- Patch is reverse; you might want to create a patch directly against the DRUPAL-5 branch instead of your potentially outdated working copy.
- You're testing module_exists() subsequently in img_assist_admin_settings() whereas one test would be sufficient.
- There are some commented out debugging? lines
- Isn't LEFT OUTER JOIN just the same as plain LEFT JOIN?
- Please remove all "mbehrman [date]" comments.
- The changes in img_assist_display() look like Image module compatibility has gone.
...and more, but I have to break now.
#10
Okay, I'll aim to make those changes and get it working on the current DRUPAL-5 branch. I made these mods for work (see chromix above) and they're sufficient for that purpose. But if I've got some down time I'll try to polish it up a bit more. Thanks for looking it over.
#11
subscribing..
#12
@mbehrman: Any updates? I would really like to review this patch :)
#13
I just found this thread. I a very interested in having an image browser that works with ImageField.
Is there any recent status on this? Is the patch included in v6?
#14
Ouch. I'm trying to do this against 6.x head, I notice that the sql doesn't take into account table prefixes.
EDIT: It actually does, but it does queries even when tables doesn't exist. It is taking it for granted that some kind of table and data will be returned.
I'll digg deeper.
#15
I don't think this patch can work together with the views based browser, as it is now. I tried to find out how img_assist_thumbs works in 6.x head, and there are no similarities to the info in the patch in this thread.
Furthermore, the view img_assist_browser stopped working after I patched all other patchable functions based on the patch in #8.
#16
img_assist_nodeapi is way different from what #8 patched against.
#17
subscribing
#18
subscribing
#19
Is there a chance that this patch makes its way to a release version of Image Assist in the near future?
#20
Bump.
Imagefield and other field related modules seem to be the way to go.
For instance for stock photography websites, the main node will be an ubercart node with imagefields.
Lack of Image_assist is the only downside from using imagefield over image.
#21
I also think a patch to support imagefields is going to grow in demand over time. There is a huge deficit right now for an easy way to insert imagefield uploaded images into a text field.
#22
We certainly need a way to insert images to cck content types, but I'm not sure if mixing in support for imagefield is the right thing to do. AFAIK the plan is that on the long run, Image will internally use imagefield or filefield, so img_assist would not need to worry about that.
#23
In the prosepoint install profile there is a modified tinymce w/filefield support. Unfortunately it is tightly woven into a couple of other custom modules.
But, at least it works for image fields
#24
Someone should inform prosepoint then that TinyMCE module has been officially abandoned in favor of Wysiwyg API.
Re-assigning proper version. Now that we are using Views, the whole issue boils down to making the row style plugin more flexible, allowing the properties page to work with a fid (replacing the nid), and making the macro tag aware of the new image source, using different parameters (while generating and parsing of macro tags is deferred to Inline API).
#25
Sounds very promising! I'll take a look at version 3.x tonight and see if it is within my capabilities.
#26
I have mailed the developer; I think it is yet another TinyMCE (javascript) wrapper for Drupal, not a rework of the TinyMCE (module).
#27
sun: so you want to go the fid route? What do you plan to do with the title and description of the image? To be honest I don't like the possible implicitations of multiple value image fields.
#28
There is some interesting discussions around these issues in #208136: Imagecache/Image* support
See for example this rant and the following comments. I think there is agreement that Image Assist should continue to work with nodes as opposed to just image files. At least until there is some other rich entity/thingy/object in Drupal that can be used to represent an image.
#29
Any news on this?
If image assist works only with nodes then multi-image nodes would not be usable.
#30
I think an ideal tool for insert images inline to text should be able to
#31
I understand this all a lot better now.
"the whole issue boils down to making the row style plugin more flexible"
Do you want to use files as the base table? Both imagefields and image.modules images are stored in the files table, so I don't know if we should use the node table. It could only be a bit problematic to leave out the entries of the derivatives.
#32
I think in order to make this module really flexible, it should be based on views only.
#33
@kirilius, it already is. What am I missing?
#34
I already is but it still depends on the actual type of image node that's behind it - Image vs Imagefield
#35
What is the status of this?
Is this project helpful in accomplishing imagefield support?
http://drupal.org/project/filefield_sources
#36
@sgriffin We first need a WYSIWYG image tool that works with ImageField, then that tool could support FileField sources as well.
Wiki page summarizing the different projects on ImageField and WYSIWYG editors : http://groups.drupal.org/node/21639
#37
IMHO, an even more basic starting point would be to be able to use images attached to the the current node via the Upload module.
#38
Any status?
#39
http://drupal.org/project/imagefield_assist ?
#40
Lancelot, ImageFIeld assist is far for complete and it does not support views yet.
#41
There is a patch to use views in imagefield_assist
#42
sub
#43
subscribing
#44
Subscribing. Getting this done would hopefully also make it very easy to create a D7 version of Image Asisst.
#45
I would love to see the converted image to imagefield works with img_assist.imagefield!
Reference:
http://drupal.org/node/201983
#46
Lord I would give my first born to see this implemented, it's one of the last pieces of my CMS and it all hinges on this.. Any dev patches for 6.0 work that bring this functionality in? Even in a limited way?
EDIT: For the most part the dev version of imagefield_assist does the trick.. It isn't quite as functional, there's no way to split it off into my images and all images and it doesn't seem to be working with views yet but at least I can attach images from outside the traditional image nodes..
#47
subscribe
Is this likely to bee a won'tfix, considering that media module is planning to fulfill this role in d7?
#48
+1
#49
Hi, is there any update on this issue?
#50
http://drupal.org/project/imagefield_assist
That's probably the closest thing to an "update" you're going to get. It's essentially a fork of ImageAssist that allows for imagefield images.
#51
This issue is fairly closely linked with: #513096: The Future of Image in Drupal 7
image.module, if it upgrades to 7.x, will probably end up using imagefield, so this module will need to be able to too, if it is to be upgraded to 7.x
#52
Subscribing