Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter ferkanter

    (@ferkanter)

    Sure, thanks for looking into it! Yes, I did clear all caches (including the object cache) every time I deactivated the plugins before testing. I made sure to start fresh each time, so the issue was still there after clearing everything. Let me know if you need anything else to help track down the fix — happy to test whatever you come up with.

    Thread Starter ferkanter

    (@ferkanter)

    Hi Carrie,

    Thanks for checking!

    Regarding the hash: neither the file name nor the file URL contains a # character:

    Note that the file on the server does end in .pdf correctly. The issue only shows up in the filename suggested by the browser’s download/save dialog, which drops the “.pdf” at the end — so it looks like it’s happening when the plugin generates the Content-Disposition filename for the browser, not with the underlying file itself.

    Here’s what the debug log shows after a test purchase/download:

    2026-7-13 05:06:38 – Watermarking may not succeed, possibly having to do with a PDF version > 1.6.
    2026-7-13 05:06:38 – Unexpected white space on your PDF? The open-source parser (TCPDI) included with PDF Ink Lite did not understand your PDF page boundaries. Upgrade to PDF Ink for better PDF handling.
    2026-7-13 05:06:53 – Watermarking may not succeed, possibly having to do with a PDF version > 1.6.
    2026-7-13 05:06:53 – Unexpected white space on your PDF? The open-source parser (TCPDI) included with PDF Ink Lite did not understand your PDF page boundaries. Upgrade to PDF Ink for better PDF handling.

    Despite these warnings, the watermark itself does apply correctly (name/email show up fine on every page) — it’s specifically the file extension in the download filename that’s missing.

    Regarding other plugins interfering: I identified three plugins on my site that seemed most likely to touch URL/file handling — a WooCommerce permalink manager (Premmerce Permalink Manager for WooCommerce), and SiteGround’s Speed Optimizer and Security Optimizer (caching and firewall/WAF respectively). I deactivated each of these individually and re-tested a download each time. The issue persisted in all three cases — the downloaded file still lacks the .pdf extension.

    The remaining active plugins on my site (Contact Form 7, Printful Integration for WooCommerce, WooCommerce Stripe Gateway, WooCommerce Tax, WPCode Lite) have no plausible connection to file/URL handling — they deal with contact forms, physical product fulfillment, payments, and tax, respectively — so I don’t believe a full plugin-by-plugin deactivation would reveal anything different. Happy to do it anyway if you think it’s still worthwhile.

    Thanks for your help!

    • This reply was modified 1 week, 2 days ago by ferkanter.
    Thread Starter ferkanter

    (@ferkanter)

    Hi Carrie,

    Thanks for checking!

    Regarding the hash: neither the file name nor the file URL contains a # character:

    Note that the file on the server does end in .pdf correctly. The issue only shows up in the filename suggested by the browser’s download/save dialog, which drops the “.pdf” at the end — so it looks like it’s happening when the plugin generates the Content-Disposition filename for the browser, not with the underlying file itself.

    Regarding debug logging: I went through the full PDF Ink Lite settings page (under WooCommerce > Settings), and I don’t see any debug/logging option there — I’ve copied the entire settings page and there’s nothing related to debugging or a “Housekeeping” section. Could you point me to exactly where this setting should be? I also checked the Plugins page for a separate “Settings” link under PDF Ink Lite, but didn’t find anything different there either.

    Thanks for your help!

Viewing 3 replies - 1 through 3 (of 3 total)