CodeCanyon WooCommerce PDF Catalog - WordPress Plugin

How to Set Up CodeCanyon WooCommerce PDF Catalog for a WooCommerce Product Catalog

CodeCanyon WooCommerce PDF Catalog is not meant to replace standard product descriptions on your site. It serves a different purpose: turning your WooCommerce store data into a PDF catalog that you can open, send to a client, print, attach to a sales proposal, or use as a working document for your sales team. In this guide, we will cover more than just installation. We will also look at the logic behind catalog selection: when to generate a full PDF, when to limit it to a category, how to prepare products, which elements to display, how to avoid creating an oversized file, and how to verify the result before making the button available to visitors.

This guide is written for store owners, content managers, webmasters, and developers helping a business build a PDF catalog from an already populated WooCommerce store. We will take a practical approach: first review the source data, then enable the necessary buttons, configure the layout, exclude unnecessary products, run a test export, and only after that decide whether to show the link to all visitors or keep generation as an internal tool.

The product's main strength is that it works directly with store data and offers extensive PDF settings: category and product layouts, cover page, table of contents, index, QR codes, shortcodes, exclusions, performance modes, custom styles, and filters. But that flexibility also creates risk: if you enable everything at once on a large store, PDF generation may slow down, images may fail to appear in the file, and the selected layout may turn out to be poor for printing. That is why this guide puts a strong emphasis on validation and troubleshooting.

This article does not include instructions for purchasing, activating a license, or bypassing limitations. It assumes you already have a valid plugin ZIP archive and a test copy of the site where you can safely verify PDF export without risking orders or your live product catalog.

What a PDF Catalog Solves in WooCommerce

A standard WooCommerce category page works well when the shopper is on the site, filtering products, adding items to the cart, and seeing current pricing right away. A PDF catalog serves a different need. It is useful when a client wants to save the assortment, share it with colleagues, open a file without constantly jumping through store pages, or use the catalog in offline sales discussions.

For a B2B store, this is often not a "nice printed brochure" but a working document. A sales manager can send a PDF for a specific category to a dealer, a procurement specialist can compare several items, and a retail location owner can print a product list for internal approval. CodeCanyon WooCommerce PDF Catalog pulls product data from WooCommerce and builds a file according to defined rules: which categories to include, which fields to show, which layout to use, and whether to include a cover page, table of contents, index, QR codes, and links back to product pages.

It is important to separate three different scenarios. A full catalog works best for a small or medium assortment where the file does not become too heavy and products are not duplicated across multiple categories. A category catalog is better for stores with a broad structure: furniture by room, spare parts by equipment type, machinery by series, consumables by purpose. A custom selection through the shortcode builder or a wishlist integration is useful when the client chooses categories or products to build a PDF of their own.

The plugin does not replace proper product pages, filters, search, checkout, or stock management. It complements the store with a document that can be read outside the site. That is why the best results come when you design the PDF catalog as a separate channel: which data belongs in it, which page format is comfortable to read, where links back to the site should appear, what to do with unavailable products, and how often the file should be updated.

Who This Plugin Fits, and When Another Approach Is Better

Before installing it, it helps to answer one question honestly: why does the store need a PDF at all? If you only need one static price list, it may be faster to assemble the document manually and upload it to a page. If you need a regularly updated catalog generated from WooCommerce, with images, prices, SKUs, categories, and product links, then CodeCanyon WooCommerce PDF Catalog becomes much more useful.

Good Use Cases for CodeCanyon WooCommerce PDF Catalog

The plugin is especially well suited to stores where the catalog is already maintained cleanly in WooCommerce and the PDF is needed as a derived document. That could be a wholesale store, a parts catalog, a packaging supplier, a furniture manufacturer, an equipment store, a dealer-facing product site, or any company where managers regularly send product selections to clients.

• The store wants to give visitors a button to export either the full catalog or a specific category.
• The sales team prepares PDFs for clients who do not always work directly on the website.
• WooCommerce categories are already structured, and products have images, SKUs, short descriptions, and attributes.
• You need to compare different PDF layouts quickly without building the catalog in a separate design program.
• The catalog benefits from a table of contents, index, QR codes, and links back to product pages.
• Different categories need different layouts or different data-display rules.

When the Product May Be Unnecessary

If the site has only a few products and you need the PDF once, installing a large tool may be excessive. The same is true for a store with tens of thousands of items where you expect instant full-catalog generation on every visitor click. The developer's documentation clearly shows that large catalogs require attention to memory, execution time, images, variations, and caching. For very large assortments, it is often more practical to generate category PDFs, prebuilt files, or a separate server-side generation process.

