Butterfingers

Hi @areoimiles,

On closer inspection, I’ve found the problem.

In the bootstrap.scss file for both versions of Bootstrap, variables.scss is imported before variables-override.scss (also, variables-override.scss is imported twice, which it’s not clear why). Unfortunately, Simply swapping the order of the imports isn’t the only fix required, since when the plugin saves the UI settings to variables-override.scss it includes variables which are only defined in variables.scss, resulting in “undefined variable” errors when compiling. If you can update the compile_scss() function to address this, it should solve the problem.

@areoimiles, this is truly an excellent feature. Thanks very much for adding this!

This is great, @areoimiles. Thanks very much!

Thanks very much for fixing this, @areoimiles!

Hi @areoimiles,

Thanks very much for this update. It’s working great, and the additional utility class and color functionality is very nice.

For setting alignwide, etc., for container blocks that are children of strip blocks, my guess is the solution is to add something for this to BlockControls and/or InspectorControls, to provide a convenient UI for toggling alignwide; basically, it’s the same as manually editing the “Additional CSS class(es)” field in the sidebar. My current workaround is just manually editing that field, but it would be convenient to have a more visible toggle.

Thanks very much!

Hi @areoimiles,

Thanks very much for this release! The new alignment functionality is very helpful.

There are a couple tweaks which hopefully are easy to add to it:
* Make the strip block’s alignment default to alignfull, based on its primary use case of “a full width div”.
* For container blocks which are children of strip blocks, provide alignwide. Currently, the only alignment choice is “none”.

No worries and no hurries, @areoimiles! Thanks for taking a look at this and continuing to develop this great plugin.

@areoimiles, thanks so much for the quick turnaround on this! It’s exactly what I needed.

Solved. Thank you very much for this!

Thanks very much, @areoimiles, and thanks for developing this plugin!

The following CSS-only solution is working for me (running WordPress 6.0):

// file: all-bootstrap-blocks/src/_editor.scss
.block-editor-block-list__layout.is-root-container { // line 113
    // Remove
    .wp-block:not([class*='container']) {
        max-width: 100%;
    }

    // Remove
    .wp-block[data-align="wide"]:not([class*='container']) {
        max-width: 100%;
    }

    // Core WordPress does this as of 5.9.0 in function wp_get_layout_style 
    // in file wp-includes/block-supports/layout.php, but it's probably fine to
    // leave it if it helps with backwards compatibility
    .wp-block[data-align="full"]:not([class*='container']) {
        max-width: none;
    }

    // Add
    .wp-block {
        
        .wp-block-areoi-strip,
        .wp-block-areoi-container,
        .wp-block-areoi-row {
            max-width: none;
        }
    }
}

Hi @areoimiles,

Thanks very much for the prompt reply and the function.

A plugin option to override the rule isn’t necessary for recent versions of WordPress. Since WordPress 5.9.0, the function wp_get_layout_style in file wp-includes/block-supports/layout.php (line 47 at the time of this writing) loads a max-width: none rule for .alignwide that is more specific than the plugin’s rule. I’ve tested this in the editor, and when a block is assigned .alignwide the CSS inspector clearly shows it overriding the plugin’s rule, and indeed, the block displays at full width. There’s nothing to break by removing the plugin’s rule for WordPress 5.9.0 or newer.

Adding just a few styles to the plugin for strip, container, and row blocks to display at 100% in the editor addresses that need without forcing all other blocks which aren’t within one of those blocks to display in the editor at full width.

The use of this plugin should compliment the core block editor experience and not require that every post use its blocks as parent blocks for core blocks. This is especially true when the plugin is added to a site with existing post content, the layout of which will appear incorrect in the editor when the plugin is activated unless that content is updated to use the plugin’s blocks, an onerous task for a site with even a small amount of existing content.

For older versions of WordPress, if the plugin were to respect settings.layout.contentSize in theme.json by default (if that file and setting is present), with an option to override that in the plugin settings (either by using a user-entered value or by falling back to the plugin’s rule, the former of which I believe would be the only option for versions of WordPress older than 5.8.0 not using the Gutenberg plugin), that would solve the problem. Additionally, it would make sense to conditionally add the rule based on the version of WordPress, so it only applies to versions older than 5.9.0, where it might be of use. Again, removing the rule entirely and replacing it with styles for strip/container/row blocks to display at 100% would be a better solution.

There may be some edge cases I haven’t addressed here, but I believe these are the most common scenarios.

Hi John,

FYI, the above code (Joerg’s + filoveg’s) does get rid of the error, but for me it doesn’t save anything. I’ve looked through the plugin code and stepped through it with a debugger, and eventually I get hit with “invalid redirect” + something or other (“action” I believe; I did this twenty-or-so minutes ago, and it’s Friday). After trying all kinds of things with the data array, I gave up and am just using wpdb to do direct SQL queries for a data migration. It’s sad, but works. Anyway, maybe you can take a look in your spare time. Sure would love some documentation for PHP besides: use REST, two sentences, and exhortations on the forums to study your code. Cheers.