That is why I always encourage people to use CP plugins and themes and ask developers to support it.
Obviously the divergence means in some cases it won’t be possible to use WP plugins “as is” on CP but I fell this has to be seen as an opportunity rather then an hindrance.
CP is different, but it’s not “worse than” (or the “runt” as we say in Italy) and is gaining traction. At a certain point, once reached the critical mass it will be more profitable for devs to support it I hope.
So far far I have been able to keep the plugins I use working (I use a lot of plugins). Using old versions is not the optimal way to handle it, but in some cases it may not be a big problem (security wise); in other cases it will, at least eventually, need to be addressed.
I wonder if a guide of sorts could help developers. The generic understanding is that “CP does not support blocks”, and I am not disputing that it might be that simple, but it also seems that developers are using ‘block scripts’ (if that is that right terminology) that are not included in CP as they improve and upgrade their WP product.
So is there some sort of a list stating what scripts are not included or what expectations a WP developer might have that would not be met by CP. I think that might help developers with interest in supporting CP to know how they can do that but still improve on the product they offer WP users (hopefully without essentially needing to provide and support 2 plugins).
Unfortunately no such thing is available and I agree saying WP without blocks means very little in terms of development.
Some block functions have been poly filled.
But it might not be possible to do that for each one, nor is CP going to do so IMHO for the amount of effort it would take.
In 2018 we forked an old copy of codex to avoid losing it. But the fact V2 is a refork of WP 6.2 pretty much defies the purpose of it. To be noted that going to the CP docs site should allow to search that codex copy but so far the times I tried to use it it responded with nothing found so I suppose the only guides available are the ones linked in that very same page.
As of now we are undertaking localization. The documentation however is another thing we will have to tackle sooner or later.
Since I do this more as a hobby I am far from fully versed, so may also be off the mark a bit. I believe some of the ‘block scripts’ make it easier for developers to build WP products using the included tools, and that is somewhat the route they are being encouraged to follow.
At the same time, CP is/has removed (some of?) those scripts, meaning developers would need to provide that functionality within the product in order to support CP.
So doing things ‘right’ in WP means as devs upgrade, we are going to have more issues. I know it is unavoidable, but mentioned before if it was realistic to provide those missing scripts in a plugin (sort of like the classic plugins for WP, to create a bridge and extend conversion compatibility).
Just some thoughts, we don’t want to lose more traction than we gain?
If plugins make use of block-related scripts, then CP isn’t going to be compatible with them. There’s no point worrying about that; it’s essentially inevitable.
However, if there’s what might be called “collateral damage,” then it’s worth exploring what we can do to mitigate or even avoid that. I’m hoping the issue with BB is of this variety, and it might then give us some clues about what we can do to prevent other similar instances.
It is definitely a patch of unpaved road to navigate.
If users and developers use the support channels we should be able to work through it, we just need to make sure people can find help when they need it.
I managed to have a quick look at this this evening.
I tried BB Lite on an installation running CP v2.0 and had no problems.
Then I tried it on the nightly for v2.1. Immediately I got the warning that jQuery was not defined. For a moment, this seemed very odd, and then it clicked. It seems that BB works on the front-end rather than in the admin. jQuery is not loaded by default in the front-end; something has to call it.
And sure enough, adding jQuery as an explicit dependency of the fl-builder-tour.js script solves that issue. So, on fl-builder.php, the relevant line should be as follows:
wp_enqueue_script( 'fl-builder-tour', $js_url . 'fl-builder-tour.js', array( 'jquery' ), $ver );
At that point, I got the same list of problems that @ElisabettaCarrara listed. But I looked and CP does include both wp.media and wp.template. As I thought, CP also does include wp_enqueue_media().
So here’s what I suspect is happening. BB is so used to certain scripts being loaded that it doesn’t always specify its dependencies explicitly. Which would be fine on the admin pages; the problem arises because BB works on the front-end. But the v2.1 nightly for CP is no longer loading some scripts in the front-end; hence the issues reported here.
Since I have only taken a quick look so far, I don’t know why the change has occurred in what is being loaded on the front-end. But my guess is that a PR for the nightly has removed any previous need for CP core to load those scripts in the front-end. If that’s so, then my money would be on a change in some of the code for the Customizer, since that also works on the front-end.
If I can find the cause, then obviously we should be able to fix it. But it might also be that BB could fix this by expressly declaring one or two more dependencies.
Thanks for looking into this. I think since the nightly one day or another will become a stable release solving this (either by declaring dependencies in BB or by modifying core slightly) will ensure people can use a reliable builder that is also (IMHO) the best on the market.
(I know it is slightly risky to go on a nightly for production sites, but I am an early adopter type of site owner :D).
That said, the errors say deferred, that made me think that the things were there and not loaded but I did not think that in fact core could affect loading for these dependencies for the plugin if not explicitly declared there.
That’s just jQuery’s way of hinting that the relevant scripts might have been loaded in the wrong order. And it’s pretty much what’s going on here because BB doesn’t expressly declare all its dependencies.
In fact, I have now managed to solve this (at least on my test site) by replacing the BB line I referred to above with this line:
wp_enqueue_script( 'fl-builder-tour', $js_url . 'fl-builder-tour.js', array( 'jquery', 'media-models', 'media-editor', 'media-views' ), $ver );
This ensures that the first BB script to load forces all BB’s dependencies to load before it does.
Will test that on my install and see if it works for me too. If it does then welcome back BB! and it could go in the next release they are planning.
@timkaye I was already testing it, the fl-builder.php file has only a line of code requiring the fl-builder-loader class file.
Are you sure that line of code has to be placed in fl-builder.php and not in the classes/class-fl-builder-loader.php that is the file that lists all the things to be loaded?
@ElisabettaCarrara Yes, that’s the file I meant. I misread what I was looking at, but you’ve found the right one.
Thanks for taking the time to figure this one out, I’ll get it into a PR ASAP.
Thanks!
Actually, there is still issues here, even tho the UI works now with that tour fix, the media modal is still totally broken, we’ll keep tinkering with it
You might find the solution I came up with for the Bricks builder also works for you: ClassicPress 2.1.0 Release Notes - #21 by timkaye
In a sense that’s a short-term fix, since it won’t work once CP gets to version 3. But that’s got to be at least a couple of years away. The longer term fix is definitely to specify the dependencies, especially if they don’t include anything from jQueryUI. Since we haven’t removed any JS files from the CP bundle, everything is still there to be called as needed.
add_action( 'fl_before_sortable_enqueue', function() {
global $wp_scripts;
$deps = $wp_scripts->registered['media-views']->deps;
foreach ( $deps as $key => $dep ) {
if ( $dep === 'sortable-js' ) {
unset( $deps[$key] );
$deps[$key] = 'jquery-ui-sortable';
ksort( $deps );
$wp_scripts->registered['media-views']->deps = $deps;
break;
}
}
});
This works ( MUST be at plugin level tho, wont work in child theme )
I’m thinking you can can put it in Beaver Builder. It’s not going to cause any problems if it’s used in WP.
Yea I have it in the same PR as the tour fix. Not gonna get out straight away so if the OP wants to use the code, it needs to go in an mu or mini plugin or something.
Thx for the help tho!