markus-th Posted December 20, 2025 Posted December 20, 2025 Hi everyone, Like many of you, I have relied on the Pages2Pdf module in the past. It was a great tool, but unfortunately, it seems to be no longer actively maintained. With the shift to PHP 8 in most modern environments, the older version of the underlying mPDF library used in the original module has become a bottleneck, causing compatibility issues. Since I needed a working solution for a current project, I have already created a fork and updated the code to work with a newer, PHP 8 compatible version of mPDF. The Idea: Wire2Pdf I am planning to release this updated version as a new module under the name Wire2Pdf. This would distinguish it from the legacy module and allow for new features (like custom font support) without breaking older installations. What I have done in a fork so far: Code refactoring for PHP 8 compatibility. Updated the mPDF library to a recent supported version. -> https://github.com/markusthomas/Pages2Pdf Before I proceed... I wanted to check with you first: Is there still a strong interest in a maintained module based on mPDF, or have you moved to other solutions (like RockPdf)? Are there specific pain points you had with Pages2Pdf that I should address if I move forward with Wire2Pdf? If there is enough interest, I will polish the code, package it as a new module, and release it. Cheers! Markus 6 2
ukyo Posted December 20, 2025 Posted December 20, 2025 @markus-th You can check @maximus module https://github.com/mxmsmnv/WirePDF
markus-th Posted December 21, 2025 Author Posted December 21, 2025 10 hours ago, ukyo said: @markus-th You can check @maximus module https://github.com/mxmsmnv/WirePDF Thanks for sharing. I’ve actually looked into that repository. The main issue I see is that it uses the class name WirePDF, which causes a naming collision because the original Pages2Pdf module already defines/uses a WirePDF class internally. This makes migration difficult and would crash the site if both are present. My goal with Wire2Pdf is to use proper Namespaces (e.g. ProcessWire\Wire2Pdf) to ensure PHP 8 compatibility without risking these kinds of class name conflicts.
Klenkes Posted December 21, 2025 Posted December 21, 2025 23 hours ago, markus-th said: Is there still a strong interest in a maintained module based on mPDF, or have you moved to other solutions (like RockPdf)? Are there specific pain points you had with Pages2Pdf that I should address if I move forward with Wire2Pdf? I still have several projects that rely on it. Mostly on PHP 7.4 but one website uses Pages2Pdf 1.1.7 by @Wanze on PHP 8.4 just fine. Any pain points? Mhh... none that I can think of right now...
ukyo Posted December 21, 2025 Posted December 21, 2025 @markus-th @Klenkes If you're looking to update Pages2Pdf, I recommend creating a new module with the same name but extending WirePDF instead. It’s a much more efficient way to modernize the module without reinventing the wheel. <?php namespace ProcessWire; // Instead of a full rewrite, just extend the new module class Pages2Pdf extends WirePDF { public static function getModuleInfo() { return [ 'title' => 'Pages2Pdf extends WirePDF', 'version' => '1.0.0', 'requires' => 'WirePDF' ]; } } Tip: You can use WirePDF for all new projects. To support older projects without a full rewrite, simply create a Pages2Pdf wrapper that extends WirePDF. This way, you stay up to date with the latest PDF engine improvements while keeping your existing codebase intact.
markus-th Posted December 21, 2025 Author Posted December 21, 2025 5 hours ago, Klenkes said: Any pain points? Mhh... none that I can think of right now... Maybe I have a few little goodies that you might like 😉 Wire2PDF (first Alpha) What's new? Custom fonts You can upload and use own fonts Set PDF metadata (defined with variables or custom by a specific templatefield title, subject, keywords, author and creator Create PDF/A-1b for font embedding Now i have to test before it is ready to publish. 2
markus-th Posted December 21, 2025 Author Posted December 21, 2025 @ukyo Thanks for the suggestion! I considered that approach, but there is a significant technical blocker: Class Name Collision. The legacy Pages2Pdf module already defines a global class named WirePDF internally. The module you referenced also uses the global class WirePDF. If I were to build a wrapper or if a user tries to migrate from the old module to the new one, PHP would throw a Fatal Error: Cannot redeclare class WirePDF immediately if both files happen to be loaded (which can happen easily during uninstall/install processes or if site caches aren't perfectly cleared). My goal with Wire2Pdf is to cleanly separate the logic using Namespaces (e.g., ProcessWire\Wire2Pdf). This ensures: Zero conflicts: It can theoretically exist alongside the old module during migration/testing without crashing the site. Full Control: I can ensure the mPDF library is updated and configured specifically for ProcessWire's needs without depending on a third-party wrapper that relies on global class names. So, while extending would be "dryer", a fresh, namespaced module is the safer and more robust path forward.
ukyo Posted December 21, 2025 Posted December 21, 2025 I see :(, fork and update old module look like best solution for Pages2Pdf module users
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now