Practical rule: if the catalog is meant for sales and negotiations rather than instant download by every visitor, first set up an internal generation workflow. Only enable a public button after testing PDF speed and quality on a real product set.

Risks You Should Accept Up Front

PDF generation does not depend on the plugin alone. The result is shaped by image quality, HTTP/HTTPS file accessibility, PHP settings, hosting limits, category structure, number of variations, CSS support in the PDF engine, and price compatibility with other WooCommerce plugins. That does not make the product weak, but it does mean rollout should be careful: a test site, a few control categories, gradual feature enablement, and a clear rollback plan.

What to Check Before Installation and the First Export

Preparation matters more here than it may seem. The PDF catalog is assembled from WooCommerce data. If your products do not have short descriptions, images are too large, categories overlap, SKUs are messy, and variations are set up inconsistently, the PDF will be unpredictable as well. The plugin offers many settings, but it does not fix the underlying quality of your store catalog.

Review Product Data

Start with 10-20 products from different categories. Look at which fields a PDF reader actually needs: title, price, SKU, short description, key attributes, stock status, QR code, "Read More" link, categories, tags, gallery images, variations. There is no reason to enable every possible data point just because the plugin can output it. The more blocks you add, the greater the risk of a heavy file, page overflow, and visual clutter.

• Make sure products have a main image of acceptable quality.
• Trim long descriptions if they are not needed in a printed catalog.
• Check SKUs and attributes, because the index and filtering rely on that data.
• Mark categories that should be excluded: test, temporary, hidden, or discontinued/sold-out.
• For variable products, decide whether variations need to appear as separate rows or whether the main product is enough.

Check the Server and WooCommerce

Before installation, make sure WordPress, WooCommerce, your theme, and key plugins are updated within your site's normal safe update policy. For troubleshooting, WooCommerce > Status is especially useful: it shows server parameters, active plugins, the theme, outdated templates, and error logs. For PDF generation, the most important pieces are memory limit, PHP execution time, extensions for string and image handling, and whether images are reachable by URL.

If the store is protected with basic auth, only runs on localhost, or blocks images through server rules, the PDF engine may be unable to fetch them. In that case, the file may show an error or an empty block instead of images. The developer explicitly notes that the server must be able to access the images during PDF creation, and recommends using MPDF debug mode if image loading fails.

Safe Validation Order

1. Create a backup and test the plugin on a site copy.
2. Prepare one small category with 5-10 products.
3. Install the plugin and confirm that WooCommerce > PDF Catalog appears in the admin panel.
4. Enable only basic category export, without QR codes, galleries, or complex variations.
5. Generate a PDF and open it both in the browser and in a standalone PDF viewer.
6. Check images, page breaks, links, Cyrillic characters, and generation speed.

That order may feel slow, but it saves time. If you start by enabling the full catalog, all data, QR codes, galleries, and a complex layout, it will be much harder to identify the root cause when something breaks.

Installation, Activation, and the Initial Check

Installation works like any standard WordPress plugin from a ZIP archive. In the admin panel, open Plugins > Add New, choose Upload Plugin, upload the archive, install it, and activate the plugin. After activation, check the installed plugin list and confirm that the settings menu exists. In the weLaunch documentation, the settings path is listed as WooCommerce > PDF Catalog.

If the menu item does not appear, the developer's documentation separately mentions the weLaunch Framework Plugin. Do not try to fix this by editing files. First, check the list of active plugins, WordPress system notices, and WooCommerce > Status. If a dependency is not active or the site reports a fatal error, go back to a clean install on a test copy.

First Activation Without Overloading the Setup

In WooCommerce > PDF Catalog, start by reviewing the general settings. At this stage, the goal is not perfect design. The goal is to prove that the plugin can generate a file from a small category. Enable the plugin itself, save the settings, and reload the settings page if you enabled exclusions or additional parameter groups. Do not turn on every performance option, exclusion rule, and advanced layout before you have created your first file.

Minimum Test Set

• One category with a few products.
• One product layout without galleries or unnecessary attributes.
• Main product image, title, price, SKU, and short description.
• A category export button on the category page or a standalone shortcode on a test page.
• QR codes and the index disabled until the base file is stable.

After saving, open the category page in incognito mode or as a test user. If the button does not appear, check the export link display settings, link position, page cache, and theme behavior. If the button opens but the PDF is empty or shows an error, move to the troubleshooting section below.

Quick takeaway: a successful first test is not a beautiful catalog. A successful first test is a PDF that opens, contains the expected products, displays Cyrillic correctly, renders images, and does not break the category page.

