[Escalated to 2nd Tier] WPML is saving wpml_notices on every request (MySQL binlog getting too big)

My colleague's first suggestion is to delete the following rows from the wp_options table:

wpml_notices
_wpml_dismissed_notices
_wpml_user_dismissed_notices
icl_admin_messages

To the extent that they are needed, they will be regenerated.

Could you please try that and see if it helps?

@Maarten no updates so far.

Could you please open a new thread and link it to this one so that we can interact with you directly. I think we are going to need a copy of a site that has this issue to be able to identify the cause, so if you are in a position to provide that, it will help greatly.

Please provide a copy, as described here: https://wpml.org/faq/provide-supporters-copy-site/

It will help keep the file size down if you exclude the uploads folder, we shouldn't need the site media to test this.

You can paste a link to dropbox or similar and it will automatically be hidden.

Thanks.

Thanks for that.

I managed to get a copy of your site up and running (I don't use Docker) and run some tests on it.

I could see the calls to update the options table for the wpml_notices option, even just when loading the home page on the front end.

I located where in our code this happens (its in a callback to the shutdown action) and used Xdebug to step through the code execution to identify why the option gets updated.

The option itself looked malformed, and I deleted the wpml_notices option directly from the database.

That prompts the option to get recreated, but then on subsequent page loads the problem no longer occurs.

Could you please try again on your server deleting the wpml_notices option from the options table, load the page, and then load it again to see whether the option keeps getting resaved.

For reference, let me share where in the code this is triggered, so that you can check the same yourself if you wish.

In the file sitepress-multilingual-cms/classes/notices/class-wpml-notices.php, line 177, there is this method:

	public function save_to_option() {
		if ( $this->original_notices_md5 !== md5( maybe_serialize( $this->notices ) ) ) {
			update_option( self::NOTICES_OPTION_KEY, $this->notices, false );
		}
	}

The left and right of that condition do not match, and hence the option gets updated. (Except, it doesn't after deleting the existing option entry and letting WPML re-build it.)

It only happens on the production server?

Is there a staging server where the issue also occurs that we could work on?

Working on the production server would be a last resort.

Let me set a private reply to get credentials for a staging site, if you have one available.

Thanks for that @Maarten

My colleague looked into this further and proposes a workaround for the problem, and has escalated the issue to the developers.

(If you make the below changes, keep an eye on the release notes for the next release of WPML to check if a fix is included; if it doesn't make it into the next release, you will need to re-apply these changes.)

You need to edit the file sitepress-multilingual-cms/classes/notices/class-wpml-notices.php and update the function get_all_notices (from line 55) like so:

	public function get_all_notices() {
		$all_notices = get_option( self::NOTICES_OPTION_KEY . get_current_user_id() );
		if ( ! is_array( $all_notices ) ) {
			$all_notices = array();
		}
		return $all_notices;
	}

Also, update the function save_to_option (from line 177) like so:

	public function save_to_option() {
		if ( $this->original_notices_md5 !== md5( maybe_serialize( $this->notices ) ) ) {
			update_option( self::NOTICES_OPTION_KEY . get_current_user_id(), $this->notices, false );
		}
	}

If you run into problems using that let me know, otherwise I think we should be able to close here @hugoC-18

Thanks for your patience.