Multiple custom styling issues

Yes! I checked the page source, and the Description is rendered as a simple P element. But by using the containing DIV class, I was able to style those specific elements with minimal custom CSS:

.tribe_events p {
color: #000000;
}

Now all that remains is the disappearance of the featured image in the single event page. As previously said, the events use the Single post template, which my Posts also use. And Posts do display their featured image, see for instance this post: Test – Het Thrillercomplot.

• This reply was modified 1 week ago by Floris.

This confuses me.

With all other post types, I set a featured image in the sidebar, which is then shown in the post, because the template has a placeholder block for it.

When I use the advice in the linked documentation to add the featured image to the template (which is already present), nothing changes for existing events, which is already bad news.

But for a new event, the editor suddenly contains a featured image block, which syncs with the featured image in the sidebar. This is non-standard behavior, and opens the featured image block to accidental deletions.

Also, I cannot add the featured image block to the existing events (it is not available for selection). Given that all my existing events already have a featured image selected in the sidebar, this means this hack is not a solution. (It also means that accidental deletion of the featured image block in the editor cannot be fixed.)

I’m growing very frustrated with TEC.

Don’t get me wrong, I use TEC on my other site, and am very happy with it there. But that site does not use Gutenberg, and also uses a more standard black-on-white color scheme. It seems that for inverted color schemes and Gutenberg, the TEC plugin is lacking in basic support of standard behavior.

What I would expect:

• Custom styling applied to all block types included in the Events templates.
• Standard Featured Image behavior: select it in the sidebar, and it’s included in the post based on placement in the template.

As it is now, the only way to get TEC to do what I need on this site, is to: either add significant amounts of custom styling, and accept the strange, non-standard behavior of the featured image; or revert to a non-Gutenberg theme. (Because the only reason it currently sort-of works is that I’ve accepted for now that I need to invert my color scheme for the TEC pages. Which is not acceptable in the long term, so in the long term, all the custom css would need to be re-added.)

And I have yet to hear any kind of acknowledgement from you guys that this may not be the best way for TEC to support Gutenberg, and that this may need some updates and bug fixes on your end. Instead, the customizations pile up, even though, as I said, it seems to me that these are all features that should work out-of-the-box. (Even the P styling for the description. If a P element is part of the TEC templates, TEC should apply the custom styling to P nested in the TEC DIV, it should not be necessary to add custom CSS for that.)

I eagerly await your response.

Hi Darian,

Thanks once again for your continuing support. I’m really impressed with you and your colleagues’ efforts and willingness to help. That’s not as common as it should be, StellarWP is exceptional here!

That said, based on your response I don’t think I’ve made my points entirely clear.

I’m sure that needing the featured image block in the editor is expected behavior for TEC. My point, and disappointment, is: it’s non-standard behavior for WordPress, nor for other plugins that create CPTs. Standard behavior I’ve seen everywhere but in TEC is: setting the featured image automatically includes it in the presentation of the post, without needing representation in the editor. This is what for instance Posts, Pages, WooCommerce Products etc. do. So to me, it seems that adding the featured image block to the editor for events is a workaround for a limitation of TEC.

Similarly, I am used to styling customizations applying automatically to all relevant elements that should be affected by the customizations. As you knowm, I have customized the styling through Appearance-Customize-TEC, that’s what we started this discussion with. But that customization is applied very imcompletely, necessitating numerous custom css entries, as also already discussed above. To keep the css customization manageable, I had to abandon part of my desired site-wide styling, and accept that TEC looks different.

Needing that much custom css defeats the purpose of the styling customization UI. And like I said, it seems to me that it should be possible to code TEC to take into account the various styles that might be nested in the TEC wrappers. That the custom styling is not applied correctly or fully in the presentation of TEC pages, suggests to me that some css styles have been forgotten in the code to implement the custom styling choices. Most other plugins, and WP itself, succeed in applying custom styling (through the UI) wherever applicable.