Detailed Setup After Installation: From Buttons to the PDF Layout

The biggest mistake when configuring CodeCanyon WooCommerce PDF Catalog is to think of it as a single on/off switch for "make a PDF." In practice, it is a set of connected decisions: which products go into the selection, where the visitor sees the button, how categories look, how products look, which data is displayed, whether you need a cover page and table of contents, how heavy the file will become, and how the plugin will behave on a large catalog.

General Settings and the Product Selection Logic

In the general settings, confirm whether the plugin is enabled and which extra parameter groups are active. If you use WooCommerce filters on the category page, the Product Query Options settings include a mode that can help generate a PDF from the already filtered product set. That is useful when a client selects a color or another attribute and the PDF should reflect the current filtered view. But this mode should be tested separately, because theme filters or third-party plugin filters may not behave like standard WooCommerce queries.

Also review category and product sorting. The documentation describes different product sort options by date, name, title, SKU, price, and more. For a printed catalog, sorting by category and SKU is usually more useful than sorting by publish date. If the table of contents looks wrong, check the category order settings in the Query section and the category order in WooCommerce itself.

Export Buttons: Full Catalog, Category, Cart, Wishlist

The plugin can display export links on category pages and supports several PDF types: full catalog, category catalog, cart catalog, sale catalog, and, if you use the corresponding weLaunch product, wishlist PDF. Do not enable every button without a clear purpose. On a public site, one clear button on the category page is usually enough. For sales managers, a test or restricted page with shortcodes may be more practical.

If you need the button inside page content, use the documented shortcodes. For the full catalog:

[pdf_catalog category="full" text="Export Complete Product PDF Catalog"]

For a specific category, use the category ID instead of CATEGORY_ID:

[pdf_catalog category="CATEGORY_ID" text="Export Product Category as PDF"]

For a catalog without prices, the documentation includes the show_price="false" parameter. This is useful for a brochure where prices change often or are discussed individually:

[pdf_catalog category="CATEGORY_ID" text="No Price Catalog" show_price="false"]

If you want the user to choose categories, the documentation describes the builder shortcode:

[woocommerce_pdf_catalog_builder category_ids="" text="Create Catalog (PDF)" auto_select_subcategories="yes" columns="3"]

Do not place these shortcodes on a public page before load testing. A full catalog generated on every visitor click can be expensive for the server. For a large assortment, it is better to enable caching, prebuild the file, and limit public buttons to category PDFs.

Exclusions and Inclusions: What Should Stay Out of the PDF

The Exclusions & Inclusions section exists to remove products or categories that do not belong in the catalog. This is not only about hidden products. In a PDF, you often do not want temporary bundles, internal service products, items without photos, out-of-stock products, "Test" categories, seasonal sale pages, or products that are visible on the site but should not appear in a printed selection.

The documentation warns that enabling exclusions can affect performance and memory usage. So use exclusions deliberately. Do not turn them into a huge list of hundreds of individual products if you could instead improve your category structure or create a dedicated category for the catalog. One practical option is to create a service category such as "Do Not Show in PDF" and use that as the exclusion rule if it fits your product model.

Category and Product Layouts

The CodeCanyon product page mentions 5 category layouts and 6 product layouts, while the weLaunch website describes a broader set of templates and settings. In real-world setup, the exact layout count matters less than how the selected layout behaves with your data. A product with a short title, one image, and a price will look clean in almost any layout. A product with a long title, multiple attributes, variations, and a gallery can break a layout very quickly.

Test the layout using a series of control products:

1. A simple product with a short title.
2. A product with a long title and SKU.
3. A product without a price or with individually negotiated pricing, if you have those.
4. A variable product with several attributes.
5. A product with a large image gallery.
6. A product from a category with a long description.

Until all of those types look acceptable, do not treat the layout as finished. In the Products layout settings, pay attention to container height, image width, content width, spacing, margins, and template options. These are the controls that help prevent page overflow when descriptions or variation sets are longer than expected.

Which Data to Show in the PDF Product Card

The Data to Show section controls what appears in each PDF product card. The documentation lists many elements: Product Image, Gallery Images, Title, Price, Description, Short Description, Product Attributes, Read More Link, SKU, Categories, Stock Status, Tags, QR-Code, Barcode, Variations, and variation data. But a good catalog does not have to display everything.

After selecting your data, open the PDF on screen and print 1-2 pages. On screen, you may not notice that the text is too small, attributes run together, or images take up more space than they should. A print check quickly shows whether the catalog is truly usable in practice.

Cover Page, Table of Contents, Index, and QR Codes: When They Actually Help

