Duplicate project of http://drupal.org/project/cck_blocks

Although the namespace you have for your project is much better and is more applicable to d7.

Comments

dman’s picture

Yeah.
CCK block has a good history and a good number of users.
The way that cck_block uses display modes is also very powerful.
I'd suggest you maybe find a way to identify any features or options your version has that could be integrated into the front-runner and join forces.

marcvangend’s picture

Thanks for your input. I am not opposed to joining forces, but besides the more appropriate name, there are some important differences.

I do not really agree with the way CCK Blocks uses view modes. In fact, my module used the same trick initially, but it seemed wrong. IMHO blocks should not be a view mode by themselves, but they should be a result of the current view mode. Because Field as Block stores settings per view mode, it even allows different view modes to expose different blocks.

Some other differences include:
Field as Block is not restricted to nodes, but it will work for every entity type (eg. users). It is easier to configure, because you have to take less steps and submit less forms. Field as Block re-uses the field's render array instead of building it again, which should result in better performance (untested).
On the other hand, CCK Blocks supports token for more flexibility in block titles. Since it has been around longer and has more users, it may be more stable.

I will contact the maintainer of CCK Blocks and see if he is interested in integrating some of the strong points of Field as Block.

dman’s picture

I think some fresh eyes on cck_block could improve this task/feature quite helpfully.
Certainly, if now supporting all fieldable entities (not just nodes) is possible, that would be a strong improvement.

The UI for managing the view mode for fields was a long way away from where I expected it to be, but when I found it, it made enough sense. Moving the configs into the block configuration itself and letting you choose the render method there however is probably good possibility also. I think the admin UI choices do deserve to be revisited.

Next we just need a way to get a compound display of more than one field into a single block :-) ... without requiring field_collection to do so. .. Hm, I've been playing around with display_suite and field_group tricks too much...

Good to see a rethink of this task in action anyway.

damien_vancouver’s picture

Hi guys! I'm the current maintainer (it is kind of looking like the only active maintainer) for cck_blocks.

A little history.... I came across cck_blocks looking for this functionality on my first Drupal 7.0 site build. At that time there was a patch for 7 but it needed work, and also the respositories were a mess after the CVS ->Git migration. Already though people were using the module.

While CCK_Blocks obviously works (based on the number of users), I think it does suffer drawbacks from being such an old module. Most notably is that it's pretty ignorant of Field API and Entities. Based on some issue submissions from users I've added support for entities other than nodes and that is in the 7.x-dev version. But I still have not pushed that out as a new stable release, as I was hoping to get more people come along and give feedback the changes work.

The other big problem with it IMO is the user interface, which is not all that intuitive (I improved the field label wording a bit in 7.x-1.x-dev) and lacks a central configuration page. The Display Modes thing also feels like a hack from previous Drupal versions to me, although it works well once you understand it. I do see the ability to have it use the current display mode as an interesting feature that would be more useful. But, you do need to be able to hide a field from the node if you're going to have it show up in a block. I assume field as block must do this somehow. In cck_blocks you have to first hide the field from the main display and then enable it in the cck_blocks display, or it will show up in the main content AND in the block. Or if you forget to enable it in the cck_blocks view mode it just doesnt' show up at all (this is probably what confuses most cck_blocks newbies). If the hiding part could happen automatically or be a toggleable thing, then I don't see the need for the extra view mode any more.

Finally we have a blocker issue for cck_blocks now which is #1863910. Until the Token maintainers decide they want to apply that patch for us and fix Token mangling the display modes set by other modules, it will always require a pached token module. I have no idea if the Token maintainers will fix that issue, I imagine it's not top of their priority pile even though it's a simple fix.

Rather than address these things though (unless people posted issues), I was just careful to not break cck_blocks for the thousands (wow!) of sites using it. I can only assume all those people chose cck_blocks and didn't go with Display Suite (as I urge in the module description) for one or maybe both of these reasons:

  • They used it in Drupal 6 or earlier, and know how to use it.
  • They only want this exact functionality and Display Suite seemed to do it differently and therefore require more work

I would like to see a more modern solution going forward and kill cck_blocks with Drupal 7. I think this would be a good time. Perhaps we can work on field as block being the official replacement for D8, and just do a nice early job of documenting how to upgrade for cck_blocks users.

