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
Comment | File | Size | Author |
---|---|---|---|
#9 | formblock-alpha1-1694940-9.patch | 6.5 KB | Michelle |
#8 | formblock-1694940-8.patch | 6.23 KB | jgraham |
#6 | formblock-1694940-6.patch | 6.05 KB | jgraham |
#5 | formblock-1694940-5.patch | 4.96 KB | jgraham |
#4 | formblock-1694940-4.patch | 4.84 KB | jgraham |
Comments
Comment #1
jgraham CreditAttribution: jgraham commentedAttached 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.
Comment #2
jgraham CreditAttribution: jgraham commentedRe-roll with subject set to field label.
Comment #3
jgraham CreditAttribution: jgraham commentedAdd 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.
Comment #4
jgraham CreditAttribution: jgraham commentedAdd 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.
Comment #5
jgraham CreditAttribution: jgraham commentedSorry 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.
Comment #6
jgraham CreditAttribution: jgraham commentedOne 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.
Comment #7
aritra.ghosh CreditAttribution: aritra.ghosh commentedThere 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.
Comment #8
jgraham CreditAttribution: jgraham commentedPrevious patch was missing security check to ensure the user could update the entity. Additional refactoring/cleanup on the block retrieval logic.
Comment #9
MichelleHere's a version of the patch that applies cleanly against 7.x-1.0-alpha1.