We Keep Coding

How can I make the Topbar extension work with the newest MediaWiki?

I run a MediaWiki site which uses the Topbar extension. I recently upgraded the installation to the bleeding edge version from MediaWiki's master branch: version 1.28.0-alpha (91e56cc).
Afterwards, the Topbar extension no longer works:
Usually, the topbar div is not inserted at all.
Occasionally, the topbar div appears but the links are nonfunctional.
The latter issue may be a problem with my CSS (I do not know), but the intermittent behavior concerns me. So the first order of business is to make sure the topbar div at least appears every time.
This extension is just a small javascript that is supposed to run when the page loads, to add a chunk of HTML near the top (<div id="mw-writh-topbar" ...>). It does so using a jQuery function.
Unfortunately, I am not really a web developer, so even this simple routine is a bit over my head.
Here's what I do know:
There are no 500 server errors, no overt problem with the PHP.
At some point early in my investigation, the developer console sometimes complained about Uncaught ReferenceError: jQuery is not defined, but I cannot reproduce it anymore now. Research vaguely suggested it could be because the extension does not use the new ResourceLoader mechanism, so I tried to migrate Topbar to use the ResourceLoader mechanism (via maintenance/convertExtensionToRegistration.php, and then wfLoadExtension('Topbar') in LocalSettings.php) but it did not seem to make any difference.
The Topbar hooks seem to be called, because css/Topbar.css gets added to the page. But I have no clue whether js/Topbar.js ever runs, and if so, what happens.
So: how can I debug this?

You need to convert the code to use ResourceLoader - currently the extension adds the code using OutputPage's addScriptFile(), and just assumes jQuery will be available by the time it runs. Starting with MediaWiki 1.26, everything loads asynchronously, so this doesn't work, and thus the need to convert it to the new system.
Instructions for doing so are here:
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers
https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#Registering
Two notes:
Since MediaWiki 1.25, extensions are supposed to use the so-called "extension registration" instead of following the above manuals, but this might require more work and expertise.
Ugly hack warning: you can ignore all of this, and simply wrap the code in the JS file using RLQ.push( function(){ /* All of the code here */ } );. This shoves it all into the ResourceLoader's queue, so it will load after jQuery is available. I do not recommend this, but show it here for completeness' sake.

Visual composer doesn't load and gives TypeError: _.template(...).trim is not a function

My visual composer plugin doesn't work. It stuck on the loading page. And it gives an error "TypeError: .template(...).trim is not a function"
Error is on this line of code:
this.$controls = $(.template(template, data, vc.template_options).trim()).addClass('vc_controls');
Please help me to fix this out.
Here is the error which I get:

If you are unable to solve this error by upgrading or downgrading your theme or plugin, you could at least make the below changes.
1. Open the following two files:
wp-content\plugins\js_composer\assets\js\frontend_editor\frontend_editor.js
wp-content\plugins\js_composer\assets\js\frontend_editor\custom_views.js
2. Replace
this.$controls = $( _.template( template, data, vc.template_options ).trim() ).addClass( 'vc_controls' );
with
this.$controls = $( ( "vc.template_options" ).trim() ).addClass( 'vc_controls' );
This will surely work.

Solution Goto file /wp-content/plugins/js_composer_salient/assets/js/dist/backend.min.js around line 4045:
======> Replace the code
html2element: function(html) {
var $template, attributes = {},
template = html;
$template = $(template(this.model.toJSON()).trim()), _.each($template.get(0).attributes, function(attr) {
attributes[attr.name] = attr.value
}), this.$el.attr(attributes).html($template.html()), this.setContent(), this.renderContent()
},

Upgrade to Visual Composer version 4.11.2+
Note Wordpress 4.5 compatibility was fixed on 13th April:
https://wpbakery.atlassian.net/wiki/display/VC/Release+Notes

You should try to fix this by up/downgrading your theme/plugin. But if you, like me, can't solve it this way and just need to do a quick hack to get past this particular problem, the following worked for me.
Edit the following two files:
wp-content\plugins\js_composer\assets\js\frontend_editor\frontend_editor.js
wp-content\plugins\js_composer\assets\js\frontend_editor\custom_views.js
Change a single line in each of them, adding (). Change:
this.$controls = $( _.template( template, data, vc.template_options ).trim() ).addClass( 'vc_controls' );
to:
this.$controls = $( _.template( template, data, vc.template_options )().trim() ).addClass( 'vc_controls' );