CodeCanyon WooCommerce PDF Catalog includes features that turn a plain product list into a more usable document: a cover page, back cover, table of contents, index, headers and footers, QR codes, and additional text blocks. These elements are useful when the PDF is meant to be read as a catalog rather than used as a temporary export.

Cover Page and Back Cover

A cover page makes sense for a PDF that will be sent to a client or printed. In the Cover Page settings, you can choose an image and decide whether the cover should appear only in the full catalog or also between categories. The developer also notes that each WooCommerce category can have its own cover image. That is useful if categories function as separate brochures, such as "Lighting," "Cable Products," "Garden Equipment," or "Professional Cosmetics."

Do not use an overly heavy cover image. A full-page image may look attractive in the layout, but it increases file size and can slow down generation. For the first test, use a compressed image with a sensible aspect ratio, then check the PDF both on screen and in print.

Table of Contents and Index

A table of contents is useful when the catalog includes categories and subcategories. The documentation describes options for showing subcategory levels, links, page numbers, and table-of-contents placement. The index at the end of the file can list products by SKU or name with page numbers and links. In a 10-page catalog, the index may be unnecessary. In a catalog with dozens of pages, it becomes a navigation tool, especially if the client already knows the part number.

Do not validate the table of contents by appearance alone. Open the PDF, click several entries, and confirm that they jump to the correct pages. Then find a product from the index and compare the page number. If categories are not sorted the way they are on the site, return to Product Query Options and the category ordering settings.

QR Codes and Product Links

A QR code is helpful when the PDF is printed, shown at a trade show, or forwarded to a client who may later want to open the product page quickly. But QR codes take space and add generation time. For a large catalog with hundreds of products, they should only be enabled after load testing. If the PDF is mostly read on a computer, a "Read More" link may be enough because it takes up less visual space.

Result check: enable QR codes for a small category, generate the PDF, scan 2-3 codes with a phone, and make sure they open the correct product pages rather than a test domain or a locked site copy.

Shortcodes and PDF Catalog Builder for Real Working Scenarios

Shortcodes matter when the standard category button output is not enough. They let you build a separate "Download Catalog" page, a restricted page for managers, or a block on a landing page for a specific product line. The weLaunch documentation lists shortcodes for the full catalog, a single category, an email catalog, a sale catalog, a no-price version, and the category-selection builder form.

A Dedicated Page for Managers

For many stores, it is safer to start with an internal page available only to editors or sales managers. On that page, you can place several shortcodes: full catalog, key categories, no-price catalog, and the builder. A manager opens the page, chooses the needed option, and sends the PDF to the client. Meanwhile, a public visitor cannot accidentally trigger heavy full-catalog generation with a random click.

If your site uses user roles or restricted sections, configure access so the page is visible only to the right group. The plugin itself includes a Limit Access section for hiding PDFs from certain roles, but the general visibility of an internal service page is usually better controlled through standard WordPress permissions or a trusted membership/role plugin already in use on the site.

The Builder as a Controlled Category Selection Tool

The [woocommerce_pdf_catalog_builder ...] shortcode creates a category selection interface. By default, if category_ids is empty, all categories are shown. That may be convenient for a manager, but not always for a public visitor. If your catalog structure is large, it is better to limit the selection to the categories that matter or create several themed pages.

Test the builder with categories that contain subcategories. The auto_select_subcategories="yes" parameter can be helpful when a user selects a top-level section and expects to get everything inside it. But in a large store, that can dramatically increase PDF size. So first test one top-level section, then compare the PDF with and without automatic subcategory selection.

A Catalog Without Prices

The shortcode with show_price="false" is useful for materials where pricing depends on the customer, region, volume, or negotiation. That PDF can still include images, SKUs, specifications, QR codes, and links back to the site. In B2B, this is often a practical compromise: the client gets the assortment, while the manager keeps pricing flexibility.

After setup, make sure the price truly does not appear anywhere: not in the product card, not in variations, and not in extra blocks. If a third-party plugin outputs pricing through a nonstandard field, you may need to disable it separately in Data to Show or through custom CSS or a filter, if that is supported by your layout and confirmed by testing.

How to Build Your First Useful PDF Catalog: A Practical Example

Below is a concrete working scenario for a store with a B2B category called "Espresso Machine Parts." The goal is to prepare a PDF for sales managers: no unnecessary gallery, but with product photos, SKU, short description, price, product link, table of contents, and index. This example is easy to adapt to any category where customers choose by part number and specifications.

Goal

Generate a PDF for one category that can be sent to a client. The file should include the category products, a clear structure, core data, working site links, and a reasonable file size. A full-store catalog is not needed yet because it is heavier and less suitable for an initial test.

