Reduce time-to-first-use for Blaze

[EkaterinaStancheva]

Problem

Currently, Blaze Ads onboarding requires Jetpack Sync to complete before the plugin is usable, as all post queries are forwarded to the WPCOM API which doesn't have access to posts until sync completes:

Solution

1. Refactor get_blaze_posts to check sync status and route to local database queries when sync is not ready, or WPCOM API when sync is complete.
2. Refactor get_dsp_blaze_posts to bypass DSP proxy and reuse get_blaze_posts for consistent routing logic.

Proposed changes:

• get_blaze_posts now checks are_posts_ready() and routes to local DB or WPCOM accordingly
• Local queries return posts with stats as -1 (not available locally)
• get_dsp_blaze_posts maps DSP parameters and reuses get_blaze_posts for consistent routing
• Both endpoints now benefit from local database fallback, reducing time-to-first-use

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

• Create an ephemeral site, installing the Jetpack Beta plugin
• Enable this feature branch on the ephemeral site
• Create a couple of new posts
• Now, connect your user in Jetpack and quickly go to the Tools->Advertising dashboard
• Ensure that you're seeing all of your posts (even if the site is still syncing)
• Experiment by searching and sorting and ensure everything works as expected
• Click the promote button in the header to test get_dsp_blaze_posts
• Ensure the posts load correctly
• Play with the filters and ensure everything works as expected
• Wait a bit until the sync is ready. This can take some time. You can check if the sync is ready by checking the sync_ready response parameter. When ready, go through the steps above again and verify that everything works as expected.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the update/reduce-time-to-first-use-for-blaze branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/reduce-time-to-first-use-for-blaze

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/reduce-time-to-first-use-for-blaze

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/blaze/src/class-dashboard-rest-controller.php	0/773 (0.00%)	0.00%	113 💔

Full summary · PHP report · JS report

_{Coverage check overridden by Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR .}

[EkaterinaStancheva]

@sbarbosa , I have a few questions related to this PR:

• We haven’t had tests for the Blaze Plugin. Do you think it’s fine to add “Covered by non-unit tests” label or should we create unit tests?
• Could you please review the testing steps described and let me know if you notice any scenarios that are missing?

[sbarbosa]

Hi @EkaterinaStancheva!

• We haven’t had tests for the Blaze Plugin. Do you think it’s fine to add “Covered by non-unit tests” label or should we create unit tests?

It's true that we don't have much unit testing in this module. It would be nice to add some, at least for these new funcitons that we are creating. The module will now have more internal logic as before, so it would be nice to cover part of it at least.

But its probably fine also to move that task for the future too.

• Could you please review the testing steps described and let me know if you notice any scenarios that are missing?

There are easier ways to test this. When we create the Jetpack PR, it will create a feature branch that you can easily test by installing the Jetpack Beta plugin. So technically, you can just:

• Create an ephemeral site
• Install the Jetpack plugin, and the Jetpack Beta plugin
• Enable this feature branch on the ephemeral site
• Create a couple of new posts
• Now, connect your user in Jetpack and quickly go to the Tools->Advertising dashboard
• That should trigger the new logic, and you should see all of your posts (even if the site is still syncing).

I think this should test the real production steps.

