imagefield for D6

subscribing

subscribing

subscribe

subscribing

Subscribing!

suscribe too

subscribing

I'm looking forward to this update as well! :)

Eagerly awaiting a D6 release :) (and imagecache too :) )

> cck (HEAD ver) is available for D6. Only Synchronization is missing. Is there a schedule for imagefield port ?
I am confused. is cck for drupal 6 available or is ImageField available for drupal 6 available? Do I have to do a "cvs checkout" or whatever to get the code?

cck is available for testing in head. Yes you would get it through CVS

Hi,

Any update on imagefield for D6?...

TIA,
Boaz.

subscribing

subscribing

Oh my fricking goodness.... all you people who 'subscribe' to issues drive me freaking insane! Learn to make a reasonable comment or watch RSS feeds! stop cluttering my issue queue or write some stinking patches yourself. I'll update to D6 when I'm good and ready and not a moment before.. You may still have some time to wait since I haven't started working with D6 yet, and it isn't even on my development horizon yet. I think I may get to D6 projects in summer or fall.

dopry,

What is the time effort to port ImageField to D6 ?

He mentioned it above in comment #15?

http://drupal.org/node/224813#comment-787419

dopry,

I hope it's okay that I added ImageField to this list. Feel free to edit. :)

Sounds good.. The real hold up is a chain of dependencies...

I need to get the 2.x releases out, the 2.x releases are blocked by a missing imageAPI feature. ImageMagick support. The Imagick support shipping with it is broken. It's either the imagick extension or php's internals that are broken, so if you happen to be a php internals guru with experience debugging extensions and objects hit me up on my contact form I could use a bit of help. I'd love to have command line imagemagick support instead... imageapi_imagemagick.module... I've put in a skeleton with an example open and close function... just need some one to fill in the blanks and I'm shy on bandwidth for implementation and testing.

So basically once I get a stable release of ImageAPI, I'll move onto a stable release of ImageCache 2.x, then ImageField 2.x...

The I start Drupal 6 ports at ImageAPI then ImageCache, which I already have patches for... So I can get to imagefield more quickly.

.darrel.

Heck I'll throw in a mostly complete cmd line imagemagick module for imageapi if some one can test and debug it ... :)

@Dopry: is there any information about this ImageMagick problem in ImageAPI? Was it trying to use MagickWand?

I can take a look at it if there is some info on the problem posted..

[subscribing]

I'm taking a stab at porting Imagefield to D6 at the moment. I've got the settings working and the imagefield displaying, but not yet able to upload any images ;)

I'll continue poking away at this and ultimately try to keep the patch size down by avoiding changes where ever possible, but the port to D6 really is quite an overhaul. At least we can get rid of all that crazy session logic now with the new FAPI.

dopry, i've posted a few patches to get the command line imagemagick code working but i'm coming to the conclusion that there might be a fundamental disconnect between the way that imagemagick works and the way imagecache would call it. for testing i've been loading a page with ~30 thumbnails of 2-5 MB files and it's killed both my laptop and server. you end up with 8 instances of convert running at the same time eating up a ton of memory and disk IO and blocking each other. it think the trick to getting it working would be queueing up the calls to convert so that only one is running at a time. anyway i'll follow up on this in the imageapi queue.

Okay this patch is fully working in every scenario I've tested. Important changes/notes:

- Imagefield now claims $element['#type'] = 'image'
- Supports drag and drop :D
- Even though CCK handles multi-value fields now, imagefield still necessitates manually implementing the multi-value widget anyway.
- Removes all SESSION code and uses the handy $form_state['storage'] instead.
- The validate functions now upload the file to final destination (as per-norm in D6, thanks dopry :D).
- Insert/update functions just set file status to permanent.
- All preview code was removed thanks to the above two points.
- Switched dependency from upload.js to the AHAH framework
- Converts widget-level image limit to use the new CCK multiple limit. The new limit is on the field level, so that could cause some upgrade strangeness for some users.

