Alin (a11n)

That’s great to hear! Thanks for letting us know and thanks everyone!

Hi @moodyhosam,

Good question!

Jetpack Boost can replace part of what Autoptimize does, but they’re not identical.
Boost handles the major performance wins most sites need today, including:

• Critical CSS
• CSS and JS concatenation
• Deferring non-essential JavaScript
• Image CDN with WebP
• LCP image optimization
• Page caching
• Lazy-load improvements
• Performance scoring

For many sites, that covers the bulk of front-end optimization without needing multiple plugins.

Autoptimize still includes some more advanced or niche tools, such as HTML minification, Google Fonts optimization, AVIF generation, and very granular expert-level controls. If you rely on those very specific features, you may want to keep it.

If your goal is a simpler setup with fewer moving parts, Boost is usually enough on its own.
If you prefer fine-grained tuning and lots of switches, Autoptimize remains a strong option.

I hope this helps, but if you have other questions, please let us know.

Best,
Alin

Hi @ghost81,

Thank you for the update. At this poiont, to make sure we give you the right guidance, I am checking this internally with our development team to confirm the exact limitations and possibilities here.

As soon as we have an update, we’ll follow up.

Thank you!

Hi @moodyhosam,

Yes, what I said back then still applies. WP Super Cache focuses on deeper caching options, while Jetpack Boost focuses on front end performance improvements like Critical CSS, JavaScript optimizations and image performance. They are complementary as long as you avoid enabling the same type of caching in both plugins.

If you are already happy with WP Super Cache, you do not need to “migrate” to Jetpack Boost. You can keep WP Super Cache for page caching and use Boost on top of it for the extra front end optimizations. If you prefer a simpler setup with fewer plugins, you can use Boost’s own page caching instead, but that is optional.

Let me know if that helps or if you have other questions.

Hi @robhamburg,

Thanks for clearly explaining the situation. Here is how WP Job Manager handles taxonomies, based only on what the plugin itself is responsible for.

WP Job Manager relies entirely on WordPress’s built-in taxonomy system. It does not create, store, or unregister taxonomies on its own. Instead, it simply displays whatever taxonomies WordPress has registered for the job_listing post type. All taxonomy data is kept in WordPress core tables (wp_terms, wp_term_taxonomy, and wp_term_relationships).

Here’s a breakdown for each of your questions:

1. Where does WP Job Manager store references to custom taxonomies once registered?
WP Job Manager doesn’t store any taxonomy definitions on its own. It reads them directly from the standard WordPress taxonomy tables:

• wp_terms
• wp_term_taxonomy
• wp_term_relationships

2. How can we fully remove a taxonomy so it disappears from both WP Job Manager and the Field Editor lists?
Since WP Job Manager does not manage taxonomies internally, removal needs to happen at the WordPress level. Once a taxonomy is no longer present in the WordPress taxonomy tables, WP Job Manager will stop displaying it.

3. Is there any known compatibility issue between Pods and WorkScout in taxonomy handling?
I’m not aware of anything documented in this area. If you need specifics on how those components register taxonomies, their developers would be the best source.

4. Which hook or function in WP Job Manager registers existing taxonomies so we can trace their origin?
Since WP Job Manager doesn’t register custom taxonomies, it only displays whatever taxonomies WordPress has already registered for job_listing, so there isn’t a plugin-specific hook for that.

If you’d like to look deeper into how taxonomies, terms, and relationships are stored, you can find the full reference here:

https://wpjobmanager.com/document/developer-reference/plugins/core-wpjm-database-entries/

I hope this helps. If you have more questions about WP Job Manager, feel free to ask.

Best regards,
Alin

Hi @nilreb5,

It sounds like WooPayments is trying to use Jetpack’s built-in connection system to verify your account, which is why you’re receiving those Jetpack codes even if the Jetpack plugin isn’t installed.

Since you recently moved your site, that connection may still point to the old domain. The best next step is to reconnect your site, or by temporarily installing the Jetpack plugin, connecting it once, and then trying again.

If you still run into issues, please share your site’s URL so we can take a closer look. If you’d rather keep that private, you can reach us through this contact form instead, and make sure to add a link to this forum thread.

Thank you!

Hi @ghost81,

Thanks so much for taking the time to explain everything in detail.

What you’re seeing (manual publish works, scheduled doesn’t) happens sometimes with scheduled posts for custom post types, and probably especially on subsites in a multisite setup.

At the moment, automatic sharing is most reliable with regular posts. For custom types like yours, scheduled shares aren’t always picked up as expected. The safest workaround is to publish manually (as you’ve already noticed) or use an external tool for social scheduling.

We can’t arrange direct calls with our developers for now, but I’ve made sure your feedback is noted.

Thanks again for your patience and for testing this so thoroughly. If there is something else instead that we can help you with, please let us know.

Best regards,
Alin

Hi @elledawn,

Good news — the fix for this issue is now available!

You can update Jetpack to version 15.1.1, which fully resolves the error you experienced with the Asset CDN (photon-cdn.php).

After updating, you can safely re-enable the Site Accelerator feature if you had previously turned it off.

Thanks again for your patience while this was being addressed — and please let us know if anything still looks off after updating.