Region View Modes is a simple module that allows users to place fields in regions. It does this by creating View Modes for each region of any active themes. It then places rendered nodes (run through the custom view mode) in the corresponding regions.

See more detail, instructions, and screenshots on the project page.

Git Repo: git clone --branch 7.x-1.x http://git.drupal.org/sandbox/jeffam/2130043.git region_view_modes

Typically, this problem area is addressed by the creation of Views block displays that include only the required fields. The blocks are then placed via the block admin page or Context. This is a cumbersome approach, requiring the site builder to modify several settings, and may have a small performance impact if the node is loaded for each block placed on the page. A slightly lighter-weight variant of this technique would be the Field as Block module, which mainly removes Views from the mix.

Display Suite has the ability to place fields in blocks, but this requires the DS Extras module and, again, a cumbersome process of configuring the blocks, placing fields in the block 'regions', and then placing the block itself. One limitation is that fields can only be placed into one block. Region View Modes will allow a field to be placed in more than one region. One example of this would be to add the same image on the page as a large image style in the main content area and, say, a thumbnail in the right sidebar.

Lastly, there is a sandbox module called Fields in Regions that does something similar. I like how, similar to this module, it doesn't require the placement of blocks. Configuration is a bit complex, though, and it doesn't seem to allow for things like Field Groups and multiple displays of the same field.

This module is intended to be a very lightweight way to lay out pages using as much core functionality as possible. Theme regions and view modes are already part of Drupal core, and this module simply brings them together. It stands at ~150 lines of code (25% of which are comments) and I don't wish for it to grow much larger.

Thanks for your consideration.

Reviews of other projects

https://www.drupal.org/node/2106059#comment-9271561
https://www.drupal.org/node/2326343#comment-9272237
https://www.drupal.org/node/2296053#comment-9272325

Comments

PA robot’s picture

Status: Needs review » Needs work

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxjeffam2130043git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

spheresh’s picture

Сode is short and clean as for me. Just one thing.
I can't change a weight of "Region View" block. (It was placed a latest in blocks' list) I think module is overly specific without this functionality.

jeffam’s picture

@spheresh - Do you mean that blocks placed in the region appear before the fields? That's a good point, and something I should test more.

jeffam’s picture

Status: Needs work » Needs review

I have no idea how to respond to the PA robot, but I did indeed deal with errors from the pareview.sh review in my .module file. At this point, it's mainly complaining about line length in the readme file, so I fixed that, too.

jeffam’s picture

Issue summary: View changes
jeffam’s picture

@spheresh - I added a setting that allows placement of fields before or after system blocks. Does that address the limitations you found?

Region View Modes Placement

spheresh’s picture

What are you think about hook_block_init? somehow so http://d.pr/i/VPDT...
This would allow change the weight of the usual method for Drupal Users

jeffam’s picture

What are you think about hook_block_init? somehow so http://d.pr/i/VPDT... This would allow change the weight of the usual method for Drupal Users

Ah. I see what you mean. Region View Modes doesn't use blocks by design. It wouldn't really make sense to be able to put, as in your example, Bartik theme: Footer region into another region. I would recommend Fields in Blocks for something like that.

I wanted to avoid the need to place a block, thus keeping the module as simple as possible. But it's an interesting thought to have a Region View Mode Blocks module that creates a block for each view mode and automatically places it in a region. I still don't like how one would be able to move it out of that region though.

spheresh’s picture

I wanted to avoid the need to place a block, thus keeping the module as simple as possible.

This makes sense, in any case...
It is not a blocker. I think it's more like a additional features

heddn’s picture

Status: Needs review » Needs work

Very few blockers. Great solution for a common problem.

.info file is missing a version
version 7.x-1.x

Not a blocker, but good info:
if (($node = menu_get_object('node', 1)) && (arg(2) !== 'edit')) {
No need to pass any arguments to menu_get_object when they are the default.

heddn’s picture

Status: Needs work » Reviewed & tested by the community

I'm corrected. Version shouldn't be included. This is ready for RTBC.

https://drupal.org/node/542202#version

jeffam’s picture

Issue summary: View changes
jeffam’s picture

Issue summary: View changes

Added another review.

jeffam’s picture

Issue summary: View changes

One more review.

jeffam’s picture

Issue tags: +PAreview: review bonus

Tagging

stBorchert’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for your contribution, Jeff!
That's honestly one of the best project applications I've seen in a while.

Minor notes

Personally I'm a fan of "early returns" in functions. As an example, in region_view_modes_page_build() you're using if (($node = menu_get_object('node', 1)) && (arg(2) !== 'edit')) { and put the complete function code within this condition. If you negate the condition you could simply return and put the main code after the condition:

<?php
function region_view_modes_page_build(&$page) {
  global $theme;
  if (!($node = menu_get_object('node', 1)) || (arg(2) === 'edit')) {
    return;
  }
  // Main code of function.
}
?>

The same applies to loops ... Instead if putting all the code into an if-clause, simply negate the condition and continue; ;)

<?php
foreach ($region_view_modes as $region_view_mode_name => $region_view_mode_info) {
  $visible = !empty($view_mode_settings[$region_view_mode_name]['custom_settings']);
  if (!$visible || ($region_view_mode_info['theme_name'] !== $theme)) {
    continue;
  }
  // your code ...
}
?>

It's just a personal opinion and makes the code more readable (at least for me ;) ).

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

apaderno’s picture