Skip to content

Fix: Bug Inconsistency: Standardize post meta key naming with the wpai_ prefix - #867

Open
hbhalodia wants to merge 7 commits into
WordPress:developfrom
hbhalodia:fix/issue-866
Open

Fix: Bug Inconsistency: Standardize post meta key naming with the wpai_ prefix#867
hbhalodia wants to merge 7 commits into
WordPress:developfrom
hbhalodia:fix/issue-866

Conversation

@hbhalodia

@hbhalodia hbhalodia commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

What?

Closes #866

Why?

  • PR fixes the inconsistency in meta keys for the post metas.
  • PR also adds the migration/upgrade file to convert from old meta key to new meta key

How?

  • PR renames the meta key from old to new meta key.
  • PR updates the references from old to new meta key.
  • PR adds the upgrade file that supports the migration from old meta to new meta key.

Use of AI Tools

  • Yes, Claude Code.
  • Opus 4.8
  • Used for implementation of the issue based on details added by me on the issue. Implementation was then reviewed and tested locally by me.

Testing Instructions

  • Activate AI plugin.
  • Generate the summary of any post/page.
  • Check the DB for the meta key, it would be new meta key.
  • For migration, Activate the plugin with the version mentioned, the old meta key should be now replaced with new meta key.

Screenshots or screencast

  • None

Changelog Entry

Fixed/Breaking - Inconsistent name for the post meta key for the summarization and image generation, while other follow wpai_ prefix.

Open WordPress Playground Preview

@codecov

codecov Bot commented Jul 14, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.43590% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.49%. Comparing base (5599e9d) to head (4f8bd69).

Files with missing lines Patch % Lines
includes/Admin/Upgrades/V1_3_0.php 97.05% 1 Missing ⚠️
Additional details and impacted files
@@              Coverage Diff              @@
##             develop     #867      +/-   ##
=============================================
+ Coverage      80.43%   80.49%   +0.05%     
- Complexity      2565     2568       +3     
=============================================
  Files            110      111       +1     
  Lines          10448    10482      +34     
=============================================
+ Hits            8404     8437      +33     
- Misses          2044     2045       +1     
Flag Coverage Δ
unit 80.49% <97.43%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@hbhalodia
hbhalodia marked this pull request as ready for review July 14, 2026 11:49
@hbhalodia
hbhalodia requested a review from a team July 14, 2026 11:49
@github-actions

github-actions Bot commented Jul 14, 2026

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@dkotter dkotter added this to the 1.3.0 milestone Jul 14, 2026

@dkotter dkotter left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments but overall this looks good. I do see there's still references to the old meta keys in some of our documentation so also need another sweep across the entire plugin to ensure all references are updated

Comment on lines +44 to +46
$this->rename_post_meta_key( 'ai_generated', 'wpai_generated' );
$this->rename_post_meta_key( 'ai_generated_summary', 'wpai_generated_summary' );
$this->rename_comment_meta_key( 'ai_note', 'wpai_note' );

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're using direct DB queries to update meta, may need a cache flush after this runs in order to ensure any cached values are flushed out. Likely not a problem as we're not changing data, just keys but may be better safe than sorry

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, Will flush the cache to ensure everything works expected.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wp_cache_flush works and is likely fine since this is a one-time thing but does clear out the entire cache, whereas we only need to worry about the post and comment cache. We could modify things to track which post IDs and comment IDs were updated and then just clear those caches (potentially using clean_post_cache/clean_comment_cache). Any thoughts on that or is that not needed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think, clean_post_cache/clean_comment_cache is needed, as wp_cache_flush would wipe every cache on the site. So IMO it's not needed as post/comment and every object cache would be flushed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, wp_cache_flush will clear the cache we need here but also deletes all other caches. So on sites heavily reliant on cached data for performance, running wp_cache_flush can have a negative impact on the site. Likely won't be a problem here but we could be more specific with the cache flush functions to only clear what we need

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, also this is a one off thing, so we can go with wp_cache_flush here.

Comment thread includes/Admin/Upgrades/V1_3_0.php
Comment thread includes/Admin/Upgrades/V1_3_0.php Outdated
@hbhalodia
hbhalodia requested a review from jeffpaul as a code owner July 16, 2026 05:53
@hbhalodia

Copy link
Copy Markdown
Contributor Author

Left a few comments but overall this looks good. I do see there's still references to the old meta keys in some of our documentation so also need another sweep across the entire plugin to ensure all references are updated

This is now done in commit - 2d53db7

Thanks,

register_meta(
'comment',
'ai_note',
'wpai_note',

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something I hadn't thought about until now, these meta keys we're renaming are set as show_in_rest => true. This means this data is exposed via REST and there could be others that are consuming/using that data. This rename would break their integrations.

I would guess there's a low (potentially zero) amount of users doing this but any thoughts on what is a breaking change here? At the very least, we'll need to call this out as a breaking change in our changelog but wondering if there's anything else we should consider here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would guess there's a low (potentially zero) amount of users doing this but any thoughts on what is a breaking change here?

Yes, there could be breaking change, for eg; Users using/depend on Rest API for data would break, since ai_generated key would no longer be return in response, it would be wpai_generated. So user who access it as meta.ai_generated would get undefined, so it would silently break that part.

Another example could be user external writes request with body params as {"meta": {"ai_generated": ""}} would break, because rest does not knows about this key, so it would silently drops this key. So until noticed it won't be visible.

May be we have 2 pathways here,

  1. Document it as a breaking change in newer version. Simplest but may have backward compatibility issue. But since amount of users would potentially be zero doing this would work.
  2. Keep the meta key and register newer one side by side, drop the other one after few releases and add the deprecation notice or similar using the older keys could be an option.

IMO, we should go with the 1st, just document it as a breaking change in the release doc.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think I'm fine with option 1 here. But probably worth us discussing @jeffpaul prior to merging this in

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @dkotter @jeffpaul, Any updates on this? Let's get this updated before more users uses the AI plugin, so better to update these inconsistencies.

Thanks,

@dkotter dkotter Aug 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not had a chance to discuss with Jeff but I'm still fine with option 1 here so let's move forward with that

Edit: just saw Jeff left a comment on the Issue. I'm fine with the renaming

@hbhalodia hbhalodia Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @dkotter I think this would be added at the time of release right? So no any changes in PR.

Let me know if there is any other feedback on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug Inconsistency: Standardize post meta key naming with the wpai_ prefix

2 participants