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.
Module asset provides function override asset in contextual menu for assets. This function allows user to change some fields only for this instance of asset. For example, he can change description for photo.
But on some projects I have asset with only one field - image. And this field cannot be overridden. When user tries to use "override" function, he sees empty form without fields and he can be at a loss because it's strange behavior.
I propose to add special option for asset type, to allow to disable overriding for exact type of asset.
Comment | File | Size | Author |
---|---|---|---|
#13 | asset_deny-override-2559669-13-D7.patch | 1.92 KB | eugene.ilyin |
#7 | asset_deny-override-2559669-7-D7.patch | 6.28 KB | eugene.ilyin |
#5 | asset_deny-override-2559669-5.patch | 6.1 KB | eugene.ilyin |
#3 | asset_deny-override-2559669-3.patch | 6 KB | eugene.ilyin |
#2 | screenshot_156.png | 12.56 KB | eugene.ilyin |
Comments
Comment #2
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedComment #3
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedI've prepared patch to solve this problem. I hope it would be useful.
Comment #4
IRuslan CreditAttribution: IRuslan commentedIt's good catch to remove override if it's useless.
But i think better to pass some real asset options with _assets_get_overridable_fields() to JS instead of adding some option.
In this approach — if there is no fields to be overridden, override contextual option will be hidden.
So my idea is:
- during provisioning of field config on Drupal side check if there are field to override with _assets_get_overridable_fields()
- get this option in initialization of CKEditor menu and commands and do not init override
Comment #5
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and commentedIt's good idea to use data from function _assets_get_overridable_fields().
But I still propose to give possibility to deny "override" option for some cases, even we have fields to override, because not all projects need this extra option and it can confuse content manager.
So I propose to hide option "override" if option "Deny to override fields for instance of asset" is active or we have no fields to override.
I've prepared new patch.
Comment #6
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and commentedComment #7
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedI've updated patch because I found mistake in part for plugin.js
Comment #8
IRuslan CreditAttribution: IRuslan at DrupalJedi commentedHi, great work!
But i'm still thinking that we need to provide a generic way to configure contextual options in such case, instead of configuring each item separately.
About hiding override option automatically — it's good idea.
Just small detail. From what i see, editor.contextMenu.addListener callback called each time when we open menu.
Result of callback is the list of menu items for each certain situation (asset). This means that instead of deletion of previously added item (couple of lines above), we need to just do not add it.
So what we need to do is just to add new condition here:
if (conf && conf.modes && !(conf.modes.length === 1 && conf.modes.full && !conf.fields.length)) {
I propose to split your patch into 2 — fix with auto-hiding and configurable option — to make possible for others to re-use this feature if needed.
Comment #9
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedComment #10
IRuslan CreditAttribution: IRuslan at DrupalJedi commentedComment #11
IRuslan CreditAttribution: IRuslan as a volunteer and at DrupalJedi commentedFrom my point of view, the most acceptable solution is next.
We could add to place where we build context menu additional check, something like (it's rough example and should be well tested):
It will allow:
1. Do not break any previous versions/setups. No any hook_updates needed.
2. Allow any custom developers in a flexible fashion to control the context menu even per certain asset instance if needed.
I.e. we could override theming of asset template per asset type and restrict it. Or to add this attribute to global asset template to restrict options at all. Or these attributes could be added on the fly via JS if needed.
In the future, we could improve this and make it dynamic, i.e.
<some-asset-tag-in-template data-asset-suppress-menus="assetcut,assetdelete,assetoverride, etc">
So in your case, you just need to modify asset template to add attribute where needed.
Comment #12
IRuslan CreditAttribution: IRuslan as a volunteer and at DrupalJedi commentedComment #13
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedDone, could you check it please?
Comment #14
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedComment #16
IRuslan CreditAttribution: IRuslan as a volunteer and at DrupalJedi commentedGreat work!
Committed to dev.