Bence Szalai

It is clearly one of those decisions that ignores what the users want.

Which is okay, you can do that, it is free software, we have no rights to complain.

But be bold enough to admit that your product has pivoted and existing users concerns are ignored as a deliberate decision. There is no need to be wishy-washy with “At the moment, there isn’t an option or hook available to fully disable the builder.”. Whoever made this decision to turn a plugin that had purpose A to a completely different plugin serving purpose B must have made this decision knowing that it’ll put existing users into a situation they did not choose to end up in.

Again, it is fine, you can do that. But don’t pretend it is a fair thing to do.

I can tell you what it looks like: You had this plugin, installed on large number of sites, because it was a go to Customizer extension for developers for many years. It was obvioulsy not installed by end-users, it was used by devs. So looking at the large install base you just decided to effectively hijack all those sites and try to push you new and completely unrelated product onto those websites, hoping the end users would pick it up.

Again, you can do that, but don’t create this deeply unjust discussion suggesting the builder cannot be disabled “At the moment”. We all know what is going on.

You may be polite with your words, but is it really polite to think we are all blind / dumb to not see what you did? I don’t think so…

You can do whatever you want with your software, but you cannot at the same time expect us to pretend we don’t see what you did and to not speak up when you make a fool out of us all…

• This reply was modified 1 month, 1 week ago by Bence Szalai.
• This reply was modified 1 month, 1 week ago by Bence Szalai.

I’m glad to find this information!

May I suggest you add few words about it here: https://woo-docs.payaddons.com/ ?

Also the placeholder text on the configuration UI for the secret key suggests sk_live_xxxxx. Probably it’d be better to suggest rk_live_xxxxx and link the list of required permissions there.

Yes, that is the one.

To be honest it is quite strange that you cannot reproduce the warning, it is a core warning emitted here: https://github.com/WordPress/WordPress/blob/master/wp-includes/l10n.php#L1369

The warning itself is a bit strange too because the warning is only emitted if the call happens before after_setup_theme but the message says there should be no such calls before init. (after_setup_theme happens before init). Maybe they will later tighten the criteria to init but they already put the message so if someone makes adjustments they will not have to do that again. Only speculation.

To be honest I don’t know if my workaround is really working well, I’m only using the plugin to collect and report stats but not the frontend UI parts, so it may break some things. I just wanted a quick dirty fix.

I think a proper fix would be instead of moving the whole plugin initialization as that really risks breaking other things just simply move the Widget initialization to the init hook. It still requires some refactorings as your Container class does a fairly linear initialization, but afaics the only reason Widget is initialized early because it is passed to WordPressPopularPosts, and the only reason it is passed is to be able to handle the loading of all services with a single $WordPressPopularPosts->init() call in Bootstrap.php.

If you remove [this](https://plugins.trac.ww.wp.xz.cn/browser/wordpress-popular-posts/tags/7.1.0/src/Container/WordPressPopularPostsConfiguration.php#L56-L65) whole call from WordPressPopularPostsConfiguration.php and as a dependency of WordPressPopularPosts and instead you can add this to Bootstrap.php i think that would work and leave everything else the same as now except for the Widget:

add_action('init', function() use ($container) {
    $container['widget'] = $container->service(function(Container $container) {
        return new Widget(
            $container['widget_options'],
            $container['admin_options'],
            $container['output'],
            $container['image'],
            $container['translate'],
            $container['themer']
        );
    });
    $container['widget']->hooks();
});

(I only used the closure for simplicity, if you want to support older PHP version probably you want to use a proper named callback.)

Sidenote: since $container['widget'] is not used anywhere else it is not necessary to add it to the container at all.

I am having a very similar issue, except for me the Content Display block was missing, others were fine.
Turns out that the var advgb_blocks_vars = { line that should contain a JSON under the original_settings.styles array had an object, who’s css property was not a css, but an HTML. Being so escaping somehow failed, so eventually this variable as well as subsequent variables, including advgbBlocks were never set on the editor screens.

Indeed the CSS ended up being an HTML because a CSS file was not where it was supposed to be, which ended up resulting in the WordPress 404 HTML. I’ve added < !-- < ?= $ _SERVER['REQUEST_URI'] ?> --> to the top of the head of my theme to find out the missing CSS file.

Eliminating the wrong CSS enqueuing fixed the issue.

On one hand I’ve written it in hope that it may help others facing similar issues.

But on the other hand I’m wondering how it is possible? AdvancedGutenbergMain::$original_block_editor_setting is added to the page using the standard wp_localize_script. How come escaping breaks when one of the array members end up being an HTML instead of CSS? It is supposed to go through json_encode so it shouldn’t matter. Still, the JSON is broken…

So looking into it more, turns out WordPress is quite naive when encoding json in the localize script call calling wp_json_encode without any options, which in turn calls PHP json_encode without options. Adding JSON_HEX_TAG to the call fixes the broken JSON and thus the missing PublishPress blocks issue as well.

UPDATE: So it turns out the issue is caused by another plugin which injects CSS files using non standard method, that is it buffers all HTML output, then searches for </head> and adds it’s style links before that tag. Since the inline JS object created by wp_localize_script contains the token </head> due to a whole 404 HTML is included instead of a CSS, now this script finds that tag, and injects it’s <style... tag before. However indeed this tag contains a " which closes the JSON string and breaks the object structure. The only reason adding JSON_HEX_TAG “fixed” the issue, is that </head> became \u003C/head\u003E which was now immune to that non standard behaviour.

This being said, my issue might have been a different one than OPs, but in may be related. My takeaway: If PublishPress blocks are missing, check the console for Uncaught SyntaxError: missing } and Uncaught ReferenceError: advgbBlocks is not defined errors, as it may point into the direction of solution.

• This reply was modified 2 years, 2 months ago by Bence Szalai.