As Shady sherif said at Maulik's suggestion, this is what I've changed in 2 places at frontend-editor.min.js and it worked!! Thanks to you both!
Change this:
this.$controls=$(_.template(template,data,_.extend({},vc.template_options,{ evaluate:/\{#([\s\S]+?)#}/g})).trim()).addClass("vc_controls");
With this:
this.$controls=$(("vc.template_options").trim()).addClass("vc_controls");

UPDATE:
in current updates none of this is needed just replace the plugin
I had problem with WPBakery Page Builder in version 6.0.2.
Wordpress: Version 5.2.1
ERROR: Uncaught TypeError: window.vc.frame_window.jQuery is not a function at window.vc.ShortcodesBuilder.buildFromContent (frontend-editor.min.js? Ver = 6.0.2: 10)
     at Object.vc.build (frontend-editor.min.js? ver = 6.0.2: 10)
     at frontend-editor.min.js? ver = 6.0.2: 10
I was reluctant to upgrade, as there might be a bug. (But it is a fact that an update is bug fix)
Since the update to version 6.0.3 was not successful.
Solution:
Mine was restoring the backup of the whole site.
Tip: Never forget Backup.

This article suggests rolling back your worpress version prior to 4.5. http://forums.artbees.net/t/urgent-wordpress-4-5-broken-vc-backend-editor-workaround-fix-in-comments/2734
This is where you can find older versions of wp to install https://wordpress.org/download/release-archive/30
I haven't tried this myself just a suggestion.
If this is still a problem for you I solved this same error I was getting by manually updating my theme through ftp. I downloaded the latest version of the theme because automatic updates were not working. I kept wordpress version 4.5. Here are the steps I took as follows.
I renamed the theme example x-updating once uploaded named the current theme x-previous then changed x-updating to x and deleted x-previous.
I updated js_composer the same way as step 1. Uploaded latest version of js_composer which was bundled with the theme. This is updated in plugins outside the theme. At this point you should be able to update visual composer from the wp dashboard if it hasn't already.
This got vc working again but left me with some weird errors happening in vc_templates vc_column.php file. I had to manually comment out the trouble code to get the errors to go away.
These 3 steps are a little nerve racking if you are not familiar with uploading files directly to your public_html root directory of your website. Some themes may offer support and do the ftp uploading for you if you provide them with ftp username password.
One more thing to do is clear your cache for your website. In chrome you can clear your cache by going to chrome://settings/cookies enter website.com in the search bar and click remove all clearing all locally stored data for your website. Manual updating themes and plugins is recommended only if auto updates aren't possible then you do the above. For my theme and this same exact error in question I followed these really well-done steps https://community.theme.co/kb/updating-your-theme-and-plugins/. However this will be different depending which theme you have. And if you would rather roll back your wp version you can follow my original suggestion. But for me I like to have everything new and up-to-date.
One more important note if you do have this theme then I had to delete x-shortcodes plugin from plugins direcotry of my website because my updated theme uses cornerstone instead of x-shortcodes to process important shortcodes to make vc work properly. Another thing to know is none of your data should be harmed while uploading plugins and themes all the data/content is stored safely in your data-base not in your theme.

I tried the following solutions:
maulik`s (but there was no such files on my plugin folder - frontend_editor.js and custom_views.js, just a "vendors" folder on "/wp-content/plugins/js_composer/assets/js/frontend_editor"),
Amritosh pandey`s solution (does not work even after cache & history cleaning),
Berein`s solution (does not work too).
I solved the problem by using a Amritoshpandey's solution:
https://gist.github.com/levantoan/519bb0d42c9f7bd6c4d78ef1686bb848
("The following code has completely corrected my problems, I can load the page, add, clone, remove, etc")
The Amritoshpandey's code should be pasted in /wp-content/plugins/js_composer/assets/js/dist/backend.min.js instead of:
render:function(){var $shortcode_template_el=$("#vc_shortcode-template-"+this.model.get("shortcode"));if($shortcode_template_el.is("script"))this.html2element(_.template($shortcode_template_el.html(),this.model.toJSON(),vc.templateOptions["default"]));else{var params=this.model.get("params");$.ajax({type:"POST",url:window.ajaxurl,data:{action:"wpb_get_element_backend_html",data_element:this.model.get("shortcode"),data_width:_.isUndefined(params.width)?"1/1":params.width,_vcnonce:window.vcAdminNonce},dataType:"html",context:this}).done(function(html){this.html2element(html)})}return this.model.view=this,this.$controls_buttons=this.$el.find(".vc_controls > :first"),this},

If you have Visual Composer 4.9, just replace these 2 files from archive
- frontend-editor.min.js
- backend.min.js
path: /wp-content/plugins/js_composer/assets/js/dist
Don't forget to make a backup of your files.
https://yadi.sk/d/JH4cbtnH3UoU3F
click "download add"
(tested with VC 4.9 & WP 4.9.5)

I used version 4.10 and upload the file assets/js/frontend-editor.min.js to the same file in 4.12 version.
Note: I keep my version and update only this file. I things this issues risen after update my php version, but i dont sure about that.
That`s work fine.
I get this file here: https://www.downloadfreethemes.io/visual-composer-v5-0-1-page-builder-for-wordpress/
I have theme license.

Replacing file
> wp-content\plugins\js_composer\assets\js\frontend_editor\frontend_editor.js
> wp-content\plugins\js_composer\assets\js\frontend_editor\custom_views.js
is not a solution, you can download cracked version and resolve it:
https://www86.zippyshare.com/v/fguQVId6/file.html

1.Please Deactivate the plugin
2.Delete all the files from plugin folder (js_composer folder)
3.Download the Latest Version of Visual Composer
4.Add new Plugin --> and select the downloaded plugin -->Upload --->Activate

vim YouCompleteMe not working on MacVim

I am a huge fan of vim and I've been using it for the last two years. I'm quite new to web programming. Currently I'm working on Node.js and I wanted some additional plugins which can help me learn this new technology. I installed tern_for_js and YouCompleteMe using Vundle. I also compiled YCM, but I don't see any auto-completion or javascript support. Here is my .vimrc:
syntax on
set number
set laststatus=2
set nocompatible
set expandtab
set shiftwidth=2
set smartindent
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'
Plugin 'bling/vim-airline'
Plugin 'scrooloose/nerdtree'
Plugin 'ternjs/tern_for_vim'
Plugin 'Valloric/YouCompleteMe'
call vundle#end()
:map <F2> :echo 'Current time is ' . strftime('%c')<CR>
set guifont=ProggyCleanTT:h18
colorscheme torte
NERDTree
Can anybody tell me what I'm doing wrong. Or did I miss something? Is there some extra configuration that have to be made?

The following lines are crucial for vundle to work correctly
filetype off " required
put it before
set rtp+=~/.vim/bundle/Vundle.vim
Turn it back on after vundle end
call vundle#end()
filetype plugin indent on
Also you don't need :map , map is fine.

YUI Version Conflict Issue in Portlet

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,

Drupal CiviCRM Javascript Conflict

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.