The new module is ~150 lines shorter, not quite the same benefit that link.module saw (~250 lines shorter), mostly because imagefield can't use the standard multi-value handling. Still an improvement though. The upgraded module is feature-equivalent to the D5 version, other than the addition of drag and drop.

Way cool, Nate !
Could you summerize why imagefield need is own implementation of the multiple widget ? I was sort of hoping CCK's default one would be genereic enough...

Hi Guys...

Patch sounds impressive!

I am having problems patching but... I get 15 / 19 hunks fail... just wanted to check... which version do I need to patch?

After sleeping on this then giving it new testing this morning, I realized I hadn't tested the single-image upload use-case much at all. There are some bugs with presentation and uploading two images will not display the latest image in the node form. I'll refactor today and repost.

@yched: Well the core handling *could* have worked but it was a little overwhelming at times to have 3 fields show up on every click of "more" (alt, title, and upload). The default image field then provided 6 fields by default (two complete imagefields). Instead I wanted to maintain the current behavior of imagefield with a single upload field then alt and title fields available after uploading. Anyway, perhaps we could look at switching to the default behavior later.

@mojoinst: Apply against the DRUPAL-5--2 branch.

fixed bad a t() call where the arguments were incorrectly being passed to the enclosing function.

Fixes since #30:

- Upload of a single image now works correctly.
- Added clear-block around single image display.
- Now works correctly when an imagefield is placed inside a field group.
- Files saved in the correct directory according to field settings.

What are the odds of getting a version 6 module? :) I'm not that good with patches...

@Boletus, it's inevitable that a D6 version will come out some time. Please respect the time of maintainers and avoid posts that don't contribute to the effort to complete this task.

Boletus, it's actually a pretty simple process. take a look at http://drupal.org/patch/apply keep in mind that you'd want to apply the patch to the current HEAD snapshot.

testing out the patch in #33 and noticed one thing. the files directory check seems like it's creating an extra layer of files directories.

my files directory is "sites/default/files" and the field has "images" as it's directory. when uploading the first file i got the following messages:
* The directory sites/default/files/sites has been created.
* The directory sites/default/files/sites/default has been created.
but when i saved the node the file it ended up with filepath = "sites/default/files/images/me_on_beach.jpg" as it should.

Thanks! I didn't want to upset anybody, but if I can patch together a version 6, I can help test it.

Tried Patch, with mixed results. What did I do wrong?

Edit: Attached result as a file - quicksketch.

I uploaded the module and enabled it. Got a

warning: Missing argument 1 for imagefield_menu() in /home/web12323/domains/example.se/public_html/sit/sites/all/modules/imagefield/imagefield.module on line 13.

Added an imagefield to a page content type:

warning: Missing argument 3 for form_set_value(), called in /home/web12323/domains/example.se/public_html/sit/sites/all/modules/imagefield/imagefield.module on line 382 and defined in /home/web12323/domains/example.se/public_html/sit/includes/form.inc on line 1285.

Boletus, run update.php after applying the patch. This will clear the menu system cache which is what is likely causing those errors. Also, make sure you're running the absolute very latest version of imagefield (not just RC6) from CVS.

Here's an updated patch which should prevent the duplicate directory creation noted by Drewish in #36. It also properly throws an error if the destination directory is not writable. Previously it just failed silently (support requests just waiting to happen ;).

i updated the imagecache patch to start working on the field formatters: http://drupal.org/node/232624#comment-807703
the one hitch that i can see is that the node id isn't being passed in so you can't have an image that links to the node. i'm trying to track down a solution: http://drupal.org/node/157176#comment-807704

Two more fixes:

- Adding content_notify() calls in hooks enable/disable and install/uninstall.
- Adding nid in imagefield_field($op == 'sanitize') so that imagecache formatters can link to the node.

Hi Guys... looking really good so far!

I have installed and all is working well... except for when i goto upload a file.

I have set the image directory to 'thumbnails', and when I try to upload I get a message 'The directoy sites/default is not writable'.

Is there anything I have done wrong?

