Move node links out of bottom of node

You asked for input - here it goes. I agree with you on all your points. As an admin customer of yours, I would like to see all links removed by default from comments and nodecomments, except the standard forum links, the ones you mention (reply/quote, edit/delete). That is how most admins and end users expect a good forum to work.

Next, to take care of the remaining junk that other modules add (there could be useful stuff, but rarely needed), only admin can make a good decision. Just in case admin needs some of them, you could provide one list in settings (per content type perhaps) that will filter in some. The list probably should contain path patterns which to allow, and settings should provide a couple of options of how to render them (a drop-down menu, a node-like links list, or some other method).

That way it will look nice out of the box, and admin will have full control when needed to show some extras.

Third level could be one step more - get the list grouped with custom PHP, which in essence should be an array in form:

The above will create 'Subscribe' dropdown menu for all links from subscribe module, and inline group of links from abuse module (which may be an invention of my imagination). With such approach, a single asterisk '*' will pass all links into default inline representation.

Now, after writing the above, I think even standard buttons (reply/quote, edit/delete) can be described in same fashion, just use '#type'=>'button', and '#img'=>'btn_image_xxx.gif'. I hope you like that idea.

The thing to remember here is that the links can come from any contrib module as well as custom modules. So dealing with it in an automated fashion is difficult if not impossible. I'm thinking the best plan of attack is taking the links from common modules and putting them in logical places. To do that, it we need to define "regions" of a forum post and have some sort of hooks to add to those regions. For instance, there could be a "moderator" region where fasttoggle and similiar links go.

Michelle

Regions sound good too. I'm not sure which regions you have in mind, just guessing bottom of the post, top of the post, inside post and maybe parent_ flavors of the same.

Expanding on the idea and including regions, the internal representation (per content type) would look like this:

The order of entries is important, first matching pattern would trigger the filter which will put that link into region and format it with selected type. Weight will order the links in one region. So the code will take that setting, go through it and pick any links from node that match the pattern, and render them into the corresponding region.

The result from the above will look like this:

% Author %
%Post ...%
[Delete] [Edit] [Reply] [Quote] Subscribe> Report> Misc>
%moderator _unpublish_ _promote_ %

Where [...] is a button, ...> is a menu, _..._ is a link

'#type' can be 'hide', 'button', 'link' or 'dropdown'.

Does that system look flexible enough?

The setting entry could be plain PHP code in textarea - it is easy enough for an admin to set up. I bet you can cover 95% of sites out there with reasonably small default setting, maybe just a little more elaborate than my example.

@iva2k: To be honest, I really am not following what you're saying there. But I'm not ready to get into implementation, anyway. I was just putting the idea out there for discussion of what should go where. I've got a pile of other things to do before putting coding time into this.

http://www.lullabot.com/articles/great-pretender-making-your-data-act-field could factor into this.

Michelle

Yeah, it is easier for me to see it through implementation. But my point also was that there is no reason in trying to predict where people would want to move all these links. Just give them a simple universal solution to configure it, and move on. I basically proved to myself that I can describe that universally enough, and it can be executed. But I don't have an answer for you where to move each possible link. I think it is an open-ended problem.

Not sure who you are expecting to do this configuring? If you mean the maintainers of the contrib modules, not likely. I haven't had a lot of luck getting other maintainers to add code for my modules. If you mean the end users, they aren't going to be writing code. Whatever solution we end up with for this needs to just work.

Michelle

I'm sorry if my explanations are not clear, but I use late night hours to do that. So bear with me. Or just ignore;-)

>Not sure who you are expecting to do this configuring? If you mean the maintainers of the contrib modules, not likely.
I am absolutely not implying maintainers of other modules should write any config code for AF.

>If you mean the end users, they aren't going to be writing code.
It depends on perspective... I mean site admins. "end user" are not a monolithic group. I assume end users are site admins, which in turn have their end users (site visitors). I have no vision for site visitors to do any configuration, so it leaves site admins.

Site admins can't always write code. However, you can make them write "some" code, especially if they want to customize beyond 95% of functionality. Drupal provides PHP entries for them already. That's the thinking I used to arrive at the PHP array solution above. I believe you can give them a PHP setting field, and let them fill in this array, giving enough examples and instructions. They are not that dumb to being not able to do that. As I said, a default value (my example above + maybe a couple of more entries), in my opinion, will cover 95% of cases. A catch-all clause ('*') will move all links we don't yet know about into a dropdown list. That will clean up the forums view, and will keep it clean, no matter how many contrib modules site admin will install. Isn't it what you are striving for?

So, to reiterate all I've tried to say above, the plan that I have in mind is as follows:
- Add a setting field per content type (only those types that are involed in AF display will use it - Forum and Comment /from nodecomment/, so it makes sense to keep those fields in AF settings)
- Each of these 2 setting fields parses as PHP code, and should return array().
- Each array element describes: a. Name of the group, b. filter that matches link paths (uses wildcards) c. type of display (link, button, dropdown), d. region on the forum view where it should be moved, e. weight for sorting the groups within the region
- The default value is preset to place (reply/quote, edit/delete) as buttons, everything else moved under a single dropdown menu by catch-all entry
- Code the implementation - in the hook that should rearrange the links, it will take the setting value and run each link through the filters in that setting, determining where it ends up (both region and group), then sort each region and then each group. Send to render.

From site admin / end user perspective, that's what they will experience:
- Install AF+nodecomment modules, enable, configure forums
- They will see a tidy forum display with buttons reply/quote, edit/delete, and a dropdown menu 'Other' which will collect all links from all other modules (such as subscribe...). If they add a new contrib module which adds more links later - they all will end up in the dropdown menu. No configuration is needed. Non-forum nodes are not affected.
- 95% will be happy with that
- 5% will ask - can I move links around, change where they appear and how? The answer is "yes - just put few lines into that setting field. Here are some samples...". One will need few IQ points to understand it, but no need to learn programming.

Making a more involving GUI is nice, but will be way too much work for the task at hand, and I think for 5% of cases it is just not worth it.

Ok, this is starting to make my head spin. LOL! I'm going to put this on hold for a while. Will come back to it, though, once I get some other things off my to do list. Thanks for the writeups... Lots of ideas.

Michelle

This isn't going to make it into 2.x. Postponing for 3.x.

Michelle