Automatic posts from PrestaShop to a Facebook Page can handle recurring messages: new products, promotions, restocks and new guides. In Automatic Facebook Posts Pro, rules select the content, a template builds the message and the queue follows a schedule. Before enabling real publishing, plan how to check the selected content and the prepared messages.

What not to automate without review

Do not present the entire existing catalogue as new arrivals or keep repeating the same products. Check the public URL, description, price and image assets. An image is required for photo formats, but not for every kind of post. A promotion message should match the offer visible to its audience, not a private discount for a particular customer.

Publishing organic posts is a separate task from advertising, the Meta catalogue and Pixel/CAPI measurement. The posting module does not replace those integrations and provides no basis for promising a particular reach or sales result.

Ten publishing rules, but not all at once

Automatic Facebook Posts Pro provides rules for new products, new ph_simpleblog entries, promotions, ending promotions, restocks, bestsellers, product rotation, article rotation, categories and CMS pages. Blog support requires a separate, active ph_simpleblog module.

Event-based rules record an initial state for existing content. The first scan is therefore not intended to publish the current catalogue in bulk as new arrivals. Older products can be presented through rotation or manual selection. Starting with two or three rules makes it easier to check whether their scopes repeat the same messages.

Three scenarios: a demonstration plan, not test results

The example below is only a demonstration plan for a future simulation. It has not been run in the module or through CRON, no queue jobs have been created and no runtime results have been collected. There has been no Meta login, no application or token creation and no actual Facebook post.

Planned checks for three fictional cases
ScenarioDemonstration dataPlanned check
New productDEMO-PROD-101: a public product available to order, with a price and an imageWhether a product appearing after the initial state has been recorded creates the right event and meets the rule filters
PromotionDEMO-PROD-202: a regular price and a detected reduction available to a guestWhether a new promotion meets the rule conditions; an ending-promotion reminder also needs a future end date
Blog entryDEMO-BLOG-17: an active ph_simpleblog entry, title, excerpt and public URLWhether the entry is accessible to a guest and its publication date is not in the future

The planned schedule is Tuesdays and Thursdays from 10:00 to 16:00 in the shop's time zone, with no more than two posts a day and at least 180 minutes between posts. These are values chosen for the example, not settings saved in a shop or a verified publishing schedule.

Post templates and supported variables

The module prepares text posts, link posts, single-photo posts and multiple-photo posts. Templates use shop data. For a product, {description} contains the short description; for a blog entry, {title} and {excerpt} can be used.

Demonstration template for a new product:

New in the shop: {name}
{description}
[[price]]Price: {price}[[/price]]
{url}
{hashtags}

Demonstration template for a promotion:

Promotion: {name}
[[price]]Current price: {price}[[/price]]
[[regular_price]]Regular price: {regular_price}[[/regular_price]]
[[promotion_end]]Offer until: {promotion_end}[[/promotion_end]]
{url}

Demonstration template for a blog entry:

Guide: {title}
{excerpt}
Read more: {url}

Fragments such as [[price]]...[[/price]] omit the text when the field has no value. Before use, check the prepared message, link and meaning of each price. The regular price does not mean the lowest price in the last 30 days. The module reads the product's default variant rather than creating a separate automatic post for each combination. Templates do not generate AI content or automatic translations.

A schedule and queue, not instant publishing

Weekdays, the time window, a daily limit and the gap between posts restrict the available slots. Rules also have a priority and a delay after an event is detected. Manual posts use the same queue and restrictions, so clicking a publish button does not guarantee a post will appear in that same minute.

Before processing a job, the module fetches the content again and, for product rules, checks the filters and whether the promotion is still valid. Saving a rule, creating a job, completing a simulation and successfully publishing are separate stages. When checking an implementation, inspect job status and history, not just the confirmation that settings were saved.

CRON and the module's simulation mode

Full background operation requires CRON to be configured on the server. The module's instructions recommend running it every minute; installing the module alone does not mean the system task is already running. The administration panel does not need to stay open.

Simulation mode finishes a prepared job with a simulated status before sending the post to Meta. Turning simulation off does not automatically send jobs already completed in this way: real sending requires an explicit retry. This describes module behaviour, not a report that the plan shown here has been executed.

Facebook authorisation: requirements before sending

Connecting requires a Facebook Page, appropriate access for the person managing it and details of their own Meta application. The module description provides for a wizard using App ID, App Secret and a user token, plus a separate form for an existing Page token. Saving the queue does not confirm a working connection.

Before real sending, check the current requirements in the Meta Pages API posting documentation. This guide does not specify a current API version or a complete permissions list. Expired or revoked access needs diagnosis; the module does not replace the account owner's renewed consent.

UTM and measurement boundaries

Links prepared by the module receive utm_source=facebook, utm_medium=social, a campaign name from the template and a publication marker in utm_content. These parameters can help identify traffic in separately configured analytics, but do not confirm a visit or a purchase.

Keep successful post publication, a shop visit and an order separate. The module does not provide its own Facebook reach or sales statistics. Assessing commercial results requires actual measurement and order data, with consent and attribution limits taken into account.

What the module does not cover

Its scope is Facebook Pages, not personal profiles, groups, Instagram, paid campaigns, videos, reels or stories. The module does not create PrestaShop promotions or coupons. It uses source assets and does not generate graphics. Changing a product in the shop does not automatically edit or delete a post already published.

When to choose Automatic Facebook Posts Pro

If you need to publish selected shop content using rules, templates, a schedule and a queue, see Automatic Facebook Posts Pro. Before enabling sending, prepare representative cases, check CRON and confirm access to the Page. The example above remains an unexecuted demonstration plan.

See the author's articles
Patryk Marek

Patryk Marek — owner of PrestaDev.pl and a developer specializing in PrestaShop. For many years, he has been involved in creating, developing, and maintaining online stores. He combines work on store and module code with the configuration of the server environment in which these solutions operate.

He designs and develops PrestaShop modules, customizes existing features, and prepares integrations with wholesalers and external services. He works on product data import and updates, catalog management automation, the order process, and tools supporting the store owner's daily work.

His experience also includes store updates and migrations, error diagnosis, performance analysis, and the configuration of servers and services required for PrestaShop to operate. When solving problems, he takes into account the dependencies between modules, the theme, PHP, the database, and hosting settings.

On the blog, he shares knowledge gained from many years of programming practice and working with the technical backend of stores. The guides focus on specific problems, ways to verify them, and the limitations of the described solutions. They help store owners and technical specialists prepare changes, assess their scope, and verify the result.

Comments (0)

No comments at this moment

New comment

You are replying to a comment