Porting emailpanels to d7 seems to be a challenge, created this issue for d7 port of emailpanels.

Comments

chriscalip’s picture

Broken attempt to port emailpanels to d7 - the problem is the additional complexity from d6 email module menu_router of email/%/% that is restricted to (nid,field) to d7 email module menu_router email/%/% ($object_type,$object_id,$field_name)

-- I am kinda stumped, need help.

chriscalip’s picture

Write to ctools queue and ask for clarification if ctools has a setup for a conditional hook_get_arguments($task, $subtask_id)

Title: CTOOLS page manager "improve context detection"

Description:

Hello, I wanted to start a discussion about the implications of fields being available in most (all)
entities (node,term,user) in particular how we look at menu routers.
First of all I think it's great that we can share fields in all entities,
the ability to share an email field in content types, terms, etc.. etc.. is just awesome.

Contrib Module's also have taken advantage and are readjusting their own page callbacks to this fact.

For the email module has a menu_router(path,page_callback) :

a. (d6 version) menu_router ('email/%/%',email_mail_page) with email_mail_page($nid,$field_name);
b. (d7 version) menu_router ('email/%/%/%',email_mail_page) with email_mail_page($object_type,$object_id,$field_name);

chriscalip’s picture

I gotta remember the advice when I start on this issue again going to faqpanels d7 port now and yeah that other faqpanels issue.

merlinofchaos chriscalip: You would use a relationship.
merlinofchaos chriscalip: You would set the arguments themselves as strings; the relationship could then process the strings and produce the proper context.
merlinofchaos	chriscalip: Custom relationships are also reasonably easy. The hardest part is that you'll need to be able to create placeholders that pretend to be every possible entity.
merlinofchaos	chriscalip: That isn't that hard.
chriscalip’s picture

Issue summary: View changes

gave a more detailed description.