davidryal

[davidryal]

Thanks for quick reply ! Any idea when that update would be? Because “upgrading” to Gutenberg requires redesigning client websites, it needs as much lead time as possible (which is why they released Gutenberg as a plugin first).

Since it replaces Visual Composer in functionality, what about the option to disable (or not install) VC and use Gutenberg instead? If Kleo provided that option, it might be the quickest path to everything being back to normal. 🙂

(And I would still MUCH rather have that option so that the theme works overall with Gutenberg, even if it means a few special features in Kleo that relied on VC don’t work)

Then again, looking at the code, it seems to be a simple error, where the Gutenberg Toolbar is simply pushing the lefthand menus items down and floating incorrectly. Confirmed that it works correctly using a default theme like Twentyseventeen.

Thanks again!

Attachments:

You must be logged in to view attached files.

[davidryal]

@johnand your comment-out solution worked for me yesterday after hours of frustration, thanks!

just FYI, I also was experiencing the inability to access theme options, but thought I would note that upgrading to the 4.2.4.3 theme version released overnight seems to have solved that bit, in addition to removing the need to comment out line 400 to ensure normal operation (no idea what they did elsewhere, but nothing changed in required-plugins.php in the new patch).

[davidryal]

commenting out line 400 in kleo\lib\required-plugins.php worked for me too, per: https://archived.seventhqueen.com/forums/topic/wordpress-backend-became-unusable-after-installing-kleo#post-161844

looking forward to a fix from the 7Q team!

[davidryal]

Hm, maybe I was wrong — reverting to WP 4.7.4 has the same slowness/502’s. Is there anywhere I can download significantly older versions of Kleo so I can test back to when speed was at max? Thanks!

[davidryal]

Yes! It looks like it worked! Can you tell me what changes you made, so that I can accomplish the same thing on the client’s live production website?

Thank you!

David

[davidryal]

Hi Radu-
If you look at Step 3 above, the 3 js errors how up when you try to EDIT an entry as an admin, like so:

https://www.opentest.co/share/94f597b09c6211e6b1777d3d580c8a9a

Once you’ve reproduced that, feel free to switch to a default theme on that site, to verify that all fields show for editing as they should when Kleo is not running.

…Also, additional clue: running Theme Check on Kleo comes up with the following:

COPY CODE

WARNING: Found wp_deregister_script in kleo-framework/options/core/enqueue.php. Themes must not deregister core scripts.
Line 215: wp_deregister_script( 'jquerySelect2' );

I’m not 100% sure that a jquery-dependency issue is to blame here, but it sure appears so, given the similarity to the StackOverflow issue I linked above..?

Thanks again!

[davidryal]

Hi Radu-

I don’t know what the error you mention is (I’ve never seen it), but I’ve disabled the unrelated plugin that was triggering it; this doesn’t not fix the 3 errors I posted here about. The 3 errors that show up in the process I described in my last post are:

COPY CODE

Uncaught ReferenceError: gform is not defined
http://cabec.staging.wpengine.com/admin/cea-lookup/entry/3518/?gvid=2892&page=gf_entries&view=entry&edit=8c0a35ecb0 line 788

Uncaught ReferenceError: gform is not defined
http://cabec.staging.wpengine.com/wp-content/plugins/gravityforms/js/conditional_logic.min.js?ver=2.0.7 line 1

Uncaught ReferenceError: gformExtractFieldId is not defined
http://cabec.staging.wpengine.com/wp-content/plugins/gravityforms/js/conditional_logic.min.js?ver=2.0.7 line 1

I am not using any caching plugins on staging (on production, the host, WP Engine, uses its own, but that is not an issue here — I am working on staging).

I have toggled and tested with every combination of Kleo speed/dev mode/etc. toggles. The problem is with the theme, because these errors go away when using a default (i.e. 2016) theme & no changes in plugin configuration (all plugins active).

I am not a developer, but to me this looks like a larger incompatibility with how Kleo loads jquery vs. how Gravity Forms does it. I think these links are more along the lines of the problem/solution:

http://stackoverflow.com/questions/23786388/js-error-on-gravity-forms — in it, an answer says this:

COPY CODE

"I had exactly the same problem, and managed to track it down to some theme code.
I was using the bones theme, which de-registers the default jQuery JS and adds its own using the Google CDN...

As you can see, it deregister's the default jquery script, and then adds its own cdn-jquery script, which is fine, apart from the fact that the Gravity forms scripts have a dependency on jquery and not cdn-jquery!

Because they can't see the default jquery script, they don't load, and it would seem that they fail silently, simply emitting this JavaScript error because said JavaScript is loaded without checking dependencies.

In any case, I fixed it by re-naming the bones register script to jquery, might not be the best way to fix this, but it works."

…or maybe this?: http://micahjon.com/loading-jquery-in-the-footer-with-gravity-forms/

Hope this helps. Thanks for staying on top of it and helping me get it fixed.
Cheers,
David

[davidryal]

This reply has been set as private.

[davidryal]

Hi-
It doesn’t work if all js is moved to the footer, it jsut removes 1 of the 2 js errors. The only thing that works is reverting to the last version of the theme that I have available, 4.0.8 (it may work in some newer versions, but I can’t get ahold of them to try any others).

[Author]

Posts