Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Sometimes you need to use the bean to create only entity type without the need to create block for it, so I add a patch that add page configuration(block/config-blocks) that allows to Enable/Disable block that related to entity type create from bean.
Comment | File | Size | Author |
---|---|---|---|
#22 | interdiff-2806123-20-22.txt | 1.81 KB | Samvel |
#22 | bean_block_status-2806123-22.patch | 7.93 KB | Samvel |
| |||
#20 | bean_block_status-2806123-20.patch | 8.11 KB | Samvel |
| |||
#16 | bean_block_status-2806123-16.patch | 8.16 KB | Samvel |
| |||
#5 | interdiff.txt | 3.78 KB | Samvel |
Comments
Comment #2
m.attar CreditAttribution: m.attar commentedComment #3
DamienMcKennaThanks for the patch! FYI "Needs review" is the correct status when a patch is uploaded.
Comment #5
Samvel CreditAttribution: Samvel at DrupalJedi commentedI reviewed patch #2
Nice idea.
Patch not working, i append reroll with few fixes:
1) Code format fixes
2) Append missed comments (for example block comments for functions and hooks)
3) Changed path to config page, because previous path can't be found anything in menu
4) Improvements on config form, because there are no any conditions, for example if we haven't beans yet
5) Append removing variable in hook_uninstall
Comment #6
Samvel CreditAttribution: Samvel at DrupalJedi commentedIn general, my vision of the settings is completely different. I see this setting in bean type form (when we create or modify bean type) and may be i see it in bean entity form (to override global bean type setting). Because current form in patch not usable, it's not sorted, without pager and when we will have too much blocks it will be not ok.
How you think guys? We can skip current solution or may be move settings to bean type and bean entity forms (although I do not want to overload bean entity).
Comment #7
Samvel CreditAttribution: Samvel at DrupalJedi commentedRelated ticket #2836128: Bean unnecessarily fully loads all bean entities on hook_block_info where this issue should be done as i explained above. I will process it.
Comment #8
Samvel CreditAttribution: Samvel at DrupalJedi commentedAlso now i understand that solution in #5 not fully work, because it's by default removed all existing blocks.
It work for new projects without content, so you can use it.
By the way i start work on solution with configuration in bean type and bean form. By default blocks will be enabled. In bean type we can disable blocks for any bean type and if blocks disabled for bean type - in each bean we can enable it as block.
Comment #9
Samvel CreditAttribution: Samvel at DrupalJedi commentedComment #10
Samvel CreditAttribution: Samvel at DrupalJedi commentedAccording to #2836128: Bean unnecessarily fully loads all bean entities on hook_block_info it's major issue (impact to perfomance)
Comment #11
Samvel CreditAttribution: Samvel at DrupalJedi commentedIt's done, please review.
Comment #12
Samvel CreditAttribution: Samvel at DrupalJedi commentedRemove one empty line in patch
Comment #13
DamienMcKennaExcellent work, everyone.
A few minor things:
Otherwise I'm excited to get this committed.
Comment #14
Samvel CreditAttribution: Samvel at DrupalJedi commentedHi @DamienMcKenna,
Attached new patch and interdiff
Comment #15
DamienMcKennaAlmost there - comments need to wrap at 80 chars.
Comment #16
Samvel CreditAttribution: Samvel at DrupalJedi commentedI see only one place, fixed.
Comment #17
Samvel CreditAttribution: Samvel at DrupalJedi commentedComment #18
DamienMcKennaAdditional nitpicks:
Looking through the patch itself, I wonder if we really need the option of controlling it on a per-bean basis? Shouldn't it be enough to control it per bean type? Does anyone actually need that level of flexibility?
Comment #19
DamienMcKennaComment #20
Samvel CreditAttribution: Samvel at DrupalJedi commentedI did it, but i think we can split to more readability.
Sorry, about what period are you talking?
I think, it's case when we have bean type with many entities and only one - two of them should be used as block. In one project on my work we have about 10 bean types and each of them have already > 1000 beans. Sometimes some block inserted on homepage thru block UI, other blocks not needed in block UI.
Comment #21
DamienMcKennaAlmost there :)
Good point about the bean usage, that can get rather hairy on some sites because it was used in place of ECK.
Comment #22
Samvel CreditAttribution: Samvel at DrupalJedi commentedI can append only one dot at the first line, but if we look to other places in same file - it's missing everywhere.
I copied it, but with difference. I think they should be different, because in one place it's status of all bean type, but in other place it's status only for bean entity
Comment #23
DamienMcKennaThat's fine about the coding standards, I created #2940809: Clean up the codebase to do a general cleanup of the codebase.
Comment #24
Mile23Patch in #22 still applies.
This patch seems to successfully allow you to turn off blocks per bean, but it doesn't change the behavior of caching by bean.module.
Being able to turn off block per bean, plus separation of concerns for block caching as per #2577095: Move Block table integration to a submodule would go a long way towards solving a number of scale issues, and make further scalability changes maintainable.