Frontend output

[slimndap]

• The current HTML output of the production and event lists is heavily outdated.
• Doesn't work very well on mobile devices.
• Default CSS is still using floats and the HTML structure is hard to style by frontend developers.
• Accessibility was never considered.
• Additional views may be nice (eg. calendar or timelines).

[atkozie]

Well this is affirming! I've wrestled mightily with styling the front end of this plugin.

[slimndap]

Please feel free to submit improvements.

[atkozie]

Individual control over the datetime components would be helpful. It all outputs as one piece of html, so I can't for example use CSS remove the year from the datetime like my client wants.

I've been digging through the files of the plugin to try to find a way to rip out the year output, but I only sort-of read PHP and JS, and I definitely don't write it. So I was unsuccessful.

[slimndap]

Currently it would require a programmer to write a little bit of custom PHP code.
The output of the startdate can be changed by using the wpt/event/startdate filter.

[carstingaxion]

I also thought about this now, had a look across all add_shortcode calls and their output and came to the following:

1. Given, that we come to a new data architecture, using post_types, taxonomies and shadow-taxonomies, etc., so that we can make more efficient calls based on WP_Query using core functions.

2. And decide to not further support classic themes with the new version ⚠️

3. We can simply go on and create a bunch of blocks, which are (by design) able to replace a defined shortcode - incl. it’s attributes - into one or more blocks by itself using block transforms.

4. @slimndap All of your reasonable pain-points regarding

   • outdated HTML
   • responsiveness
   • accessibility
   • and even additional views
     … will be (at least party) covered by core blocks, which we will leverage the most - I suggest

5. By creating only core block-variations rather than new custom blocks, we don’t have to worry about most of the UI stuff, instead we will get progressively enhanced blocks, reliably tested and with the best integration for the world of (block)-themes. IMHO Most of the found shortcodes could be transformed into variations of the core query-block.

6. The coming block-bindings API will be the second important piece, as it allows us to connect the existing post_meta data to be rendered into core-blocks super easily! This would also be the way to go with the datetime-component mentioned by @atkozie

7. For many of the existing options related to the visibility of particular features, like for e.g. the existing Show event list on production template we now have block-hooks, which will allow us and existing users to do a theme switch easier, because some of the structure of a classic template can be regenerated on-the-fly even with an empty theme. This should help us a lot providing a nice upgrade-experience.

What do you (all) think about the proposed way?

I‘ll try to create some demo blocks based on existing shortcodes or post_meta or both in my repo dedicated to theater production blocks, let’s see.

(Edit: Added number 7, which I forgot when submitting the comment)

[carstingaxion]

The essence of my thoughts have already been here on the repo:

The front end output is very clean, to ensure accessibility and compatibility with themes and can be customized using hooks and template files.

Source: @slimndap #321

[carstingaxion]

First tests were successful.

Bildschirmaufzeichnung.vom.19.02.2024.01.32.16.webm