Squiz DXP

User story: As a web editor, I need to change list type attributes to ensure policies display the correct list type (see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ol#attributes ) Issue/Opportunity: It is not possible to change list type attribute in the Matrix wysiwg editor. Changling list type requires using the source code editor, and the new list types do not render in the wysiwg view. Request: Support all HTML list type attribute values in the wysiwg editor, including choosing which type to use, and rendering this correctly in the wysiwyg editor.

Currently all editors can see and change all metadata applied to an asset. This can lead to a lot of metadata fields being visible to editors that aren’t even relevant to them (and in some cases they shouldn't be changing them). It would be great to be able to restrict particular fields, sections, or even entire schemas. In our design system template we have nested content areas that are set up when a site is created - it'd be great if these particular fields were only visible to (or at the very least editable by) system administrators. If we had more fine-tuned permissions control, then some users with write access might be able to see and edit some basic fields, but then users with admin access might see more advanced ones – and depending what user groups they are in they might see none, some, or all.

It would be useful to have a way to set up flexible layouts within my pages. For example, for a landing page I'm building I want to position components into two columns for part of a landing page, but have full width components for other parts of the page. I know I can do this with custom paint layouts, some custom CSS and other code tricks, but i'd like my content editors to be able to self serve and set up their page content like this.

Currently the WYSIWYG editor doesn't style elements the same as the published site (e.g headings, body copy fonts etc). Also our editors have requested small tweaks to aid content creation, such as underlining text with lang attributes, correcting list type styling to match html etc. Current workaround is via a user specific CSS file/browser add-on. However having a WYSIWYG specific CSS file in the repo or something similar would be more useful.

Source: https://squizmap.squiz.net/matrix/12589 Votes: 19 Thoughts: Looks like a high value enhancement as there's good demand for it -- Summary: A feature that would greatly help with extending the metadata functionality and making it even more powerful would be repeatable metadata sections. The idea being that a schema would have a section that is defined as repeatable, and the schema would be copied any number of times and filled with relevant data.

We are using a redirect asset to provide a link to a survey from a component on our site. When the New window toggle is used it invokes javascript to open in new window without the browser address bar which gets blocked by some web browsers. As the target attribute of the link element is included in the html spec could a non-js approach to this be used or offered instead? E.g. the New window setting could offer: New window (toggle) Use javascript (toggle) Options Window width/height... Without toggling use javascript target attribute will be set to _blank

Hi team, We are on v6.46.0 and using design system components. When workflow is enabled and content on a page is updated, during the approval process, updated content is not highlighted. This seems to work when out of box Squiz matrix code blocks are used on v6.26.0. The issue is due to SSJS rendering the content - since it's using the design system component, it's rendering all content via SSJS, and the Handlebars template, so it sees all changes as new updates. How does this work with Component Service? Is there any potential solution for this issue as its quiet important for the devolved publishing across different business areas. Let me know if you need more information on how to recreated this issue. Cheers

It would be very useful to be able to define a first class content type in the CMS. Currently in Matrix we do this with a standard page, a metadata schema, a paint layout and maybe a custom design. These aspects all need to be managed separately meaning lots of room for error. There's also no good simple end point for headless CMS capabilities. If we had a concept of first class 'content types' in the CMS, that allowed content modelling, default templates, and a built in way to use it via API, it would be very useful to better model the kinds of structured content Squiz customers need to manage.

Change the default setting for assets to hidden links, rather than menu links, or allow organisations or users to choose their own default. Hidden item is the safer option, and the most common assets we create need to be hidden e.g. news items. The current state adds risk, as many editors forget to change assets to hidden, and this adds time to every task. It's only adds a few seconds to each task, but the frequency of those tasks means the time adds up.

User story As a web editor, I want to be able to link web users to an asset in a specific location in the site tree, to ensure they have the most relevant context. Issue/Opportunity Many of our assets are linked in multiple locations in the asset tree (legacy issue). In some situations, we want to preserve the multiple locations, but recommend one or the other based on where we are creating the hyperlink. Solution(s) We can hardcode URLs, but this creates a risk of links breaking when updated. Ideally, there would be an optional field to specify a URL when hyperlinking to an asset.