Closed (fixed)
Project:
Node Gallery
Version:
6.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
9 May 2010 at 20:49 UTC
Updated:
3 Jan 2014 at 01:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
scroogie commentedForgot the tag.
Comment #2
justintime commentedJust a note: when writing the hook_update_N code to upgrade 2.x to 3.x, it's probably pretty safe to assume that we'll be required to add a imagefield to any existing content types already in a gallery<->image relationship. I can't think of a valid reason why someone would have duplicated the actual image in an imagefield on a node in 2.x.
There's plenty of hardcoded references to an imagefield name in the module. I knew it was wrong, I just wanted to get some POC code working. We should probably store that data in the relationship table, and make a function that uses static variable to cache the content_type->imagefield_name maps.
Also, you don't need to tag ng3 anymore, since we have a release to associate it with. Doesn't hurt, but not required :)
Comment #3
scroogie commentedOh, I see. I didn't think of that (upgrading the existing ng content types). Can I just alter the schema (adding the field names to the relationship table), or do you want update functions already?
Comment #4
justintime commentedI just committed in a bit of code that creates some placeholders for us. I modified the schema on the relationships table to include a column named imagefield_name, and I modified it so that when asking for a relationship array, you get that field as well. I littered in a bunch of todo's with this string: '// @todo: eliminate hardcoded reference to field_node_gallery_image below' where I had hardcoded the field name in the code.
Here's some thoughts on the topic:
1) In admin.inc, when we are setting up relationships, we should present the user a select option that contains a list of all current imagefields on the image content type. If that list doesn't contain field_node_gallery_image, then we should offer that as an option as well and create it for them via the submit handler if the user selects it.
2) Regarding installation and upgrade. If the user is doing a new installation, we should just use the content copy module functionality already in the .install file to setup new content types for the user. However, using content copy on a pre-existing content type is a little iffy at times. I think that instead of using content copy on 2.x -> 3.x upgrades, we should just use our own code to add our field_node_gallery_image field to the pre-existing image content types.
Comment #5
scroogie commentedThis is a snapshot of the work-in-progress patch, so you can keep track of the changes. There is some stuff to discuss.
The patch tackles only point 1) at the moment. I'll have a look at point 2) now.
Comment #6
scroogie commentedIs there more than one image content type possible for NG 2.x?
Next patch, with first implementation of 2).
Comment #7
scroogie commentedForgot the include.
*edit*
Ignore this one, sorry. Something went wrong with the patch creation.
Comment #8
scroogie commentedThis one should be better.
Comment #9
scroogie commentedNew patch including the fix for the default relationship.
Comment #10
scroogie commentedSo as #796880: Default relationship not setup on a fresh install has been commited, #8 should be the right patch.
Comment #11
justintime commentedI was able to get through and commit all of this except for .admin.inc and .install. There was a bug in theme.inc where you were using $node when the object was actually in $image, make sure you pull that one in.
I'll get to the rest of the patch later.
Comment #12
scroogie commented.admin.inc contains most of the important code regarding the reltionships. .install had the changes of the other patch included, as worked on the same copy of files (unfortunately). Can I help somehow?
Comment #13
justintime commentedI'm just doing my due diligence and reviewing code before I commit it in. It *will* get committed in, I just need some time to review and test. I didn't commit those two files because they had the most to review, and my lunch break was about over :)
I should get them reviewed and committed tonight.
Comment #14
justintime commentedI reviewed the code - there was one bug where you were using the wrong variable name on the relationship list page that broke the link over to the imagefield page, but that's all I found. I changed a bit of the text on the admin page, it's not perfect so let me know if you don't like it.
Honestly, I'm fried and didn't get the change to test all the install stuff, but it looks pretty sound so I committed it. Thanks for all your help.
Comment #15
scroogie commentedAh, so I misunderstood you. I thought the patch didn't apply properly for all files! Sorry.
About the link: Do you mean the field link to the imagefield page? That was actually on purpose, so that the user can find the field configuration more quickly.
What do you say about taking the field out of the -.cck file. I thought it's okay for now, but maybe we want to change that later.
Comment #16
scroogie commentedAnd may I ask you what timezone your from? Just for coordination.
Thanks and greetings
Comment #17
scroogie commentedAh, I found the issue with the link. I wonder how that even worked for me. I guess I need to test more thoroughly.
Comment #18
justintime commented@scroogie - I'm CDT (US/Chicago). I'm on Google Talk at the email address you have for me, and I'm in #drupal most of the time too if IRC is your thing.