Extension talk:Pdf Export

Jump to: navigation, search

About this board

archives of this page: archive 1, archive 2, archive 3

blank pdf when exporting pages with titles with spaces in them

1 (talkcontribs)

I found a bug in PdfExport: REL1_30 (2017-09-21T22:16:05) where the pages only export to pdf if the page name is one word. For example:


exports fine, but


exports an almost empty pdf.

The fix was to merely replace the underscores in the URL with spaces. To do this, I changed the following lines in PdfExport.php (in the extensions folder) from this:

       $nav_urls['pdfprint'] = array(
           'text' => $skintemplate->msg('pdf_print_link')->text(),
           'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".wfUrlencode("{$skintemplate->thispage}"))

to this:

       $nav_urls['pdfprint'] = array(
           'text' => $skintemplate->msg('pdf_print_link')->text(),
           'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".$page_name_with_spaces)

then run update.php

Reply to "blank pdf when exporting pages with titles with spaces in them" (talkcontribs)

I installed PdfExport and htmldoc. I can see the link on the panel menu to export a page, but I have a blank page as a result.

When I use the Pdf Export special page and try to export after selecting the pages I want, I have a blank page too.

Does someone have any idea please ?

Nischayn22 (talkcontribs)

The following worked for me. I commenting out the following line:

$bhtml = preg_replace('/width="(\d+)"/e', '"width=\"".($1> $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1)."\""', $bhtml);

In the file \wiki\extensions\PdfExport\converters\MPdfConverter.php

This post was hidden by Nischayn22 (history)
This post was hidden by Nischayn22 (history)
Reply to "Blank page when exporting"
MZipperer70 (talkcontribs)


Has anyone an Idea how to use a template as Header/Footer? Or is there a possibilty to use variables set with Extension:Variables in Header/Footer?

Thank you in advance for yopur ideas or solutions.


Reply to "Using Template as Header / Footer"

Extension:PdfExport not working with 1.28.0: Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php

5 (talkcontribs)

Extension:PdfExport not working with 1.28.0 Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php (talkcontribs)

Call to undefined method Article::preSaveTransform()  Backtrace: mediawiki 1.27

This post was hidden by (history) (talkcontribs)

please anybody have solution ? (talkcontribs)

Fatal error: Call to undefined method Article::preSaveTransform() in /home/toor/www/extensions/PdfExport/converters/PrincePdfConverter.php on line 114

Reply to "Extension:PdfExport not working with 1.28.0: Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php"
Mariana duarte100 (talkcontribs)

the first case(Extension:PdfExport) gives me the link print as formate PDF, but when i click on, gives me an error that export as format pdf- error, means doesnt find any convertion pdf and explain that i need to install PrinceXML, DomPdf o HTMLDoc. but i install DomPDF and Html doc and PrinceXML and doesnt work

and the second case with Extension:ElectronPdfService

gives me the link print PDF but when i click on , told me that the service doesnt find the page

Reply to "HELP PDF" (talkcontribs)

I've installed htmldoc as instructed, but I get the following message: Warning: require_once(/opt/bitnami/apps/mediawiki/htdocs/extensions/PdfExport/PdfExport.php): failed to open stream: No such file or directory in /opt/bitnami/apps/mediawiki/htdocs/LocalSettings.php on line 179.

If I go to my extensions folder, I only see a PdfHandler, but not Export. Pointing it to handler does nothing and I also created the PdfExport folder myself, but of course nothing occurs.

Reply to "Cant find the PDF Export Directory"

MW 1.26 PHP7 PrinceXML PdfExport 3.2.0 - ParseError / preg_replace

Lanthanis (talkcontribs)

Due to security issues the modifier /e of the method preg_replace is not supported in PHP7 anymore.

I use a Windows Server 2012 R2 with PrinceXML.

The error occures in the PrincePdfConverter.php and suggest to use the new method preg_replace_callback.

This is the old code:

// set upper limit for width
  $bhtml = preg_place('/width="(\d+)"/e', "width=\"".($1 > $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1). "\"", $bhtml);

I got a ParseError while changing the code to:

//set upper limit for width
  $bhtml = preg_replace_callback ('/width="\d+"/', 'replaceCallback', $bhtml);
  function replaceCallback() {
       return "width=\"".($1> $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1)."\"";

The $wgPdfExportMaxImageWidth variable is a global one. Does anyone know a bit PHP and can help me ?

PHP Manual - preg_replace

PHP Manual - preg_replace_callback

Reply to "MW 1.26 PHP7 PrinceXML PdfExport 3.2.0 - ParseError / preg_replace"

Unable to generate PDF when using the Toolbar on side

5 (talkcontribs)

I noticed a problem with thew ExportPdf extension, If I try to generate the page I'm viewing, ie: http://WIKI_SITE/w/index.php?title=Special:PdfPrint&page=My_Document_Page

It fails and generates a dummy PDF with nothing really in it. If I go to the Special page manually then in the 'Enter the title of the page you want to export to PDF' put the *actual* document title 'My Document Page' it works, is this a known issue? If so, is there any workarounds?

Thanks (talkcontribs)

This seems to be related to the underscore‒space equivalence/conversion in Mediawiki. A workaround that does the job in my case is to add, between the following two lines in extensions/PdfExport/PdfExport_body.php,

  if ($dopdf) {

(approx. line 111) the new line

    array_walk($pages, function(&$val, $key) {$val = strtr($val, '_', ' ');});

which converts underscores to spaces. This requires PHP ≥ 5.3 because of the anonymous function (a. k. a. closure) created by the function keyword, but it could easily be rewritten using create_function(). (talkcontribs)

I have a similar problem in our Wiki. (It's german btw) The spaces are not a big deal in our Wiki, but when I'm trying to export a PDF with umlauts (äöü) in the title, I get the same empty document as the thread opener. Do you have an idea how to fix this? (talkcontribs)

Today I found a solution for this. If you're using the MwLibPdfConverter.php you can add

setlocale(LC_CTYPE, "en_US.UTF-8");

at line 5. After this the PDF were created correctly.

Sorvis (talkcontribs)

I had the same issue with MwLibPdfConverter.php but the setlocale did not fix my issue.

Instead I modified it on line 45 to include this:

$page = strtr($page, '_', ' ');

Reply to "Unable to generate PDF when using the Toolbar on side"
Ralfk (talkcontribs)

After updating from MW 1.23 to 1.24 the extension stopped working (using the htmldoc converter) due to method userCanRead() not existing any more. In order to work under MW 1.24 I had to change file PdfExport/converters/HtmlDocPdfConverter.php from

if (is_null($title) || !$title->userCanRead()) {


if (is_null($title) || !$title->userCan('read')) { (talkcontribs)

In MW 1.19 in the file /usr/share/mediawiki/includes/Title.php the following method is available:

public function userCanRead() {         wfDeprecated( __METHOD__, '1.19' );         return $this->userCan( 'read' );     }

This can be used in later versions to allow such legacy extensions to work.

Reply to "MW 1.23 -> MW 1.24" (talkcontribs)

Using MW 1.24.1 with htmldoc it seems that the 'permissions' option is incorrectly set in the converter.

The code initially sets the permissions option to null, It then adds the permissions prefixing them with '--permissions' (e.g. '--permissions no-modify'). However, when it comes to execute the htmldoc process it uses "'--permissions '.$permissions". this produces a command-line containing (for example) '--permissions --permissions no-modify').

In our case we didn't set any permissions, but did set the paper size (which follows permissions) to A4. This failed and always produced a Letter sized PDF. Dumping the command-line out showed that the permissions option was still being used - e.g. '--permissions --size A4'. I assume that htmldoc barfed on this and ignored the A4 size option. So a default needed to be set.

I used the following patch to correct the problems:

--- HtmlDocPdfConverter.php.orig        2014-12-01 23:15:27.000000000 +0000
+++ HtmlDocPdfConverter.php     2015-03-03 14:21:21.455341787 +0000
@@ -43,9 +43,9 @@
                                $perms[] = 'no-annotate';
                        if( count( $perms ) == 0 ) {
-                               $options['permissions'] .= '--permissions all --encryption';
+                               $options['permissions'] = 'all --encryption';
                        } else {
-                               $options['permissions'] .= '--permissions ' . implode( ',', $perms ) . ' --encryption';
+                               $options['permissions'] = implode( ',', $perms ) . ' --encryption';

                       if( $options['owner_pass'] !=  ) {
@@ -54,6 +54,8 @@
                       if( $options['user_pass'] !=  ) {
                               $options['permissions'] .= ' --user-password ' . $options['user_pass'];
+               } else {
+                       $options['permissions'] = 'all';
       } (talkcontribs)

This has since been correcetd by initialising the said variable before the start of the if construct:

$options['permissions'] = '';

Reply to "Htmldoc - permissions incorrectly set"