Thanks for reviewing mojoinst. I seem to be having trouble getting that path saving correct. Here's another updated patch that I've tested after moving my files directory to sites/default/files (I could reproduce the problem you noted after changing this setting).

Thanks for teaching me to be of some use in the process. ;)

Stupid question: do I apply the patch to the HEAD version always, never to the previously patched files?

I love it.... :-)
Works pretty well...

I installed a new version of Drupal 6.2, and enabled just CCK Content module and imagefield HEAD version, patched with imagefield6.patch from comment #45.

I downloaded the head version as instructed from http://drupal.org/node/96519 in comment #35.

Still gets the following when enabling imagefield:

warning: Missing argument 1 for imagefield_menu() in /home/web12345/domains/example.se/public_html/lab/sites/all/modules/imagefield/imagefield.module on line 13.

I am supposed to add the patches cumulatively?

I put the patch file in the imagefield folder and run Patch < imagefield6_4.patch from PuTty.

Very nice work with the patch...

I have corrected two bugs:
1) it's ok for 'image path' to be empty
2) image no longer belongs to one node, and therefore you can't test if you have permission to view the node its attached to

Boletus, I appreciate your efforts to test this out. each patch should be applied on it's own, e.g. to test the one in #49 you'd reverse the previous patch to get a clean copy of the module and then apply the new patch.

it still seems like you're having trouble getting the patch applied though. i tried repeating the steps i'd given you and it looks like i was wrong, the patches are against the DRUPAL-5--2 branch not HEAD like i'd said. the problem is that there isn't a -dev snapshot for DRUPAL-5--2 and the -rc releases are a bit out of date.

so you could either use CVS to checkout the DRUPAL-5--2 branch and then apply the patch or just manually download the files from the cvs web app: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/imagefield/...

whoops, not sure how that got changed.

Nice jrgensen. I tried that regex for several minutes. The simple strpos() does the job very well, not sure why I was wanting to use preg_match() so badly. Both changes look great to me.

You wouldn't mind hinting what patch command parameters to use? I downloaded the 5.2 files and applied the patch6_4. Most of the patch attempts failed.

How can I use CVS to checkout code? Do I need some special permissions?

Perhaps somebody could zip and attach the latest patched imagemodule folder for me to test, since I'm such a total unix moron. :/

jrgensen, I'm not sure the imagefield_file_download() implementation is correct. core's upload module's has got some issues (basically it assumes right now that no other modules would be accessing files). but we need to look inside the table that we use to join {files} to {node} and make sure it's a file that we own before checking for user_access permissions.

Boletus, check out http://drupal.org/node/321 for help with the CVS commands.

as a follow up to #54 i just posted a patch for the upload module: #247095: Upload.module hard-codes 'view uploaded files' permission check

Lo and behold! :) It actually worked! ... and there was much rejoicing ...

So. What's to test?

I seems that if I set the Global Setting Number of Values to Unlimited, and upload 1 image the node states:
You can only attach one image to this field. Delete the image if you wish to be able to upload a different one.

Hmm, it seems that in some kind of backwards-compatibility quirk, CCK defines "unlimited" as 1 and 1 as 0.

<select id="edit-multiple" class="form-select" name="multiple">
  <option value="1">Unlimited</option>
  <option value="0">1</option>
  <option value="2">2</option>
  <option value="3">3</option>
  ...
</select>

I suppose this makes sense for statements like if ($field['multiple']), because 0 means "not multiple". 1 means "multiple" (unlimited). Then every higher number is a specific value. So let's fix on our end.

quicksketch, i'd just run into that and was going to report it. glad you're so on top of it ;)

@drewish would you elaborate on #54
We don't know how the file ended in the files-folder, and there is no marking of where it came from...

what do you meen by 'a file that we own' is it the user or the module that own the file?

jrgensen,

We don't know how the file ended in the files-folder, and there is no marking of where it came from...

what do you meen by 'a file that we own' is it the user or the module that own the file?

