| 开发者 | fastog |
|---|---|
| 更新时间 | 2026年11月2日 16:55 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
og:image points at that cache. Your host never runs a headless browser,
never stores a generated image, and never eats the bandwidth of a social crawl.
Nothing to manage, and nothing to re-export when a price changes./social-image.jpg endpoint that 404s —
the failure modes that make self-hosted image plugins collapse on ordinary hosting.fastog-for-woocommerce folder to wp-content/plugins/, or install
the plugin from the admin.Most stores ship no Open Graph image for product and category pages, so social
platforms fall back to a logo or a blank tile. FastOG prints a designed og:image
for every page type, so every share gets a card worth clicking.
That is the usual symptom: the platform crops whatever image it was given to 1200x630. A product photo that is square or tall gets its sides or its top cut off, and a logo tile gets stretched. FastOG serves a card already composed at 1200x630 with the product photo fitted inside it, so the platform has nothing left to crop.
Yes. Product covers are drawn from live catalogue data, so the price on the card matches the price on the page, and a discounted product gets a sale badge. Every plan draws these fields — they are never locked to a higher tier. If a price changes after a link was shared, the next share draws the new price.
On Facebook, FastOG already handled it: the plugin registers WooCommerce's own product
webhooks, so saving a product asks Facebook to re-read that page and the new card
normally replaces the old preview within seconds. You do not need the Sharing Debugger.
If Facebook is still showing the old card, confirm the product page itself is serving the
new og:image — purge your own page cache if a caching plugin or your host is still
handing out the old HTML — and re-scrape the page in the Facebook Sharing Debugger.
WhatsApp, LinkedIn and X are a different story, and we will not pretend otherwise: none
of them lets anyone request a refresh, so we cannot push one. What we can do is make
sure the right image is waiting — cover URLs change with the cover, so their next read
gets the new card. When that read happens is up to them; LinkedIn and X typically
re-read within about a week. Their own inspectors (LinkedIn Post Inspector, X Card
Validator) can nudge that if you are in a hurry.
Facebook, and only Facebook, because it is the only one that offers a programmatic refresh — that is what FastOG calls when you save a product. Every other platform either caches a preview we cannot reach (WhatsApp keeps it in the recipient's app) or exposes no way to ask at all (LinkedIn, X). Those follow their own schedule, and a share that was cached before your edit can keep showing the old card until they re-read.
Not for the covers themselves. Without WooCommerce, FastOG covers your front page and blog posts from WordPress data alone. WooCommerce adds the storefront page types: product, product category and shop covers read your catalogue, so those three need it installed and active.
No. Covers are rendered and cached on FastOG and served from there, so your server only signs a URL — there are no images generated or stored on your hosting and no impact on page speed.
FastOG does. If Yoast, Rank Math, All in One SEO or SEOPress is active, we do not
print a competing <meta property="og:image"> — a second one does not override the
first, it competes with it, and social crawlers take the first they find. Instead
your FastOG cover is handed to that plugin, so it prints our image with its own
title, description and URL. Without an SEO plugin, FastOG prints the full set of
Open Graph and Twitter card tags itself.
No. The editor's script and stylesheet are bundled inside the plugin and served from your own site. The only requests that leave your server are the FastOG API calls the Studio editor makes when you open it.
Only after you explicitly choose Start setup. Activation and ordinary admin page loads do not contact FastOG.
No. Only a site-level profile (site name, site URL, WordPress/WooCommerce/PHP versions and locale) is sent when you connect. No customer, order, or other personal data is transmitted. FastOG also verifies site control through a one-time proof challenge. The temporary proof secret is sent only over HTTPS and discarded after verification.
On FastOG. og:image URLs point at FastOG, so your site doesn't need extra
storage or a CDN.
One HTML comment above the social tags — <!-- Social card by FastOG --> with our
URL — so anyone reading the page source can see where the og:image host comes from.
It is a comment: nothing is added to what visitors or crawlers see, no request is
made, and it is stripped of anything that could become markup.
Turn it off on FastOG → Tools → Page source: the switch is in wp-admin, costs
nothing, and no plan changes with it. If you would rather not have the setting on the
screen at all, define('FASTOG_WC_ATTRIBUTION', false); in wp-config.php or
add_filter('fastog_wc_head_attribution', '__return_empty_string'); in a small plugin
also removes it.
Paid plan trial availability is shown in the checkout flow. Community is free forever and does not require Stripe Checkout. Pricing and plans are at https://fastog.com/plugin-pricing.
Yes — the plugin is translated into 27 languages: Arabic, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian, Indonesian, Italian, Japanese, Korean, Norwegian (Bokmål), Polish, Portuguese (Portugal and Brazil), Romanian, Russian, Spanish, Swedish, Thai, Turkish, Ukrainian, Vietnamese, and Chinese in both its Simplified and Traditional forms. These translations ship inside the plugin, so they work on any install with no extra step: WordPress uses the language you set under Settings → General. If WordPress.org has a language pack for your locale, that pack is used instead of the bundled copy, so corrections made on https://translate.wordpress.org/projects/wp-plugins/fastog-for-woocommerce/ arrive without waiting for a release. A language that is only partly translated falls back to English string by string rather than breaking a screen. If yours is incomplete and you would use it, say so on the support forum — that is what decides which language gets attention next.
Yes. Community is free forever, covers up to 100 items across all four page types, and renders clean covers without a watermark. It includes four base templates plus the Black Friday and event-agnostic Seasonal Offer product looks, live price and sale badges, and stock badges. Starter adds 24 curated templates and rating badges; Pro adds the Custom Builder and metafield mapping; Scale adds scoped rules and priority rendering. Community does not require Stripe Checkout.
No. Until you finish it, FastOG points Studio and Plan at Setup so nothing half-configured goes live — and Skip setup for now lifts that immediately. Tools is never held back: that is where you reconnect or disconnect.
Cover URLs contain the settings that produced them, so editing a cover produces a
new URL and there is nothing on the FastOG side to clear. Your own page cache can still
keep serving the old og:image, so purge it if a caching plugin or your host caches
pages. After that, Facebook is refreshed for you (saving a product asks
Facebook to re-read the page); WhatsApp, LinkedIn and X pick up the new image on their
own next read.
Deleting the plugin removes everything it stored on your site, including its access key, from every site on a multisite network. Your store record and cover images on FastOG stay in your FastOG account, where you can delete them; covers already shared in social posts keep working until that record is removed.
No. The stored credentials (API key, secret and tier) are migrated automatically, so there is nothing to re-enter.
app:picker) instead of a web address, because the plugin's
pages are not URLs — so the message and its button now point where the work actually happens.collection and collage ask for two to four product photos, which only a product with a gallery can supply — on a category, a shop page or a single-photo product collection drew empty bordered tiles, which reads as a broken cover rather than a design. Covers already served from these layouts keep working; the wizard and the pickers simply stop offering them.%20 at the end of the parameter, which some request pipelines trim before the signature is re-derived — so the cover answered 401 invalid_signature on every fetch, permanently, while the URL looked correctly signed everywhere. Cover copy is now signed with no leading or trailing blank.%0A inside the signed cover URL, and WordPress's own esc_url() deletes %0a/%0d from any URL it prints — so the crawler fetched a URL the signature no longer covered, and every such cover answered 401 invalid_signature on every attempt. Cover copy is now signed as a single line, so what is signed is exactly what gets printed.