• Resolved Sabinou

    (@sabinou1)


    I notice there’s a HUGE number of people, here and on dozens of webmaster forums, who are currently adding define(‘SCRIPT_DEBUG’, true); to their wp-config.php file after they updated to wordpress 3.5.

    Of course a fix will come sooner or later, we can trust the wordpresss devs, but until them, seems many webmasters are eager to get a properly working editor again ??

    I wanted to ask, just in case, is there any potential problem with the addition of define(‘SCRIPT_DEBUG’, true); to our wp-config file ?

    I have read https://codex.www.ads-software.com/Debugging_in_WordPress carefully, and apparently, ‘SCRIPT_DEBUG’, true only comes as a first step before adding actual logging to file triggers.

    I come to ask a confirmation : this is it, I am not mistaken ? We can keep it to “true” on a production website with big traffic, there won’t be any after effects, or server performance issues ?

    Sorry to be paranoid, and thanks a lot if someone can respond ??

Viewing 10 replies - 1 through 10 (of 10 total)
  • Just in case, ask the question here too.

    Apologies, because it doesn’t answers your question and also takes this post out of the “unanswered” list here in the forums. But it’s a nice question and if you get an answer over there you can post it back here ??

    Hope it helps.

    “SCRIPT_DEBUG is a related constant that will force WordPress to use the “dev” versions of core CSS and Javascript files rather than the minified versions that are normally loaded. This is useful when you are testing modifications to any built-in .js or .css files. Default is false.”

    define(‘SCRIPT_DEBUG’, true);

    by adding this to your wp-config file, you are essentially just using the un-minified versions of javascripts and css. So it seems to me, the core of the problem is in fact within the css and javascript. BUT, if you add that line of code to your config file, you’ve just added extra file size to your scripts and css. The question then is how much extra file size does it add by adding that line of code? Not a huge issue for most, but when dealing with SEO, file size and load speed are a big deal, and adding un-minified scripting can make a large difference.

    My fix to the problem with WP-3.5 was to manually reinstall WP. I think there is something fishy with the auto-upgrade that is causing issues with the javascript and css. When I replaced my WP3.5 install manually, it solved my problems with the editor.

    BUt note, if you are doing a manual reinstall, make sure not to overwrite “wp-content” folder, and your wp-config.php files. That would really muck things up.

    You may want to use the chrome “pagespeed” plug-in and test whether adding that line affects your page loading time.

    Thread Starter Sabinou

    (@sabinou1)

    Haaa… I also learned that wordpress was kind enough to mimify its core scripts O_o

    Since speed matters, indeed, I guess I won’t be able to be just satisfied with the addition of debug true to my wp-config file, sigh.

    Thank you very much, Casey ! ??

    by adding this to your wp-config file, you are essentially just using the un-minified versions of javascripts and css. So it seems to me, the core of the problem is in fact within the css and javascript. BUT, if you add that line of code to your config file, you’ve just added extra file size to your scripts and css. The question then is how much extra file size does it add by adding that line of code? Not a huge issue for most, but when dealing with SEO, file size and load speed are a big deal, and adding un-minified scripting can make a large difference.

    SCRIPT_DEBUG only applies to the admin. It will not effect the load time or the “SEO” or your site. It will make your admin load slightly slower but you probably will not even notice it. It will also allow you to pinpoint what scripts are conflicted using the browser tools console.

    Of course a fix will come sooner or later, we can trust the wordpresss devs, but until them, seems many webmasters are eager to get a properly working editor again ??

    This is not a problem with WordPress. This is a problem with themes and plugins that use javascript on the post edit screen.

    Thread Starter Sabinou

    (@sabinou1)

    It’s even better now, if I know it only affects the admnin side ! Thank you Chris !

    However, when you write this isn’t a problem with WP, this is linked with themes and plugins, I regret to say I disagree. I have had this problem even with all plugins deactivated (through phpmyadmin), the browser cache emptied, and the blog configured to use TwentyTwelve.
    I don’t intend to fret too much on this since the problem is solved as far as I am concerned, but, well, this is how I experienced the bug preventing to add hyperlinks and the like.

    Thread Starter Sabinou

    (@sabinou1)

    Thanks for the info, Chris, it’s good to know it will only affect the admin, I am reassured !

    Now, regarding your statement that this is caused by either a plugin or a theme, I even had the problem with all plugins deactivated (through phpmadmin), the browser cache emptied, and the blog made to use the twenty twelve theme.
    So, I don’t think it’s caused by a third party software.
    That said, what would be left would have been a clean reinstallation (deleting the 3.4.2 folders, uploading instead their 3.5 version), something I didn’t do.

    great post caseyctg and Chris Olbekson- It is good to know it only affect the admin – It will be great if you can suggest how to use the browser tools console to pinpoint what scripts are conflicted.

    This may help with the browser tools troubleshooting:

    https://codex.www.ads-software.com/Using_Your_Browser_to_Diagnose_JavaScript_Errors

    That link helped me a great deal, @elkay. Thanks for posting it. I am also having problems with the minified scripts in the admin of a couple of our clients’ websites. I haven’t yet reinstalled WP, but the SCRIPT_DEBUG flag did help me.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘So, it isn't bad to keep SCRIPT_DEBUG', true in a "production" blog, right ?’ is closed to new replies.