The views blocks show up in the block refresh admin page, but it seems the options or settings fail to get attached. Has something to do with the way the code looks for only module based blocks, so I'm wondering what the best way to get it to attach to views blocks would be.

CommentFileSizeAuthor
#14 block-refresh-arguments-d6-1017768-14.patch5.04 KBpaul2
#8 block_refresh-d7-1017768-8.patch3.17 KBmichaellander

Comments

bocaj’s picture

bocaj commented
Priority: Normal » Major

I can confirm that this is not working in the 7.x release as well. Not sure at the moment what the issue is, but will look into it shortly. Thanks for catching this idiotprayer!

idiotprayer’s picture

idiotprayer commented
Title: Block refresh does not work with Views blocks » Block refresh cannot refresh Views blocks with arguments

My issue isn't quite specific enough. I just made it back to this today, and it seems that Block Refresh does in fact work with Views blocks; however, it does not work with views blocks which have arguments. Understandably, since the page where we are loading the block from does not know the context in which the original block is placed. Not sure where or how we can store arguments to use in the reload. An additional variable to pass to the js? And build the block with an explicit value from the menu?
I'll look into it, but any hints would be appreciated.

michaellander’s picture

michaellander commented
Assigned: Unassigned » michaellander

I can confirm this bug. I'm looking into it.

michaellander’s picture

michaellander commented

idiotprayer, would you mind giving me a specific example of how you are using it? I've current made a way for it to work with NID from URL and Term ID from URL, however, I don't feel this covers all use cases.

idiotprayer’s picture

idiotprayer commented

Ah, I now see how my use case is perhaps a little more involved... I'm using it in conjunction with Organic Groups, so the argument I'm looking for support with is the Current group from context argument, though it seems to me there should be a way to 'hold' whatever argument is initially used?
Eg. I'd like to show all the comments for a specific group. The argument I use is (Node) Fields - group_audience - gid, set to current group from context. Works splendidly until block refresh attempts to reload, at which point the argument is ignored.

idiotprayer’s picture

idiotprayer commented

how are you doing it for those two cases you mention? if you get me started I'll see what I can come up with.

michaellander’s picture

michaellander commented

idiotprayer, sorry for the delay, I've had little time to get back to this as of late. My approach was to take the current arg() and append it onto the hook_menu item. So it would callback /block-refresh/..../arg(0)/(arg1)/etc

Then use func_get_args() in the callback function, I would retrieve all args, and grab the path for the requesting page. My problem however, is that I'm not familiar enough with views yet to know exactly where to pass the arguments to. Ideally, if we can just tell views to forget the current arguments, and instead get it's arguments from the path we give it. Then it'll be pretty easy to do.

I was able to use a hook to load the view and change the argument for node id and term id specifically, but I would think their is a more flexible solution to use the args with any argument type.

michaellander’s picture

michaellander commented
Status: Active » Needs review
StatusFileSize
new block_refresh-d7-1017768-8.patch3.17 KB

Maybe the break did me some good. Think I just figured it out. Give the attached patch a try for me

idiotprayer’s picture

idiotprayer commented

Thanks for the patch! Initial inspection looks good.
I veered off into using the ajax framework to build the callback links and a less than ideal usage of views_embed_view, which left me with recurring ajax queuing errors /tricky js. As soon as I get a chance I'll give this a spin and review.

michaellander’s picture

michaellander commented

Ah ok, let me know what you think when you get a chance. I think I may add one additional thing that will look for anything stored in $_GET to pass along as well(minus ['q'] obviously). This way, if a block has multiple pages that you have clicked through in a view or something, those aren't lost on refresh.

michaellander’s picture

michaellander commented
Status: Needs review » Closed (fixed)

The first major release has the fixes and also includes additional code to handle any $_GET values. Let me know if you have any additional issues.

Gus24’s picture

Gus24 commented

Can someone port this patch to D6?

svenassmann’s picture

svenassmann commented

I'd need this in D6 as well!

paul2’s picture

paul2 commented
StatusFileSize
new block-refresh-arguments-d6-1017768-14.patch5.04 KB

Here is a Drupal 6 version of the above patch. It also updates Group context after the path is changed, which is apparently necessary for the correct OG context to be detected when most OG Views are generated. I'm not sure if this applies to OG Views in D7.

paul2’s picture

paul2 commented
Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Closed (fixed) » Needs review
spazfox’s picture

spazfox
Location Olympia, WA
commented

Patch at #14 works great for me on D6, but I had to comment out these lines to avoid a WSOD (due to undefined function) because I am not using this module with OG:

if ($group_node = og_determine_context()) {
+			og_set_theme($group_node);
+			og_set_group_context($group_node);
+			og_set_language($group_node);
+		}

Could also be resolved with a quick conditional check if OG is installed.

tripper54’s picture

tripper54 commented
Issue summary: View changes
Status: Needs review » Needs work

See #16

mqanneh’s picture

mqanneh
he/him
Primary language English
Location Amman
commented
Status: Needs work » Closed (outdated)