How to make the Advanced Layer Builder DEFAULT when creating a new page/post?

anyone? anyone? :-)
:-(

@Ismael,
that’s great, thank you!

for reference, i’ve been cobbling together all i could find on the subject and i “THINK” i’ve found a great solution that (so far) works.

first, i’m disabling the WordPress Gutenberg “new” editor (cause i think it sucks); but that leaves the previous WP default “classic” editor button.
second, with your code, i’m auto-clicking the Enfold Advanced Layer Builder button on new page/post creations.
third, i’m auto hiding the WP classic editor button (so nobody can accidentally click it & get confused or whatever – really, it just makes me feel better).
fourth, i’m hiding the words that say which editor was used on the page/post listing pages to have a cleaner interface.

✌🏼

// ADMIN: DISABLE WP GUTENBERG EDITOR FOR POSTS & POST TYPES
add_filter('use_block_editor_for_post', '__return_false', 10);
add_filter('use_block_editor_for_post_type', '__return_false', 10);

// ADMIN: AUTO-CLICK TO ENABLE ENFOLD'S LAYOUT BUILDER WHEN CREATING NEW PAGES/POSTS
function trigger_alb_on_load(){
	?>
	<script>
	(function($){
		$(window).load(function() {
			$("#avia-builder-button").trigger('click');
		});
	})(jQuery);
	</script>
	<?php
	}
add_action('admin_head-post-new.php', 'trigger_alb_on_load');

// ADMIN: HIDE WP DEFAULT EDITOR BUTTON
function hide_default_editor_button() {
  echo '<style>
    #avia-builder-button {
      display: none;
    } 
  </style>';
}
add_action('admin_head', 'hide_default_editor_button');

// ADMIN: HIDE EDITOR INFO IN LISTINGS
function remove_ALB_post_state( $post_states, $post ) {
	if("! has_blocks( $post->ID )") {
		unset($post_states['wp_editor']);
	}
	if("!= Avia_Builder()->get_alb_builder_status($post->ID)") {
		unset($post_states['avia_alb']);
	}
return $post_states;
}
add_filter('display_post_states','remove_ALB_post_state',999,2);

this was working great since last post, but now since latest update, it’s not working at all. when creating a new page, it just shows the classic editor. i’m guessing the jquery trigger click bit is where it’s failing, but i’m not sure about that.

thanks Victoria,
i’ll try that, but isn’t that just a bandaid & not a real fix?
your thoughts on that please.

this is now at the top of the admin pages…

`jQuery Migrate Helper

Right now, you are using a plugin to support some old code in this website’s jQuery JavaScript library. That code is deprecated, meaning it is basically obsolete and is losing the support of your themes and plugins and WordPress itself.
This plugin, called Enable jQuery Migrate Helper, is not a fix. It is a temporary solution to give your plugin and theme authors time to update.

If you get warnings, please check for updated versions of the plugin or theme that generated the warning. There will very likely be one you can install. When you have updated your plugins and themes, and there are no more warnings, please deactivate Enable jQuery Migrate Helper.

You are currently using a legacy version of jQuery. It has no support and doesn’t receive security updates. Please upgrade as soon as possible. `

…and even with the setting to show it turned off :-(

what version of jquery was enfold using before the big upgrade that caused the need for this plugin? is there a way i can go back to that one? the plugin only allows 1.12.4.

yes, i have it set to “Legacy 1.12.4-wp” – which is the only option to choose from.

QUESTIONS:

• so, are you saying that with the current version of WordPress & Enfold, you tried my code from above (#1201727 on April 8, 2020), and when you go to create a New Page, it works as it should? if that’s the case, then i suppose i have a plugin that’s conflicting with it. which would suck because i have a careful, small list of plugins i’m using. would hate that the updates caused one of them to conflict with that code.
• are you saying that the current version of Enfold is 100% updated & compatible with the current version of WordPress? this would mean that i should NOT need to use this jquery migrate plugin; instead, i have a conflict to hunt down. any idea what i should look for to find where the conflict is, or, is there anything about the above code that i could change that might make it work again?
• is there any way to make the site use whatever version of jQuery prior to the big update? the v1.12.4 seems rather old.

thanks for your assistance Ismael.
i’ve spent way too much time on this but i THINK i’ve figured it out; or at least figured out a workaround…

perhaps the upgraded jquery/theme/wp/etc is now causing the functions script to fire too soon. i’ve found by adding a short Timeout, it now works as it was :-)

now, i’m no coder; i just hobble these things together as best i can from what i can find, so PLEASE check me on this – have i added the “setTimeout” function into what i had correctly/optimally? i don’t want it to cause any other issues.

here’s the orig script i found:
setTimeout(function(){$('#avia-builder-button').click()}, 100);

i took that & put it inside the same PHP function as above (#1201727 on April 8, 2020),
i’m unclear on whether i should have kept it as “.click()” or like i was using with the “.trigger(‘click’)” – BOTH seems to work as far as i can tell.

	<script>
	(function($){
		$(window).load(function() {
			//$("#avia-builder-button").trigger('click');
			setTimeout(function(){ 
				$('#avia-builder-button').trigger('click')}, 100);
		});
	})(jQuery);
	</script>

PS: i discovered a “Disable jQuery Migrate” option in the theme > performance settings. is that the same thing as the “Enable jQuery Migrate Helper” plugin? i have de-activate & un-installed the plugin version but have left yours enabled.