We want the ability to expose individual fields for a specific entity id in specific blocks.

Proposed solution:
1. Expose config option on the field instance setting. This has to be at the field_config_instance_id level as this will allow us to recover the other pertinent details such as entity_type. This will then make available a block. This process is similar the node type block configuration although at the field level.
2. Recover the currently active entity via menu_get_object() with an additional call to drupal_alter() to allow other modules to adjust what the currently active entity is. Similar approach to #1694894: comment form for currently active node

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jgraham’s picture

Status: Active » Needs review
FileSize
4.81 KB

Attached patch builds off the editablefields module if it is present. (Use at least 7.x-1.x-dev, there a few bugs fixed in the dev branch.

Once you have enabled formblock and editablefields navigate to content type structure, and edit a field (eg. admin/structure/types/manage/page/fields/field_image) then check the box corresponding to 'Enable data entry from a block' this will expose an option for a block that you can enable via standard administer blocks, context, etc.

Requirements: editablefields 7.x-1.x-dev.

@mikey_p, as we discussed at the PDX front-end meetup I can refactor this to a standalone module if there is interest to add this as its own module for formblock. I figured since the code footprint is relatively small and we leverage editablefields for most of the work it might be reasonable to include in the main formblock module.

jgraham’s picture

FileSize
4.83 KB

Re-roll with subject set to field label.

jgraham’s picture

FileSize
4.88 KB

Add additional check to make sure the field exists on the entity before attempting to load the editable field form. Avoids some errors/warnings and half-built blocks.

Minor spacing cleanup.

jgraham’s picture

FileSize
4.84 KB

Add additional contextual information for drupal_alter() having the field we are loading the form for in addition to the entity is important to have enough contextual information.

jgraham’s picture

FileSize
4.96 KB

Sorry for all the patch chatter, we are getting to implementing this and finding a lot of edge cases to fix this.

Re-roll of 4, with additional check to make sure the current entity bundle matches the field instance bundle.

jgraham’s picture

FileSize
6.05 KB

One more update. This removes the use of field id as that may vary from site to site. Instead we build a delta of field-ENTITYTYPE-BUNDLE-FIELDNAME and then hash that via md5 if the delta is longer than 32 characters, similar to how views blocks use hashes.

This makes it so that we can use context etc. to manage our block display and have consistent non-site dependent block displays.

aritra.ghosh’s picture

There is a project called "Advanced Form Block".
http://drupal.org/project/afb
It provides multiple node add/edit forms in blocks and also their ajax saving. you can give this a try.

jgraham’s picture

FileSize
6.23 KB

Previous patch was missing security check to ensure the user could update the entity. Additional refactoring/cleanup on the block retrieval logic.

Michelle’s picture

Issue summary: View changes
FileSize
6.5 KB

Here's a version of the patch that applies cleanly against 7.x-1.0-alpha1.