Support forums : Branches

dashboard plugin hooks

Discussion about existing branches and the directions they need to go in, or, for branches that are going to happen. "Quickies" is wide open. "Branches" is more focused.

Moderator: Dracones

dashboard plugin hooks

Postby EdB » Fri Oct 14, 2011 5:56 pm

https://code.launchpad.net/~quam-plures ... ugin_hooks

There has been a comment on the dashboard page ever since forever about adding hooks across it. So I figured why not, then I figured it'd be easy to branch back to QP (QP1? QP proper?). What it does is very simple: 5 hooks for the dashboard page which are demonstrated in the test plugin "this is the TEST plugin responding to ... "

Code: Select all
'DashboardAdminMain' => 'Called on the dashboard main column when admin permissions exist.',
'DashboardAdminSide' => 'Called on the dashboard sidebar when admin permissions exist.',
'DashboardBlogMain' => 'Called on the dashboard main column when a blog is selected.',
'DashboardBlogSide' => 'Called on the dashboard sidebar when a blog is selected.',
'DashboardGlobalMain' => 'Called on the dashboard main column when no blog is selected.',


Tested and ready to rock but I won't put it into merge until some time for discussion happens.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: dashboard plugin hooks

Postby leeturner » Sat Oct 15, 2011 3:49 pm

This is a really good idea as it moves us towards a time where we can write plugins that do things like check for a new release etc. Hey, I'd even be happy to make the recently edited items become a plugin so I can replace it with something more useful ;)

Nice one, thanks for branching back to QP (QP1? QP proper?)

L
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: dashboard plugin hooks

Postby EdB » Sat Oct 15, 2011 4:43 pm

Yeah it seemed easy to do and I figured "field of dreams" type of stuff: can't do a plugin without a hook, but we shouldn't wait on a plugin to add a hook. I mean, a hook that seems like it has a valid viable point behind it.

Hey instead of a plugin that makes a widget that only serves dashboard, how about making it a widget directly?

Hey actually why not just fix the recently edited bit that you don't like? I mean, what are the odds that you come up with something and say "here are my improvements to a canned piece of the dashboard" and someone actually says "no I like the same old shit"?

On QP/QP5: I should go elsewhere to discuss it but whatever. I do want them to stay related. ESPECIALLY when I do distributed antispam. That other app went to the dark side so fuck 'em: zero support, zero respect. QP just moves too damned slow for me. Big diff there eh?

Anyway the diffs are already getting way ahead of me. When I did this branch I thought do a quick test to prove it works and it failed because I forgot I am changing every instance of "collection" back to "blog" and began with folder & file names. Doh!
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: dashboard plugin hooks

Postby leeturner » Sat Oct 15, 2011 5:06 pm

EdB wrote:Hey actually why not just fix the recently edited bit that you don't like?


Its not that I don't particularly like any one bit of it. Just that if it was a plugin/widget that made use of the new hooks I could remove it entirely.

L
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: dashboard plugin hooks

Postby EdB » Sat Oct 15, 2011 5:36 pm

ah. Kinda like what I would do with the entire idea of a dashboard page ;)

So ... how do you feel about widgetizing it? What I'd like to avoid is a plugin that does nothing more than make a reasonably simple widget. To use a hook we have no choice but to do a plugin. OTOH if we turned the dashboard into 2 or 3 containers (main, sidebar all, sidebar admin) then we could take the current bits and widgetize them. Put them in the qp_view_admin folder as their own little files and let the installation owner decide what the dashboard looks like for their installation.

Bit longer to get that whole thing rolling, but I think the end result would be much more where we should be.

Nominally related is that I really don't like plugins that get shared public to admin. Calendar and Archives. Hell I don't like that they are plugins when all they do is a widget, and I really REALLY don't like that the Archives widget has a field for "block title" which is actually used but the "title" field that all widgets get is still there and doesn't get used, but that is even further afield eh?

Heck I dunno. Either way it sounds like a lot of code for what I consider a stupid page. How about on/off switches that ID#1 can set for each of the current canned bits? Totally cheap solution, but gets rid of the bit you want gone, doesn't take a rocket scientist to code up, can work now, doesn't stand in the way of plugins using these hooks, and doesn't stand in the way of one day containering and widgetizing the whole shebang.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: dashboard plugin hooks

Postby leeturner » Sat Oct 15, 2011 5:43 pm

