Luke Carbis

@crumptoninc Thanks for your suggestion. The background image doesn’t use a srcset, you’re right. That’s a sensible change, though –?and since the image isn’t loaded as a CSS background, it’s entirely possible.

I’ll pass this on as feedback to the dev team.

@app1e5auce You should look for the editor styles CSS file that you’ve created. It should be loaded via the path you choose, e.g. blocks/block-image-callout/preview.css.

I just double checked with the latest version of Genesis Custom Blocks, and the preview stylesheet loaded perfectly.

Can you double check that you got the block’s slug correct?

@app1e5auce Those paths look correct to me. I understand that the editor styles aren’t showing. Could you check in your inspector to see if the stylesheet is loaded at all?

Is it possible that there’s some CSS overrides happening, that don’t allow your editor styles to apply?

Ciao @recetteitalienne. Currently the only block that supports structured data is the Pricing Table. We don’t have support for FAQPage structured data in any of our blocks, as we don’t have any blocks specifically dedicated for FAQs.

@fourwhitesocks Yes, that’s right. There’s just a minor typo in your example. It would be genesis-blocks/gb-accordion.

Hi @2aussietravellers –?thanks for posting. I just tried your site on my iPhone and the links all work great for me, just one tap required.

Is this something you’ve managed to fix?

Hi @tussharctg – I’ve tried deploying from Staging to Prod in my WP Engine environment, and it worked perfectly. This seems like a problem very specific to your setup. Could you maybe try using a different deployment method and see if that changes anything? Additionally, could you try without any additional plugins enabled?

• This reply was modified 3 years, 11 months ago by Luke Carbis.

Ciao @enricopadovani.?As you’ve probably figured out, non é possibile al momento. It wouldn’t be too hard to add, though. I’ll mention the request to the team. I know there’s quite a large backlog of features that we’re working on, so it’s unlikely to be a priority in the next couple of months unfortunately.

@reelism Thanks for letting us know about the conflict! Definitely it’s something we’d like to avoid, but as I’m sure you can imagine, it’s hard to keep track of what other plugins and themes are doing, and keeping up with that.

Having said that, I think a sensible path forward could be to add an option to Genesis Blocks to automatically dequeue the styles as suggested by @johnstonphilip. That could be a good catch-all solution for if there are ever any conflicts.

I’d have to run the idea by the team, but what do you think?

Glad you got it sorted!

@nicolewp Hi Nicole! Shavua tov!

I’ve just tried out an accordion block on 5.7 myself, and had no problems with it. The expand / collapse arrows show up as expected on Chrome desktop, and other browsers I tested too.

So then I went on a search to try and discover why the arrow could not be showing on the page you linked to. At first I thought the arrow might be added via CSS through our plugin…?but then I learned (for the first time) about the <details> HTML tag: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details

Genesis Blocks inserts a HTML tag that does all the accordion work. I didn’t know such a thing existed until today. All the styling, including the arrow, should be handled by the browser.

So then I looked a little closer at the theme that you’re using and found the problem. On line 83 of your stylesheet (https://nicciherrmann.com/wp-content/themes/rebalance/style.css?ver=5.7) the <details> tag is told to display: block. This display property hides the browsers default handling of the accordion. Removing details from this CSS definition fixes the problem.

Hope that helps! Sorry for the wall of text. I had fun figuring out what the problem was and wanted to share the journey.

Luke

• This reply was modified 3 years, 11 months ago by Luke Carbis.

Hi @2ysub2ysur . Thanks for your question. The answer is: Not yet. But it’s a solid idea. We’re always striving to align closely with the standards that Core sets up.

@stinkykong Sorry it took me a while to get back to you. I’ve been testing this out myself too.

I’m trying to define exactly what the problem is, so I can report it back to the team. I think I’ve narrowed it down to this:

When in the Block Editor, the Container block does not correctly display “Inside Container Max Width” settings greater than the theme’s default content width.

That’s a bit wordy, I’ll try to put it another way…

In the Block Editor, the Container block’s “Inside Container Max Width” gets overridden by the theme’s default content width. This causes the Editor to display Containers differently in the Editor than on the Frontend.

Do you think that covers it?

@tussharctg Could you expand on how you trigger the error, please? Does it happen during regular use? During migration? During deployment?

If you could provide steps to reproduce the problem that would better help me understand what’s happening.

@personalchemist It’s hard to say for sure, but I’d recommend playing around with those Content / Sidebar percentages to see if you can get things scaling right.