{"id":20491,"date":"2026-11-03T12:16:37","date_gmt":"2026-11-03T11:16:37","guid":{"rendered":"https:\/\/surver.nl\/kennisbank\/wordpress-debug-modus-inschakelen\/"},"modified":"2026-11-03T14:42:16","modified_gmt":"2026-11-03T13:42:16","slug":"enable-wordpress-debug-mode","status":"publish","type":"kennisbank","link":"https:\/\/surver.nl\/en\/kennisbank\/wordpress-debug-modus-inschakelen\/","title":{"rendered":"Enable WordPress Debug Mode"},"content":{"rendered":"<figure class=\"wp-block-image size-full\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"642\" src=\"https:\/\/surver.nl\/wp-content\/uploads\/2026\/11\/kennisbank-wordpress-debug-modus-inschakelen-v2.jpg\" alt=\"Enable WordPress Debug Mode\" class=\"wp-image-20490\" srcset=\"https:\/\/surver.nl\/wp-content\/uploads\/2026\/11\/kennisbank-wordpress-debug-modus-inschakelen-v2.jpg 1024w, https:\/\/surver.nl\/wp-content\/uploads\/2026\/11\/kennisbank-wordpress-debug-modus-inschakelen-v2-300x188.jpg 300w, https:\/\/surver.nl\/wp-content\/uploads\/2026\/11\/kennisbank-wordpress-debug-modus-inschakelen-v2-768x482.jpg 768w, https:\/\/surver.nl\/wp-content\/uploads\/2026\/11\/kennisbank-wordpress-debug-modus-inschakelen-v2-18x12.jpg 18w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">There's something wrong with your site, but WordPress won't tell you what it is. A page stays blank, a button doesn't work, or you just get a message saying a critical error has occurred. You can enable WordPress debug mode by going to <code>wp-config.php<\/code> the constants <code>WP_DEBUG<\/code> and <code>WP_DEBUG_LOG<\/code> on <code>true<\/code> to place and <code>WP_DEBUG_DISPLAY<\/code> on <code>false<\/code>, so that errors in <code>wp-content\/debug.log<\/code> appear instead of on your visitors' screens. Below, you'll learn how to do this safely, how to read the log file, and why you should turn it off again afterward.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wat-de-debug-modus-doet\">What Debug Mode Does<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Debug mode is a setting in WordPress that displays PHP errors, warnings, and deprecated function calls, including the file and line where the problem occurs. On a live site, it\u2019s turned off by default. This is intentional, because an error message can reveal file paths or database information that you don\u2019t want out in the open. If you turn it on, you won\u2019t have to guess which plugin is causing the problem anymore. You can see it right there. That\u2019s why, for me, this is the first step for almost any error without a clear message, from a <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/how-to-fix-the-wordpress-white-screen-of-death\/\">white screen of death<\/a> until the report is submitted <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/a-critical-error-has-occurred-on-this-site-resolve\/\">A critical error has occurred<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Three institutions are collaborating. <code>WP_DEBUG<\/code> Enable error reporting. <code>WP_DEBUG_LOG<\/code> determines whether those messages are sent to a log file, and <code>WP_DEBUG_DISPLAY<\/code> or whether they appear on the page itself. So, the correct combination on a live site is: debug on, logging on, and display off. That way, you get the information, and your visitor simply sees the site\u2014or, in the worst case, the same error as before. If you can still access the dashboard, be sure to also check <strong>Tools &gt; Site Diagnosis<\/strong>. Under the \"Info\" tab, you'll see the PHP version, the memory limit, and whether debugging is enabled\u2014I like to list that information next to the log. For a more comprehensive step-by-step guide on troubleshooting errors\u2014from database connection issues to an offline site\u2014please visit <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/troubleshooting-wordpress-errors\/\">Troubleshooting WordPress Errors<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zo-zet-je-de-debug-modus-aan\">Here's how to turn on debug mode<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">To enable debug mode, add three lines to <code>wp-config.php<\/code>, the configuration file in the root directory of your WordPress installation. A typo in this file will take your site offline, so take your time and save a copy first.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the File Manager in your hosting control panel or connect via SFTP, and navigate to your site's root directory.<\/li>\n\n<li>Download <code>wp-config.php<\/code> as a backup copy, and open the file in the editor.<\/li>\n\n<li>Check to see if there is already a line with <code>WP_DEBUG<\/code> state. Please adjust that, because defining the same constant twice will cause an error.<\/li>\n\n<li>Place these three lines above the comment line that says you should stop editing <code>define('WP_DEBUG', true);<\/code> <code>define('WP_DEBUG_LOG', true);<\/code> <code>define('WP_DEBUG_DISPLAY', false);<\/code><\/li>\n\n<li>Save the file and repeat the step that went wrong.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">From that point on, WordPress writes everything to <code>wp-content\/debug.log<\/code>. The file will only appear when there is actually something to report. If you're working on a test copy, then you may <code>WP_DEBUG_DISPLAY<\/code> You can count on that <code>true<\/code>. Then you'll see errors right on the screen as you're building, which saves you the trouble of searching for them. If you're working with SSH, you can do it without the editor. With <code>wp config set WP_DEBUG true --raw<\/code> WP-CLI will set the value for you, and you'll run that command for the other two as well. If you're not used to working with configuration files, read this first <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/wordpress-code-editing\/\">Editing WordPress Code<\/a>. There, I explain how to make those kinds of changes without breaking your site.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"het-logbestand-lezen\">Reading the log file<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">At <code>debug.log<\/code> Are you looking for lines with <code>PHP Fatal Error<\/code> around the time you saw the error, because those are the messages that actually crash a page. Open the file and scroll to the bottom; that's where the most recent lines are. Each line lists a time, the type of message, and the path to the file. You can usually tell the source right away from that path. If it says <code>wp-content\/plugins\/plugin-name\/<\/code> if so, then it's that plugin. Does it say <code>wp-content\/themes\/theme-name\/<\/code> If it's there, then it's part of your theme.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Don't panic if you see a log full of notifications. A <code>Notice<\/code> or <code>Deprecated<\/code> is a signal to the plugin developer that something is outdated, not an immediate error. Many sites have hundreds of them, and the site works just fine. A <code>Warning<\/code> It's worth noting, but it usually doesn't break the page. You'll find it in <code>debug.log<\/code> If nothing appears, check the server's error log as well. On our hosting service, PHP writes errors to a file <code>error_log<\/code> in the directory where the error occurs. There, you can also catch errors that occur before WordPress starts its own logging. If you want to see which requests came in around that time, you can find the access log in cPanel under <strong>Raw Access<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"veilig-werken-en-daarna-weer-uitzetten\">Work safely, then turn it off again<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Always turn off debug mode after you've finished your diagnosis, because the log file keeps growing and is stored by default in a location that anyone can access. Many people aren't aware of this. Anyone who knows the address <code>\/wp-content\/debug.log<\/code> If you type this after your domain, the file can simply be read on many servers, including paths and sometimes data from forms. You have two options. You can have the log written to a different location by setting <code>WP_DEBUG_LOG<\/code> specifying a path outside your public folder instead of <code>true<\/code>, or you can block the file with a line in <code>.htaccess<\/code>. Examples of such rules can be found in <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/wordpress-htaccess-file-explanation-and-common-rules\/\">The .htaccess File Explained<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When you're ready, press <code>WP_DEBUG<\/code> back to <code>false<\/code> or delete the lines, and also delete <code>debug.log<\/code>. If you want to dig deeper, there are two more switches. <code>SCRIPT_DEBUG<\/code> loads the unminified WordPress scripts, which is useful for troubleshooting JavaScript issues, and <code>SAVEQUERIES<\/code> logs every database query. The latter slows down your site, so it belongs on a <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/wordpress-staging-environment\/\">staging environment<\/a>. A plugin like Query Monitor makes this information easy to read and helps identify the causes of <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/causes-of-a-slow-wordpress-website\/\">a slow WordPress site<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What we offer at Surver with our shared hosting plans is everything you need for this. You get File Manager, SSH, and WP-CLI, and those <code>error_log<\/code>The server writes the -files itself. On our <a href=\"https:\/\/surver.nl\/en\/managed-hosting\/wordpress\/\">Managed WordPress Hosting<\/a> You make the diagnosis yourself. If you want someone else to keep track of updates and step in if things go wrong, check out <a href=\"https:\/\/surver.nl\/en\/services\/wordpress-maintenance-management\/\">WordPress maintenance<\/a>. If the error occurred immediately after an update, the recovery procedure is described in <a href=\"https:\/\/surver.nl\/en\/knowledge-base\/how-to-fix-a-failed-wordpress-update\/\">Site Down After an Update<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"veelgestelde-vragen\">Frequently Asked Questions<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why isn't a debug.log file being created?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Usually, it says <code>WP_DEBUG_LOG<\/code> not on <code>true<\/code>, is <code>WP_DEBUG<\/code> further on in the file, click it again <code>false<\/code> set, or the lines appear below the line where you need to stop editing. It's also possible that no error has occurred yet since you turned it on.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Does debug mode slow down my site?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Just a little bit, because every notification is written to disk. On a site with a lot of notifications, you'll definitely notice it. That's why you should only turn it on for diagnostic purposes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Can I enable debug mode without editing wp-config.php?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Yes, using WP-CLI via SSH or a plugin that sets the constants for you. However, a plugin won't work if you're seeing a white screen, because you won't be able to access the dashboard. On Surver shared hosting, SSH and WP-CLI are available in all plans.<\/p>","protected":false},"excerpt":{"rendered":"<p>Er is iets mis met je site, maar WordPress vertelt je niet wat. Een pagina blijft leeg, een knop doet niets of je krijgt alleen de melding dat er een kritieke fout is opgetreden. De WordPress debug-modus schakel je in door in wp-config.php de constanten WP_DEBUG en WP_DEBUG_LOG op true te zetten en WP_DEBUG_DISPLAY op [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":20490,"template":"","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}}},"kennisbank_categorieen":[62],"class_list":["post-20491","kennisbank","type-kennisbank","status-publish","has-post-thumbnail","hentry","kennisbank_categorieen-wordpress"],"acf":[],"_links":{"self":[{"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/kennisbank\/20491","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/kennisbank"}],"about":[{"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/types\/kennisbank"}],"author":[{"embeddable":true,"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/users\/2"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/media\/20490"}],"wp:attachment":[{"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/media?parent=20491"}],"wp:term":[{"taxonomy":"kennisbank_categorieen","embeddable":true,"href":"https:\/\/surver.nl\/en\/wp-json\/wp\/v2\/kennisbank_categorieen?post=20491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}