We present a set of proposals aimed at improving frontend display flexibility, modernizing style, and optimizing the workflow for editors (Backend\Editors).
1. Flexible Definition of Image Dimensions per Element
Current State:
When using elements such as "Text and Image" or "Text and Media," dimensions (Width and Height) are globally defined for all media elements via the Media\Adjustments option. The Crop option only allows for trimming but does not allow control over the display dimensions on the frontend for each individual record.
Proposal for Improvement:
Enable the individual definition of the display width and height for each image. This is crucial for achieving precise and controlled frontend layout, independent of global settings.
2. Modernization of Default CSS
Current State:
The default CSS for standard elements does not adhere to modern styling standards. It uses outdated methods such as position: text{relative}, right: 0, left: 0, and inefficient centering using float.
Example of outdated code:
.ce-center .ce-outer {
position: relative; float: right; right: 50%;
}
.ce-center .ce-inner {
position: relative; float: right; right: -50%;
}Proposal for Improvement:
Upgrade the default CSS by utilizing more modern and efficient solutions (e.g., Flexbox or Grid) for layout and centering.
3. Implementation of a Search Field for Content Type Selection (CType)
Current State:
A search field is missing for the selectbox when selecting "Type [CType]". The available option to switch to a sidebyside display negatively affects the layout of backend forms. This is a critical workflow issue for Backend Editors:
- When adding other tt_content elements in custom records, editors know the required element's name. Instead of typing the name into a search field, they must manually scroll through a pop-up or type the name on the keyboard while the field is selected.
- This is a tedious process: if the editor makes any typing error, they must re-select the field and restart the entry.
Proposal for Improvement:
Enable a search field for the select box used for "Type [CType]" by modifying the underlying JavaScript to support search functionality.
4. Simple Exclusion of Pages from the Sitemap
Current State:
Pages that should not be in the sitemap (e.g., 404 error pages or content example pages) often appear there. The current method (disabling the index and follow options) can inadvertently affect the robots settings of records located on that page.
Proposal for Improvement:
Introduce an explicit, separate field/option at the page level for excluding the page from the sitemap. This would allow easy sitemap management without compromising the SEO settings for associated records.
5. Enhancement of Content Elements by Expanding Headline Fields
Current State and Limitations (Existing Fields are Insufficient):
The currently available headline fields (which include Headline, Headline position, Headline type, Date, Headline link, and Subheadline) lack the necessary flexibility to achieve modern styling. The key issues are:
- Text Position Dependency: The text positioning defined for the Headline automatically reflects onto the Subheadline.
- Style Control (Missing Classes): There is no mechanism to define separate CSS classes for the Headline and Subheadline individually. This prevents the application of distinct styles (fonts, colors, sizes) to each element.
- Automatic HTML Tag Inheritance: If the Headline TYPE is defined as H2, the Subheadline automatically defaults to H3. Modern design requires the ability to override this and use a simple p tag for the subheadline, for example.
Proposals for Field Expansion:
- Enable independent HTML tag definition (H1, p, div, etc.) for the Subheadline.
- Introduce fields that allow for the individual definition of CSS classes for both the Headline and Subheadline, and add other fields for Subheadline, like we have for Headline
- Add fields for Labels to be positioned above the main Headline. This is often required by modern design and facilitates content editing and better SEO.
6. Enabling the Bodytext Field in Standard Plugin Elements
Current State:
For elements of type Plugin (in the CType list), the Bodytext field is currently disabled. This restriction is typically defined within the system's TCA configuration. Consequently, to add introductory text, editors must use a separate Text element above the plugin, which complicates the content structure and editing process.
Proposal for Improvement:
Modify the TCA configuration to enable the Bodytext field within Plugin elements. This will allow for the placement of introductory text within the same element, simplifying styling and overall content management.