EdB wrote:So ... how do you feel about widgetizing it? What I'd like to avoid is a plugin that does nothing more than make a reasonably simple widget. To use a hook we have no choice but to do a plugin. OTOH if we turned the dashboard into 2 or 3 containers (main, sidebar all, sidebar admin) then we could take the current bits and widgetize them. Put them in the qp_view_admin folder as their own little files and let the installation owner decide what the dashboard looks like for their installation.


Ultimately this is where I would like to go with the dashboard (and the write screen for that matter).

EdB wrote:Bit longer to get that whole thing rolling, but I think the end result would be much more where we should be.


Yeah, quite a big investment in time and code for this one. I agree it is where we should be though.

EdB wrote:Nominally related is that I really don't like plugins that get shared public to admin. Calendar and Archives. Hell I don't like that they are plugins when all they do is a widget, and I really REALLY don't like that the Archives widget has a field for "block title" which is actually used but the "title" field that all widgets get is still there and doesn't get used, but that is even further afield eh?


Totally agree on this. The two should be totally unrelated.

EdB wrote:Heck I dunno. Either way it sounds like a lot of code for what I consider a stupid page. How about on/off switches that ID#1 can set for each of the current canned bits? Totally cheap solution, but gets rid of the bit you want gone, doesn't take a rocket scientist to code up, can work now, doesn't stand in the way of plugins using these hooks, and doesn't stand in the way of one day containering and widgetizing the whole shebang.


It doesn't bother me enough to worry about on/off switches at the moment. Unless others think this would be of some benefit then I am cool with it.

I see you have removed all the manual links from the edited files in this branch.

Note to self.... add back in at some point.

L
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: dashboard plugin hooks

Postby EdB » Sat Oct 15, 2011 6:24 pm

leeturner wrote:I see you have removed all the manual links from the edited files in this branch.

Oh snap!

Worse than changing folder/file names, that was one of the first things to go. Unfortunately it doesn't show up on a feature test. The thing is once I was done with it in QP5 I thought it would be reasonably easy to branch it here. So I lifted the dashboard page almost entirely, and dropped in a couple of large blocks on the other 3 files. Next time I'll make a scan for get_manual_link before committing a change :) ESPECIALLY if an entire file is copy/pasted over.

Anyway that's sort of part of pushing branches to shared space: it allows easy correcting for those interested in getting something all the way through the process and into QP's core.

Off topic Having a heck of a hard time starting the distributed antispam thing. Got pretty far, and kinda know where it'll go, but where do I store the data that needs to be stored short-term? If you send me a request to join my cell, part of what you send me will be a nonce-like value that I have to send back. If I don't then obviously you never asked me. You can only have 3 cellmates, but you can ask an unlimited number of installations. It's just that when 3 accept then no more outbound and no more accepts will be honored. So how do I store those nonce-like values?

hmmm... As a setting name/value pair of the domain you asked and the nonce? A pair of settings maybe so I could expire them eventually? Or after 3 accepts then wipe out all remaining? Gotta have some way to tag the info as a cell-request is the thing.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: dashboard plugin hooks

Postby Kimberly » Sun Oct 16, 2011 2:25 am

I was thinking about this today. looking over the dashboard. I read the post the other day but did not know of anything I could add to the discussion. Just because I don't comment does not mean I am not looking and thinking.

Certainly add the hooks, there is no reason not too that I can see.

As for changes in the dashboard, I have been thinking of ripping out the top toolbar (the suckerfish?); the one with the dropdowns. I never really cared for it on that other app.
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: dashboard plugin hooks

Postby EdB » Sun Oct 16, 2011 3:35 am

_adminUI_general.class.php, comment out "require $templates_path.'_toolbar.inc.php';" and you're done.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: dashboard plugin hooks

Postby Kimberly » Sun Oct 16, 2011 4:29 am

EdB wrote:_adminUI_general.class.php, comment out "require $templates_path.'_toolbar.inc.php';" and you're done.


Not quite rip it all out but most of it. I find that I don't use it. For users, the logout button might be useful and sometimes I log out so I can log in as a user and test things out. And that is most of what I go to the toolbar for. That is the key really for thinking about the dashboard; are there places you rarely or never go to? Then maybe they could be store out of the way. The roll-up of sections was a really nice addition; but we could also have a list of hide and unhide sections of the dashboard for those that we really don't access often.
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Next

Return to Branches

Who is online

Users browsing this forum: No registered users and 1 guest

cron