of course we know which files in the files directory are "our" files, it's tracked in the database. otherwise how else would we be able to get a list of the images associated with the node? we need to change the query to join {files} to {node} via the CCK tables so that the only matches we consider are files we've uploaded. i haven't looked into the exact SQL to do it because of the database magic CCK does, but it's obviously a solvable problem.

Hi all...

have installed and implemented... all working fine from what i can tell with latest patch!

one quick question... is it possible to control the output of the image using the theme template?... ie... create the field... hide the standard output and pull the image into a certain position using the the theme node.tpl.php

sorry if this is a noob question...

i am new to drupal and made the decision to jump straight into 6... really like the program and look foward to becoming a (hopefully valued) contributor.

any help would be much appreciated...

i assume it would be something along the lines of hide the field in all outputs then retrieve from database in them template... but if someone could point me in the right direction that would be great!

thanks

mojoinst

ok found it :)

use the $node->field_name[0] array :)

OK... think i have found a bug.

(maybe not.. let me know :))

have created an image field for stories and book pages - all fine when accessed as user 1... but when any other user tries to edit or create content... they image field doesnt display.

cant find any place to actually asign permissions for the administration of images.

something im missing?, something thats on the todo list? or something missed?

apart from that... have done alot of testing... all seems for be functioning well!

This patch fixes the multiple issue so that imagefield properly recognizes $field['multiple'] = 0 as Unlimited and 1 as a single image upload.

It does not fix the imagefield_file_download() problem mentioned by Drewish in #54. Removing the node_access() check is a good idea at this point because like jrgensen mentions, there is no longer a $file->nid to check against since a file can be associated with more than one node. There is already a "TODO" mentioning that there should be a lookup to see if files are actually owned by imagefield. Since this is already an issue in the Drupal 5 version, I'd like to say we should let it slip by until we fix the issue in both versions at once. In the mean time, this patch still includes the removal of node_access().

@mojoinst, I'm able to use imagefields fine with any user, not just user 1. It is a bug, but we need to figure out how to reproduce it.

Should one unpatch the imagefield files from the changes made by the 6_5-patch before applying the 6_6-patch?
$ patch -R < imagefield6_5.patch
...
...
$ patch < imagefield6_6.patch

patch 6_6 does not work that well. The node I'm testing, with 3 imagefields, won't render at all. Drupal times out after 30 sec. So I deleted it and started fresh.

If I create a new node of the content type that have the 3 imagefields, it's not possible to add images. Where the upload fields used to be there now is three lines:

You can only attach 0 images to this field. Delete an image if you wish to be able to upload different images.
You can only attach 0 images to this field. Delete an image if you wish to be able to upload different images.
You can only attach 0 images to this field. Delete an image if you wish to be able to upload different images.

The setting in the field number of values (images) is set to 1.

If I set one field to unlimited values (images) I get an upload field when I create a new node. The image uploads, but at the same time a huge red box appears, stating:

You are only allowed to upload up to images.

:) Almost looks like I'm the one that wrote that message ...

The Alt and Title fields does not work like they should. Even if I click the boxes, the setting won't stay.

Just wanted to drop a line saying the patch is looking good with a cursory review. I'm finishing up some imageapi/imagecache fixes for the 2.x branches... I'm going to try to get around to reviewing this patch next week I hope...

It's not possible to create a node with imagefields set to unlimited, since the node cannot be saved.

If I set number of values to 10 for a field, I can add images, and when I press save, the page is created but the page stays in edit mode. For each time I press "save" a new instance of the page is created.

Thanks again Boletus... This multiple thing really twists my logic around. I'm going to extensively test this one before posting another patch.

I'm only pleased to be of some use... ;) Please let me know if I can help you test.

I think I have almost got the hang on checking out code from CVS now and applying and reversing patches. And I'm as good at usability as I am incompetent a programmer. And if it can be broken, I'll break it. :)

Here's a patch which I'm pretty sure solves the multiple thing once and for all. I also found that I wasn't passing the #weight value to the widget, so a validation error could cause the imagefield to suddenly jump up higher in the form because it wasn't assigned a weight.

