js Conflict in admin panel – I guess it’s from the core WP installation

2 Views

A client’s site: causing serious js conflict or js loading disabilities, is under custody. Activating DEBUG, Deactivating all Plugins, and Activating Default theme “T13” found that, still the problem resides. The DEBUG is totally fine – no disabilities or mis-functionalities. It was in an Old WP version, I updated everything – so now it’s all UPDATED. (WP version 3.6.1 as on today)

Symptoms

Read More
  • Can’t add/edit any post/page content — isn’t loading the default editor, can’t even switch to the HTML mode, because tab’s not working
  • The sub menus are not opening on hover, suppose I want to go to the Widgets page, then I need to click on the Appearance link then to the Widgets link. Hover is not working there.
  • Tabs are not working – tried Skitter slide show in an instant, can’t configure it from back-end because it’s not functioning with its tabs.

The client’s site is an Online Newspaper site and have many news – the database size is huge. If I take the theme and install a new fresh WordPress then:

  • What would I do with the old database? How can I import all the posts etc. into the new installation of WordPress so that I get them nicely work with the new WP installation? — is simply a WordPress Import (Tools » Import) can solve the problem or can it cause much greater problems?

Otherwise,

  • How can I resolve the js conflict or js loading disabilities in wp-admin?
Post Views: 2

Related posts

2 comments

  1. Script debugging in WP

    The constant SCRIPT_DEBUG is used to switch between minified and not minified versions of JavaScript files. But there’s more.

    $file.js

    Check if you’re using CONCATENATE_SCRIPTS and COMPRESS_SCRIPTS as well. Both are only used by core admin per default, but I use it in my themes as well to check which bag of scripts I’m loading. So watch out for it, set it and see the following example.

    $extensionJS = (
    ( defined( 'COMPRESS_SCRIPTS' ) AND COMPRESS_SCRIPTS )
    AND ( defined( 'CONCATENATE_SCRIPTS' ) AND CONCATENATE_SCRIPTS )
    AND ! ( defined( 'SCRIPT_DEBUG' ) AND SCRIPT_DEBUG )
)
    ? '.min' : '';

    $file.css

    For completeness here’s the CSS example

    $extensionCSS = ( defined( 'COMPRESS_CSS' ) AND COMPRESS_CSS ) ? '.min' : '';

    You don’t need it…

    Anyway, since we got Google Chrome Dev Tools, it’s pretty pointless to switch between compressed and uncompressed versions – as long as you didn’t use some minification process like “uglify” that’s renaming your variables to shorten them – as GC got “Pretty Print”. See the following example from the “Sources” tab (hit script link in “Elements” tab to open your file there). Image made with LiceCap.

    Google Chrome Dev Tools: Pretty Print

  2. Thread Status: PARTIALLY SOLVED!

    Well, it’s a nice journey for me with kaiser, s1lv3r and Rarst through the debugging.

    First of all, I tried this thread with s1lv3r’s suggestion:

    • Cleared Cache
    • Cleared Cookies and all the offline data
    • Used Chrome’s incognito window

    But after all the necessary measurements I found two errors still resided (not in the front-end, but in the wp-admin end); used Developer Tools in Google Chrome — “Resources” tab (+ Console then) after kaiser’s suggestion:

    • Uncaught SyntaxError: Unexpected token ILLEGAL on load-scripts.php in line 3
    • Uncaught SyntaxError: Unexpected token var on load-scripts.php in line 10

    First day discussion was ended with no solution. At second day, we get back to the same state. That time met with Rarst. And with a
    nice suggestion from Rarst, I added script_debug to wp_config.php:

    define('SCRIPT_DEBUG', true );

    And I got access to the problematic zones where I couldn’t get enter. But Rarst reminded me:

    it’s not really “fixed”, it’s just that dev version of scripts and
    disabled concat works. hard to say, concat is messy and needs a lot of
    debug to understand what is going wrong

    Then I googled and found this thread helpful understanding the SCRIPT_DEBUG. In summary, as caseyctg said:

    PROBABLE SOLUTION – we are heading to…

    And for an easy solution we (the office staffs) came to a solution:
    We are going to install them a new WordPress with a new theme with a new hustle-free plugin-sets to their main domain: http://example.com. For our theme the old data-storing process won’t work, as we designed our WP Newspaper Framework with different methodology. So at the end we will reside the old database in peace with a sub domain like: http://archive.example.com with a link into the new site’s Archive template’s sidebar. We hope it won’t bother the readers.

Comments are closed.