I try to debug a javascript function called from Generate Thumbnails plugin in Wordpress. The function uses jquery. So the actual call that I want to debug occurs in jquery.
The problem is that default jquery.js inside Wordpress is minimized and therefore obscure. I changed that file with the uncompressed version of jquery.js file in wp-includes\js\jquery.
But when I debug that function with Firebug's debugger, Firebug still shows me the old, minimized version of jquery:
I copied the location of the script file shown in Firebug and opened it in browser: http://localhost/wordpress/wp-admin/load-scripts.php?c=1&load=jquery,utils,jquery-ui-core,jquery-ui-widget&ver=368b0ffbc13bc55b5ae45ad40a5368d9
This time, the true, uncompressed version of jquery.js was opened.
It seems like Firebug opens the old version of jquery. I restarted the Firefox but it wasn't resolved.
What might be the reason of this problem? Is this Firebug related or Wordpress related?
I'd agree with the people who commented on your question - it seems like a browser cache problem.
If it's a test system, one thing I'd suggest is setting the WP_DEBUG constant to true in your wp-config. That'll download the uncompressed versions of the javascript libraries. That has two advantages:
You don't have to copy different javascript files around, and
The file names differ from the standard ones (they have .dev in them, from memory), so you shouldn't hit any caching issues.
I'm assuming there's an uncompressed version of jquery in WordPress. Apologies if there isn't; I haven't checked. But in general I'd recommend this approach.
See Debugging in WordPress in the codex for more information.
Related
I have a file that is dynamically loaded by sapui5 as a controller. I have altered my code so that I can leverage Typescript for Intellisense and fault detection.
My JS file is successfully created, and runs correctly in Chrome. The DevTools/Sources/Network window does not list my 'FinalAssembly.controller.js' file, nor does it list the similarly named 'FinalAssembly.controller.ts' file.
I have found that if I remove the '//# sourceMapURL=' line from the bottom of my file, Chrome will eventually list my JS file.
I had read that use of the '//# sourceURL=' line at the top of my file would cause my file to be listed, but it wasn't, further, I read that use of this directive should allow me to vary the name that is displayed in the Sources list, it doesn't. It appears that Chrome is ignoring this directive.
As of today, Chrome indicates that it is up to date at version 66. I have read lots of articles and Github issues over the last 4 hours that indicate that Source Maps tend to be problematic and can fail in some versions of Chrome.
The map file itself works in Internet Explorer, but I can't really see myself developing with that.
Has anybody debugged JS with a Source Map in Chrome 66? Can anybody suggest how I can debug my map file usage in Chrome?
I have placed a very simple test created via VSCode (tsc.exe) at my website: http://www.ia.uk.com/TypescriptTest/default.htm - on my Chrome 66 this one doesn't seem to download the map file at all (Fiddler didn't see any request for that). Doesn't show any TS view of the code. This is not a dynamically loaded library as per my original problem, but does show that there is a problem.
It turns out that DevTools has it's own set of settings. The preferences tab has a "Enable Javascript Source Maps", which was switched off in my copy. I don't recall ever being in that screen, but obviously this box got unchecked.
For normal JS files as in my small example, both JS and TS files are displayed. When the file is dynamic, only the TS file is displayed. This means that if maps are disabled, you get nothing (because the JS file isn't displayed).
Just open devTools and reset the browser.
Make sure your Angular app is up.
If your Angular app is not up, then you can't see the .ts file in Chrome. So you need to first run the Angular app.
I'm using NetBeans for PHP.
When I edit a .js file, it gives me javascript code completion.
How can I get it to also give me jQuery code completion?
First go to Tools -> Options -> Miscellaneous and click on the Javascript tab,
make sure the targeted browsers are configured properly, code completion changes by the minimal version of the targeted browsers to make sure that the functionality is supported.
You also need to add the jquery js file to your project so netbeans would be able to parse it and to properly add code completion.
These answers are misleading because jQuery no longer self-documents using "scriptdoc." Version 1.1.4 was the last to have this. Anything newer than that (>=1.2 ~mid-2007) is gutted.
amending that: VSdocs actually work:
http://code.jquery.com/jquery-1.4.1-vsdoc.js
or http://www.asp.net/ajaxlibrary/cdn.ashx for version after 1.4.1
i suspect using a non-minified version of jquery would help.
For Netbeans 6.7 / 6.8 / 6.9, just follow the guide here:
Using jQuery to Enhance the Appearance and Usability of a Web Page
There's a section about half way down called "NetBeans Code Completion and API Support".
Worked no problem for me.
Note: "Choose the uncompressed version, i.e., 'Development', before downloading the jQuery library. Using the uncompressed version will allow you to examine the JavaScript code in the editor, and aid in any debugging processes."
Tip: Tools / Options / Miscellaneous / JavaScript. In the "Targeted Browsers" section, ensure IE is "6 or later". Otherwise, you'll get "Not supported" errors in the code completion pop-up and a lot of the commands will be struck out.
I use netbians 7.x for development on drupal 6.x. Autocomplete works after adding non-minified version jquery-1.2.6.js file to the root folder of the project (so it will be with any version).
It is important to specify the version of the file name, without -1.2.6 will not work!
The basic rule is that your jQuery (or for that matter any js lib) should be found in the same project you need auto complete to work. So just place jquery-1.x.y.js somewhere in your project (that can be reached by NetBeans as it reaches your js file) and you should be good to go.
To test you can put the jQuery file in the same folder as your js file being edited.
Make sure your Internet connection is working, because NetBeans downloads documentation when is needed. I think that NetBeans downloads it from there, but this is only my assumption. This is parsing friendly XML document with whole and recent jQuery documentation.
I have an application running that is using the YUI js framwork (v3.0). The user can click a button within my app which will upgrade them to the latest version of the framework (3.4). The problem is that on ie8 I'm getting some strange javascript errors. After debugging it seems that an old version (3.0) of the loader-min.js file is retrieved from the browser cache as it still being used by the YUI object when it's instantiated. So during my upgrade I create a script node, add the location to the new loader file (3.4), and then insert it into the head section. Think we're all familiar with this technique. However, when the user navigates to the next page, the file that is loaded is lost and the old version (3.0) still remains in the cache. Have verified this by using developer tools and looking at all the javascript files the app has loaded.
I've tried lots of different things to get the new version (3.4) I'm loading to override the version currently in cache, which will fix the javascript issues. I've tried adding a unique string to the end of the file name that is being loaded which is typically how js files can be 'versioned'. I've made sure the Etag and Cache-Control headers for the new version I'm trying to load have been set. Nothing works and I'm banging my head against the wall.
One small restriction, I have to use javascript to try and load this new version of the loader-min file. I cannot add a simple script tag to my html because of how the upgrade process works. Any thoughts, ideas, pointers as to why IE8 will not cache the version I am loading dynamically?
Caching problems like this are normally solved by giving the new version of the script a different filename (often containing the version number) and changing the HTML that includes it to reference the new filename so that it can never be confused with the old version by a caching system.
In fact, this version system should probably be used on all external script files so when you upgrade them, you can make sure that viewers get the new version immediately and old/new versions of the scripts are never accidentally mixed by a caching system.
Jquery.com provide 2 version of jquery library. I always use Minified version because i never edit anything in jquery base file. but what is the use and purpose of another Uncompressed Code version? Does people edit main library file to get something?
If yes then if we edit anything in main file then we can't use google ajax library link.
Production (19KB, Minified and Gzipped)
Development (120KB, Uncompressed Code)
If you're using the minified version during development, browsers will tell you there's an error on line X, but line X might consist of hundreds or even thousands of lines of uncompressed code. This makes it very, very difficult to figure out what exactly caused the problem.
Developing against uncompressed code thus allows you to see what's causing problems and fix. Minified jQuery should always be used in production, and the core functionality of jQuery shouldn't be tweaked - that's what plugins are for.
edit 5/2014: Source maps have been implemented in many browsers to allow debugging of minified code. https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
It just makes it much easier to read the source code of jQuery, especially during debugging to see what is happening with a problem in your application.
It's for Debugging (although I would argue that if you're using jQuery, you should be looking through the source to understand it).
In ASP.NET at least, when using the ScriptManager control, you can assign one script to use in Debug mode and another to use in Release mode, so using the uncompressed version in debug allows you to step through the source and figure out if an issue you're having is coming from there, but when you finally build the release, you'll use the minified and gzipped version.
I have been using jQuery IntelliSense in VS2008 and it has been great. Recently I added a reference to jQuery UI and since then, the jQuery IntelliSense has went away. I found that once you reference another .js file in your document, the IntelliSense goes away. Any way to avoid this?
If there are errors in any refernced files it will break intellisense for all files references from the same document. The next version of Visual Studio is going to be much more robust in this respect. I apologize directly for this fragility. We made some design decisions early on that we prevented us from making VS9 external references more robust.
In the meantime, use the following workaround. Install SP1 from the link Slace gave you. If you have a reference a file named .js and there is a file named -vsdoc.js in the same location, then JS intellisense will pick up the -vsdoc version. If that script is empty then it won't generate an error. Identify the jquery plugin that is causing intellisense generation to fail and place a -vsdoc version next to it. You won't get intellisense for UI, but you will still get jquery and other plugins that do work.
Anything you put in the vsdoc version will show up in intellisense. You could put spoofed versions of the data structures that you want to display in intellisense if you want to.
It's likely that there's a bug in one of the subsiquiently referenced JavaScript files. Open your JS file and once the "Updaing JavaScript Intellisense" has gone from the status bar of Visual Studio (there is a menu option which will force the JS intellisense to refresh, don't remember where it is, I just created a keyboard shortcut via the Tools -> Options -> Keyboard area) open up your Errors window and under the Warnings you should find the reason why the intellisense has failed to load.
It's generally a bug found when parsing one of the files but I have had stack overflows when I had a lot of files referenced.
Edit: You also should make sure you have this VS patch installed: http://code.msdn.microsoft.com/KB958502 and VS 2008 SP1 (install SP1 first!). Then you just need to have:
/// <reference path="/path/to/jquery-1.3.1.js" />
Ensure that you maintain the -vsdocs on the intellisense file and it will be automatically picked up (as long as it's in the same folder as the file you reference)
The accepted answer helped me fix this issue but didn't resolve the problem. I installed the hotfix: http://code.msdn.microsoft.com/KB958502 but was still receiving an error.
Error:
Error updating JScript IntelliSense: D:\Dev\Test\Scripts\jQuery-1.3.2-vsdoc.js: 'jQuery.support.htmlSerialize' is null or not an object # 1430:4
It appears the addition of the follwing file without the appropriate -vsdoc.js file causes the above issue.
<script src="../../Scripts/jquery-ui-1.7.custom.min.js" type="text/javascript"></script>
I added an empty file "jquery-ui-1.7.custom.min-vsdoc.js" to my scripts folder and the Jscript Intellisense issue went away.
I'd like to present a slightly better solution. A few months ago I tackled this problem and created a very basic vsdoc file for jQuery UI. Here's the link to the blog post (which has the file for download).
I solved this per the advice above with a minor extension: the trick for me was to add a reference on my page to both my jqueryui.com library AND to the blank -vsdoc.js version of the file I created:
<script type="text/javascript" src="../../Scripts/jquery-ui-1.7.2.custom.min.js"></script>
<script type="text/javascript" src="../../Scripts/jquery-ui-1.7.2.custom.min-vsdoc.js"></script>
Hope this helps!
Great, the tweak is by creating an empty *-vsdoc.js file for each troublesome *.js files.
I found this error caused by anonymous function e.g. like this:
(function($) {
$.anything...;
})(jQuery);
Hope this caused will help somebody creating the http://code.msdn.microsoft.com/KB958502 and JScript IntelliSense Team.