Preparation

• The category contains 10-30 real products with photos, SKUs, and short descriptions.
• Important attributes are filled in: compatibility, material, size, or another selection parameter.
• The plugin is installed and activated on a test copy of the site.
• The page cache has been temporarily cleared so the new export button can be seen.
• The administrator has access to WooCommerce > Status for error checks.

Configuration Steps

1. Open WooCommerce > PDF Catalog and enable the plugin in the general settings.
2. In Product Query Options, choose sorting by SKU or title if that makes sense for your category.
3. In PDF Export Buttons, enable category export and choose the button position on the category page.
4. In Exclusions & Inclusions, exclude internal service products and out-of-stock products if they should not appear in the client-facing PDF.
5. In default Settings, choose the page format and orientation. For product cards with photos, start with portrait orientation. For wide tables, start with landscape.
6. In the Category layout, enable the category title, short description, and category image only if they help explain the section.
7. In the Products layout, choose a layout where the image and text do not conflict. Check container height, image width, and spacing.
8. In Data to Show, enable Product Image, Title, Price, Short Description, SKU, Product Attributes, and Read More Link.
9. In Table of Contents, enable the TOC if subcategories are included in the PDF.
10. In Index, enable SKU or product title if the catalog is longer than a few pages.
11. Save the settings and generate the PDF from the category page.

Validation

Open the PDF and review it like a client would. The first page should make it clear what category the document covers. Products should appear in the expected order. Photos should render instead of showing empty placeholders. The SKU should be readable without zooming. Attributes should not stretch the card across multiple pages unless absolutely necessary. "Read More" links or QR codes should open the correct products on the live domain.

A Common Gotcha

If the PDF looks fine for a small category, that does not mean the full catalog will behave the same way. The full catalog includes more images, more HTML, more categories, more variations, and more chances to hit server limits. So after a successful category test, run a second test: either a category with 50-100 products or the heaviest section in the store. Only after that should you enable the full catalog, caching, and daily regeneration, if you actually need them.

Performance for Large Catalogs and Caching

PDF generation can be much heavier than rendering a normal WooCommerce page. The plugin has to fetch products, assemble HTML, process images, apply the layout, and hand everything off to the PDF engine. The more products, variations, galleries, QR codes, and categories you include, the higher the load. The weLaunch documentation has a separate section on large PDF catalog issues and recommends adjusting plugin settings before raising server limits.

What to Disable First

If the full catalog takes too long to generate or leads to a 500/504 error, do not start with drastic server changes. First, reduce the plugin's workload. Disable variations if they are not critical. Disable QR codes. Disable galleries or use smaller image sizes. Reduce the size of the main product and category images. Enable performance-oriented settings such as Use Images Locally, Enable Caching, and other modes from the Performance section, if they fit your server environment.

Use Images Locally should only be enabled when the images actually live on the same server and are available through a local path. If the site uses a CDN, external storage, or protected links, test a small category first. Enabling it incorrectly may not speed up PDF generation and can introduce a new failure mode instead.

Caching as a Way to Avoid Regenerating PDFs Every Time

Caching is especially important for a public full-catalog button. The timeout documentation explains the logic clearly: enable caching, generate the full catalog once, store the resulting file on the server, and avoid rebuilding it on every request. But the cache must be refreshed after products and categories change. Otherwise, the client will download an outdated file.

If products change daily on the site, define a process: who is responsible for refreshing the PDF, when the cache is cleared, who checks the file after the refresh, and how generation failures are detected. The documentation mentions daily cache regeneration through a Cronjob, but that also needs testing. If the server cannot handle it overnight, the next morning you will not have a fresh PDF, just an error in the logs.

When a Full Catalog Should Be Replaced with Category PDFs

If a single product belongs to multiple categories, the full catalog can contain duplicates or become much longer than expected. In support discussions, the developer explicitly recommended using a category catalog when the full file produced many duplicates because of overlapping categories. That is an important practical takeaway: sometimes "full catalog" sounds better, but category PDFs are clearer and faster in real use.

Best performance test: compare three files: one category, the heaviest section, and the full catalog. If the full file is unstable, do not try to hide that behind a nice button. It is better to offer categories or a prebuilt PDF.

Images, Fonts, Cyrillic Characters, and CSS in PDF Output

A PDF is not the same as a regular website page. Browsers tolerate a lot: complex CSS, scripts, responsive blocks, lazy loading, external resources. A PDF engine is stricter. The developer uses mPDF, and its CSS support is not equivalent to a modern browser. That is why appearance settings must be checked in the actual generated PDF, not only in HTML debug output.