This comment (#46500 (comment)) also adds other ways to test the branch, but this change will only apply to self-hosted installations, so the testing steps I shared should be enough to test the sync delay fix.

---

@EkaterinaStancheva, one thing to consider here is that this will need to be the last PR we merge. We can merge this before we implement all of the other changes, because if not, the user will see the post but will get errors the moment they try to promote a campaign.

[EkaterinaStancheva]

@sbarbosa Thank you very much for insights!

But its probably fine also to move that task for the future too.

As we discussed yesterday, I added Coverage tests to be added later label.

There are easier ways to test this.

I updated the PR description to add the testing steps you shared. I went through them, and everything works fine.

one thing to consider here is that this will need to be the last PR we merge.

I added DO NOT MERGE label.

[sbarbosa]

The code looks good and works as described.
I tested the changes on the Blaze Ads plugin and also worked fine 👍🏻

[j6ll]

Hey @EkaterinaStancheva I tested the changes but seeing some behaviour that could be a bug.

No branch loaded - see the message as expected

Branch now loaded - don't see message, posts response is empty

Can see posts here (I created them before connecting Jetpack)

I updated a post, and then they all show

[j6ll]

Thanks @EkaterinaStancheva for working on this - I left some minor comments to check. There are a couple I'm not 100% on, but worth a quick check.

[EkaterinaStancheva]

Hey @EkaterinaStancheva I tested the changes but seeing some behaviour that could be a bug.

@j6ll I’m testing by creating an ephemeral site with Jetpack Beta, pointing to this branch. And I haven’t experienced any issues. I’m not sure how to reproduce your test. How do you create the ephemeral site in a way that you can switch between branches? Do you think this could be a cache issue caused by switching between branches? @sbarbosa, I would also appreciate your thoughts. I tested multiple times and haven’t encountered any problems. However, I assume I might be missing something. 🤷‍♀️

[EkaterinaStancheva]

@j6ll @sbarbosa I addressed the feedback, so I'm requesting your review again. We already merged #46578, #46623, #46642, so I believe there are no blockers to merge this PR after approval. I'm removing the DO NOT MERGE label. @sbarbosa Please correct me if I'm missing something!

[sbarbosa]

LGTM 👍🏻

I just deployed all of the related PRs, so we are now able to use this branch and run a full test (to detect if we missed a change in the DSP).

@EkaterinaStancheva, would it be possible to merge the trunk into this PR so we get the latest change to the create campaign endpoint?

That way, it will refresh the feature branch, and we will be able to use an ephemeral site for the test.

[EkaterinaStancheva]

@EkaterinaStancheva, would it be possible to merge the trunk into this PR so we get the latest change to the create campaign endpoint?

@sbarbosa I already merged the trunk branch into this one. The create campaign endpoint should be there.

[sbarbosa]

Awesome, @EkaterinaStancheva. I ran a clean test of the full flow and successfully created a campaign using data from an unsynced post.

During the process, all of the related endpoints returned "sync_ready": false 👍🏻

Didn't find any blockers related to the flow. I think we already fixed all of the affected endpoints.

[j6ll]

How do you create the ephemeral site in a way that you can switch between branches?

Hey @EkaterinaStancheva I do the following:

1. Set up a new Jurassic Ninja site
2. Install the Blaze Ads plugin from the WP directory
3. ssh to my WP sandbox
4. cd apps/blaze-dashboard && yarn dev --sync to copy my local files to my WP sandbox
5. Point widgets.wp.com to my sandbox in my hosts file
6. Switch branches

[sbarbosa]

Hey @EkaterinaStancheva I do the following:

1. Set up a new Jurassic Ninja site
2. Install the Blaze Ads plugin from the WP directory
   ssh to my WP sandbox
3. cd apps/blaze-dashboard && yarn dev --sync to copy my local files to my WP sandbox
4. Point widgets.wp.com to my sandbox in my hosts file
   Switch branches

I am not sure about these testing steps. Technically, the Blaze Ads plugin has not yet been updated to this Jetpack Branch. So if you want to test these changes with the Blaze Ads plugin, you have two options:

1. Install Jetpack Beta on your site (alongside Blaze Ads) and then switch the branch in Jetpack Beta to this feature branch.
   In these settings, the jetpack autoloader should use this branch class (class-dashboard-rest-controller.php) instead of the old controller class that the Blaze-Ads plugin currently uses. I haven't tested this, but I think this is how the Jetpack autoloader works.

2. Copy the modified class projects/packages/blaze/src/class-dashboard-rest-controller.php to the jetpack vendor folder in the Blaze Ads repo and build it. Then install that version of the Blaze ads plugin. This will ensure you have this change in the plugin.

In both scenarios, you will need to configure everything before connecting the site to Jetpack, because it usually takes a couple of minutes to sync a blank site. You will need to run the test quickly.

Additionally, I am not sure why you are sandboxing the Blaze dashboard. We haven't made changes to the dashboard, so the test can be done with the production code (no need for a sandbox here).

[j6ll]

@sbarbosa @EkaterinaStancheva - Sorry folks, there's been a mix-up here. These testing instructions are not for this PR. My bad!

[j6ll]

This worked great for me. I saw the post straight away. I no longer see a sync message. This is a great improvement. Thank you, Ekaterina!