A lot of people have wanted this in Jetpack: a default social image setting for Open Graph previews.
I opened a pull request this week that tries to make it real.
The PR is open and ready for review, not merged. If you have wanted this setting in Jetpack too, this is a good moment to test it, leave feedback, or add your voice to the request.
For me, it is also a milestone: my first contribution in the Jetpack monorepo, started from a user pain that kept showing up in real work.
People want a Yoast-like default social image in Jetpack. If a post does not have a featured image, or if Jetpack’s existing image discovery does not find the right image, site owners want one place to choose the fallback.
That fallback image has technically been possible for a long time. Jetpack has documented ways to add a custom Open Graph image through code, including the jetpack_open_graph_image_default filter and a resource article about adding a default Open Graph image. But that path assumes you know where to put code, how filters work, and how to avoid breaking something. That is the gap.
I have had to solve this with custom code, or by creating a custom admin screen under Settings > Reading. That can work for one site, but it does not feel like product. The setting people need should live where they already preview how their site appears when shared.
Open Graph metadata is one of those quiet parts of the web that most people only notice when it breaks. You publish something, paste the link into Slack, Facebook, LinkedIn, or a text thread, and suddenly the preview is wrong. It changes how the work feels when it leaves the site.
So the feature is intentionally straightforward. The PR adds a default social image picker to Jetpack Settings > Traffic, because that is where the Google, Facebook, and X preview UI already lives. The setting is stored at the site level as jetpack_social_open_graph_settings, with a default_image_id value that points to the selected media attachment.
The UI uses the space Jetpack already gives to search and social previews. We shaped the accordion copy to fit the rest of the page: Expand to choose a default social image and preview. Inside, the picker sits beside the existing preview context, and the helper text gives a clear best-practice target: Recommended size is 1200x630px and < 600 KB.
My first instinct was Jetpack Social, but the better answer was sitting in the Traffic settings page. That screen already shows how Google, Facebook, and X preview the homepage. Users are not choosing an asset in isolation. They are trying to understand what people will see when their site is shared.
That changed the implementation. The backend setting still lives in the shared Jetpack Social/Open Graph settings layer, but the main user-facing control moved to Traffic, where the preview already exists. That’s a small product decision, but it’s exactly the kind of decision a power user can see clearly. I know where I would look for that setting because I know the feeling of trying to fix the preview.
The Jetpack monorepo does not reward guessing. I had to learn its shape: the Publicize package, the Jetpack plugin, shared settings, React admin screens, REST option validation, changelog requirements, build commands, test suites, and CI checks.1
The point was to follow the contributor path seriously: read the source, use the repo tooling, work locally, run the tests that matter, verify the UI in a real WordPress environment, and let the review process tell me what still needed work.
That is the part I want non-coders to see. You do not have to become a traditional developer before you can participate more concretely. You do need to respect the project, follow its guidance, and keep asking the question a user would ask: does this make the product better in the place where people naturally expect it?
The feature changed through iteration. It started in one settings surface, then moved to Traffic. The image-size guidance changed. The helper text changed. The width inside the accordion changed. The styling changed so the helper text matched the rest of the page. Each refinement came from looking at the screen and asking whether the experience felt like Jetpack.
Codex helped me move through the unfamiliar parts, including the local environment. I still cannot explain Docker to you in a satisfying way. I know the workflow needs an environment where Jetpack can run, and I can ask the agent to handle that setup while I stay focused on what the user should see.
That does not mean the tool gets to decide the product. The best iterations came from user experience questions: Should this live in Social or Traffic? Should the picker be separate from Social Image Generator? Should the preview update in the same space where Jetpack already shows link previews?
That loop caught details tests alone would have missed. The first UI placement was wrong, the helper text started with a weak image-size recommendation, and the content width inside the accordion needed to match the rest of the page.
The tests mattered too. The PR now includes JS coverage for the Traffic UI and PHP coverage for the Open Graph settings path. CI caught real issues, code coverage pointed to behavior that needed proof, and static analysis forced defensive handling around REST input.
The PR body mattered too, because this is public. Internal workflow notes, skill scaffolding, and local setup artifacts do not belong there. Maintainers need to know what changed, why it belongs, how to test it, and what it does not try to solve.
The lazy headline is “AI wrote a Jetpack PR.” That misses the useful part.
The better takeaway is that a persistent user pain can become a concrete contribution when the workflow becomes understandable. You still need judgment. You still need to think like a user. You still need to read the code, test the site, and respect the review process. But there is little excuse now to let the same pain eat at you forever without at least trying to fix it.
So many of the best product insights come from people who use the software every day, support people using it, or notice the same rough edge again and again. Those people haven’t always had a realistic path from pain point to patch. AI-assisted development gives more of us a way to show up with something specific enough to review.
This PR may change during review. It may need revisions. That’s fine. That’s part of the process.
For now, I’m proud that the branch exists, the tests pass, the preview works on a real Jetpack test site, and a long-running user request has a concrete proposal in front of maintainers.
What is the WordPress pain you have seen enough times that it might be time to turn it into a patch?
- Like I knew any of this stuff anyway. So many great skills and resources have been created now to make AI-assisted contribution feel much more possible. ↩︎
Leave a Reply