If Images Do Not Display

A typical symptom is a red X, an empty space, or an error where an image should be. The weLaunch documentation explains several common causes: the site is running on a local server, images are blocked by .htaccess or .passwd, the server cannot fetch images over HTTP/HTTPS, CURL is disabled, allow_url_fopen is off, GD Library is missing, or there is an SSL certificate problem.

A safe validation flow looks like this: open the direct image URL in a private window without authentication. If the image does not open there, the PDF engine may not be able to fetch it either. Then enable MPDF Debug Mode in Advanced Settings on a test copy and check the exact image error. Do not manually edit the plugin or mPDF files unless you fully understand the consequences. It is better to fix image accessibility, certificates, CDN behavior, or local paths first.

If the PDF Shows Strange Characters

The documentation on strange symbols in PDFs points to the PHP extensions mbstring and gd. This is especially important for Russian-language catalogs: if the server handles multibyte strings poorly, the problem will usually surface faster than it would with English-only text. Check those extensions in your hosting panel or through hosting support. This article intentionally does not provide a one-size-fits-all server command because PHP is managed differently across hosting environments.

Custom CSS Without False Expectations

Advanced Settings includes a debug mode that shows the raw HTML before PDF generation. The developer recommends using it to inspect elements and then add CSS in the custom CSS field. That is the right approach for small refinements: spacing, variation-row background color, distance between products, and simple typography. But mPDF does not support all CSS, so advanced browser techniques may not work.

Below is a small example for a case where variation rows visually blend into the surrounding text. The basis is the official weLaunch article about changing the variation attributes row background. This CSS should be placed in the plugin's custom CSS field after checking the HTML through debug mode:

.woocommerce-pdf-catalog-variations .variation-head-row,
.woocommerce-pdf-catalog-variations .variation-head-row th {
  background-color: #f3f6fb;
  color: #1f2937;
  font-weight: bold;
}

After saving, generate a PDF for a product with variations and inspect only that part. If the style does not apply, do not make the CSS more complicated. Go back to debug mode, confirm that the classes are present in the HTML, and keep the limitation in mind: the PDF engine does not support every CSS property. The rollback is simple: remove this block from custom CSS and regenerate the PDF.

Adding Custom Data Through Filters

If the catalog needs to show an extra field, such as pack size, author, series, or ACF data, the developer documents filters for injecting HTML into the product information block. That is already a developer task, or something that should be handled carefully with Code Snippets on a test copy. Do not place PHP inside the plugin files.

The example below is adapted from the documented filter woocommerce_pdf_catalog_before_product_information_categories. It outputs the case_pack meta field if that field exists:

add_filter( 'woocommerce_pdf_catalog_before_product_information_categories', 'cb_pdf_catalog_case_pack', 10, 2 );

function cb_pdf_catalog_case_pack( $html, $product_id ) {
    $case_pack = get_post_meta( $product_id, 'case_pack', true );

    if ( empty( $case_pack ) ) {
        return $html;
    }

    return $html . '<p class="catalog-case-pack">Case Pack: ' . esc_html( $case_pack ) . '</p>';
}

Validation is mandatory: create a test product with the meta field, generate a PDF for a small category, and make sure the field appears in the right place without breaking the layout. If the PDF stops generating, disable the snippet and return to the standard settings. If you need to output variation data, do not copy this example mechanically. Variations have a different structure and must be tested separately.

SEO, PDF Indexing, and Safe Link Publishing

A PDF catalog can end up in search engine indexes if the file or the generation URL is publicly accessible. That is not always bad. In some cases, a company wants the catalog to be discoverable. But more often, dynamic PDFs with parameters, outdated prices, or duplicate products should not compete with store pages. weLaunch has separate articles explaining how to keep PDF exports and generation parameters out of search indexes.

Why a Dynamic PDF Should Not Compete with Product Pages

A WooCommerce product page is usually better for search: it updates faster, contains structured data, reviews, the cart, current stock, and proper navigation. A PDF is useful as a reading document, but it can become outdated. If a search engine starts ranking the PDF instead of the product page, the user lands in a file rather than in the store. That is why public PDF publishing needs careful rules.

For parameters like ?pdf-catalog=, the developer suggests exclusions via Google Search Console or robots.txt. Do not copy these rules blindly to a production site. First, inspect the actual URLs your plugin generates and make sure no other important pages use similar parameters.

A Practical Publishing Pattern

