Generation Options — Output Format & cURL
The Generation Options tab controls how your product feed is formatted and how the module triggers the background feed generation process via cURL. Most stores work well with the defaults, but this tab is your first stop when diagnosing generation failures or working around server restrictions.
Available since v2.0.0
Overview
When you save and generate your feed, the module makes an internal HTTP request (via cURL) to your store's feed generation URL. This internal call kicks off the actual generation in the background, so your browser does not time out while thousands of products are processed.
The settings on this tab let you:
- Choose between RSS XML and ATOM XML output formats
- Control how cURL handles timeouts and SSL certificates during that internal call
- Enable a URL randomization parameter that forces cache systems to serve fresh data rather than a stale cached response
These are global settings — they apply to all shops in a multi-shop installation.
Configuration
Go to Modules > Module Manager > Facebook & Instagram Product Catalogue Feed Pro > Configure, then click the Generation Options tab.
Output Format
| Field | Values | Default | Description |
|---|---|---|---|
| Select the generation output format | RSS XML, ATOM XML | ATOM XML | The XML dialect written to the feed file |
RSS XML is an older, stricter format widely supported by all platforms. ATOM XML (the default) is a newer, more flexible format preferred by some providers — notably Google. Facebook and Instagram Commerce accept both. Unless you have been told by a specific platform to use RSS, keep the default ATOM.
Platform note: Most platforms accept both formats, but preferences differ. Google prefers ATOM XML. Pinterest, on the other hand, may prefer or require RSS XML — check Pinterest's current catalogue feed documentation if you are submitting a feed there. If you submit the same feed file to multiple platforms, create a separate feed URL per platform and set the format to match each platform's requirement.
cURL Settings
| Field | Values | Default | Description |
|---|---|---|---|
| Use Curl Timeout | Enabled / Disabled | Enabled | Runs feed generation as a background process by setting a very short cURL timeout |
| Use Curl SSL | Enabled / Disabled | Enabled | Verifies SSL certificates on the internal cURL call |
Use Curl Timeout is the key setting that enables background generation. When enabled, the module fires an internal cURL request with a 1-second timeout. The request starts the generation process and then deliberately disconnects — the generation continues running on the server without keeping your browser waiting. If your feed stops generating immediately with zero or very few products, this is the first setting to disable.
Use Curl SSL controls whether the internal cURL call validates your store's SSL certificate. Disable this only if you see certificate-related errors in your PHP error log or if you are running the module on a development server with a self-signed certificate.
When to disable Curl Timeout: If your feed stops at the very beginning and the error log shows a cURL error or a connection refused message, disable this option. The generation will then run synchronously within the PHP request rather than as a detached background process.
When to disable Curl SSL: Only disable if your server has a misconfigured or self-signed SSL certificate and you see SSL verification errors. On a production store with a valid certificate, leave this enabled.
Cache-Related Settings
| Field | Values | Default | Description |
|---|---|---|---|
| Generation Randomization | Enabled / Disabled | Disabled | Adds a unique random parameter to each generation URL call |
When Generation Randomization is enabled, every cURL request the module makes — including cycle continuation calls — appends a randomize parameter with a unique value. Most reverse proxies (Varnish, Nginx microcaching, CDN edge caches) use the full URL as the cache key. Without this parameter, a cached response from a previous generation may be served instead of actually triggering a new generation run.
Enable this setting if:
- Your store sits behind a caching layer (Varnish, Cloudflare, a CDN)
- You suspect the feed is not refreshing even though the cron runs correctly
- Your hosting provider told you that dynamic URLs are being cached
How It Works
Background Generation via cURL
When you trigger a feed generation (manually or via cron), the module calls its own generation URL internally using cURL. The generation URL looks like:
https://yourstore.com/module/facebookproductsfeed/GenerateFeed?fpf_secret_key=...
With Use Curl Timeout enabled, the connection timeout is set to 1 second and the total timeout is also 1 second. This causes the cURL call to "fail" immediately from the caller's perspective, but the PHP process on the server continues running and writes the feed file. This is the standard technique for fire-and-forget background tasks in PHP environments that do not support true background processes.
With Use Curl Timeout disabled, the cURL call waits for the generation to complete before returning. This is reliable on servers with generous max_execution_time values but will block the browser or cron caller for the full duration of generation.
v2 Cron URL Format
If you upgraded from a version earlier than 2.2.6, you may see a notice in the Back Office telling you the generation URL has changed. The FPF_NEW_CORN_URL flag is set during the upgrade to trigger a one-time informational banner that shows you the updated cron URL format using the cleaner module route:
https://yourstore.com/module/facebookproductsfeed/GenerateFeed?fpf_secret_key=...
The older format used a direct cron.php path. The new format is handled by PrestaShop's routing layer and works more reliably across different server configurations. Once you acknowledge the notice in the Back Office and update your cron job to the new URL, the banner disappears. The Automatic Generation (Cron Jobs) tab always shows the current correct URL for your store.
Random Parameter During Cycle Continuation
When cycle-based generation is active (your catalogue is large enough to require multiple cycles), each continuation request carries the randomize parameter when Generation Randomization is enabled. This ensures every cycle call bypasses the cache independently, not just the first request. Without this, a caching layer could intercept a continuation request, return a cached "generation in progress" response, and silently halt the multi-cycle process.
Usage Examples
Example: Feed stops generating with 0 products on a shared host
Your feed generates 0 products and the Dashboard shows the last generation completed instantly. Go to Generation Options, set Use Curl Timeout to Disabled, save, and trigger a manual generation. The module will now wait for the generation to complete synchronously. Once generation works, check whether your host permits long-running PHP requests and consider setting up a cron job via CLI instead.
Example: Feed does not refresh even though cron runs
Your cron runs every hour but the feed timestamps do not change. Your store uses Varnish. Go to Generation Options, enable Generation Randomization, save. The next cron run will append a unique parameter to the generation URL, bypassing the Varnish cache and triggering a real generation.
Example: Self-signed certificate on a staging server
You are testing the module on an internal staging server with a self-signed SSL certificate. The feed fails to generate and the error log shows SSL certificate problem: unable to get local issuer certificate. Go to Generation Options, disable Use Curl SSL, save. Generation will succeed because the internal cURL call no longer validates the certificate.
Important Notes
- All settings on this tab are global — they apply to all shops in a multi-shop setup. You cannot configure different cURL behavior per shop.
- Generation Randomization reads from the global configuration regardless of the current shop context, because it applies to the generation URL itself, not to product data.
- The short cURL timeout (1 second) is intentional when Use Curl Timeout is enabled. Do not interpret it as an error — the generation continues on the server after the connection drops.
- If you are running generation from the command line (CLI cron), cURL settings do not apply. The generation runs directly in PHP without making an internal HTTP request.
Troubleshooting
| Problem | Solution |
|---|---|
| Feed stops at 0 products immediately | Disable Use Curl Timeout and retry. If generation works without it, your server does not support fire-and-forget cURL calls. Use a CLI cron job instead. |
| Generation URL cron does not trigger | Enable Generation Randomization if your server uses page caching. Also verify the secret key in the cron URL matches the one in Feed Protection. |
| SSL certificate error in PHP log during generation | Disable Use Curl SSL. This is expected on staging servers with self-signed certificates. |
| Banner says "generation URL has changed" after upgrade | Copy the new URL from the Automatic Generation (Cron Jobs) tab and update your cron job. The banner clears once acknowledged. |
| Feed appears stale despite frequent cron runs | Enable Generation Randomization to bypass any caching layer sitting in front of the generation endpoint. |
Frequently Asked Questions
My feed generates correctly when I click 'Generate Feed Now' but not from the cron job. Why?
The manual button triggers generation directly from your browser session, bypassing cURL. The cron job uses the generation URL, which goes through cURL. Check that your cron URL contains the correct secret key and try enabling Generation Randomization if a cache layer is involved.
Should I disable Curl Timeout if my catalogue has 50,000 products?
No — for large catalogues you should keep Use Curl Timeout enabled, because it allows the generation to run in the background across multiple cycles without blocking. If generation stops, the issue is usually the cycle configuration, not the timeout. See the Cycle-based Generation guide.
What is the difference between RSS XML and ATOM XML for Facebook?
For Facebook and Instagram Commerce, both formats work equally well. ATOM XML is the recommended default because it is more flexible and preferred by Google Shopping. Only switch to RSS XML if a specific import tool or platform explicitly requires it.
Does Generation Randomization affect the feed URL that Facebook uses to download the catalogue?
No. The random parameter is added only to the internal cURL call that triggers generation on your server. The feed file URL that Facebook fetches to read your catalogue is separate and is never modified by this setting.
I disabled Curl SSL and the generation works, but is this a security risk?
It is a minor risk in production because the internal cURL call skips certificate validation. On a live store with a valid SSL certificate you should keep Use Curl SSL enabled. If you had to disable it for a production store, investigate why your certificate chain is incomplete — the cause is usually a missing intermediate certificate on the server.