I’m not saying that this should be fixed right now. But it confuses me that you and your colleagues keep repeating that this is expected behavior, and nothing to be surprised or dissatisfied about; that you keep offering workarounds without calling them workarounds.

I can create as much custom css as needed to achieve my desired effect, and I can (probably) add the featured image block to the editor. But based on my experience with WP and numerous plugins, this should not be necessary, and suggests TEC can do with an update to support the expected behavior of featured image and custom styling.

Do you understand what I mean?

Floris

Okay, @d0153 Darian, I’ve added my voice to that feature request.

As for the featured image: I understand your reasoning, but I suggest this is not optimal from a user’s perspective. I feel you need very sound reasons to deviate from expected standard behavior. Flexibility is all good and well, but the standard featured image behavior is very well-established and familiar to users, and not wanting the featured image to appear is the deviation.

I would suggest there are three use cases for the featured image that TEC may want to support for events:

1. Featured image presented in standard fashion, at the top of the Event page.
2. Featured image not presented at all.
3. Featured image presented in a different location on the Event page.

Case 1 is out-of-the-box WordPress behavior. As demonstrated by the fact that the standard Single template has a block/placeholder for the featured image. It is weirdly non-standard that the TEC single event apparently ignores that block in the template.

Case 2 is a no-brainer: if the user does not want a featured image presented, all they need to do is not set it.

Case 3 can be achieved by the user through inserting an image block (or image in non-Gutenberg) instead of setting the featured image. But strictly speaking, it’s not a featured image use case, as the very definition of the featured image includes its automatic appearance at the top of the post.

I expect there are all kinds of edge cases, like TEC users wanting the featured image to appear in the calendar popup and/or list, but not at the top of the event page. But I think those edge cases should be supported as edge cases; these should require special settings, custom css and perhaps even functions.php additions. Because these are the exceptions, the non-standard behavior. It doesn’t make sense to modify expected standard behavior to support edge case.

Your offer to help in expanding custom css to fully support my color scheme tempting, but I’m going to think about that for a while. The thing is: the custom css we’ve collected thus far to support the color scheme is already somewhat extensive:

.tribe-common-c-svgicon:not(.tribe-events-c-view-selector__list-item-icon-svg) path{fill:#fff !important;}
.tribe-events button.tribe-events-c-top-bar__datepicker-button{
	color: #fff !important;
}
.tribe-events .tribe-events-c-view-selector__list-item-text{
	color: var(--tec-color-text-primary) !important;
}
.single-tribe_events .tribe-blocks-editor .tribe-events-schedule .tribe-events-schedule__datetime{
	color: #fff !important;
}
.tribe-events .tribe-events-header__messages{
    background: #fff !important;
}
.tribe-block__event-price .tribe-block__event-price__cost, .tribe-block__event-price .tribe-block__event-price__description,
.tribe-block__organizer__details h3,
.tribe-block__venue .tribe-block__venue__meta .tribe-block__venue__address, .tribe-block__venue .tribe-block__venue__meta .tribe-block__venue__phone, .tribe-block__venue .tribe-block__venue__meta .tribe-block__venue__website,
.tribe-events-calendar-list__month-separator .tribe-events-calendar-list__month-separator-text,
.tribe-events-calendar-list__event-date-tag-daynum,
.tribe-events-calendar-list__event-venue,
.tribe-events-calendar-list__event-description,
.tribe-events-c-small-cta{
    color: #fff !important;
}

And as you can see in bold, the custom css code already includes hard-coded white color in four places, and TEC variable font color as well. This works, but is of course awful to maintain: if I change my color scheme, I have to also go through the custom css and replace each instance of the color I’ve changed.

It would already be much better if instead of hard-coded colors, the custom css could refer to the TEC color settings in all cases, as you’ve done in one instance here (var(--tec-color-text-primary)). But background color, font size etc. may also be customized, and parts of the TEC pages missed in applying those customizations, and then this custom css grows even larger and more unwieldy — even assuming the relevant variables are available.

• This reply was modified 1 day, 4 hours ago by Floris.