David Tolnem

@ronalfy Thank you for reacting quickly. ??

For anyone else who comes across this thread, here is the search and replace I ended up going with. It doesn’t work for links that have other options set, like specific colors or opening in a new tab, but that’s rare enough for us that we could handle those few cases manually.

wp search-replace '<!-- wp:tiptip/hyperlink-group-block -->\s*?<a class="wp-block-hyperlink-group" href="([^"]*)"' '<!-- wp:tiptip/hyperlink-group-block {"url":"\1"} -->
<a class="wp-block-hyperlink-group" href="\1"' --regex --regex-flags=m --dry-run

While the block recovery removes the error message, it unfortunately makes the block not have a link anymore.

I’ll attempt writing a regular expression to handle the migration via wp search-replace.

Thank you, I’m glad to hear that. ??

I notice this ticket is marked as resolved, but this is also an issue for us in the latest release.

As far as I can tell, it’s caused by SEOpress using the same CSS classes as the block editor snackbar, but adding its own CSS to animate it.

Removing all of the CSS from SEOpress related to .components-snackbar-list and .components-snackbar, the block editor snackbar function starts working again.

We’re seeing the same issue on a site that uses WooCommerce and WooCommerce QuickPay. Users with the role editor do not have the ‘manage_woocommerce’ capability, and are therefore redirected back to the referer whenever they go to edit.php for any post type.

I’m guessing that the idea behind the redirect is to send the user back after a bulk update if the action is ‘quickpay_capture_recurring’, but currently it happens every time for users without the ‘manage_woocommerce’ capability on the ‘load-edit.php’ action.

So the following might be more appropriate?

        public function handle_bulk_actions() {
	        $wp_list_table = _get_list_table( 'WP_Posts_List_Table' );

	        $action = $wp_list_table->current_action();

	        // Check for posts
	        if ( ! empty( $_GET['post'] ) ) {
		        $order_ids = $_GET['post'];

		        // Make sure the $posts variable is an array
		        if ( ! is_array( $order_ids ) ) {
			        $order_ids = array( $order_ids );
		        }
	        }

	        if ( current_user_can( 'manage_woocommerce' ) ) {
		        switch ( $action ) {
			        // 3. Perform the action
			        case 'quickpay_capture_recurring':
				        // Security check
				        $this->bulk_action_quickpay_capture_recurring( $order_ids );

				        // 4. Redirect client
				        wp_redirect( $_SERVER['HTTP_REFERER'] );
				        exit;
			        default:
				        return;
		        }
	        }

        }

Our workaround for now has been to make all the users on that site administrator, but that requires a certain level of trust.

We’ve been having the same issue, and I discovered that the issue seems to stem from WordPress 4.3 having added the text domain ‘password strength’ to the translation of the words “Strong”, “Medium”, etc.

https://github.com/WordPress/WordPress/commit/153511f78fb7bee90b511689af0091526879745a#diff-39977d20425ebfb23f09eb9d22eb7f0c

Force Strong Passwords hasn’t yet updated from the old version where those phrases didn’t have a text domain.

We also have our hosting on WP Engine, so I’ve written to them to see if they can add a patch to their mu-plugins before the official plugin gets fixed.

This is not a conflict as such, the issue is that Gravity Forms Auto Placeholders assumes that all input fields in gravity forms have an id, which now causes an issue in WordPress 4.0 (presumably because of an updated version of jQuery).

It can be solved by updating line 88 in the plugin from
$.each($('.<?php echo $gfap_class; ?> input, .<?php echo $gfap_class; ?> textarea'), function () {
to
$.each($('.<?php echo $gfap_class; ?> input[id], .<?php echo $gfap_class; ?> textarea[id]'), function () {