Scott Bowler

Do you think you’ll add it in the future?

Wow, you rock! Review left, will test this out and make the purchase ??

That would be fantastic, thank you!

@nick6352683 the way our democratic process works is as follows:

1. anybody can create a petition
2. if the petition achieves enough support it will be put to community vote
3. if there is a majority in favour, the petition request gets implemented

So 7 votes on a petition is a very long way off something getting implemented in ClassicPress.

@nick6352683 that’s quite a lot of disinformation you’re sharing right there. Our primary goal is to serve the business market and “mutilating WordPress” wouldn’t serve that goal.

You seem extremely angry about our fork, and I don’t understand why. You’re not forced to use it or support it, but it will be a viable option for a lot of people.

One last comment – can you not see the elephant in the room? Two (apparently popular) plugins exist to delay or disable Gutenberg, which you are promoting as a viable solution. This by itself is a major red flag – people have invested time and money to counter your actions.

The state of denial shown in all these threads is extraordinary.

Please respond to my suggestion of making this a default plugin instead of core.

• This reply was modified 6 years, 4 months ago by Scott Bowler.
• This reply was modified 6 years, 4 months ago by Scott Bowler.

As a very basic example of breaking changes, Gutenberg doesn’t support disabling auto p via a hook.

I don’t want to take this off topic, but the fact you think Windows 10 was a good release sums up Gutenberg succinctly.

On a side note, there is a very clear formula to replies to negative gutenberg reviews “{{thank you}} {{why don’t you like gutenberg even though your review says exactly why}} {{we are going to continue despite your feedback, but we’ll veil this by asking what you like about gutenberg}} {{ps by the way you can slow your installation down by having gutenberg in core but add more bloat by adding a plugin to disable it}}

It’s time to take your heads out the sand and realise that you are wrong. Your egos are going to kill WordPress.

Ah, that makes sense – thanks for the fast response!

I deactivated all the plugins and turned them on one by one – there seems to be a conflict with Advanced Custom Fields Pro which removes the tab

I’m experiencing the following error on 1.6.5.2, WordPress 4.6 (waiting for 4.7.1 before updating to the latest version).

Uncaught TypeError: Cannot read property 'substring' of undefined
    at NestedPages.Factory.e.setPostType (nestedpages.min.js:2)
    at NestedPages.Factory.e.init (nestedpages.min.js:2)
    at new NestedPages.Factory (nestedpages.min.js:2)
    at HTMLDocument.<anonymous> (nestedpages.min.js:2)
    at i (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery…:2)
    at Object.fireWith [as resolveWith] (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery…:2)
    at Function.ready (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery…:2)
    at HTMLDocument.K (load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery…:2)

Any ideas?

To clarify the above posts… You need to go to “Users > Roles”, choose your role you want to have access, and then choose “Custom” on the left hand side. Scroll down until you reach:

gravityforms_event_tracking
gravityforms_event_tracking_uninstall

And make sure the first column (Grant) is ticked for both.

Getting the same problem – gravity forms v2.03

Hi Guys,

I think you might have misread my most recent post ?? The solution you provided doesn’t work because the filter you suggested no longer exists in your codebase.

Sorry to keep going on about this point, but it’s a big issue.

Thanks in advance,

Just looked into implementing this using the code in your link and it seems the “yith_wpv_vendors_allowed_post_types” filter doesn’t exist in the Yith source code.

In addition, Yith doesn’t attempt to check what post types the user is allowed to have access to – the code below (from Yith) just throws an error if the user isn’t an admin, super user, vendor or the owner of the product when trying to access other post types:

if ( $vendor->has_limited_access() && false !== $product_vendor && $vendor->id != $product_vendor->id ) {
                wp_die( sprintf( __( 'You do not have permission to edit this product. %1$sClick here to view and edit your products%2$s.', 'yith_wc_product_vendors' ), '<a href="' . esc_url( 'edit.php?post_type=product' ) . '">', '</a>' ) );
            }

Perhaps this functionality has been removed at some point?

I disagree – by default Yith shouldn’t interrupt the accessibility of other post types, that’s not the scope of the plugin.

I handle permission to post types separately (and globally) and having to manage this twice just for the vendor plugin is a huge headache.