Drupal 7 version - upgrade task

Thanks!

Drupal 7 is on the road map for a vague time in the future. I don't think it will be especially challenging with this module, as it interacts fairly minimally with Drupal APIs.

For the time being I'm going to leave it be, but if community desire for a D7 port starts growing, I will shift my timeline to the more immediate future.

I would gladly welcome a port from anyone else who felt inclined as well!

I saw the screencast: usefull module!

+1 for D7, if I had the skills I would help with the code, I can help testing and reviewing.

Now this is one impressive module and I'd love to see it for D7!

+1 for D7. 8)

Another +1 for D7.
I have limited time, but I can help with the D7 port if you like.

@jurveen - That would be great. The first step is to run through with the coder module and get an initial port. Is that something you could take on?

@justindodge, yes I can start with that. I'll contact you for the details.

Gonna post a link to this on the project page.

+1 for D7, has anyone started this?

I have run the D6 module through coder review - it's not actually too bad - result attached. I'm struggling with coder upgrade as it requires php above 5.3 so that toString is available, but none of our servers run above 5.17 for obvious reasons. I guess the first job is to fix this little list.

Hey Carl, thanks for the effort!! Sorry I couldn't let you know just a little bit sooner, but jurveen has already provided me with the initial port based on the coder review.

There is still a ton more that needs to be done to get the module actually working of course, and I'm working on that today. As soon as I can get all of the basic functionality happening without seeing major errors, I'll throw up the dev branch for all to behold.

At that point, I'll REALLY be appreciating testing and patches to get it up to speed. I'll keep you all posted!

Hi guys - so the 7.x-1.x-dev branch is up on the project page.

I haven't gotten as far as I would have liked, but we have some basic functionality, and hopefully it won't be too long until it's feature complete.

I'm going to edit the task description with some useful info about whats working, not working, tested, etc.
Really appreciate any help getting through the list!

I'm thinking that with 7.x it might be smooth and sensible to integrate with contextual links. I think I might also be able to add the ability to add hotblock items to any block, not just specially created hotblocks.
Any thoughts?

Would transitioning management to contextual links mean that in order for an admin to manage the blocks they would need permission to see all contextual links? If that's the case, that would not be ideal. I like thinking of hotblocks a quick and easy way for "client admins" to manage the site. It provides a simple method of managing sidebars without granting too much access to certain roles. If you have to grant access to see all contextual links, just to get access to hotblocks, i think that devalues the module... But, if you could just make the hotblock admin links look and feel like contextual links (maybe through theme functions?) that could be cool..

as far as making any block a potential hotblock, that might be cool of you could make it an option, on the admin block page.. but again, that might open up a pandora's box of too much to think about, and too many permissions to start to worry about. I think panels and panels IPE do a good job of filling the role of "super user" drag'n'drop management, but I think that hotblocks should focus on simpler tasks that don't get into the abysmal realm of making it work for everything..

just my 2 cents.. i've used the 6.x version a few times, and i'm just now trying out 7.x. i'm sure you'll be hearing from me soon :)

Would transitioning management to contextual links mean that in order for an admin to manage the blocks they would need permission to see all contextual links?

Well out of the box, there is one permission for contextual links - you can use them or not, so I guess the answer is yes. However, a user would still only see contextual links for actions which they have permission to execute, so it seems like good permission management would make this a non-issue, but obviously it's a little more complex than that and easier said than done. Does that still make it a deal breaker for you?

But, if you could just make the hotblock admin links look and feel like contextual links...

That might be an option - I'm thinking there is some good code to leverage in core here that would allow me to prune/simplify the hotblocks code.

Maybe another way to go is to make it so hotblocks integrates with contextual links, but only if it's turned on - besides, if contextual links is turned on it's probably going to make the hotblocks controls looked a little jacked anyway.

I think that hotblocks should focus on simpler tasks that don't get into the abysmal realm of making it work for everything..

Very wise and well said. My goal for the 7.x-1.0 release is just to get a straight across port of the 6.x branch in order to fulfill that very desire. However, I hope that with a layered approach that doesn't alienate anyone needing to keep it simple, I can leverage the interface to add a little more power and flexibility that will suit some other unsolved problems I encounter frequently with block management for the future.

I think I got the blocks as hotblocks working, patch attached -- should i open a new issue for this particular patch since issue has a whole bunch of todo's ?

Ok I also patched up tabledrag for D7 -- patch attached. This includes the work done in #16 and also a patch I put up in #1683088

@tmsimont - Thanks for the patches, you're an all star!

I think as long as the patches and subsequent discussion is in a single and digestible bite, we can tack them on to this issue.

If we need to get into any greater depth, I'd say that warrants a new issue for cleanliness - for now this looks fine.

So I've been working with this for a little while now and just successfully converted my page tabs into contextual links, and now I totally agree that hotblocks should be using contextual links, too. I don't think it would be that difficult to accomplish.

One of the biggest roadblocks with converting to a contextual links menu, however, would be the fact that an empty hotblocks region is invisible. Contextual links do not become visible until the user mouses over the region that is relevant to the contextual links menu.

We'd need to somehow highlight an empty hotblocks region so an admin user could be drawn to mouseover the region and discover the contextual links.