Boletus, I usually just throw away the previous file, get a new one, then apply the patch to the fresh copy when testing. Thanks!

It works much better. Seems the number of files you can add are fixed.

But I still cannot save the node/page. When I press Save the page reloads, states that the page has been created, and goes into edit mode again.

The imagefield.module revision was updated to 1.30.2.6.2.50 on 2008/04/18. I can't apply the above patch. Any ideas?

New patch for the updated version. Now with fewer changes since the code styling patch was committed.

Hi All...

I'm running patch 6_7 and am getting the following error whenever a user otherthan user 1 is uploading a file:

"The selected file LOGO.gif could not be uploaded. Only files with the following extensions are allowed: ."

in the configuration of the field i have "Permitted upload file extensions" option set to: "jpg jpeg png gif"

Anyone else having this problem?

Mojoinst

Note doesn't apply agaist head but since head hasn't been updated in months it looks like devel is done else where. 1 Hunk was offset against imagefield-5.x-2.0-rc7 so I am guess that the patch imagefield6.patch was done against rc6 but still appears to work with rc7.

Thanks
Robert

As per #29 and #50, apply against the DRUPAL-5--2 branch, which is the latest version in development.

quicksketch,

Don't get me wrong it works great for my use.

Can someone mail me a patched version? I cant use patch on my windows XP because of the XP bug.
notare ? gmail.com

ispace,

Sent you a copy.

ispace, there's no such thing as an XP bug. i've applied many a patch on XP you just need to convert the line endings. look for u2d or unix2dos.

doesn't apply any more, bunch of conflicts. i'll try to re-roll if quicksketch doesn't beat me to it.

looks pretty hairy... dopry applied some "code cleanups" which means that large swaths of code got change and i'm not familiar enough with everything dopry quicksketch did to wade through the changes and be sure i'm not missing anything.

Wouldn't it be easier to start a D6 Branch with one of the working patches? I'm not yet too familiar with patching, but it seems pretty confusing, when it's not clear anymore where to apply the patch in order to make it work.

Yikes, huge changes. rmiddle, sorry about the hard time I gave in #79, looks like RC7 was indeed the last version this applied to cleanly.

Dopry's been on a tear fixing a few last things before 2.0. Due to the changes between 5 and 6, the relevant code needs to be moved to completely different places. I'll look at this next week, this one I'm headed on the road.

quicksketch,

No big deal. I put my notes in there since it wasn't 100% clear were to run the patch against and head was by far way out of date. I understand the fun of patching since I have 2 Version 6 patches outstanding for other modules myself.

Thanks
Robert

hm,
using Drupal-6.2, CCK-6.x-1.0-alpha, I applied patch from #76 to imagefield-5.x-2.0-rc7. I could create the field type and add it to a content type. But when i actually try to upload an image I get this error (Javascript alert)

An HTTP error 0 occurred. 
/imagefield/js/ccksample/field_cck_image

"ccksample" is the contenttype and "field_cck_image" is the name of the imagefield

The selected image did get uploaded, I can see it when looking in the file system

Any ideas?

Greetings.

I've just deployed rmiddle's imagefield6.zip in #82 to a freshly installed Core 6.2, CCK 6.x-1.0-alpha.

However, whilst the AHAH-based "Upload" does work, upon "Save" the image information does not seem to be associated with the node.

This issue is readily fixed if we change this function in line 171:

function imagefield_file_update($node, &$file, $field) {
  imagefield_file_insert($node, $file, $field);
}   

to include an additional "return":

function imagefield_file_update($node, &$file, $field) {
  return imagefield_file_insert($node, $file, $field);
}   

Everything works fine afterwards.

Attached is a re-packaged .zip that includes only this fix.

Cheers,
Audrey

A new patch against DRUPAL-5--2, or a D6 branch as per #86 would be appreciated.

+1 for just starting the branch. CCK seems quite stable right now, and peole are willing to inspect and test this code (which is working fine for some of us). That's what -dev is all about. :)

