Bug #10835

permission issue with tcpdf-cache folder

Added by Moeinedin Shashaei 9 months ago. Updated 9 months ago.

Priority name:
Category name:
WordPress Plugins
Target version:
Start date:
Due date:
% Done:


Estimated time:



We have seen arbitrary errors from a post to PDF converter plugin that we use on multiple sites. Like what you get when you want to download this article​ from JADT:

How can we make sure that the pdf-cache directory permission is 755 throughout all the sites?

Thank you



#1 Updated by Boone Gorges 9 months ago

  • Category name changed from Directories to WordPress Plugins
  • Status changed from New to Resolved
  • Target version set to 1.14.3

Hi Moeinedin - This problem can indeed sometimes be caused by fileserver permissions. But in this case, it's not. A few months ago, based on some errors I was seeing in the logs, I implemented some changes in wp-post-to-pdf that ensured a writeable cache directory, by defining a proper value for K_PATH_CACHE etc:

diff --git a/wp-content/plugins/wp-post-to-pdf/tcpdf/config/tcpdf_config.php b/wp-con
index c295ed7c99..93cec75b26 100644
--- a/wp-content/plugins/wp-post-to-pdf/tcpdf/config/tcpdf_config.php
+++ b/wp-content/plugins/wp-post-to-pdf/tcpdf/config/tcpdf_config.php
@@ -90,15 +90,21 @@ if (!defined('K_TCPDF_EXTERNAL_CONFIG')) {
     define ('K_PATH_FONTS', K_PATH_MAIN.'fonts/');

+        $upload_dir = wp_upload_dir();
+        $cache_dir = $upload_dir['basedir'] . '/tcpdf-cache';
+        if ( ! file_exists( $cache_dir ) ) {
+                wp_mkdir_p( $cache_dir );
+        }
      * cache directory for temporary files (full path)
-    define ('K_PATH_CACHE', K_PATH_MAIN.'cache/');
+    define( 'K_PATH_CACHE', $cache_dir );

      * cache directory for temporary files (url path)
-    define ('K_PATH_URL_CACHE', K_PATH_URL.'cache/');
+    define( 'K_PATH_URL_CACHE', $upload_dir['baseurl'] );

      *images directory

In this case, the problem was that the image TCPDF was trying to pull in is located at http:// ... which the Commons redirects to the https:// equivalent. The version of TCPDF that ships with (the abandoned) wp-post-to-pdf doesn't follow redirects, and the library wasn't smart enough to fail gracefully. I've put in place a hotfix that forces cURL to follow redirects when fetching images

diff --git a/wp-content/plugins/wp-post-to-pdf/tcpdf/tcpdf.php b/wp-content/plugins/w
index 71f2963db4..4c9a92fe13 100644
--- a/wp-content/plugins/wp-post-to-pdf/tcpdf/tcpdf.php
+++ b/wp-content/plugins/wp-post-to-pdf/tcpdf/tcpdf.php
@@ -7899,6 +7899,7 @@ class TCPDF {
                     curl_setopt($cs, CURLOPT_SSL_VERIFYPEER, false);
                     curl_setopt($cs, CURLOPT_SSL_VERIFYHOST, false);
                     curl_setopt($cs, CURLOPT_USERAGENT, 'TCPDF');
+                    curl_setopt($cs, CURLOPT_FOLLOWLOCATION, true);
                     $imgdata = curl_exec($cs);
                     if ($imgdata !== FALSE) {

#2 Updated by Moeinedin Shashaei 9 months ago


Act of genius as always.
Does this fix the problem throughout the entire Commons or we need a new hotfix for every different redirection?

#3 Updated by Boone Gorges 9 months ago

Thanks for confirming!

Should fix it everywhere, at least where the problem is related to redirects. But please do let me know if more problems come up!

Also available in: Atom PDF