1. For clients, keep a category PDF link only where it genuinely helps product selection.
2. For the full catalog, use caching or a prebuilt file if the assortment is large.
3. Do not place multiple duplicate links to the same PDF on every page of the site.
4. Make sure the PDF includes links back to product pages if the reader should return to make a purchase.
5. If the PDF should not be indexed, configure restrictions for the relevant parameters or files and verify them after publishing.

After publishing, open the PDF as a regular visitor would. If the file is accessible, downloads correctly, does not require admin authentication, and contains working links, you can move on to broader testing: multiple browsers, a mobile device, and one external user or sales manager.

Combining It with Other Plugins and Standard WooCommerce Features

The plugin runs on top of WooCommerce, so the result depends on how other extensions modify pricing, attributes, user roles, wishlists, and product visibility. The developer lists support for several third-party solutions, including WPML, Yoast SEO, WooCommerce Wishlist, Wholesale Prices, and WooCommerce Group Attributes, but every combination still needs to be tested on the actual site.

WPML and a Multilingual Catalog

If the store is multilingual, the PDF should match the language of the page or the selected category. Check not only product titles, but also system strings: price labels, stock, SKU, read more, button labels, and table-of-contents text. Support comments for the product have included questions about translating system strings, and the developer recommended Loco Translate for some labels. On a production site, it is better to verify the standard translation flow through WPML and localization files first, and only use Loco Translate for strings that truly do not change.

Wishlist as a Customer-Driven Product Selection

If the customer should build their own product selection, a wishlist integration may be more practical than a massive category builder. The user adds products to a wishlist and then gets a PDF for that exact selection. On the business side, this works like a soft quote request: the client shows interest, and the manager receives a clear list of products.

Testing the integration is straightforward: create a test user, add products to the wishlist, enable the Wishlist PDF export link setting, generate the PDF, and compare the list. Pay special attention to variations, pricing, and hidden products. If the wishlist plugin stores data in a nonstandard way, do not assume compatibility without testing.

B2B Pricing and Discounts

In the filters documentation, weLaunch explains that pricing uses the standard WooCommerce function get_price_html. That is a good sign for compatibility with B2B or discount plugins that hook properly into WooCommerce price HTML. But if a pricing plugin renders the price only on the public page through JavaScript or a custom block, the PDF may not see it.

A practical test is simple: log in with a B2B role, generate a category PDF, and compare the price in the PDF with the price on the product page and in the cart. Then repeat the same test as a regular user. If the prices differ in unexpected ways, start by checking the B2B plugin settings and user roles rather than trying to fix the PDF with CSS.

Troubleshooting Common Issues

The best way to troubleshoot PDF catalog problems is by symptoms. Do not change ten settings at once. Build a small test PDF, enable parameters one by one, and note exactly when the error appears.

The PDF Takes Too Long to Generate or the Server Returns 500/504

Symptom: the full catalog hangs, takes several minutes to open, triggers a server error, or fails only on large categories. Possible causes include too many products, variations, galleries, QR codes, a heavy cover image, duplicates from multiple categories, or low PHP memory and execution time limits.

What to check: test a small category first, then a heavy category, then the full catalog. Disable variations, QR codes, and galleries; enable Enable Caching; reduce image sizes; and try Use Images Locally only if the images are on the same server. If the issue remains, check WooCommerce > Status, error logs, and hosting parameters.

When to roll back: if the public full-catalog button is unstable, disable it and keep category PDFs or a prebuilt file instead. Do not keep raising server limits indefinitely if the business need is better solved by smaller catalogs.

The PDF Shows a Red X or Empty Space Instead of Images

Symptom: product text is there, but images do not load. A common reason is that the PDF engine cannot fetch images by URL: the site is protected by authentication, the local domain is not reachable from the server, the CDN blocks requests, CURL or allow_url_fopen is disabled, GD Library is missing, or there is an SSL certificate problem.

What to check: open the direct image URL without logging into the admin panel. Then enable MPDF Debug Mode in Advanced Settings and inspect the image error. If the test domain is password-protected, temporarily remove the restriction for testing or use local image mode if it fits the server setup.

How to fix it: restore file accessibility, enable the required PHP extensions through hosting, check the certificate, and review server rules. Do not start by editing mPDF files. That is fragile and will be lost during updates.

Russian Text Turns Into Strange Characters

Symptom: the PDF opens as garbled technical text, shows strange characters, or renders Cyrillic incorrectly. The weLaunch documentation links a similar symptom to the PHP extensions mbstring and gd.

What to check: server-side PHP extensions, the selected font, whether product data contains Cyrillic, the site's encoding, and how the issue behaves on a small category. If the problem only appears on specific products, inspect text copied from outside documents and any unusual special characters.

