sbeaney

I’m experiencing the same issue, specifically after updating Elementor and Elementor Pro to 3.24.0

It would also be nice if we could specify the security beyond the 8 character minimum. Enforcing strong passwords would be ideal (upper, lower, numeric, special).

I also added this code to try and force SVGs to work but it still dice:

add_filter( 'wp_check_filetype_and_ext', function($data, $file, $filename, $mimes) {

? ? $ext = isset( $data['ext'] ) ? $data['ext'] : '';

? ? if ( empty( $ext ) ) {
? ? ? ? $file_parts = explode( '.', $filename );
? ? ? ? $ext = strtolower( end( $file_parts ) );
? ? }

? ? if ( $ext === 'svg' ) {
? ? ? ? $data['type'] = 'image/svg+xml';
? ? ? ? $data['ext'] = 'svg';
? ? } elseif ( $ext === 'svgz' ) {
? ? ? ? $data['type'] = 'image/svg+xml';
? ? ? ? $data['ext'] = 'svgz';
? ? }

? ? return $data;

? }, 10, 4 );

I mentioned in my original post that the license was registered there. I don’t see what clicking save again would do. Regardless I clicked save again an then went to update the plugin and it failed again.

Unfortunately the problem can’t be fixed with CSS since the DOM structure is overridden to display the toggles. I suppose I could write some JS to parse the new DOM nodes and rewrite it to use checkboxes, but I think that would end up taking way too much time ??

Honestly I can’t believe Salient would override the checkbox value “type” in the attributes array passed to the standard plugin’s vc_add_param() function. That seems so anti-consumer to me when it would be just as easy to extend the functionality to add their own “toggle” type.

I think I am going to write them a strongly worded support ticket explaining my dissatisfaction lol.

Thank you again for your time helping me debug this!

I just disabled the version of Page Builder bundled with the theme and installed/activated the standard version. Doing this enabled your plugin to work as intended and shows the checkboxes inline properly with the labels. The issue appears to be with the way the version bundled with the theme handles checkboxes (overriding to display toggles?).

I poked around in ~/plugins/hide-content-by-role-for-wpbakery/include/admin.php to see how it was registering the roles and applying them to the contend editor, but there doesn’t seem to be anything I can easily modify to make work with the theme’s version. It’s unfortunate because your plugin is exactly what I’m looking for, but since I’m stuck using the theme’s page builder plugin I’m out of luck.

Thank you for helping me look into this, and I do appreciate the time spent troubleshooting on your end. I’m sorry it turned out to be a waste. I’ll try reaching out to the theme’s author to see if there’s anything they can do to improve compatibility.

I tried disabling all the other plugins except for WPBakery Page Builder removed all custom CSS but it didn’t have an affect on the toggle labels.

Digging through the elements viewer it looks like there’s no HTML responsible for displaying the role in the popup, although the input values are set to the specific role they’re responsible for as seen in this screen shot:

View post on imgur.com

Since this version of Page Builder is bundled with the theme, I suppose it’s likely they have proprietary code added that’s incompatible with this plugin.

We’re using version 6.2.0 packaged with the Salient theme (https://themeforest.net/item/salient-responsive-multipurpose-theme/4363266).

I’m not sure how to attach a screenshot though, so here’s a link to a screenshot I took: https://i.imgur.com/jy5tFyD.png

I updated the plugin myself to handle consuming the categories.

In case you ever do want to release category matching, as the edit pipes page indicates you’re able to do (but fails to actually implement), you’ll need to update the way the object is serialized into JSON. The categories are created as SimplePie_Category objects which fail to deserialize from the JSON cache properly. Alternatively, fix the call returning to deserialized object to make sure the SimplePie_Category objects are handled properly. I’m not familiar with SimplePie so I edited the content pre-serialization.

I had to add the call “$item[$i]->get_categories()” to assign the “$row->category” object and then parse the result into a pipe (“|”) delimited string from an array of SimplePie_Category objects. I’m parsing them into a pipe delimited string because that’s what the post adapter is expecting to find when parsing the categories. If I left the $row->category object as is, when the post adapter script reads the output it encounters an array of __PHP_Incomplete_Class, which you then can’t get the data out of.

I’m marking this as resolved, since I resolved it myself, but it’s a shame that such a robust plugin with so much potential is missing some of the basic features you would expect. Also, the fact that your answer was to turn around and try and sell me a product instead of extend the plugin speaks volumes to which end this plugin is supposed to serve. It’s a lot like giving someone a car, but then telling them they have to pay for the wheels, engine, wiper blades, seat belts, etc.

I’ve taken a look at the post adapter like you said and I don’t think that’s what I need to modify.

I’ve stepped through quite a bit of the pipes code and it appears when consuming the RSS feed the plugin doesn’t even consider grabbing the post categories from the feed to assign to the new post, despite there being a “[di] category” section that can be assigned to.

Is perfectly matching up RSS feeds to new posts not the entire purpose of the plugin? Why is there a destination input for category when the source output’s categories aren’t read or parsed? This seems like it’s a massive bug in the plugin.