I totally agree. Things are a little to messy here in this thread for a non-unix interface guy and photographer. So please help us to help this project. :)

I own a Canon 40D by the way and whole-heartedly recommend it! I want to chip in both to the Canon EOS 40D present and to the development of the imagefield6: if a usable 6.0 version is released in the near future.

yhager, Moonshine, Boletus : No one's forgotten about this but until dopry gets finished up with the changes he wants to make in the 5--2 branch it's going to be hard to keep this patch updated. I think the biggest help right now would be some serious testing of the 5.x-2.x code so that dopry can branch it and move on to 6.x.

rrmaniar28, it's marked as "code needs work" for a reason, wait until it's back to "needs review" to do any testing

this still doesn't work but it at least applies cleanly. i need to walk through dopry's latest commits and figure out what should be applied. i've tried to identify the areas that need work with D6TODO notes. i'm posting it so i can hopefully get some feedback from quicksketch.

Love this community. Love when all strength gathered. Thumbs up!

Are there still major changes coming for the 5--2 branch that would preclude us from trying to get a Drupal 6 dev version going?

It looks as though 5--2 has been at release candidate 8 for a couple weeks now and there is only one issue marked "critical" in the queue. What would help the most.. Verify this critical issue? More testing for 5--2? More patience ? hehe :)

Thanks!

I have tested that latest patch in D6.2 and only problem I found is field label in node add form, which is in field_ form instead of human readable form.

Could you zip and attach the latest patched module files for me to test as well? The patch mess is making me dizzy. ;)

Or should I not test this at all?

Rolled a new patch for use with 5.x-2.0-rc8.

I had to do a three way compare of 5.x-2.0-rc7, 5.x-2.0-rc8 and a patched version of 5.x-2.0-rc7 to determine what had changed and what changes needed to be carried over, so expect that there may/will be things I missed and things that are buggy. I can confirm that it patches and it appears to work. There also appears to be some debug code in there, I didn't look to remove it as it may be there purposefully.

A couple bugs I found in both the previous patch and my own patch:

When you set a limit for uploads that is more than 1, it will keep adding the upload field and allowing you to upload more images, it will throw an error saying you have to delete one of those images, but it did allow you to upload the image.
If you delete one of the images you will be able to save, however the image you deleted is not actually deleted and is perfectly accessible. I'm presuming that this is due to the images being directly uploaded instead of being uploaded to a temporary directory.

I tested the 5.x-2.0-rc8 version and these bugs did not exist.

Edit: Another side-effect of uploading to the destination folder instead of a temporary folder is that even if you choose not to post the node the files you uploaded still exist. It opens the ability to have a griefer/bot upload ridiculous amounts of files onto your site.

@deciphered: re: bots + uploads.

• It's still an issue with tmp files. just becuase they're in a tmp folder doesn't mean they aren't on your server.
• validation can prevent move_uploaded_file form ever being called. think akismet like antispam services.
• use quotas.
• wrong forum for that discussion.

but thanks for the updates to the patch I'll be reviewing it soon..

@all: If you do not have something useful to add to the testing or debugging of the ImageField/D6 Port, please do not comment.

Just a heads up, I'm having big issues on my test sites at the moment, constant HTTP errors being returned from the AHAH call during the upload process of Imagefield. These issues seem to be occurring with both the previous patch and my own patch.

I'm trying to hunt down whether it's a problem with my environment, my patch, cache or all the above, so I would appreciate if someone else could confirm that my patch actually does work as it's possible that a cache/environment issue on my end could have made it look like my patch worked when it may not have.

Update: After setting up 2 new temporary environments (rPath LAMP VM), installing Drupal 6.2 and CCK on both, my patch on one and the previous patch on another I still get the error on both. I still have absolutely no idea what the cause of this problem is, but my guess is if the previous patch worked for you, my one should as well.

@deciphered: You should start working with what I've committed to HEAD.

