Debugging

PDF Ink has its own debugging system to help get to the bottom of things when PDF stamping isn't going correctly. This might be due to plugin conflicts, PHP version issues, or a code bug - most times, we'll need to see the logs to find out!

If you are having troubles with PDF Ink (or maybe with a library), it’s very helpful to know what’s going on “under the hood.” There are two ways to get more information, especially if you are not getting descriptive error messages printed to your screen. Here’s two places to look:

  1. WordPress debug logs
  2. PDF Ink debug logs

PDF Ink Debug Logs

PDF Ink also has its own built-in logs which will log events more specific to the plugin. By default these are turned off. Turn them on by going to WordPress Menu -> PDF Ink -> Debugging. Click the “Enable Logging” checkbox and then in the multiple selection box below, choose the type(s) of events you want to log. If you are having any sort of issue with PDF Ink, all three types should be on.

PDF Ink debug log settings

Once PDF Ink logs are turned on and saved, return to the problematic action that was causing errors or undesirable results, and perform it again. Logs will be created, and can be viewed on the PDF Ink debugging screen — just scroll down past the settings to view them.

Logs provide detailed information which will be helpful during troubleshooting. Otherwise, we are often just scratching our heads and gazing into a crystal ball (and referring you to Troubleshooting).

When submitting a support request, go ahead and cut and paste the logs in an email to us!

WordPress Debug Logs

WordPress includes optional debugging which collects all warnings and errors created by themes, plugins, and WordPress core – in a little file called “debug.log.” This file is usually intimidating to new users, but shouldn’t be, because if it is read word-by-word, it can point a person right to the source of the problem. Especially if your site is experiencing “white screen of death” (WSOD), this file is the first place to go, because usually it will tell you the exact line on the exact file causing the problem, making it easy to track down and fix.

If your site is in development, it’s nice to have WordPress debugging turned on. We usually turn it off for production sites unless there is a problem, and only then turn it on temporarily. Read more about how to turn on WordPress debugging.

Turning Debugging on with wp-config

In the wp-config.php file, we use the following three lines so logs are saved to a log file and not displayed/printed to the screen. It’s prettier that way.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Once these three lines are saved in your wp-config.php file, perform the problematic action on your website again, and then view the logs.

Where are WordPress log files stored?

Logs will be stored in your WordPress /wp-content/ folder in a file called debug.log

What am I looking for in the logs?

You are specifically looking for the word “error”. If you are not a developer, you’ll probably want to ignore all the lines that start with “PHP warning”. These are just warnings and are 99% of the time are not actually breaking things. Perform a search through the log file for the word “error,” and you will have found the root of the issue you are experiencing.

Please try giving the log a read. Many people’s brains turn off when they see a debug log, but most often the error will give you solid clues about what needs to change. You might be able to fix it yourself — which is a great feeling!

We want to hear about errors, but if you want to tell us about warnings, too, that’s okay. We prioritize errors.

Turning Debugging on using a Plugin

If editing your wp-config.php file is something you can’t or won’t do, consider using the WP Debugging plugin to do it for you. Although for some people using this plugin can be even more confusing than just editing the wp-config.php file, the plugin is easy to install and turn on, and you should be able to find the debug logs in the WP dashboard after running the problematic action again.