app1e5auce

Hey all,

I just wanted to add to this thread in case it helps someone in the future.

I had this plugin working properly on my local machine, but when moving it onto a live server it was not working. The buttons just would not show up on checkout.

After lots of debugging I found out that the plugin was not registering the paypal payment option as “enabled” in woocommerce, even though the little toggle switch was showing “enabled” in my woocommerce payment admin.

I just toggled the paypal payments off and on, and now the buttons are showing for me.

Aha!

Thank you for your response. I’m glad the issue is tracked somewhere. I will try that shortcode trick.

Thanks again!

I disabled the theme and plugin editor in my wp-config.php.
define(‘DISALLOW_FILE_EDIT’, true);

Yup you got it. I just found it myself. In the iThemes Security plugin, there is a setting to disable the Plugin and Theme file editor for security reasons, which I always enable. This setting sets DISALLOW_FILE_EDIT to true, and therefore any checks for the ‘edit_files’ capability will fail, so WP DB Manager gets removed from your menu.

To the developers: I think its a bad decision abandoning the ‘manage_database’ cap used in the past. Database backups should not be tied to the Plugin and Theme editor. It doesn’t make a lot of sense. I think its perfectly reasonable making your own cap for your own plugin.

The same here. I’m back to version 2.80.5 again.
I don’t have iTheme.

Do you have any security plugin? Right now I’m guessing this has something to do with WP DB Manager switching its required capability to ‘edit_files’. I’m wondering if iThemes and others might lock down that cap for some reason. Not sure, still looking into it.

Just wanted to jump in and say I had this same problem with a client today.

I have dozens on clients all running up-to-date versions of iThemes Security. One client, seemingly randomly, had 404s on every page except the home page. I looked in the .htaccess file, and the WordPress code had been replaced by some standard iThemes code adding an IP to the blocked list.

Obviously, iThemes code usually safely inserts above the default WordPress code which is needed for links to resolve. Not sure why this one time resulted in file being broken.

As an update to any person in the future that find their way here,

This is a known issue that you can read more about here:

https://github.com/Yoast/wordpress-seo/issues/17006

Apparently it is intentional that the final breadcrumb in schema has nothing other than @id, which references another point in the schema that does have all the correct information.

Some tools (like SEMRush) do not properly detect this. Yoast is working with them to correct those scan errors.

Hello,

Yep I went through that article before making my post. All my pages definitely have titles. And as I explained above, entering the advanced breadcrumb title did nothing.

I don’t think its a coincidence that dozens of clients had no schema issues for months, and now have hundreds of BreadcrumbList schema issues right after Yoast made changes to the breadcrumb schema functions. Especially since I can simply change a single function back to its 16.1 version and all the errors are fixed.

I also see in your 16.3 release notes:

Fixes a rare bug where the name property could be missing in the breadcrumb Schema due to plugin conflicts.

So at least you are aware of the problem. However I’ve disabled all my plugins except Yoast, and the problem persists.

Would you like me to try anything else on my end?

• This reply was modified 3 years, 6 months ago by app1e5auce.

Hey Luke,

I went down the rabbit hole today and figured out what is causing this issue: a non-typical WordPress folder structure.

I use Bedrock. Bedrock rearranges the WordPress file system. The WP_CONTENT_DIR is the /app folder, and WordPress core files go in a /wp folder.

I went into the core wp_enqueue_style function and printed out the WP_Styles Object. An example:

[genesis-custom-blocks-editor-css] => _WP_Dependency Object
(
    [handle] => genesis-custom-blocks-editor-css
    [src] => https://genesis.local/app/plugins/genesis-custom-blocks-pro/vendor/studiopress/genesis-custom-blocks/css/blocks.editor.css
    [deps] => Array
        (
        )

    [ver] => 78af8c18648205f9991d20eb79a727f9
    [args] => all
    [extra] => Array
        (
        )

    [textdomain] => 
    [translations_path] => 
)

[genesis-custom-blocks__block-fancy-text] => _WP_Dependency Object
(
    [handle] => genesis-custom-blocks__block-fancy-text
    [src] => /app/themes/twentytwentyone/blocks/fancy-text/preview.css
    [deps] => Array
        (
        )

    [ver] => 1.2
    [args] => all
    [extra] => Array
        (
        )

    [textdomain] => 
    [translations_path] => 
)

The [src] of the genesis-custom-blocks-editor-css is a full URL. That works. The [src] to my custom block preview.css is not a full URL. Now, the URL isn’t incorrect per se, but WordPress in Bedrock is looking for it in the wrong place. wp_enqueue_styles is looking for /app in the same place that /wp-admin, /wp-content, and /wp-includes live. But that is the /wp folder in Bedrock. That is not where the /app folder is.

When I manually go into the core enqueue function and add https://genesis.local to the beginning of the [src] for that one block preview.css file, it loads perfectly.

I’m not sure if there is a way for you to get get_template_directory_uri() somehow built into how these editor style paths are created, but I think that may be a solution for everyone. Right now I’m going to try to just build my own editor styles enqueue function that will add the styles with my paths.

Hopefully this helps you, or someone else in the future!

• This reply was modified 3 years, 8 months ago by app1e5auce.
• This reply was modified 3 years, 8 months ago by app1e5auce.
• This reply was modified 3 years, 8 months ago by app1e5auce.

Hey Luke,

Thanks for the reply. What CSS file would I be looking for in my inspector? Would my file be loaded all by itself, or is it packaged somehow with other block css files?

If it is meant to load all by itself, it is not showing in any of my above tries. I also tried all my files with something crazy like * { color:red !important; } so I could easily tell if they loaded. No luck.

I don’t think any CSS overrides are happening. I use very few plugins. I don’t know what could cause that.

Hey all,

I was still getting this error today, even after updating to all the most updated versions. Turns out, if you have an old Block Lab block that you migrated into Genesis, and that block had a textarea field, it will still be trying to send ‘textarea’ as the schema type. It will then still throw this error.

I went into the block, deleted all my textareas, and the recreated them all. I was careful to recreate them with the same names and ids. In doing this, I lost no data in my blocks and the errors are now gone.

Hopefully this helps someone!

Edit: I’m now seeing that you instructed people to update the block. That probably would have fixed my issue ??

• This reply was modified 4 years ago by app1e5auce.

Hey @optimizingmatters , thanks for checking in.

I have no idea what caused it. I updated WordPress and Autoptimize on other GoDaddy clients, and none had the same issue. I’m unsure what about this one specific GoDaddy setup caused a problem with my other client, but at this point, like most things, I’m sure it’s GoDaddy’s fault.

I have Autoptimize currently disabled on that GoDaddy client that had issues. I need to revisit it in the future.

Thanks.