How to fix it: enable the required extensions through hosting, choose a font that supports Cyrillic, remove broken characters from product data, and regenerate the PDF. If the problem persists, attach a small test catalog and the WooCommerce system report when contacting support.

The Layout Breaks on Variations, Galleries, or Long Descriptions

Symptom: the product card jumps to the next page, a large blank gap appears, variation rows collapse into each other, or a table becomes unreadable. The cause is usually a combination of the selected product layout, container height, amount of data, and CSS limitations in the PDF engine.

What to check: disable the gallery, then variations, then the long description. If the layout becomes normal, re-enable elements one by one. Review container height, image size, content width, padding, line height, and Limit Variations.

How to fix it: choose a different Products layout, reduce image size, limit variations, use the short description instead of the full description, and add careful CSS in custom CSS after inspecting the HTML through debug mode. If you need a radically different template, use documented filters or custom development rather than editing plugin files.

The Export Button Does Not Appear Where Expected

Symptom: there is no PDF button on the category page even though the plugin is enabled. Possible causes include the wrong button type being disabled, a different link position being selected, the shop page being built with a custom template, old page cache, role-based restrictions, or the theme hiding the button with CSS.

What to check: the PDF Export Buttons settings, Limit Access, page cache, a test in a default theme on a site copy, and a shortcode on a separate page. If the button does not appear on the main shop page, one of the developer's support comments suggests using a shortcode as a practical workaround.

How to fix it: enable the correct link type, change its position, clear cache, output the button via shortcode in a suitable location, or hide the default button and keep a controlled export page instead.

The PDF Gets Indexed or Appears in Search Instead of Product Pages

Symptom: a search engine shows the PDF or the generation URL instead of the product page. The cause is public links to a dynamic PDF and missing restrictions for generation parameters.

What to check: the actual PDF URLs, indexing settings, the presence of PDF links in menus and pages, and Search Console reports. If the PDF should not be indexed, configure exclusions for the relevant parameters or files and verify that product pages are unaffected.

How to fix it: remove unnecessary public links, block generation parameters from indexing, keep the PDF as a client-facing document, and preserve the main search value on product and category pages.

How to Validate the Final PDF Before Publishing

PDF validation should be a separate stage, not just a quick glance to see whether the file opens. Build a short control checklist and run through it before every layout change. This matters especially after updating WooCommerce, the theme, a B2B plugin, a translation plugin, or PDF Catalog itself.

Editor Checklist

• Only the intended categories and products appear in the PDF.
• No internal, test, or hidden items are included.
• Photos load correctly and do not look blurry.
• Cyrillic, currencies, and special characters display correctly.
• Pricing matches the user role and WooCommerce settings.
• SKUs, attributes, and variations do not break the layout.
• The table of contents, index, links, and QR codes go to the correct pages.
• The file is not too large to send to a client.
• The cache refreshes after product changes.
• The public button does not trigger heavy generation unnecessarily.

Developer Checklist

A developer should also review WooCommerce and PHP logs, compatibility with the current theme, outdated WooCommerce templates, behavior under a test role, behavior with page caching disabled, and the result after clearing the PDF cache. If you use filters or custom CSS, keep a list of those changes in the project documentation so that after updates you can quickly see exactly what is affecting the PDF.

Readiness criterion: if a manager can explain to a client why the PDF contains these exact products, these exact fields, and this exact order, the catalog is much more ready than a file where everything was simply "exported."

When CodeCanyon WooCommerce PDF Catalog Is the Right Choice

CodeCanyon WooCommerce PDF Catalog is worth using when you need more than a one-off PDF. It gives you a controlled process for generating catalogs from WooCommerce: a full file, category PDF, cart export, sale catalog, builder, no-price catalog, cover page, table of contents, index, QR codes, restrictions, performance settings, and technical extensibility through CSS or filters. It is especially valuable for B2B and wholesale workflows where the PDF helps sell outside the site while keeping the data tied to WooCommerce.

Before putting it into production, verify three things: product data quality, generation stability at real catalog volume, and whether the final file makes sense to the client. If those checks pass, you can download CodeCanyon WooCommerce PDF Catalog, install it on a test copy, and walk through the setup step by step using this guide.

If the store is small, start with a category PDF and a shortcode. If the store is large, do not promise users an instant full catalog without caching and load testing. If you need a custom design, use the built-in layouts, custom CSS, and documented filters, but keep the changes reversible. That way, the PDF catalog becomes more than a decorative add-on. It becomes a working tool: the client gets a clear file, the manager can prepare selections faster, and the site stays stable.