Content creation quirks

Please update this if you introduce a new quirk. This will help future site maintainers figure out how things work, or refactor things as Drupal and its modules continue to evolve.

Use of Layout Builder

• Layout builder is an out-of-the-box Drupal 10 functionality
• It allows single column and multi-column layout, with a drag-and-drop interface for various content blocks
• Fits our requirements to be able to build up a page by putting together different components

Existence of spacer block

• Instead of building spacing into each component themselves, a discrete spacer block was created solely for use in the Layout Builder
• This is because there is different nesting of markup depending on whether blocks are placed in the same section or separated by different sections
• Providing the spacer block ensures a more consistent way of handling spacing between components

Existence of press logos block

• Instead of creating a whole new content type and layout template just for a block of logos to be used in a single spot on a single page, it seemed more prudent to just create a custom content block
• Note that the block uses the full HTML text format such that we can ensure the markup ends up the way we want it to
• Styles are inline to make the block as isolated as it possibly can

Exceptionally complicated hero banner

• The general idea is that the more configurable you want to make a component, the more complicated it ultimately becomes 乁⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ㄏ
• This is probably the most complicated content type we have in terms of its template, because we have chosen to allow configuration from the CMS interface
• As such, in the template, we end up having to extract the field value from the CMS to display on the template as conditionals, for example, we display different markup if the banner type is different, or we use the field values as CSS variable values etc.

Summit speakers and talks are duplicated each year

• In an ideal world where unicorns shit rainbows, the summit speaker and summit talk content type would be reusable year by year but due to the shape of the data from Sessionize, this has proven untenable
• Essentially, the more massaging we have to do on the Drupal-end, the efficacy of importing the data drops significantly
• On Sessionize, speakers do not have any form of date field attached to them so we would have to manually tamper a year field
• The biggest issue is the problem of duplicate speakers, i.e. the same speaker has multiple speaker ids on Sessionize
  • Talks are linked to specific speaker ids, so if there are 2 of the same person, the feed import will not be able to link to the correct speaker
• TLDR, the most straightforward solution was to make every year's speaker and talk distinct 乁⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ㄏ

Styling code blocks

• While inline code is styled automatically, if you want to create a code block, you need to manually add the class codeblock to the container element that holds the <code> elements.