Woocommerce PDF Watermark

Hey, some random web developer here.

Have some (hopefully) useful fixes for your Woocommerce PDF Watermark plugin.

While doing tasks for my clients I came across some issues:

Environment: Nginx 1.22.1 / PHP 7.4.33 (FPM-FastCGI) / OpenSSL 3.0.2

——

Major issue: result PDF is an empty file, no issues in error_log.?

SOLUTION:

This was harder to track, as there are no references of an error in log or elsewhere.

End of a day, after debugging online server, I found one piece of code which silently died returning false on all requests:

/wp-content/plugins/woocommerce-pdf-watermark/includes/lib/fpdi/FpdiProtection.php on line 502:

  protected function arcfour( $key, $data) {
        return openssl_encrypt($data, 'RC4-40', $key, OPENSSL_RAW_DATA, '');
    }

You version of FpdiProtection.php is 2.0.0, while the actual 2.0.3 (https://github.com/Setasign/fpdi-protection/releases/tag/v2.0.3) has this ?bug? noted (https://github.com/Setasign/fpdi-protection/blob/master/src/FpdiProtection.php#L210):

OpenSSL with RC4 supported is required. In case you use OpenSSL 3 make sure that legacy providers are loaded (see https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers).

——

Minor issue: temporary files not removed, PHP warning in error_log.

PHP Warning:? unlink(…): No such file or directory in /wp-content/plugins/woocommerce-pdf-watermark/includes/class-wc-pdf-watermark.php on line 635

SOLUTION:

line 635:

public function cleanup_files() {
	if ( ! empty( $this->stamped_file ) ) {
		session_write_close();
		if (stristr( getenv( 'SERVER_SOFTWARE' ), 'nginx' )) fastcgi_finish_request();
		sleep(5); // lame, but some race conditions occur rarely
		array_map( 'unlink', $this->stamped_file );
		$this->stamped_file = [];
	}
} // End cleanup_files()

line 606:

// Set the stamped file so we can delete it via shutdown hook.
$this->stamped_file[] = realpath($new_file);

——

Hopefully you can check this and apply in future releases.

Thanks, have a nice day!

——

P.S. just a small note on X-Accel-Redirect / XSendfile:

• with Nginx, make sure fastcgi_ignore_headers is not blocking X-Accel-Redirect;
• to work correctly, the further rules processing should be stopped with ^~

location ^~ /wp-content/uploads/woocommerce_uploads {
	if ( $upstream_http_x_accel_redirect = "" ) {
        return 403;
    }
    internal;
}