contextual-related-posts icon indicating copy to clipboard operation
contextual-related-posts copied to clipboard

I can infinitely "Save" posts & pages while the plugin is active

Open jeflopodev opened this issue 1 year ago • 4 comments

Describe the bug Without the plugin being active when I publish & save a post or page, the "Save" button becomes disabled and you can't save it again till there are any new changes (that's correct).

But when I activate the plugin I can keep pressing the "Save" button infinitely, even when there are no content changes.

To Reproduce Steps to reproduce the behavior:

  1. With the plugin disabled, create a new post and/or page, add any content, publish and save it.
  2. Check if the "Save" button is disabled when there are no new changes.
  3. Now Activate the plugin, go to the post / page you've just create, make changes, save it.
  4. Check if the "Save" button, now that the plugin is enabled, let you infinitely press the save button in the gutenberg editor.

Expected behavior Having the plugin active should not affect the behavior of the save button. The plugin should not prevent the "Save" button becoming disabled when there are no changes to the content.

Screenshots In the video I first show how the plugin is inactive. Then I go & refresh the post, make a modification and save it. The button becomes disabled, each time. Also with the Page, I basically do the same. Then, I go to the plugins and activate it. And repeat the same procedure, but this time I can infinitely save the page, without needing to make changes to the content. The save button doesn't become disabled.

https://youtu.be/l2J2lvO2ojk

Desktop (please complete the following information):

  • OS: Windows 11 23H2 build 22631.3880
  • Chrome 126.0.6478.183
  • Contextual Related Posts Version: 3.5.2
  • WordPress 6.6

jeflopodev avatar Jul 21 '24 10:07 jeflopodev

I can confirm this issue exists and it's because of the metabox. However, I'm not yet sure as to what the solution can be as I just use the inbuilt WordPress add_meta_box() function.

Please see this issue as it's related to WordPress core directly: https://core.trac.wordpress.org/ticket/59395

ajaydsouza avatar Jul 22 '24 20:07 ajaydsouza

I asked for you :) As you can see above. The guys from WordPress seems to recommend to use the Unified Extensibility API instead of metaboxes As "The best path forward". https://make.wordpress.org/core/2024/06/18/editor-unified-extensibility-apis-in-6-6/

Hope it helps, in any way.

jeflopodev avatar Jul 24 '24 12:07 jeflopodev

Thanks. It does. However, I personally think this is not an ideal way forward as the meta box works well for now rather than me rewriting components in react, which is honestly time-consuming and painful!

I am also not a fan of putting all this into the sidebar as a UI choice.

I will eventually, but not immediately as the editor is still evolving and as you'll see in the link above that it's for WP6.6 and above.

Another issue is, the panel will not work outside of Gutenberg and while I'll love to have the stats, I wouldn't be surprised a lot of people use the plugin in the Classic Editor which again means duplicating work.

I know not the helpful answer but as the solo dev on this plugin with very few outside contributions, I need to prioritise various issues.

I'm going to keep this open as I still think it's something to be resolved at the right time.

ajaydsouza avatar Jul 24 '24 12:07 ajaydsouza

I completely agree. Your reasoning is logical. At least I'm glad that this is a known issue. I guess that If they eventually remove classical themes... metaboxes could also be deprecated. But as you said... that's the future.

jeflopodev avatar Jul 24 '24 14:07 jeflopodev

I'm marking this as closed as I don't think I'll implement something that goes against the current meta structure. It does need a change in the way WP do the block editor.

ajaydsouza avatar Dec 16 '24 18:12 ajaydsouza