Closed (fixed)
Project:
Referential Integrity for CCK
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
10 Sep 2009 at 15:40 UTC
Updated:
28 Sep 2009 at 15:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
robertdouglass commentedI'm thinking something like this:
Comment #2
robertdouglass commentedOr, probably better...
Comment #3
robertdouglass commentedI found two places that need the hook invoked.
Comment #4
markus_petrux commentedHow about?
The hook would only be invoked when necessary, and now you know if it is about a node or user reference field, and the related nid or uid, which is something you may not care, but just in case you may wish to process only node reference related stuff or whatever...
...or we could even provide the result of
cck_referential_integrity_get_reference_fields($field_type)as an argument to this hook, and then you have a lot more information.Comment #5
markus_petrux commentedOops, we posted previous comment almost at the same time. Well, I think it would be nice to provide context to this hook.
I'm setting the issue as needs work, and I'll look into it later or tomorrow if you haven't already. Probably it is possible to insolate this snippet into a separate function that is invoked from both places.
Comment #6
robertdouglass commentedGood idea. I also added a block that redirects to admin/content/node/orphan-references when there are no more orphans. Sorry to mix issues but since the queue is quiet, and I have your attention ;-)
Comment #7
robertdouglass commentedComment #8
robertdouglass commentedYes, the code is duplicate, but not massive. I'd be on the fence about isolating it. Too many functions makes hard to read. But your call.
Comment #9
markus_petrux commentedI just committed a slight variation of your patch:
http://drupal.org/cvs?commit=261938
The result is that we are invoking hook_cck_referential_integrity_update($cached_nids, $updated_fields) to let other module know which nodes have been changed.
Re: "I also added a block that redirects to admin/content/node/orphan-references when there are no more orphans"
I haven't included this. The main orphans report does not offer links to view orphans for fields that haven't. In case someone visits that page, then the message "Could not find orphans for this field." is rendered, and the breadcrumb in that page allows you to visit the main orphans report, so I think that drupal_goto() is not really necessary.
Comment #10
robertdouglass commentedRe: redirect. Ok. It still works without it, of course, but since people use this module to do batch operations (they mostly install it when they notice they've got a big problem), I thought the extra ease in workflow would be good. Yes it's true that you can no longer get to the report if there aren't orphans, but when using my version with the redirect, I find this to be a good thing, and a nice confirmation that the job is done. And it saves me a click.
Comment #11
markus_petrux commentedRobert: I believe I don't understand your workflow here. The main Orphans report is telling you how many orphans exist per table, and there's no link to browse orphan records for tables that do not have orphans. In this case, you can only view this report if you enter the URL manually. If you do, then it's up to you what to do next, but I would say it is just fine to render an empty table with a message that states there is no orphan record for the current selection. This is the pattern I've always seen in similar Drupal reports, or even in views (where you have the chance to configure the "empty" message).
Adding a drupal_goto() changes the most commonly used pattern, and I would only change it if there was a reason to do so.