tbob21

It may only be an issue for product variations. We are also using PVT Product Variation Table for WooCommerce to display the data. Nothing else has changed recently this combination has been running for several years without issue – simply reverting the plugin version solved the issue.

• This reply was modified 3 months, 1 week ago by tbob21.
• This reply was modified 3 months, 1 week ago by tbob21.

Seems to work fine on 6.5.4.

Yes, it auto updated and broke several sites. They were running the latest 6.4 patch as they have to manually be updated to 6.5.

The issue in my case is only with Woocommerce pages. After commenting that line out the issue is gone.

It’s using Gutenberg and CPT for content.

There are several other plugins but nothing that should affect taxonomy

2.2.2 broke it. Commenting out the line fixed it again.

I see 5.14 is released. It still does not work with PHP 8.1. Only 8.0 and below.

Version 5.13.8 of SLP. Why are you testing with PHP 8.0.1? That is about 8 months old at this point and has several vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/year-2022/PHP-PHP.html). The current PHP 8.0 version is 8.0.22.

I had this issue as well. I just changed the permalink to another option then back to the option I had before, now all seems to be working as expected.

It seems like it’s not really compatible with the latest Gutenberg, for me it was missing the Categories on the side. I’ve just disabled Gutenberg for the Portfolio plugin only by adding the following to the photography-portfolio.php file:

/**
 * This file should work without errors on PHP 5.2.17
 * Use this instead of __DIR__
 */
 
add_filter( 'use_block_editor_for_post', '__return_false' );
 
$__DIR = dirname( __FILE__ );

If a custom HTML anchor is set then it will override your plugin and the plugin will not function properly, it should really use the HTML Anchor if set in the post/page.

Changing Insert Method to from Legacy to Normal seems to fix the issue in the latest version.

I didn’t realize there were now plugin options.

Unfortunately it doesn’t, these are public pages.

Yes, I believe it was enabled on my sites. Just looking at my backups before the 8.0 update the permissions were still 0400.

I believe there should have been a warning after update to warn that files may have been reset to “hazardous” permissions, if it wasn’t for the sites going down I may have not noticed.

Just to be clear, I realize that this isn’t as much of an issue on dedicated hosting, but on shared hosting it is more likely to be an issue.

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

I did see that, as mentioned in that very post setting to more restricted permissions is more secure.

Required? Maybe not, but the WP documentation does say it’s a “hazard” to leave it at 644.

I was more concerned with the plugin overriding the permissions I had set previously which should not be happening, sounds like the plugin needed more testing before this major release.

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

I disagree on the wp-config.php permissions.

See the following documentation:

Changing File Permissions

NOTE: If you installed WordPress yourself, you likely DO need to modify file permissions. Some files and directories should be “hardened” with stricter permissions, specifically, the wp-config.php file. This file is initially created with 644 permissions, and it’s a hazard to leave it like that. See Security and Hardening.