Thanks prometheus6 for offering this patch. I just created this project so I thought I would insert this patch based on your email to drupal-devel list. It needs some work before it is functional. I need to look at how the security changes from what my code does. I don't yet understand the full impact of your proposal. You said:

I took a look at the blogroll module and made a patch to make the configuration page a LOCAL_MENU_TASK of user/edit. I think that's the best place to put it.

Aldon also pointed out that the link on line 71 would need upating to be compatible with the new changes.

CommentFileSizeAuthor
#6 BLOGROLL PATCH.txt3.18 KBPrometheus6
#4 blogroll.module.diff22.67 KBgrantbow@civicspacelabs.org
#1 BLOGROLL_CVS0.txt2.65 KBPrometheus6
BLOGROLL_CVS.txt1.27 KBgrantbow@civicspacelabs.org
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented
FileSize
BLOGROLL_CVS0.txt2.65 KB

1- By becoming a local task relative to the user/edit page, it "inherits" all the security from that page.

2- Aldon was right, I didn't notice the edit link in the block. This patch (to be applied after the previous one) fixes that.

grantbow@civicspacelabs.org’s picture

grantbow@civicspacelabs.org CreditAttribution: grantbow@civicspacelabs.org commented

I applied the patch and it worked OK, but I found that when going to the regular account editing page it didn't show at all. Much more seems required to do this right. I am working on creating properly functioning blogroll_user() and blogroll_categories() hooks as is done in profile.module. So I will leave this open as a patch for now but will roll this into my next big CVS checkin of the module. There are quite a few cases handled by profile_user() that I need to figure out if they are applicable to blogroll_user() as well.

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented

"regular account editing page"?

If you're talking about
http://www.example.com/index.php?q=blogroll/edit

The patch eliminates that altogether...there shouldn't be two whole different urls to access the same function. If it's a subtask of the user/edit pages it should be that. If it's a standalone page, it should be that. Links to get to the page can be scattered all over the site but they should all point to the same url.

grantbow@civicspacelabs.org’s picture

grantbow@civicspacelabs.org CreditAttribution: grantbow@civicspacelabs.org commented
FileSize
blogroll.module.diff22.67 KB

Oops, I thought I could make this work but I couldn't in the time I have allotted today. I've backed it out again for now. Here's my current version of the entire patch. It is not complete and needs more work. Please provide a replacement for this patch as you have done and do not try to patch patches.

The trouble I see is that my version is simple about having a new editing page that's separate. It provides and processes form data and there are no Drupal APIs that complicate things (IMHO). Using the user editing area for the editing page will require integrating some Drupal APIs with hooks as I started to implement. I do not fully understand them yet. If you can provide a patch that works and implements those other hooks cleanly that would be great, While your current patch may be functional, from the Drupal API perspective it seems like the wrong way to do it. I'll apply it when it's ready. Let's keep at it.

grantbow@civicspacelabs.org’s picture

grantbow@civicspacelabs.org CreditAttribution: grantbow@civicspacelabs.org commented

Oops, our comments got crossed. What I mean is that with ?q=user/1/edit sometimes I see blogroll listed (when I'm at ?q=user/1/edit/blogroll), sometimes I don't (like when I got to ?q=user/1/edit. My patch starts to address this with the blogroll_categories() function that allows it to show all the time.

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented
Component: User interface » Code
FileSize
BLOGROLL PATCH.txt3.18 KB

With this patch the blogroll input form is NOT a local task of the user page. It can be made such in short order. You've also got your edit link when a user is viewing his own blogroll back.

The blogroll can appear on EVERY PAGE:

  • The blogroll belonging to the blog's owner appears at ?q=blog/#
  • The blogroll belonging to the node's creator appears on every full page node display
  • On every other page, a blogroll built from unique entries in the entire blogroll table, sorted by the number of times the site is blogrolled by all bloggers on the system
grantbow@civicspacelabs.org’s picture

grantbow@civicspacelabs.org CreditAttribution: grantbow@civicspacelabs.org commented

We talked on the mail list. This may be an excellent patch when a 4.6 branch is started. I haven't gotten there yet. Right now blogroll is only a 4.5 module. Sorry for the delay.

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented

As you know I'm not the IRC guy, but if you're basically happy with your functionality I can patch in LOCAL_MENU_TASKs for you. I promise I won't do anything else :-)

drewish’s picture

drewish CreditAttribution: drewish commented

Well, considering someone's got a patch for 4.7, maybe it's time to take another look at this and see if it still applies?

robbiethegeek’s picture

robbiethegeek CreditAttribution: robbiethegeek commented

Just took over this module and closing issues that are over 2 years old that no longer apply this module was abandoned and is being restarted with a different focus.

robbiethegeek’s picture

robbiethegeek CreditAttribution: robbiethegeek commented
Status: Needs review » Closed (fixed)