I'm loading yui.js 3.3.0 version file from portlet but liferay its using 3.2.0 yui.js file,
so whenever i'm loading that page js errors are coming like
G_ENV._loaded[VERSION] is undefined - this error is coming in yui.js which is liferay using that is 3.2.0 version.
so its replacing value like G_ENV._loaded[3.2.0] and that will throw an error becoz we loaded 3.3.0 version from portlet.
I replaced yui.js 3.2.0 version file in portlet but It was throwing some other js errors.
How will it work same in 3.2.0 or Is there any way to update existing version of yui?
This is the code of yui.js in this line its throwing error
if (!G_ENV._loaded[VERSION][name]) {
missing.push(name);
} else {
used[name] = true; // probably css
}
Any help would be appricated, anyone has faced this kind of problem.
Thanks
Upgrading, changing, or overwriting the native YUI installation in Liferay is extremely difficult, because of two reasons. One, Liferay 6.0's UI framework (Alloy) runs on YUI 3.2.0. Two, the native portal template instantiates alloy ui onto the global YUI object (YUI.AUI), which is awful, as it makes the YUI framework tightly coupled to the horrifically implemented AUI. Your browser calls this AUI reference, on the YUI object, as the page is loading and after the window.onload event. If you try to replace or modify the global YUI object, it screws up Alloy, which Liferay's UI runs on.
Since upgrading is out of the question, the next best alternative is to bring in just the new YUI modules you want to use. Also, you could try out Liferay 6.1 CE, which has 3.4.1 built in, but it looks like its still in beta testing.
Here's an example of bringing in and using the dom-core module from YUI 3.4.1 and using it in Liferay 6, which runs on YUI 3.2.0. I got the idea from YUI's docs on how to bring YUI 2 modules into 3 (http://yuilibrary.com/yui/docs/yui/yui-loader-ext.html). To quickly figure out dependencies each module has, you can use YUI's online configurator http://yuilibrary.com/yui/configurator/.
var config = {
ignore : ["skin-sam-overlay","skin-sam-widget","skin-sam-widget-stack","skin-sam-tabview"],
groups: {
yui341: {
base: '/js/yui-3.4.1/build/',
modules: {
yui341_yui_base: {
path: 'yui-base/yui-base.js'
},
yui341_oop: {
path: 'oop/oop.js',
requires: ['yui341_yui_base']
},
yui341_features: {
path: 'features/features.js',
requires: ['yui341_yui_base']
},
yui341_dom_core: {
path: 'dom-core/dom-core.js',
requires: ['yui341_yui_base','yui341_oop','yui341_features']
}
}
}
}
};
YUI(config).use('yui341_dom_core',function(Y){
//YUI 3.4.1 config modules are now accessable through 'use' call
console.log(Y.version); //say hello to the newer version (3.4.1)
Y.use('dom-core',function(Y){
//Finally have access to native 3.4.1 module
console.log(Y.DOM);
});
});
Actually, the problem isn't because of Alloy being shoved onto the YUI object. That would be fairly trivial to work around by just simply doing:
YUI.AUI = AUI after loading the new YUI.
The problem is because of everywhere Alloy (and even YUI modules already loaded on the page) references YUI, it expects it to be a specific version of YUI.
In many cases, this isn't that big of a deal, as the API between YUI releases isn't that far off. However, between 3.2 and 3.3 there were some changes in Widget, as well as other general changes that could cause problems.
The issue is that YUI currently doesn't have an acceptable way to load multiple versions of the library onto the page that won't cause some sort of conflict.
(Because the YUI global get's overwritten, as well as it's properties, such as YUI.Env).
However, I have been kicking around an idea for one possible way to handle this, using dynamically generated iframes to load a separate YUI instance in a different window and pass it along to the original page).
If I can get that working, it's something that we will be backporting to all versions of Alloy, so that Liferay users can leverage it as well.
Josh, if you have any thoughts on a better way to handle this, I'd definitely be all ears.
Thanks,
Related
In my project, there is a custom third-party library (a single build file), which they have created using a couple of non-AMD and AMD files. And most of the properties are exposed directly to window objects. In our project as per the new requirement, we have to load this third-party library in asynchronous mode using requireJS. I tried with shim configuration but am getting an error from third party library saying that globals/window, globals/documents are needed.
How to resolve the above error in the current project without editing a third-party library? is it possible?
How to consume this third party libs properties in the project, since all properties are exposed directly to window Object.
This is the error we are encountering now
Could anyone please help me with this?
Thanks in Advance!
It looks like your 3rd party library is video.js. Video.js was (see below) creating two global objects global/window and global/document which seem to be used for testing video.js on the server where there is no window or document.
You can see their definition here and then the import. If you're willing to edit the file (and stop video.js tests from working server-side) then that's a simple solution.
You said you didn't want to edit the library though, so let's look for other solutions. You could just go ahead and define them like so:
define('global/window', [], () => {
return window;
});
define('global/document', ['global/window'], (window) => {
return window.document;
});
Then load video.js:
require(['video.7.5.0.min.js'], (videojs) => {
window.videojs = videojs;
// any other initialization you want here
});
Also it might be helpful to know which version of video.js you're using. It appears this might have been fixed in 7.11.1 (in this PR) so there's a good chance that just upgrading to that version or later makes the problem go away.
There's a lot more discussion on this problem in this issue, but it appears to be closed due to the previously mentioned PR.
I use SignalR 2.2.0 in a MVC5 project. SignalR depends of JQuery in client-side.
JQuery recently released new version, I updated it from Nuget, specifically from version 2.2.4 to 3.0.0.1, but then SignalR stopped working. Startup command "$.connection.hub" in javascript fails.
After a long time head scratching, I downgrade JQuery to 2.2.4 and everything is fine again.
Am I the only one getting this problem? There is any workaround?
Thanks.
You must edit the signalR code by yourself, In jquery 3 they removed the shortcut for load event :
Breaking change: .load(), .unload(), and .error() removed
These methods are shortcuts for event operations, but had several API
limitations. The event .load() method conflicted with the ajax .load()
method. The .error() method could not be used with window.onerror
because of the way the DOM method is defined. If you need to attach
events by these names, use the .on() method, e.g. change
$("img").load(fn) to $(img).on("load", fn).
https://jquery.com/upgrade-guide/3.0/
so in the file jquery.signalR-{version}.js :
you must update this line :
_pageWindow.load(function () { _pageLoaded = true; });
To :
_pageWindow.on("load",function () { _pageLoaded = true; });
Finally version 2.2.1 of SignalR was released, solving this problem. Thanks for all comments.
If you're still getting errors like this after updating to 2.2.1 and jQuery 3.x then read on...
TypeError: Cannot read property 'client' of undefined
Like I am you are probably using the dynamically generated proxy, and you checked your /signalr/hubs file and found you don't have any proxies defined.
var proxies = {};
Wait you may ask I didn't change anything - where did they go?
Well, like me you probably were in such a hurry to upgrade signalR to 2.2.1 that you forgot to do it in all your projects and now you are using both 2.2.1 and 2.2.0 in different assemblies. (I am defining my hubs in a different assembly than my main app).
All I needed to do was make sure I had the latest nuget package version in every project and it all worked. Should work fine after rebuilding. If not, this may also help.
Also do yourself a favor and read the jQuery 3 upgrade guide if you use much jQuery elsewhere.
I'm having a couple of issues with my upgrade from 4.1 to 4.4.7:
Existing custom addons no longer work. I'm getting a JavaScript error
on the following call in my init function, for example:
CKEDITOR.plugins.add( 'pdf',
{
lang: 'de,en,es,fr,fr-ca',
init : function( editor )
{
editor.addCommand( 'pdf', new CKEDITOR.dialogCommand( 'pdf' ) );
.
.
.
It no longer appears to recognize addCommand as a valid method.
After removing all plugins, I am able to get the editor to appear, however, my menus have disappeared.
Is there a clear upgrade path from 4.1 to the current version, or at least a list of deprecated methods? I haven't been able to locate it.
Thanks.
You should probably at least scan the changelog. Breaking changes are always explained there.
Do remember you are trying to incorporate over 2 years of active development into your customized editor. There were lots of new features introduced during this time, so your plugins may need some serious adjustments.
As for particular methods, just check the API. Information such as whether something is deprecated or examples how it should be implemented will be there (example: editor.addCommand).
As for building custom plugins, check the plugin tutorials for some working code and explanations. The source codes are available on GitHub.
Last but not least, remember to clear the browser cache after changing any JavaScript/CSS files. This usually solves most issues with toolbar/menus etc. disappearing after an upgrade or configuration change.
Installed CiviCRM in a fresh Drupal install, customized the CiviCRM and added data. The actual Drupal site was built separately in a separate install. Now that it is complete, I merged the CiviCRM with the new Drupal Site (files and database). Everything appears to work except when logged into CiviCRM: http://example.com/civicrm/dashboard it says:
"Javascript must be enabled in your browser in order to use the dashboard features."
And yes Javascript is enabled. The CiviCRM Menu is all broken and such. Chrome also reports the following errors:
Uncaught TypeError: Object # has no method 'menu'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
main.js:6Uncaught TypeError: Object # has no method 'cycle'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
Javascript compression under performance is not enabled. Any ideas?
CiviCRM uses the jQuery object as cj instead of $ in order to avoid conflicts with the Drupal JQuery library. In theory, they are fine using different versions because they are namespaced differently (which jQuery supports officially using noConflict()).
The conflict you have probably comes from your modifications causing either Drupal or CiviCRM to load its jQuery library at a different point in the bootstrap, or making it try to load jQuery more than once. This would make the operation to convert $ into cj pick up the Drupal jQuery object after it has already been instantiated, rather than before, leaving Drupal and/or CiviCRM without the libraries it needs being attached to the $ object (are you using # instead of $?).
Search for all code that uses noConflict() everywhere on the page in question and its JavaScript includes. You should only find it in one place. Compare with the demo.civicrm.org pages to see the difference and you'll probably find an extra one in there somewhere. Best hope for fixing it is to adjust the load order of your custom modules in the Drupal system table, or else set the second noConflict() call to run conditionally on there not being a cj object already.
I've completed a bug report. Applying this patch resolved the problem for me in a seemingly clean way. This way the jQuery library does not get loaded more than once if not necessary.
Up till now my system used dojo 1.3.2 successfully. I have many Javascript files with our own declared classes which are combined together using shrinksafe to a single Javascript file.
I tried to upgrade to dojo 1.4.x (I tried several minor versions). I used the build system with a layer file with all the dojo.require()'s I use (the same one I used to build the 1.3.2 version.). The build process seems to be successful.
Unfortunately, I cannot succeed in bringing the system on the air. Firebug throws exceptions such as ... is not a constructor for my declared classes, and mixin #0 is null.
Please help !
These error point to 2 things:
1) Make sure you have a full src build of dojo.
2) The signature of dojo.declare changed in 1.4:
previously you will probably have had the following declaration for a class with no inheritance:
dojo.declare("myNamespace.classA", [], {...
In 1.4 the empty array of inherited classes will break a custom build. You should upgrade your code to the new signature of dojo.declare:
dojo.declare("myNamespace.classA", null, {...