Of course, the thousands of cck_block fans may not see it this way, and might howl for an upgrade. But I hope they just want the functionality in a simple to use format.. which a nice more modern module could provide for d8 and beyond.. maybe this could be it!

In that case I'd say let's let this module live and get stabilized and we will maybe announce on the cck_blocks page that we're going to retire it in favour of this module. I will try the module out in the next week and let you know if I can see any other problems once I've tried it. If we find any functionality is missing that was in cck_blocks, we could merge it in for the d7 version so it's feature complete before it's time to start work on a d8 port. And having that d8 version available right off the bat will help prevent people porting cck_blocks and starting to use it, so we'd have to be on top of getting it ready on time. I can help with this though, since I'll need it for my own sites when they upgrade.

damien_vancouver’s picture

Status: Active » Closed (duplicate)

I'm going to mark this issue as a dupe of #1920636: Collaborate with CCK Blocks for now, where there's going to be better discussion going on.

damien_vancouver’s picture

Oops, sorry... I closed the wrong issue! Reopening, and marked #1920926: Possible duplicate as the dupe of this one.

marcvangend’s picture

Status: Closed (duplicate) » Active

Dan, thanks for your feedback. There are indeed many ways we could solve the admin UI challenge. CCK Blocks chose to add a new view mode, I chose to reuse existing view modes. If I understand correctly, you are suggesting a third option, similar to how the core Block module and Menu Block allow you to define blocks. I like that idea, especially because it's a well known UI pattern.

Interesting that you mention putting multiple fields in a single block - I was already thinking about adding that feature. In the context of Field as Block as it is now, I seemed logical to me to build on Field Group and render the entire field group as block. That said, It may be better to see if I can cooperate with CCK Blocks and get the admin UI sorted out first.

dman’s picture

Actually, I slightly misunderstood your alternative to the cck view mode, and (having not yet tried this one out) I just guessed how *I* would have re-thought the admin, if not doing it via the content type management :-}. But yeah, like menu_block would be about right. In some cases.

As Damien also notes, the view_mode method is a bit old and funny. I think it probably was reasonable at the time because of the way it could easily re-use all the display widget settings UI without adding any new code. That at least was a win.

Yet another option would be to extend the per-field settings in field display management with 'expose as a block' as either a checkbox or a new pseudo-region. That would be really easy to find. I should try yours out before I keep speculating ...

Thanks for your big contribution above Damien.
It looks like this is going to be a nice way to go forward!

marcvangend’s picture

...to extend the per-field settings in field display management with 'expose as a block' as either a checkbox or a new pseudo-region. That would be really easy to find.

That sounds exactly like the solution Field as Block is currently using. I added a screenshot of the admin UI to the project page earlier today:
Field as Block admin UI screenshot

dman’s picture

I knew I should have tried it out before continuing to speculate :-)
Hah!

marcvangend’s picture

Title: Possible duplicate » Collaborate with CCK Blocks
Assigned: Unassigned » marcvangend

I have discussed this with Damien, maintainer of CCK Blocks, and we're exploring the possibility to collaborate, merge the two projects, and possibly deprecate CCK Blocks when that process is finished.

13rac1’s picture

Any update on this? Is CCK Blocks being deprecated?

damien_vancouver’s picture

@erosi,

Yes, CCK Blocks will be deprecated and not ported to Drupal 8, in favour of this module (or any of the more modern alternatives).

The biggest reason is just how old the code is. Among other problems CCK Blocks has very poor entity support (just a few entity types hacked in to some obselete Drupal code in the initial d7 port really).

However, as to retiring it.... Despite me trying to document / suggest alternatives as strongly as possible on the CCK blocks module page, another 5000 sites have installed it since then. So I believe people are just upgrading based on what they know from previous versions. Since it's apparently too popular to kill for D7 - we can't expect these people to migrate to something else now, it looks like all we can realistically do is not make a D8 port and provide a well documented / tested migration path to Field as Block.

So if there is a D8 CCK_Blocks, it will be merely a migration helper tool (much like the CCK module became in D7). I think given the usage stats I mentioned above, that might be the most effective way to steer these 10,000+ CCK block site builders to the correct new module and help them get their migration done. If we do it as a Field as Block helper module, they may not find it as easily (even if we document it on the CCK Blocks page).

13rac1’s picture

Thanks for the update!