The Inline Block module allows the delegation of placing blocks on an individual node to the node's author(s). Permissions are built-in to the module to restrict this capability, by role, on a per node-type basis, and per-region. This module works best when used in conjunction with modules that create dynamic blocks, like views or bean. Bean may be slightly more powerful than views, as the bean module also allows content-editors to create their own blocks. It can be extremely useful to allow the content-editor to place desired blocks in the allowed regions. The inline block module makes this possible via its own context plugin and the blockreference module. When a content-type is enabled to allow inline blocks, additional fields are added to the type, one for each selected region. This is how each node keeps track of the blocks assigned to it. When it comes time to render the node, the fields are removed from the node object and transferred to the theme/context layer, thus making sure the block is rendered only once.

This module is unique because it can isolate a content-administrator's ability to place blocks to ones that are controlled by the site administrator.

The project sandbox page is at http://drupal.org/sandbox/partyka/1884674
The git repository is at http://drupal.org/project/1884674/git-instructions

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://ventral.org/pareview/httpgitdrupalorgsandboxpartyka1884674git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and 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.

partyka’s picture

Two things about the automated code review:

1) The warnings about function names beginning with the module's name to avoid conflicts -- these functions begin with an underscore as they are helper functions, and need to insure that there will never be a conflict with any hook. I have yet to see guidance on how to handle this situation (and I have looked for it).

2) There are errors being reported in the file plugins/inline_block_context_condition.inc and inline_block_context_reaction.inc are due to the interface that these classes must conform to (except for the class name itself).

PA robot’s picture

Status: Needs work » Closed (won't fix)

Closing due to lack of activity. Feel free to reopen if you are still working on this application.

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

partyka’s picture

Assigned: Unassigned » partyka
Status: Closed (won't fix) » Active
fuzzy76’s picture

Assigned: partyka » Unassigned

For internal functions you use a single underscore in front of the function name, not double underscores. Since there still are issues, but you have indicated activity, I'm setting this back to "needs work".

fuzzy76’s picture

Status: Active » Needs work
PA robot’s picture

Status: Needs work » Closed (won't fix)

Closing due to lack of activity. Feel free to reopen if you are still working on this application (see also the project application workflow).

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