Lewis Rosenthal

Thanks, Yordan. Email sent, with reference to this thread.

Pastebin… Now why didn’t I think of that? LOL

https://pastebin.com/adNgYbTS

Thanks for following up.

No fatal-errors logs, but the error I first mentioned is listed in wpo-wcpdf* logs (that is the only error, and it is listed once for every attempt to generate a PDF).

I’m not sure how to attach a text file (the status report) here. I can paste into a code block, of course. Is that what you meant? Please advise.

If you’d still like the wpo-wcpdf log from yesterday, I can put that on our FTP server for you, but as I say, the only entries are the ones which match what I listed at the beginning of this thread.

Thanks, Yordan.

Indeed, we are using the default Simple template. I’m wondering if the process could be running OOM and we are simply not able to complete the generation (and giving up). I have 256MB set as the memory limit, and what seems like plenty of time per script (30 secs). I’m not seeing OOM reports in the php error log, though.

Thanks for the quick follow-up. I guess what I need to do is install it in my sandbox and try a few things. You have confirmed my suspicions, though. I had a hunch that this wasn’t going to be easy.

Cheers, and thanks again.

• This reply was modified 1 year, 10 months ago by Lewis Rosenthal.

Well, ordinarily, I’d say, no, it’s not logical for things to just stop working. However, there are a number of reasons that might happen.

A good place to start checking on the status and health of the PHP engine is with phpinfo():

https://php.net/manual/en/function.phpinfo.php

You should see that mbstring is enabled.

The Simple HTML DOM third-party component used in the extension merely calls mb_detect_encoding() which itself is a function provided by the mbstring PHP extension. So, what you are seeing is likely only a symptom of the problem, and not a problem within the plugin itself (if you were to run something else on the server, such as phpMyAdmin, you would probably receive the same error, as phpMyAdmin also requires mbstring to be enabled).

What probably happened is that something is either keeping the mbstring extension from being loaded (or found), has removed it from the list of extensions to load in php.ini, or the server is running out of resources somehow, making it impossible for mbstring to function.

Start your research on the basic error message reported:

Call to undefined function mb_detect_encoding()

There are lots of search engine hits for this issue. Check the php error log, assuming you have it enabled, and also the web server error log for some clues. In any event, this isn’t something we can address in the plugin code. We need the Simple HTML DOM parser component to dissect the elements on the page to hand off to the PDF engine. Simple HTML DOM has a dependency upon mbstring. If mbstring’s functions aren’t available, that’s what needs to get fixed.

Thanks for your kind words. I’m glad this plugin has worked well for you, as it has for many others. One of these days, I really want to get back to it, as it is long overdue for an udpate to the PDF class (at least), and some more code cleanup for newer versions of PHP.

The error you report seems to be a failure of PHP’s mb_detect_encoding(), rather than a particular defect in the simple HTML DOM component. What version of PHP is this? Is mbstring installed/enabled?

Without information from the PHP error log, I’m afraid the only help I can offer is to uninstall and reinstall the plugin and be sure to clear the cache. This is working for me under 4.8.1-en_US, and I’m afraid I don’t have a French version installed on anything to test more specifically.

Hi…

After changing to DéjàVu, did you clear the cache to be sure that you were getting a fresh PDF and not one which had already been created?

Hi…

Please check the font settings in the admin area, and be sure to use a unicode font, such as DéjàVu Sans. If that doesn’t work, I’m afraid I don’t have any other suggestions.

Hi…

No support at the present time, I’m afraid, though others have submitted snippets for inclusion. Search the posts here and see what comes up. It’s on the to-do list, but I have had a hard time finding the time to get back to this code.

Good luck

Lewis

Hi, Jack…

Please ensure that your logo does not have transparency (an alpha channel). If so, the TCPDF class will stubbornly refuse to render it.

I do need to update the version of the class used in WP Post to PDF Enhanced, I know, and I need to address some other outstanding things. Time has been in short supply. Still, unless there is something really odd with the logo image it should work. I have no confirmed incompatibilities with even WP 4.6.1 (I just have not updated the plugin to reflect that), so it should not be any sort of compatibility issue.

Check the image.

Cheers

Lewis

Hi, Rebecca…

Please read the FAQ and please select a font which supports Hebrew, such as one of the DeJa Vu fonts. Helvetica does not, and that is the default font. This is discussed in the FAQ.

Please report status of this after you have changed the font, and please provide a link to the site so that I may follow-up, if necessary.

Cheers

Hi, Saeed…

Fonts are selectable in the back end, including fonts which should be suitable for Persian (try one of the DejaVu variants). You may set these from the Typography section of the admin page.

The latest version of the plugin already supports RTL as an override to the default setting for the system. I haven’t tested it much, however. I take it that your site already defaults to RTL and yet the content is not rendered that way. You may force all PDFs to RTL with the following modification to the main class, right around line 326, which should be just above the comment:

// set header and footer fonts

Insert:

$pdf->setRTL(true);

Then, when you have a need to render specific content as LTR, wrap that with the shortcodes “wpptopdfenh_ltr” and “/wpptopdfenh_ltr” to override the RTL setting.

I’ll consider adding the RTL as a global setting if the system does not automatically do this (I really thought that it did, but it has been a very long time since I looked at that code).

HTH

Lewis

Please confirm that you are using version 1.1.1

TCPDF is not our code, we just use it to render PDFs. It is an entirely separate project, not under our (my) control. Offhand, I haven’t a clue as to how to address this conflict. Perhaps the author of LearnDash might have an idea.

As time permits, I can certainly look at LearnDash and see where we’re having difficulty, but time has been in short supply recently, so I can’t make any promises as to when I’ll have a chance to look.