[WIP/Proposal] Wire2Pdf – A PHP 8 compatible fork of Pages2Pdf

[Markus Thomas]

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:

1. Is there still a strong interest in a maintained module based on mPDF, or have you moved to other solutions (like RockPdf)?

2. 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

[ukyo]

@markus-th You can check @maximus module https://github.com/mxmsmnv/WirePDF

[Markus Thomas]

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]

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]

@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 Thomas]

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.

[Markus Thomas]

@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:

1. Zero conflicts: It can theoretically exist alongside the old module during migration/testing without crashing the site.
2. 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]

I see :(, fork and update old module look like best solution for Pages2Pdf module users