Jon Schroeder

Sounds good. If you’d like to see what this would look like in practice, there are sample styles and markup in this plugin (which is essentially an ACF version of the same sort of thing atomic blocks does):
https://github.com/jonschr/gutenberg-sections

My home page has a section with a video background above the fold, added via the plugin:
https://elod.in/

Screenshots of the settings:
https://ibb.co/VjcDrLj
https://ibb.co/khrZxdP

Will do!

1. Sounds good. I **do** think that pre-wordpress 5.4 the default behavior was essentially what I’m describing here. And yeah, I figured that was what’s happening, since there’s a paragraph there already (it gets focus, then immediately loses it). I may pull down a copy of the dev branch to play with this a bit and see if I can find another way (haven’t used your build system before, but it looks simple enough).

2. Yeah, after recording the video I looked further into it, and I see the pickle you’re in – the new control scheme is how you target the new blocks, but in the old scheme just wasn’t as fine-grained, and I doubt you can reliably add those controls to existing blocks since there’s not a great way to know whether they’re fullwidth or not, nor a great way to target the toolbar in the necessary use case since it’s outside the block markup. I doubt there’s much that can be done here, and that’s not your fault.

Not sure how much time I have to dedicate, but I’d love to contribute to this project a bit. There are several features I’d love to see added, and PRs might be the way to do that. Video backgrounds for the container block, controls for making the background image fixed position, default paddings for container blocks, and a few others are the things I’ve been mulling.

BTW, it does look like on blocks that were previously added, if you toggle them to not full, then back to full, that adds the [data-align=”full”] that you’re targeting in the CSS and makes the block work properly.

First of all, thanks so much!!! Night and day difference on the block selection, and the new toolbar looks great on new blocks!

I see two remaining issues:

1) The selection of the container block after adding it still isn’t happening, and this presents a huge usability issue for clients using their sites. I know that I can push the up arrow to select the parent container, but the default behavior when adding a block should be that the newly-added block is selected (otherwise, it looks like you’ve just added a paragraph). Video showing what I mean: https://www.loom.com/share/7a6a988e2cc84b31abea0e9dda7f31b3

Possible partial solution: add default padding on the backend to this block which will be overridden anyway when/if the user adds padding. That would make the block more easily selectable, though it still probably should be selected by default.

2) Is there a distinguishing factor between the old containers and the new ones in terms of CSS class or anything like that? I have a few sites that are built from those containers, and might inject some css to fix it on the old ones as well. Obviously, if this fix only applies to “new” blocks, that means every site ever built with AB using fullwidth blocks will look broken on the backend, which seems somewhat problematic.

• This reply was modified 4 years, 7 months ago by Jon Schroeder. Reason: clarity
• This reply was modified 4 years, 7 months ago by Jon Schroeder.
• This reply was modified 4 years, 7 months ago by Jon Schroeder.

Sure thing. John, if there’s anything you need help with – if you’d like me to run the current version of the plugin on Github and look for what’s working and what’s not, for example, I’m happy to put time into it. I love using Atomic Blocks, and I want it to be as good as possible.

I’m jumping onto this ticket because I’m pretty sure I’m experiencing the same behavior. An important note: I was seeing this behavior before the 2.7.1 release as well – I think the issue here is updates to Gutenberg, not anything to do with Atomic Blocks (other than Atomic Blocks now probably needing to update for compatibility).

Here’s a video showing what I’m seeing:

The issue described above is seen here, along with a few others.

I hadn’t thought of using the group block for this. That would work but feels a little unnecessary (and also might screw up some css meant to target AB containers directly inside the content wrapper, as I sometimes do in order to enforce consistent padding on mobile).

I don’t think I understand the distinction you’re making. I’d like for the outermost wrapper of the an container markup for the an container to be able to have an ID, e.g <div class=“ab-whatever” id=“myidsetintheblocksettings”>

This would allow for the wrapper itself to be used as an anchor, as typically we’re wanting to scroll the user to that section of the page, not to the heading (which might be vertically centered and scroll the user a bit too far to see the top of an image next to it or whatever).

I guess really I don’t know what the downside would be to having this setting on all AB blocks.

Welp. After fiddling with this for a couple of hours right before posting this, I just found it.

$query->set( '_sc_display', 'upcoming' );

I do wonder why the _sc_display and _sc_order components of the query aren’t functioning correctly on Genesis. If these were set to have different defaults (‘upcoming’ and ‘ASC’), it might make this plugin slightly easier to use for Genesis users.

Don’t think I need anything at the moment; this gets me all set, but still might be useful feedback for you guys.

Thanks so much!

This appears to have worked! Thanks again.

I’ll try that and follow up. Thanks so much!

I’m wrong, BTW. It’s not every attempt coming from 127.0.0.1. There are others that it’s catching as well. Screenshot: https://snipboard.io/uEVCLx.jpg

I should probably also tell you that the hosting here is CloudWays (Digital Ocean), and this particular site happens to use Cloudflare, though not all of the sites affected use Cloudflare.

Sure! Here you go:

REMOTE_ADDR = 127.0.0.1
HTTP_X_FORWARDED_FOR = IP1
HTTP_X_REAL_IP = IP1