I'm thinking that the title of the hotblocks region should be visible to the admin users even if the block setting is to hide that title... then maybe some kind of outline around the region would indicate that hotblocks can be dropped there.

Perhaps an empty region would show the contextual links lines even without a mouseover? what are your thoughts?

hmm you'd also then have to worry about the existing contextual links inside the hotblocks region, nodes and blocks have their own CL's and the hotblocks module would have to add to them some how

Committed patch in #17 to 7.x-1.x-dev.

Making the task description more useful by creating status lists.

hey I just noticed an issue with my patch -- I used

        '#children' => $block->content['#markup'],

instead of what should be

      '#children' => render($block->content),

when passing the html of a block to $sRenderedView in hotblocks_item_view()

Do you want me to just commit the change in GIT?

I just got contextual links working in place of floating controls -- I'm working now on incorporating some options relating to "view modes" since the D7 version apparently doesn't work like D6 used to on that apsect.

I will post updates soon

@tmimont #22: Go ahead and commit to git. Don't forget to pull first.
#23: Cool. Lets do the follow up for this in a separate ticket. Also, I'm hoping contextual links would be something that could be a new option for D7, rather than taking over any old functionality.

ok -- ya i agree about the contextual links, i added an option to the settings page. i'll open up a new ticket when i have some tested code to go over

OK committed the change -- it actually is a little bit more than i'd described in #22 -- i found that rather than using theme("block") that pulling a renderable array from a few block.module functions works better (this makes it possible to use contextual links):

    $oHotblocks_Item->title = $block->subject;
    $sRenderedView = theme('block', array(
      'elements' => array(
      '#block' => $block,
      '#children' => $block->content['#markup'],
    ),
    ));

to

    $oHotblocks_Item->title = $block->subject;
    $block_content = _block_render_blocks(array($block));
    $build = _block_get_renderable_array($block_content);
    $sRenderedView = render($build);

I also added a return false; if the block element is not there (when deleting a block i ran into some PHP notices, this fixed it)

You might want to double check my commit -- it's the first time I've tried to use git to commit to a module!

Updating items in working/non-working list based on recent commits.

I just edited this issue -- i noticed that if you edit a node that is a hotblock, it drops from the hotblock region. I'm not sure why... looking at this now (i backed out all of my changes to confirm that I did not cause this, I'll patch a fix to the latest 7.x-1.x version)

added to summary under "What's not working:"
Assign a node as a hotblock, then edit the node

I see the fix

if (isset($oNode->hotblocks_remove)) {

it's set to 0, should be just

if (isset($oNode->hotblocks_remove) && $oNode->hotblocks_remove)) {

I'll commit the fix to 7.x-1.x dev, but please let me know if I'm overdoing the committing :)

i'm having an issue using $block->subject on re-order like i had put up -- I'm gonna fix it to this instead:

    if ($sContext == 'reorder') {
      $oHotblocks_Item->title = $build[0]['#config']['admin_title'];
    } else {
      $oHotblocks_Item->title = $block->subject;
    }

so when using re-ordering blocks with "" as the title, there's still something visible when reordering by titles only.

@tmismont - Don't worry about the over committing, but let's start a new issue for the contextual links thing and keep this issue for more of a general update kind of thing.

OK justindodge -- sounds good.

what about this item: "Settings - Ajaxy way of changing number of hotblocks available (you can still do a full page submit for this and it will show the new blocks available after reload)"

What if we created a mechanism similar to the "Menu Block" module (http://drupal.org/project/menu_block)

This module provides an action on the blocks overview form to "Add menu block"

We could do the same thing with hotblocks, and then provide some per-block settings for each hotblock. What do you think about that? Should I take that over to a feature request page?

I've been looking for something like this for D7. Is it still being worked on?

It is still being worked on, but as is all too common with Drupal projects, real life/work is impeding my ability to make a lot of progress at the moment. Don't lose hope though, it's still on the radar :)

I've also really been meaning to cycle back around to this. I have 2 projects going live in the next couple of weeks that are using this module. I've had to work on the code a lot to get them production ready. I have made a lot of updates locally and I'm worried about pushing them all at once... I'm thinking about starting a 7.x-2.x branch... what do you think justindodge?

related features:
#1744550: Provide Contextual Links Option
#1744618: Support D7 view modes

Also -- elvizzi, if you use the most recent dev version, it should be pretty useable. If you could test it out and post any issues you encounter that would definitely help move this along

@tmsimont: Given that the 7.x-1.x branch has yet to see a stable release yet, I don't think there is a lot of reason to think about a 2.x, unless you are making changes that would prevent a user coming from 6.x from eventually upgrading, or if they do, being able to use the module for the same purpose that they did previously.

Sounds like if you're launching production sites, I have to imagine you've made some improvements. There's always the possibly of reverting, but personally I'd rather see the project move forward. I'd say commit, push, and if possible document your work here to whatever extent you can remember.

@tmsimont working with the dev version of hotblocks and so far so good!

thanks elvizzi -- i've pushed some updates to allow this module to work with contextual links and node view modes. i also changed the css depth class because the generic "depth" class was conflicting with a few other modules.

added a "not working" item