Henrique Vianna

I believe you need to revert to 4.3.6 and update to 4.4.0 before trying 4.4.1 again – see my answer on this other post.

I had the same problem when trying to update from 4.3.6 to 4.4.1 – I had to revert to 4.3.6 and then download and install 4.4.0, which seems to be the only version that properly upgrades the database schema. Finally, I updated from 4.4.0 to 4.4.1 via WP dashboard.

@laszloszalvak Thank you for your prompt reply. I would like to ask you guys to please consider, in a future update, simply disabling the fields that allow Javascript and/or enforce data sanitization if the user doesn’t have the unfiltered_html capability. I bet 90%+ of the users don’t need to add JS to their sliders.

I appreciate if you can forward this request to the developers, or point me the appropriate channel where to submit it.

Thanks again!

I’m not sure, but I see I have other plugins that created a directory inside the uploads folder, so it may work!

Another idea, if it’s just a JSON file you need to store, maybe you could use a WP transient instead?

Sorry for the crappy ideas ?? and thanks again for you willingness to help!

@britner Thank you for your prompt response!

The system user which runs PHP in my installation doesn’t have write access to the WP directory, except for some folders inside it, like uploads and cache. I suppose WP detects that and automatically sets the filesystem method to FTP, because I don’t have any particular setting for that in my wp-config.

I guess the problem is that the methods from WP_Filesystem classes always try to use whatever filesystem method is currently active, so in my case it wants to use FTP for everything.

I know that seems to be a pretty restricted/obscure issue, but I wonder if you could use alternate functions to write the design library files, because I would really love to keep it working.

Thanks again!

Henrique

I just found out that my solution above prevents me from updating WordPress, as it now tries to install updates without asking for my FTP credentials, which won’t work for my hosting setup.

So, I added the line if ( ! defined( 'FS_METHOD' ) ) define( 'FS_METHOD', 'direct' ); to kadence-blocks.php and it seems to solve the issue with the Design Library, without affecting other parts of the admin.

@britner could you please consider officially adding this to the plugin? This page provides a description of the available WP filesystem methods, and I believe the Design Library will only work with direct filesystem access, but other users may have a different configuration for WP updates.

See my reply on this other thread for a possible solution.

Hello there!

I was also having this issue since the 2.0 update. I found a solution today on this issue comment

So, adding the line below to wp-config.php should solve the problem:

if ( ! defined( 'FS_METHOD' ) ) define( 'FS_METHOD', 'direct' );

In my case, I also manually created the kadence_blocks_library directory inside wp-content and gave it write permission.

Hope that helps!

Removing the filter solved the issue. Thank you!

Cool then, thank you!

Ok, will do! Thanks for the prompt response!

Sorry for the double post, this one remained locked for several hours and I thought it had been rejected.

Solved in version 3.2.0!

E-mail sent! Thanks.

I’ve been using the restrict access option since I first installed the plugin, with the allowed usernames in the “Can Manage Plugin” field.

I disabled the restrict option, logged out and logged back in, but still no change.