search

WPBuddy / largo

A WordPress framework for news websites. Finely-crafted by INN and expertly-honed and maintained by the technology team at WP Buddy.
http://largo.wpbuddy.co
GNU General Public License v2.0
170 stars 83 forks source link

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

Open jangelico opened 1 year ago

jangelico commented 1 year ago

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

Dek/subtext Editing UI example: dek_subtext_field_UI

Dek/subtext becomes subtitle in this area: dek_subtext_field_live

benlk commented 1 year ago

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

jangelico commented 1 year ago

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 commented 1 year ago

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

Saves on custom metaboxes are always prevented because of https://github.com/WPBuddy/largo/blob/04e55edb4d85dbae4fcdacafb7363efcc67677fe/inc/metabox-api.php#L150-L153

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;
}