Possible performance issue highlighted by unexpected calls to gzuncompress()

Overview of the issue

Improvements to reduce the size of WPML translation database tables introduced in WPML 4.8 make use of data compression. This is a little more resource intensive but used in limited circumstances, never on the front end, and only during specific workflows in the back end.

But its use in some unexpected scenarios has revealed a performance issue which we are working to fix.

Workaround

In the meantime if you are affected you can comment out some specific code in the WPML plugin.

In particular, edit the file plugins/sitepress-multilingual-cms/classes/ATE/Review/ReviewTranslation.php and comment out or delete the lines 50 to 72, e.g.

		// Hooks::onFilter( 'user_has_cap', 10, 3 )
		//      ->then( spreadArgs( function ( $userCaps, $requiredCaps, $args ) {
		// 		 /** @var array $userCaps */
		// 		 /** @var array $requiredCaps */
		// 		 /** @var array $args */

		// 	     if ( Relation::propEq( 0, 'edit_post', $args ) ) {
		// 		     $translator = Translators::getCurrent();

		// 		     if ( $translator->ID ) {
		// 			     $postId = $args[2];
		// 			     $job    = Jobs::getPostJob( $postId, Post::getType( $postId ), WPMLPost::getLang( $postId ) );

		// 			     if ( ReviewStatus::doesJobNeedReview( $job ) && self::canEditLanguage( $translator, $job ) ) {
		// 				     return Lst::concat( $userCaps, Lst::zipObj( $requiredCaps, Lst::repeat( true, count( $requiredCaps ) ) ) );
		// 			     }
		// 		     }

		// 		     return $userCaps;
		// 	     }

		// 	     return $userCaps;
		//      } ) );