The GinContentFormHelper::isContentForm() method incorrectly identifies non-content forms as content forms when they appear on content form routes. Specifically, when the masquerade block form appears on a node edit page (route entity.node.edit_form), it gets treated as a content form, causing multiple sidebar instances and overlapping UI elements.
The attached GIF shows the problem: the sidebar flickers and disappears when the page reloads.
The current logic only checks route names and form IDs, but doesn't verify that the form object actually extends ContentEntityForm. This causes any form rendered on a content route to be treated as a content form, regardless of its actual purpose.
1. Install and enable the Masquerade module
2. Enable the Gin theme
3. Navigate to a node edit form while the masquerade block is present
4. Observe that two sidebars appear, with the masquerade sidebar overlapping the node edit form's sidebar
5. The masquerade form is incorrectly treated as a content form because it's on the entity.node.edit_form route
Add an explicit check for ContentEntityForm instance before applying content form logic. The fix adds a form object validation:
$form_object = $form_state?->getFormObject();
if ($form_object && $form_object instanceof ContentEntityForm) {
return TRUE;
}
This ensures that only actual content entity forms are treated as content forms, regardless of which route they appear on.
This ensures that only actual content entity forms are treated as content forms, regardless of which route they appear on.
- Apply the proposed patch
- Test with masquerade module to confirm fix
- Test with other non-content forms that might appear on content routes
- Verify all legitimate content forms still work correctly
The overlapping sidebar issue will be resolved. Non-content forms will no longer incorrectly trigger content form styling when rendered on content form routes.
I think, this part of code should be enough to determine the function which the method name impose: isContentForm(),
Then the theme need another logic to determine we are on the content edit form _page_. The method docs is not correctly gives back the method meaning: "Check if we´re on a content edit form."
None.
None.
None. This is an internal logic improvement that doesn't change the public API.
None.
The method name isContentForm() and its documentation ("Check if we´re on a content edit form") are misleading. The method should determine if a specific form is a content entity form, not whether we're on a content edit form page.
The current implementation conflates two different concepts:
- isContentForm() - Should check if the form itself is a content entity form
- "on a content edit form page" - Should be about the route/page context
This fix makes the method actually do what its name suggests by checking instance of ContentEntityForm, rather than just relying on route-based detection. The theme needs separate logic to distinguish between "are we on a content edit page" vs "is this particular form a content form."
Active
5.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.