Dek/Subtext field ("subtitle") no longer responding to edits

[jangelico]

Expected Behavior

the Dek/subtext field, which is contained in the "subtitle" class on rendered page and shows between the headline and featured image, no longer responds to edits made in the editing UI.
No new content can be added, and existing content cannot be changed

Actual Behavior

ADD NEW:
edit post > add copy to "Dek/Subtext" field > view live page > user will NOT see changes ... > return to editing UI and any copy that was added to that field is now gone. the field is blank.

EDIT EXISTING:
edit post that already has content in Dek/subtext field > change/edit copy visible "Dek/Subtext" field > Hit "Update" > view live page > user will NOT see changes ... > return to editing UI > Changes that were made are gone. Field has reverted to previous version.

We believe this started happening in early/mid December 2022.

Steps to Reproduce the Problem

ADD NEW:

1. edit post
2. add copy (including any valid HTML if desired) to "Dek/Subtext" field
3. hit "Publish"
4. view live page
5. confirm that area between headline and byline or featured image does not show your added content
6. return to editing UI: any copy that was added to "Dek/Subtext" field is now gone; the field is blank.

EDIT EXISTING

1. edit post that already has content in the "Dek/Subtext" field
2. edit that copy/content
3. hit "Updatge"
4. view live page
5. confirm that area between headline and byline or featured image does show your edited content
6. . return to editing UI to view "Dek/Subtext" field: and changes you made to copy in "Dek/Subtext" field are now gone; the field is blank.

Specifications

• Version: WP 6.1.1, Largo theme launched July 2020

Dek/subtext Editing UI example:

Dek/subtext becomes subtitle in this area:

[benlk]

I'm not working with WPBuddy or INN; I'm just being nosy with these questions:

• Have you had anyone work on you site since INN last worked on SFPP in September 2020?
• In https://www.sfpublicpress.org/wp-admin/site-health.php?tab-debug, can you go to these accordion sections and give us this information:
  • WordPress: Version
  • Server: Php version
• Is the Gutenberg plugin installed and active? You would be able to see this in Dashboard > Plugins; knowing whether it's installed or not would help narrow the scope of the debugging.
• If you have access to your host's server error log, does anything get added the error log when you save a post in this fashion?
• Have you reached out to INN's tech support about this issue?

[jangelico]

I'm not working with WPBuddy or INN; I'm just being nosy with these questions:

Have you had anyone work on you site since INN last worked on SFPP in September 2020? Yes.
In https://www.sfpublicpress.org/wp-admin/site-health.php?tab-debug, can you go to these accordion sections and give us this information:
WordPress: Version 6.1.1
Server: Php version 7.4.33.1
Is the Gutenberg plugin installed and active? You would be able to see this in Dashboard > Plugins; knowing whether it's installed or not would help narrow the scope of the debugging. Yes, we have "ultimate Blocks" by Gutenberg installed
If you have access to your host's server error log, does anything get added the error log when you save a post in this fashion?

yes, we checked that:

But does look like some block validation errors are occuring in the console when I check, and probably that theme you suspect

Not seeing any server level errors being thrown. And you mentioned you deactivated all the plugins to test?

Have you reached out to INN's tech support about this issue? tried contacting WPBuddy. no luck yet.

[joshdarby]

This happens because of the _largo_meta_box_save function in /inc/metabox-api.php

Saves on custom metaboxes are always prevented because of

largo/inc/metabox-api.php

Lines 150 to 153 in 04e55ed

	// if our current user can't edit this post, bail
	if ( ! current_user_can( 'edit_post' ) ) {
	return;
	}

current_user_can( 'edit_post' ) requires a post ID as a second argument. If no post ID is added, it should be edit_posts instead of edit_post. Since we're not passing the required 2nd arg, the function always returns false, resulting in the _largo_meta_box_save function returning/ending before the actual save since it thinks the user does not have the correct permissions to save the metabox.

Looks like this changed in WP 5.8 and we never got around to updating it.

https://developer.wordpress.org/reference/functions/current_user_can/

Working solution is to update the block to this

if ( ! current_user_can( 'edit_post', $post->ID ) ) {
	return;
}