Blog

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

In a large PrestaShop catalog, your “Faceted Search” filters are the navigation equivalent of a concierge. When a customer selects “Blue” and “Size Large,” they expect to see exactly that. If your filters return irrelevant results—or worse, an empty page—the customer assumes you don’t have what they need and leaves.

Broken attributes are a silent conversion killer. If your sorting logic is “confused,” your inventory becomes invisible. Whether it’s a color filter that shows red items under “Blue” or a size filter that lists “XL” before “Small,” these technical glitches signal a lack of professionalism that drives B2B and B2C buyers away.

The SEO Impact: Crawl Equity and Filter Bloat

While filters are dynamic, how search engines interact with them is a critical SEO factor.

• Faceted Indexing Issues: If not configured correctly, every filter combination can create a new, unique URL. This leads to “duplicate content” issues where Google finds thousands of near-identical pages (e.g., ?color=blue vs ?color=blue&size=L). This wastes your Crawl Budget.
• Canonical Integrity: We must ensure that filtered results use proper Canonical Tags to point back to the main category. This ensures your ranking power isn’t diluted across a sea of filter combinations.
• Long-Tail Opportunity: Conversely, if we want to rank for “Blue Cotton T-Shirts,” we can “open” specific filter combinations to search engines, turning your faceted search into a landing page machine.

The AEO Angle: The Precise Answer

Answer Engine Optimization (AEO) relies on the accuracy of your structured data.

• The Filtered Answer: When a user asks an AI assistant, “Show me waterproof hiking boots under $100,” the assistant “crawls” your faceted logic. If your attributes (Color, Material, Price) are misaligned, the AI will fail to cite your products because it cannot verify they meet the criteria.
• Schema for Attributes: We implement Product Schema that explicitly defines attributes. By ensuring your “Size” and “Color” filters match the JSON-LD data in your code, we allow AI agents to confidently present your products as the “Best Answer” to specific, filtered queries.

PrestaShop Execution: Fixing the Faceted Search

In PrestaShop, “confused” filtering is usually a result of index corruption or attribute mapping errors.

1. Rebuild the Attribute Index: The most common fix is found in the Faceted Search (ps_facetedsearch) module. We often need to manually trigger the “Rebuild Entire Price Index” and “Rebuild Attribute Index” buttons to sync the front-end filters with your latest product database.
2. Attribute Value Mapping: If colors are appearing in the wrong place, it’s often because multiple “Color” groups were created. We consolidate these into a single attribute group to ensure the logic remains consistent across the entire store.
3. Logical Sorting: Native PrestaShop often sorts sizes alphabetically (L, M, S, XL) instead of logically (S, M, L, XL). We use “Position” settings within the Attribute management screen to force a logical human sequence that improves the user experience.

Your filters should guide your customers, not confuse them. Let’s clean up your attributes and make sure your best products are always just one click away.

[Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

Shopify is a fantastic tool to start a business. It’s easy, it’s pretty, and it works out of the box.

But there comes a tipping point. Usually, it happens when you hit $1M or $5M in revenue. You look at your monthly bill—the subscription fees, the app fees, and the transaction fees—and you realize something terrifying:

You are paying a “Success Tax.”

The more you sell, the more they take. And despite writing them a massive check every month, you realize you are still just a tenant.

• You can’t customize the checkout (unless you pay $2,000/mo for Plus).
• You can’t change the URL structure for SEO.
• You can’t access your own database.

You are living in a golden cage.

This is why we see a wave of mature brands migrating back to Open Source (PrestaShop). They are done renting. They want to buy.

1. The “Success Tax” vs. Flat Costs

The math is undeniable at scale.

• Shopify: Takes a percentage of your revenue. If you use a third-party payment gateway, they penalize you with extra fees. Your costs scale linearly with your growth.
• PrestaShop: You pay for hosting. Whether you sell $10,000 or $10 Million, your hosting bill is roughly the same. You keep the margin.

The Migration ROI: We recently moved a client doing $10M/year from Shopify Plus to PrestaShop. The savings in transaction fees and app subscriptions alone paid for the entire migration project in 4 months. Everything after that was pure profit.

2. Data Sovereignty: “Can I See My Database?”

On Shopify, your data lives behind an API wall.

• Want to run a complex SQL query to find “Customers who bought X but not Y in the last 365 days”? You can’t. You have to buy an expensive “Reporting App.”
• Want to integrate with a custom ERP system that Shopify doesn’t support? You hit API rate limits.

On PrestaShop: You own the database. It is sitting on your server. You have Direct SQL Access. You can connect any tool, run any report, and integrate any warehouse system without asking for permission or hitting a “rate limit.” Your data is truly yours.

3. The “Banned” Risk (Terms of Service)

This is the dark side of SaaS (Software as a Service). Because you are renting space on Shopify’s servers, you are subject to their Terms of Service.

• If you sell supplements, tactical gear, or “high risk” items, Shopify can (and does) shut down stores overnight without warning.
• One morning, you wake up, and your URL redirects to a “Store Unavailable” page. Your business is gone.

On PrestaShop: You cannot be de-platformed. You own the code. You own the server. As long as you pay your hosting bill and follow the law, nobody can pull the plug on your livelihood.

4. Customization: Breaking the Walls

Shopify has a “rigid” architecture.

• SEO: You hate that every URL must have /products/ or /pages/ in it? Too bad. You can’t change it.
• Checkout: You want a unique checkout flow for wholesale buyers? Unless you are on Plus, the checkout is locked.

On PrestaShop: It is Open Source. We can change anything. We can rewrite the URL structure to match your exact SEO strategy. We can build a custom one-page checkout that integrates with your unique loyalty program. There are no walls, only code.

Stop Sharecropping

In the physical world, successful businesses eventually stop leasing and buy their own building. It builds equity.

In the digital world, moving to PrestaShop is buying your building.

• You control the costs.
• You control the data.
• You control the future.

If you are tired of asking a Landlord for permission to run your business, it’s time to move out.

Download our [5-Point Profitability Audit] to calculate your “Shopify Exit” ROI, or schedule a Migration Discovery Call below.

? [Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

You install a new “Product Reviews” module to boost sales. Suddenly, your “One Page Checkout” stops working. You uninstall the Reviews module. The Checkout works again.

You conclude: “The Reviews module is broken.” You ask for a refund.

But the module wasn’t broken. You just witnessed a Resource Conflict. You put two drivers in the front seat and told them both to grab the steering wheel. The car didn’t break; it crashed because two people were fighting for control.

In the PrestaShop ecosystem, modules are constantly fighting for resources, priority, and screen space. When they collide, your site pays the price.

The Technical Battlefield: “Hooks” and “Overrides”

To understand why your site crashed, you have to understand how PrestaShop thinks. It uses a system of Hooks.

Imagine a Hook as a specific location in your store—like the “Header” or the “Order Confirmation” button.

• Module A (Analytics) wants to hook into the Header to track visitors.
• Module B (Chat Widget) wants to hook into the Header to show a popup.

The Conflict: If Module A loads a specific version of a script (like jQuery 1.0) and Module B tries to force a newer version (jQuery 3.0) on the same page, the browser panics. It can’t run both. It freezes.

The Override War: It gets worse. Some heavy modules use Overrides. They literally rewrite PrestaShop’s core behavior. If Module A rewrites the “Cart” logic to add a discount, and Module B rewrites the “Cart” logic to calculate shipping, the second one usually overwrites the first one.

• Result: A “White Screen of Death” or a logical loop that eats 100% of your server’s RAM until the site crashes.

The Symptoms of a Silent War

How do you know if you have a conflict?

1. The “Spinning Wheel”: You click “Add to Cart,” and the little wheel just spins forever. This is usually a JavaScript conflict between two modules fighting for the browser’s attention.
2. The “500 Internal Server Error”: The site goes blank. This usually means two modules tried to modify the same database table simultaneously, and the server killed the process to save itself.
3. The “Ghost” Feature: You have a “Gift Wrap” module enabled, but the option never shows up. It’s being suppressed by another module that has higher priority in the hook list.

How We Play Referee

You shouldn’t have to choose between “Having Reviews” and “Having a Checkout.” You should be able to have both.

When we fix conflicts, we act as the referee:

1. Hook Positioning: Sometimes, it’s just about order. We go into the backend and tell PrestaShop: “Load the Checkout module FIRST, then load the Reviews module.” Simple, but effective.
2. Script Isolation: We rewrite the code so that Module A uses its own resources without touching Module B’s resources. We “sandbox” them so they stop fighting.
3. Override Merging: If two modules need to edit the same core file, we manually merge the code. We stitch them together so both features execute smoothly.

Stop Uninstalling Features

If your store is crashing, don’t just start deleting modules blindly. You are removing features that make you money.

The problem isn’t the module. It’s the traffic control.

Let us step in and direct the traffic so all your features run in harmony.

Download our [5-Point Profitability Audit] to detect hidden conflicts, or schedule a Code Review below.

? [Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

If you are still running PrestaShop 1.6 today, you are part of a unique club. You are the “Holdouts.”

We know why you stayed. When PrestaShop 1.7 launched, it was buggy and heavy. PrestaShop 1.6 was lightning fast, stable, and did exactly what you needed. So, you decided to skip the upgrade.

Fast forward to today. You are still on 1.6. Your store works. Orders are coming in.

But the world around you has changed.

The question isn’t “Can I stay on 1.6?” The answer is obviously yes—you are doing it right now. The real question is: “How long until the external world cuts me off?”

The “Island” Problem

PrestaShop 1.6 is no longer just “old”; it is an island. The bridge to the mainland has been destroyed.

While your internal code is fine, the external connections are snapping one by one.

1. The API Apocalypse: Your store relies on Payment Gateways (Stripe, PayPal) and Shipping Carriers (FedEx, UPS). These companies update their APIs annually. They are dropping support for the encryption standards used by 1.6.
   • The Risk: One day, you will wake up, and your checkout will fail because Stripe no longer accepts connections from your server’s outdated protocols.
2. The PHP Time Bomb: PrestaShop 1.6 runs best on PHP 5.6 or 7.1. These versions are ancient. Modern servers consider them a security liability.
   • The Risk: If your hosting provider forces an upgrade to PHP 8.0, your 1.6 store will instantly crash (White Screen of Death). It is incompatible.

How to Stay (Safely)

If you are determined to stay on 1.6—whether to maximize ROI or because a rebuild isn’t in the budget yet—you must adopt “The Bunker Strategy.”

You can no longer operate like a normal store. You must dig in and fortify.

1. Specialized “Vintage” Hosting

You cannot host a 1.6 store on GoDaddy or standard shared hosting anymore. They will force-update your server and break your site.

• The Strategy: We move 1.6 clients to isolated, “Hardened” environments. We run CloudLinux to artificially support old PHP versions safely. We freeze the server environment so the outside world can’t break it.

2. The “No New Modules” Rule

You cannot go to the PrestaShop Addons marketplace and click “Install.” New modules are built for version 8. They will not work for you.

• The Strategy: Your store is now “Custom Software.” If you need a new feature, you cannot buy it; we have to build it by hand. You must accept that innovation will be slower and more expensive.

3. The Security moat

Since there are no security updates for 1.6, your code is full of known holes.

• The Strategy: We place a heavy Web Application Firewall (WAF) in front of your bunker. Since we can’t fix the code inside, we make sure nobody malicious can get to the door.

The “Cash Cow” Mindset

Staying on PrestaShop 1.6 is a valid financial decision, but only if you treat it as a Cash Cow.

• Do stay on 1.6 if: Your goal is to maximize profit from your existing setup with minimal changes, extracting value before an eventual exit or rebuild.
• Do NOT stay on 1.6 if: You plan to aggressively scale, integrate with modern AI tools, or want to use the latest marketing apps. You will hit a technical wall immediately.

We Are The Mechanics for Your Vintage Ride

Most agencies will tell you to “Migrate or Die.”

We say: “If it makes money, keep it running.” But you need a mechanic who knows how to fix an engine that isn’t manufactured anymore.

We manage some of the highest-revenue PrestaShop 1.6 stores in North America. We keep them fast, secure, and profitable, despite their age.

Is your bunker secure, or is the roof leaking?

Download our [5-Point Profitability Audit] to test your legacy store’s viability, or schedule a Vintage Support Review below.

? [Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

We speak to business owners every week who are stuck on PrestaShop 1.6 or 1.7. They know they need to upgrade to PrestaShop 8. They know their current site is slow and outdated.

But they don’t move. Why?

They are terrified of Digital Amnesia.

They worry that upgrading means “starting over.” They imagine waking up on launch day to a brand-new website, but their 50,000 past orders, 10,000 customer accounts, and SEO rankings have vanished.

Let me be clear: Your data is your business. A website without data is just an empty shell.

At Marketing Media, we don’t treat migration as a “Software Update.” We treat it as a Brain Transplant. We move the intelligence of your business into a new body without losing a single memory.

The Myth: “Clean Install” Means Empty Database

Many owners assume that to get the benefits of PrestaShop 8 (speed, security), they have to delete their old database.

This is false.

We use a process called Data Mapping. We take your messy, 10-year-old database and map every single row to the modern structure of PrestaShop 8.

• Orders: We migrate not just the order, but the status history, the invoice PDFs, and the shipping tracking numbers.
• Customers: We migrate their addresses, their groups, and their purchase history.
• Passwords: This is the big one. We migrate the “Password Hashes” so your customers do not have to reset their passwords. They log into the new site using their old credentials, and it just works.

The Protocol: How We Prevent Data Loss

We never “upgrade” your live site. That is suicide. We build a Parallel Universe.

1. The Staging Construction

We build your new PrestaShop 8 store on a separate server. Your current store stays live, taking orders and making money. You can log into the new store, test it, and click around for weeks before the public ever sees it.

2. The “Delta” Migration

On launch day, we don’t re-copy the whole database (which takes hours). We perform a “Delta Migration.” We ask the software: “What changed in the last 24 hours?” It grabs only the new orders and new customers that registered while we were building, and injects them into the new site.

• Downtime: This reduces the “Maintenance Mode” window from 2 days to 30 minutes.

3. The 301 SEO Safety Net

Data isn’t just internal; it’s external. If you have a product page that ranks #1 on Google, we cannot lose that URL. We write 301 Redirect Rules for your entire catalog. If the URL structure changes even slightly, we tell Google: “The old page is now here.” You keep your traffic and your rankings.

The Real Risk is Staying Put

Here is the irony: You are afraid to move your data because you might lose it. But staying on an outdated version is the fastest way to lose it.

• Corruption: Old databases (MySQL 5.6) degrade over time.
• Theft: Unpatched security holes allow hackers to steal (or delete) that customer history you are trying to protect.

Move House without Losing Your Furniture

You have spent years building your customer list. You don’t have to leave it behind.

We have migrated stores with 2 million+ orders without losing a single line item.

Don’t let fear paralyze your growth.

Download our [5-Point Profitability Audit] to assess your migration readiness, or schedule a Migration Consultation below.

? [Schedule Your Strategy Call with Christian Fillion]

---

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

If you have a small catalog—say, 500 products—moving to PrestaShop is easy. You export a CSV, you import it, and you’re done.

But if you are a high-volume merchant with 50,000, 100,000, or 1 million SKUs, you have likely discovered a painful truth: Standard tools do not work for you.

We often receive calls from large distributors or parts suppliers who tried to migrate using a “Migration Module” or a standard CSV import. The result?

• The server timed out after 2,000 products.
• Images are missing.
• Attributes (Size/Color) are scrambled.
• The site is half-empty, and the admin panel is frozen.

Here is why “Big Data” breaks standard PrestaShop tools, and how we move mountains without dropping a single pebble.

The Physics of High-Volume Data

The problem isn’t PrestaShop itself (which can handle millions of products). The problem is the Pipeline.

1. The “Timeout” Wall

As we discussed in previous posts, web servers have a timeout limit (e.g., 60 seconds). A standard import script tries to process everything through the web browser.

• The Math: If it takes 1 second to process a product (upload image, resize, save to DB), you can do 60 products before the server kills the process.
• The Failure: To import 50,000 products at that speed would take 13 hours. No web server allows a script to run for 13 hours. It crashes immediately.

2. The “Attribute Explosion”

You might think you have 50,000 products. But if each product has 5 sizes and 5 colors, PrestaShop treats that as 1.25 Million Combinations. Standard migration tools often choke on this complexity. They create the “Main Product” but fail to generate the thousands of variations required for the “Add to Cart” button to actually work.

3. The Image Bandwidth Trap

Importing text is fast. Importing images is slow. If you have 50,000 products with 4 images each, that is 200,000 high-res images that need to be downloaded, resized (into 5 different formats), and saved.

• The Failure: This consumes massive CPU and bandwidth. Standard hosting limits will flag this as a “DDoS Attack” and block your IP mid-migration.

The Enterprise Solution: Direct Injection & Batching

We don’t use the “Import” button in the back office. For high-volume clients, we build a Custom ETL Pipeline (Extract, Transform, Load).

1. Bypassing the Browser (CLI): We run the migration via the Command Line Interface. This bypasses the web server’s timeout limits completely. We can run a script for 24 hours straight if needed, and it will never time out.
2. Smart Batching: We don’t try to shove 50,000 products through the door at once. Our scripts break the data into “Micro-Batches” of 100.
   • Process: Import 100 -> Verify -> Clear Memory -> Import next 100.
   • This keeps the server memory usage low and stable, preventing crashes.
3. The “Lazy” Image Loader: Instead of forcing the server to resize 200,000 images on Day 1 (which takes days), we import the links to the images.
   • We can configure a background worker to resize them slowly over the next week, OR use a dynamic image server that resizes them on-the-fly when a customer visits the page. The store goes live instantly, not next week.

Moving Mountains Requires Heavy Machinery

You cannot move a mountain with a shovel. You need an excavator.

If you are managing a massive catalog, stop fighting with the “Import CSV” button. It wasn’t built for you.

We specialize in high-volume migrations. We have moved catalogs with 2 million+ SKUs while keeping the site fast and stable.

Download our [5-Point Profitability Audit] to assess your data complexity, or schedule an Enterprise Migration Consultation below.

? [Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

It is a conversation we have to have with new clients far too often.

You come to us for a simple request: “I need to update my payment gateway” or “I want to change the color of the checkout button.”

We log into your server. We open the files. And we stop.

We have to call you back and say: “We can’t touch this. If we change one line of code, your entire store will collapse.”

You are shocked. “But the last developer said he fixed it!”

That is exactly the problem. The last developer didn’t fix it. He “hacked” it. And now, your business is trapped in a web of Spaghetti Code. You are effectively held hostage: you cannot update, you cannot scale, and you cannot secure your store without risking a total meltdown.

The Anatomy of a “Hack Job”

PrestaShop has a strict architecture. It is designed to be modular. If you want to change something, you use a Module or an Override.

But “Quick Fix” developers (often found on cheap freelance marketplaces) don’t follow the rules. They take shortcuts.

1. Hard-Coding Values: Instead of creating a setting in your back office for “Free Shipping over $50,” they write if price > 50 directly into the core code file.
   • The Trap: When you want to change it to $60 next year, you can’t find where the setting is. You are locked out of your own business rules.
2. Core Modifications: As we discussed in a previous post, they edit the original PrestaShop files directly.
   • The Trap: You can never update PrestaShop. If you do, the update wipes out their changes, and your site breaks. You are stuck on an insecure version of PrestaShop forever.
3. The “Frankenstein” Theme: Instead of using a proper CSS file for design, they paste style codes directly into the HTML of every single product description.
   • The Trap: If you want to change your font from Arial to Open Sans, you have to manually edit 5,000 product pages one by one.

The Hidden Cost of “Cheap” Development

You might have paid that freelancer $20/hour. It felt like a bargain.

But that “bargain” created Technical Debt.

Technical Debt is like financial debt. You borrowed time (“I need it fixed now“) against the future stability of your store. Now, the bill is due, and the interest rate is 100%.

• The “Discovery” Tax: Any professional developer you hire now will charge you double. Why? Because they have to spend 5 hours just reading the messy code to understand where the previous guy hid the logic.
• The Stability Tax: Your site is fragile. A simple server update that should take 10 minutes turns into a 3-day outage because the “Hack Job” code isn’t compatible with modern standards.

The Rescue Mission: Refactoring

How do we break the hostage situation? We don’t just add more code (that makes it worse). We perform Code Refactoring.

It is like untangling a ball of Christmas lights.

1. The Audit: We scan your files to find every instance where a core file was modified.
2. The Extraction: We take that hard-coded logic and move it into a proper Override File or a custom Module. We put the logic where it belongs.
3. The Clean Up: We restore the core PrestaShop files to their original, pristine state.

Once this is done, the “Do Not Touch” sign is gone. You can update your store. You can install security patches. You are free.

Stop Building on Rubble

If your current developer tells you “We can’t update PrestaShop because it will break the custom work,” that is a confession. They are admitting they broke the architecture.

Your store should be an asset, not a liability.

Let us untangle the mess so you can get back to business.

Download our [5-Point Profitability Audit] to detect spaghetti code, or schedule a Code Rescue Review below.

? [Schedule Your Strategy Call with Christian Fillion]

By Christian Fillion E-Commerce Strategist & Founder, Marketing Media

---

If you log into your PrestaShop back office, you might see a tempting module called “1-Click Upgrade.”

It sounds perfect. You click a button, a progress bar fills up, and suddenly your outdated store is transformed into a shiny, modern PrestaShop 8 machine. Free, easy, and fast.

Do not click that button.

We receive panic calls every month from owners who thought they could DIY their upgrade. They end up with a White Screen of Death, a broken checkout, or a database that has been partially overwritten.

The transition from PrestaShop 1.7 to PrestaShop 8 is not a simple “update” like updating an app on your iPhone. It is a major Platform Migration.

Here is why doing it yourself is a dangerous gamble.

1. The Theme Compatibility Crash

PrestaShop 8 uses a newer version of the underlying code framework (Symfony) and a different Smarty engine configuration than older 1.7 versions.

The DIY Result: You run the upgrade. The core software updates successfully. But your Theme was built for 1.7. It tries to call a function that no longer exists in 8.

• Result: Your homepage loads, but the layout is shattered. Images are missing, the menu is broken, and the “Add to Cart” button does nothing. You are now running a live store that cannot sell.

2. The PHP Version Mismatch

This is the technical killer.

• PrestaShop 1.7 runs on PHP 7.4.
• PrestaShop 8 requires PHP 8.0 or 8.1.

The DIY Result: You click upgrade. PrestaShop 8 installs. It immediately tries to run. But your Server is still set to PHP 7.4.

• Result: Critical Error 500. The site vanishes instantly.
• To fix this, you have to log into your hosting panel and change the PHP version. But wait—if you change it to PHP 8.1, your old modules (that haven’t been updated yet) will crash because they don’t support PHP 8.1. You are trapped in a loop where fixing one thing breaks another.

3. The Data Corruption Risk

The “1-Click” module attempts to modify your database structure while the site is live. If your internet connection flickers, or your server times out (because the process takes too long), the script stops halfway.

The DIY Result:

• Half your products have the new database structure.
• Half have the old structure.
• Result: Your database is corrupted. You cannot restore the backup because the backup script failed too. Your data is toast.

The Professional Approach: The “Sandbox” Method

When we upgrade a client from 1.7 to 8, we never touch the live server.

1. Clone to Sandbox: We copy your site to a separate development server.
2. Dry Run: We run the upgrade there. We watch it break. (It always breaks something).
3. Code Repair: We fix the theme, update the PHP code in your custom modules, and resolve the database conflicts.
4. Testing: We place test orders. We check mobile responsiveness.
5. Go Live: Only when the Sandbox is perfect do we swap it with the live site. Your customers experience zero downtime.

Is It “Easy”?

• If you are a developer: It is complex, but manageable.
• If you are a merchant: It is a minefield.

You are an expert at selling products, not debugging Symfony frameworks.

Don’t risk your revenue to save a consulting fee.

The cost of fixing a failed upgrade is always 3x higher than doing it right the first time.

Download our [5-Point Profitability Audit] to assess your upgrade complexity, or schedule a Migration Strategy Call below.

? [Schedule Your Strategy Call with Christian Fillion]