@fsbraun nice! I thought a bit about this and have two use cases:

1. would dragging a edit_disabled plugin outside the controlling parent still be possible, e.g. can an editor (accidentally?) destroy a parent-child complex designed by a developer so that it becomes unusable, especially as the controlling parent plugin template (probably?) counts on the existence of specific child plugins in a specific order?

2. dragging a edit_disabled plugin inside the controlling parent, e.g. changing the order of its child plugins. This might cause a similar issue, the controlling parent's template might expect the controlled children to be in a specific order?

In summary, would it make sense to also disallow direct drag & drop for edit_disabled plugins?

Of course, dragging them via a parent plugin should always be possible, as the whole complex can be dragged to another position in the placeholder, can be cut or copied and pasted elsewhere.

@macolo Draging is still fully controlled by allowed_parents and allowed_children. This means I could change the order of columns or move a column to a different row. But I should not be able to drag a column into something else than a row.

Indeed, the parent plugin cannot rely on the existence or order of child plugins. Any management code must be flexible and say recreate a missing child if needed, or might want to merge if there are several children, say, for a single slot. Disabling dragging alone would not solve this issue: There is also pasting or adding plugins.

PS: The custom component construct does ignore the order of the child plugins.

@macolo I have now implemented drag-disabling in principle (CSS and JS side). Shall we go for another plugin option that disables drag for child plugins? It would also need to disable add and paste. Something like child_edit_disabled...

Reviewer's Guide by Sourcery

This pull request introduces the ability to disable the edit modal for plugins. This is achieved by adding an 'edit_disabled' property to the plugin class or instance. Additionally, it allows adding custom classes to the drag item in the structure board via the 'add_structureboard_classes' property.

Sequence diagram for plugin edit interaction with disabled editing

sequenceDiagram
    actor User
    participant UI
    participant Plugin
    participant Editor

    User->>UI: Double clicks plugin
    UI->>Plugin: Check edit_disabled status
    alt edit_disabled is true
        Plugin-->>UI: Editing disabled
        UI-->>User: No action
    else edit_disabled is false
        Plugin-->>UI: Editing allowed
        UI->>Editor: Open edit modal
        Editor-->>User: Show edit interface
    end

Class diagram showing plugin edit configuration changes

classDiagram
    class Plugin {
        +edit_disabled: bool
        +add_structureboard_classes: string
        +allow_children: bool
        +disable_child_plugins: bool
        +get_plugin_class()
    }

    class PluginInstance {
        +edit_disabled: bool
        +add_structureboard_classes: string
    }

    Plugin <|-- PluginInstance

    note for Plugin "New properties added:
edit_disabled and
add_structureboard_classes"

    note for PluginInstance "Can override class-level
edit_disabled setting"

State diagram for plugin edit states

stateDiagram-v2
    [*] --> Normal
    Normal --> EditDisabled: edit_disabled=true
    Normal --> Editable: edit_disabled=false

    state Editable {
        [*] --> Ready
        Ready --> EditModal: Double click
        EditModal --> Ready: Close modal
    }

    state EditDisabled {
        [*] --> NoEdit
        NoEdit --> NoEdit: Double click (no effect)
    }

File-Level Changes