@all: I'm closing this issue. I'm opening a new issue for D6 porting. I ask that you do not subscribe and leave it as clear of a workspace as possible for the people testing the D6 port. I'm including some additional changes in the D6 port so the patches here are no entirely relevant, but usable. My changes are API centric and shouldn't alter the data model for the initial D6 port.

Please let me when Drupa 6 version of Imagefield is coming

Thanks

subscribing

What are the latest news on Image Field for 6.x?

What are the latest news on Image Field for 6.x?

We are all waiting for the-one-and-only dopry. I guess it's best to leave him alone, he'll get to it eventually.

Someone plz update this issue when it is released, so all subscribers will get a message.

Bug that needs to be fixed for imagefield to be used for serious testing: http://drupal.org/node/271017 (dublicate of http://drupal.org/node/268971)

For the past 4 h I was looking for the bug... couldn't find it though.

french guy also waiting for it !
thx
xavier

I'm not a programmer, but is there any thing I ca do to help?

not really. We need someone who can track down the bugs mentioned in http://drupal.org/node/224813#comment-883731

subscribing

subscribing -yes i couldnt install it also

this is great i think, i've searched it everywhere, why they didnt upload it to main "imagefield" page's download section

Hmm, not sure which to go with, the patches in #97 and #102, or the complete module in #90, but I chose #90. Something I noticed right off was that while "The maximum allowed image file size [is] expressed in kilobytes", the module is taking the value of that setting in bytes. For example, with that setting at 5000, the error returned is "The selected file [file] could not be uploaded. The file is 83.18 KB exceeding the maximum file size of 4.88 KB."

A check of file.inc indicates that file_validate_size() is looking for a $user_limit expressed in bytes.

the imagefield project node is totally fucked so it's not listing the 6.x compatible HEAD release. you can grab it here: http://drupal.org/node/96519 make sure to install the latest filefield and imageai modules too.

posted http://drupal.org/node/288443 about the screwiness with the module's project node.

drewish: Can this node be fixed? I see there is no DRUPAL-6--1 branch. I can help with CVS issues, contact me if needed.

re: #119 -- Darn! That means I'll need to be using PHP5, right?

yhager, there's no branch because it's not ready to branch ;) CVS is fine it's a problem with the project module.

drewish: Yes, I read #288443: Packaging script no longer repackages HEAD release nodes that don't know their version. after I posted, sorry. Keep up the good work!

Hi rmiddle

Thanks for ur effort, uploading images working fine but when i saved the content type i got the following error...

Fatal error: Call to undefined function imagefield_content_is_empty() in C:\wamp\www\drupal6\sites\all\modules\cck\content.module on line 803

Please let me know how to go about it...

Thanks in advance
KAMAL CHALLA

Kamal, What version are you using?

I've been using the CVS code of ImageField and 6.3-x of filefield for a week now.
As of now, there're still some bugs, but generally things look fine, YMMV here.

Please note that i'm not using it on a production site.

subscribing

Hey wuf31

Thanks for your reply. I am using drupal6.3 for my internal site. Can u please send me the patched and working module of CCK imageField for drupal 6.3, which will be great help for me. iam attaching the module what iam using in my drupal installation.

Thanks In advance
KAMAL CHALLA

For those of you who didn't notice, http://drupal.org/node/96519 now, since drewish and dww have managed to fix the node, has a D6.3-compatible version of Image Field. I presume it will show up soon on the project description page. NOTE: besides the ImageAPI and FileField dependencies, ImageAPI requires PHP5.

Hi...

I tried all the patches available for the HEAD, with those(not sure with which patch) got a working module. But it have list and hidden modes as default formats. what about the view mode means displaying the whole images in the content. Any body have the idea

Thanks in advance
Kamal Challa

@challa.kamal: Given that HEAD is compatible with D6.3, I'm not sure it's necessary to patch it.

I've not yet played with it, although I've installed it. You might find a better response to your question if you 1) post in the support queue 2) to a relevant issue, 3) preferably a new issue instead of one that has been closed. Not only will the maintainer not respond to a closed issue, but closed issues don't even show up by default.