bcworkz

Downgrading could expose you to security vulnerabilities. Don’t do it. If you’re not happy with the block editor, you’re not alone. Most users seem to like it, but some prefer the old editor. For those, the Classic Editor plugin is the solution. You can continue to use the old style editor while keeping your WP installation safe and up to date.

FYI, members helping out in these forums are all volunteers and are not in any way involved with WP development. Ranting at forum members about the direction of WP development isn’t reaching who you think it is. I do understand your frustration though.

You have 150px images saved but they are not being used by your theme because the thumbnails (featured images) your theme generates are larger than 150px. If you desire smaller thumbs to be displayed, you’ll need to customize your theme or find an alternative that has smaller thumbs. There is however a small chance your theme has a setting where you could specify smaller thumbs.

The 150px media setting only defines one of the sub-sized images that WP generates during upload. Whether they are used or not depends upon your theme. IMO 150px is too small to be used for much beyond an avatar-like icon. I think the larger sizes currently in use look better.

“Cannot reach WordPress” errors are usually temporary in nature. If the issue persists, some sort of security measures on your hosting end may be interfering. If you have any security plugins, try deactivating it to see if it resolves the issue. If so, contact the plugin developer for a more permanent fix. It could also be some kind of security measure implemented by your host, such as firewall or modSecurty. Contact your host for assistance in resolving such problems.

Updraft AFAIK doesn’t contact ww.wp.xz.cn in order to do a backup. Backup issues also indicate security measures are interfering, assuming the connection to the backup resource was working previously.

How often are these posts created? The interval might be useful information. It’s likely due to a recurring wp-cron event. Try using one of Cron management plugins to examine what has been scheduled. The recurring event that creates posts will likely reference back to the responsible plugin or your theme by how the event’s callback function is named. You may be able to stop the behavior by just removing the responsible wp-cron event via the manager plugin.

If removing the recurring event doesn’t help, confirm you’ve identified the correct theme or plugin that’s responsible by deactivating that plugin or switching the theme, then remove again any recurring event that was created. The automatic post creation should stop. Consult with the responsible theme or plugin’s dedicated support channel for how to prevent automatic post creation.

I’ve not successfully implemented general application of nonce based CSP because it’s impractical to do so and remain 100% compatible with what ever plugins someone might want to use. While it’s technically feasible to add nonces to script and style elements that match a nonce in a CSP header, we could be conveying trust where it’s not warranted. IMO it’s better to call unknown code what it is: (possibly) unsafe.

What is feasible to do is implement good CSP policy for a specific website that uses only specific, known plugins. The onus then falls upon the site owner to evaluate plugin security, then indicate exactly what is trusted via CSP directives. Ideally, every site owner should be doing this, but doing so requires much expertise that most site owner’s lack. Of course they could hire an expert to do this for them, but many are unable or unwilling to spend more money on their site.

The problem is compounded with 3rd party code that we have no control over. What might be safe when we first evaluate the code, could later become unsafe when the 3rd party code is updated. Sadly, plugins are and will remain the largest security risk in a WP environment. Throwing a nonce into an element with a 3rd party reference might get rid of a security warning, but it doesn’t really make the code any safer.

It’s possible to implement a hash based CSP policy so only the code that was specifically evaluated can be used. But then the hashes need to be updated every time there’s a code update. I doubt most site owners are willing or able to do this.

Where are you seeing these links that will not go away? If they are in post or page content, they need to be removed manually via the post/page editor. Or you can do a global search and replace operation with the Better Search and Replace plugin.

The links shouldn’t resolve to any data. If you’re still seeing deleted content after following the links, the data is stuck in a cache somewhere. If you’ve no WP caching plugins, ask your host if they’re caching content and how to flush the cache.

When we encode video we should adhere to specific standard heights (lines per frame, such as 480, 720, 1080, etc.). This is somewhat irrelevant to the height of the video viewer element a user sees in their browser. The element height is managed by element attributes and CSS and is unaffected by the video encoding height.

The answer to your question is do both. The encoding height relates to the overall video quality but does not directly impact the viewer element height. You must make a choice when encoding a video. You should also specify the desired viewer height. This could vary depending on the browser’s viewport size, so you would likely want to follow responsive design principles.

Note that embed codes obtained from video streaming services often include arbitrary viewer sizing. Our ability to alter this varies by the nature of embed codes.

When you use the customizer, the adjacent page preview shows the correct header menu? But on the actual front end the wrong menu appears in the header? You’re likely seeing cached content. Try clearing any caches involved, both server and client (browser) side.

How did a footer menu end up in the header? There’s a fallback mechanism that could use another known menu when the specified menu cannot be found. When you deleted the original header menu, the fallback mechanism came into play, then that scheme got cached, making it unusually “sticky”.