Update the documentation to clarify that the Gutenberg plugin is required (for now) for the functionality to work.

As discussed on the wp.org forum - https://wordpress.org/support/topic/gutenberg-beta-plugin/

This should also contain FAQs - some links in the UI settings screen will send the user here.

I noticed shorthand arrays ( PHP 5.4 feature ) in the plugin. Which PHP versions are we aiming for the public release?

If we want the plugin to be useful for absolutely every WordPress installation then we still need to go for PHP 5.2.4.

I usually wouldn't suggest using an old PHP version, but since this is a plugin intended to improve Gutenberg compatibility for all sites - we might have to go for core-compatibility.

Before we release the plugin anywhere, the terms functionality should be either implemented or removed.

Creating a ticket for it so that we don't forget.

Makes the plugin accessible to non-developers in the broader community.

There are WordPress installations with customized admin paths. Relying on /wp-admin/ existing in the path is unreliable.

https://github.com/Automattic/ramp-for-gutenberg/blob/master/inc/class-ramp-for-gutenberg.php#L185

To reproduce:

• configure the plugin to load on a given post_id
• load the edit screen for that post_id
• change the configuration in the theme so that the post_id no longer loads Gutenberg
• reload the edit screen
• the new configuration will not have taken effect, and Gutenberg will still load
• reload the edit screen
• the configuration will have taken effect

We really shouldn't need this extra request.

When loading this plugin using 'load' => 1, the plugin errors out edit screens for CPTs that don't have show_in_rest set to true. Gutenberg natively handles this use case just fine, but Ramp railroads over this default handling and incorrectly shows an error page of No route was found matching the URL and request method.

Ramp should not regress the behavior that exists in normal Gutenberg if loading the plugin using a default loading pattern that doesn't define specific CPTs to load.

To test this, include both Ramp for Gutenberg and HM Redirects on a site and set Gutenberg loading to 'load' => 1. Then, attempt to access the editing UI for Redirects and see the error. These CPTs neither have an editor nor have REST support and this is causing a complete failure on the edit screen.

Reference #32 for a similar patch.

I check under Settings -> Writing and the Gutenberg Ramp settings aren't displaying.

Originally reported by @micahwave

The priority of the plugins_loaded hooks is currently set in a way that makes it so no custom meta boxes get loaded.

If you use wpcom_vip_load_gutenberg, it's going to enable gutenberg here:

The issue is that gutenberg itself registers a plugins_loaded hook at a lower priority:

https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L27

With the current setup, the gutenberg_trick_plugins_into_registering_meta_boxes function is never called because ramp isn't activated in time.

If you change the load_decision hook priority to 5 it seems to fix the issue.

When I enabled the plugin, I was boggled as to why only "Post" and "Page" showed up in the list of post types where I could turn Gutenberg on and off.

After some googling I found out I needed to explicitly set "show_in_rest" to be true in my CPTs. However, even after setting that, unregistering the CPTs, and reregistering the CPTs, Ramp still did not list any of my CPTs. It was only when I deactivated the Ramp plugin and reactivated it - then I was able to see all my CPTs and pick which ones to enable Gutenberg for.

I would like to see a message in the UI that makes it clearer - if any post types are not appearing here, either link off to documentation on how to make sure your CPT supports whatever's needed, or else just mention the specific "show_in_rest" setting and make it clear you'll also have to deactivate Ramp and reactivate it after the post type(s) have been re-registered.

It would also be really helpful if the Plugins page had a link to "Settings" which took you straight to Settings > Writing. It took me awhile to figure out where to find the list of post types to toggle.

I have enabled Gutenberg Ramp but don't see checkboxes for all the custom post types on the site:

As a user, it isn't immediately clear to me why the checkboxes are missing and it looks like Ramp doesn't fully work. Looking for an explanation leads me to: https://wordpress.org/plugins/gutenberg-ramp/#screenshots where we have:

Some post types are not showing up on the settings screen
Post types that are not compatible with Gutenberg will not show up. If you think you have found a false negative (posts in that post type DO work with Gutenberg, when Ramp plugin is deactivated) please report it as an issue on GitHub here.

If custom post types are incompatible with Gutenberg, it would be a better user experience to say which don't work with a link to more information, perhaps including them in the list but with checkboxes greyed out and inactive.

Setup a Travis CI to check:

• Check for syntax errors in PHP
• Run phpcs with VIP Standards

Currently the plugin just loads rather than unloads. The unloading method is just a stub:

public function gutenberg_unload() {}

This can be implemented in two steps:

• add support for the activated Gutenberg plugin. We'll fall back to the native 4.9 editor.
• add support for core Gutenberg. We'll need the classic editor plugin.

I've been working with enabling this on a client's site and am a bit confused by how these parameters are supposed to work. They don't follow expected behavior for how booleans should work, which leads to unexpected results.

Consider the following values:
wpcom_vip_load_gutenberg( true ); -> does not load
wpcom_vip_load_gutenberg( false ); -> loads
wpcom_vip_load_gutenberg( [ 'load' => true ] ); -> does not load
wpcom_vip_load_gutenberg( [ 'load' => 1 ] ); -> loads

Passing false into a function that determines whether G'berg is supposed to load forces it to load, but true turns it off? Additionally, the type checking on the load value is so strict (and I rarely disagree with strict type checking) that 'load' => true doesn't even work when true should be the value that does load G'berg instead of the other way around.

Additionally, when testing various values the difference between [ 'load' => 1 ] and [ 'load' => true ] is easily mistaken due to the storage of this as an option instead of directly respecting the function's value. If you change it and reload the page, the new value has no immediate effect which leads to false positives and negatives.

Gutenberg copes with the embedding of Gist URLs, in the fact that they work, but output in the editor is blank. This makes any kind of editing difficult.

Here's an example of a Gist URL for demonstration - https://gist.github.com/dartiss/028c0065c06b0b84a26f40038fbf47b7. Create a new block and paste this on. The resulting block will be black, albeit editable (to an extent) - if you view it as HTML you can see the embed. Previewing and, ultimately, viewing the post will show the embed correctly.

This needs a wpcom helper with modified loading strategy. The current idea is to load gutenberg from the a8c plugin. I've added sufficient filters and actions to modify loading behavior, so this should be possible.

If we tell Ramp to always load Gutenberg in all cases or for a specific post type, then it should do so on the new_post screen.

Currently this is the case when the Gutenberg plugin is activated, but when it is inactive the classic editor loads for new posts under these conditions.

There are a few differences that we should probably look at harmonizing. The expiatory text is different for instance.

Currently this plugin allows opt-in to Gutenberg on a post-type or id basis.

In many sites, post-type is not practical, for example if the site contains a lot of content.

Opt-in by ID is specific enough to allow such sites to gradually transition to Gutenberg, one post at a time. However, IDs are tied to a specific database instance, which makes this approach hard to manage across live/production and development environments.

If this plugin allowed opt-in by post slug, or by a tag, this would allow large complex sites to easily manage which posts use Gutenberg, and to do this consistently across developer environments and production.

I could see a need for an admin alert when Gutenberg is turned off for all post types just so a user is aware. It could be set to be dismissible forever. I think some feedback on activation of the plugin would be nice.

The text could be something like:
Notice: The Gutenberg ramp plugin has disabled Gutenberg on the post, pages, ______, _______, etc. post types. If you would like to activate Gutenberg on any of these post types please click here.

If I find some time I could work on this a bit if anyone agrees.

We may need to whitelist known good post types to avoid interfering with how their plugins create a "new post" edit page, or even edit an existing post. For example WP RSS Aggregator does seem to offer two options for Add New when Gutenberg and RAMP are both activated:

Without RAMP, there is no multiple choice:

The link is http://localhost:8888/wp-admin/post-new.php?post_type=wprss_feed_item and with RAMP activated (but the post type not included in the RAMP config), results in this error: No route was found matching the URL and request method

With RAMP deactivated or if the user chooses Classic, this is the (correct) form for that post type:

I suspect other plugins may have similar issues.

Currently, nothing is greyed out in the UI in the case where Ramp sets Gutenberg to always or never load. (gutenberg_ramp_load_gutenberg() and gutenberg_ramp_load_gutenberg( false ); in functions.php )

Post types are (correctly) disabled/greyed out in the UI.

This could cause confusion where the UI appears available in wp-admin, but in fact does nothing because the function in the theme (correctly) overrides.

Only the most last ramp_for_gutenberg_load_gutenberg function call will be effective.

For example: This will only enable ramp for Post ID 157

ramp_for_gutenberg_load_gutenberg( [ 'post_types' => [ 'post', 'page' ] ] );
// some
// code
// in
// between
ramp_for_gutenberg_load_gutenberg( [ 'post_ids' => [ 157 ] ] );

Posts that do not declare rest api visibility don't work in Gutenberg. Before trying to turn on Gutenberg for one of them, check for this declaration.

We may also want to be helpful and turn off Gutenberg proactively for any CPT not visible, but I'm guessing that core may end up doing this at some point?

A user is requesting, in their situation, that access to the screen is only available to Super Admin. For now, I've provided code for this, but I wonder if we could maybe implement a simple filter or function to allow users to easily modify this.

Original request - https://wordpress.org/support/topic/option-to-allow-only-super-admins-make-changes/

When creating a new post or page Ramp doesn't load or unload Gutenberg.

For Ramp to work right now it needs Gutenberg plugin to be installed.

When WordPress 5.0 is release, the dependency is going (is it?) to change to "Classic Editor". What's the best way to handle both plugin dependencies?

Ramp doesn't do anything on its own at the moment, it's just a bridge and we need to make sure that both ends of that bridge are attached to something at all times.

Part of the solution would be to check for core version. If less than 5.0 then require both Gutenberg and Classic editor, otherwise only require classic editor.

How do we "require" another plugin? Do we display a big warning message to the user asking nicely to install 2 other plugins or this won't work, or do we use something like TGM Plugin Activation to make it easier to install the plugins?

Gutenberg Ramp 1.1 requires Gutenberg 3.5 or higher to work properly.

We should deactivate Gutenberg Ramp if the version requirements aren't met and display a notice informing the user that Gutenberg should be updated to 3.5+ for Ramp to work.

Suggested by a user on the wp.org support forum.

Do you have plans to have a setting that will disable the “Try Gutenberg” callout that’s slated for WP 4.9.8?

It would seem to make sense to disable the callout by default, since Gutenberg is disabled by default with this plugin. And I LOVE that your default setting is disabling Gutenberg sitewide.

User goes into more details about this, but is basically not installing Gutenberg so the current checks with the banner code will cause it to appear (it checks if Gutenberg is already installed, which is not an automatic assumption for Ramp users).

I've left the support ticket open, so please update the user if there is any progress with this - https://wordpress.org/support/topic/feature-request-disable-try-gutenberg-callout/

Today, while testing, I've been trying to ramp Gutenberg like this several times:

ramp_for_gutenberg_load_gutenberg( [ 'post_type' => 'post'] );

I think that it would be a nice addition to the ramp function.

Or maybe, at least cast strings to arrays so that ['post_types' => 'post'] can be used ?

Running Ramp + Classic Editor plugins together (any version combos) yields quirky results. The behaviour itself is ok. But the UI labels cause confusion.

Classic Editor UI

With the first option selected - "Replace the Block editor with the Classic editor" - Classic Editor overrides Ramp settings.

With the second option selected - "Use the Block editor by default and include optional links back to the Classic editor" - Ramp settings override Classic Editor.

An interesting side effect of this is that it allows a user to control default loading behaviour with Ramp, but utilise Classic Editor's second option to provide a fallback for editors. This is similar to the requested behaviour described in Issue #65

Proposed Solution
Leave the behaviour as-is, but change the Classic Editor labels via filter to make the behaviour clear. This would require Classic Editor plugin to place the current text in a variable that can be filtered to change to custom text by Ramp.

@justnorris @azaozz Any thoughts on this?

The disparity between having an option set and using a code to set said option leads to a good bit of confusion.

For example, when testing the new wpcom_vip_load_gutenberg for which option made the most sense on a client's site, I accidentally saw a false positive in testing 'load' => true after 'load' => 1. I changed the option to true, reloaded my page, saw Gutenberg loaded, and since this is all driven via code, expected that this would work. Came back the next day and spent 20 minutes trying to figure out what I'd done to kill Gutenberg again 🤦‍♂️ .

As a developer, if there is a function to drive functionality, I would expect a change to it to take effect immediately and not have some extra layer that makes me re-load the page several times to se if my change really, really, really, actually took this time. This is extra true in circumstances like VIP Go where the plugin is loaded without the UI being used at all - there's no reason for this option and it just adds potential issues an unnecessary overhead.

I'm trying to get gutenberg-ramp to work for the first time as we haven't fully committed to using Gutenberg yet and would like to transition our editors (and myself) using by specific post_types

I'm using WordPress 5.4-alpha-46729.

I've tried to configure gutenberg_ramp so that Gutenberg is the editor ONLY for a specific post type (a custom post-type); all other post types use the classic-editor.

I have verified that my custom post type supports Gutenberg; Gutenberg loads as I would expect as the editor when I disable classic-editor when editing that custom post type.

In wp-admin/options-writing.php#classic-editor-options ; the custom_post_type does have the check-box marked.

I've deactivated all plugins except gutenberg-ramp and classic-editor.

https://github.com/Automattic/ramp-for-gutenberg/blob/570103f9c68e9fa6067a54a25d6244c367f5fc52/inc/class-ramp-for-gutenberg.php#L19-L21

Ramp initializes on plugins_init, $priority = 20, and the options name filter loads the decision based on values of ramp_for_gutenberg_option_name.

Allowing users to change the key name after that can lead to bugs/confusion.

For example,
Adding this in theme functions.php would change the options key on the fly

		add_filter( 'ramp_for_gutenberg_option_name', function() {
			return 'the_load_criteria';
		} );

As a result, Gutenberg options would be called from ramp_for_gutenberg_load_critera on plugins_init:20, and anything after theme functions.php would save the criteria to the_load_criteria option.

Solution

1. Is the filter necessary at all?
2. If it is, initialize the value the first time options_name or get_criteria methods are called, or maybe even the constructor?

Currently, gutenberg_ramp_load_gutenberg accepts a limited set of criteria. Since the decision to load/not load in a given post edit context is based on the intrinsic characteristics of the current post, the decision could be based on any attribute of the post -- not just ID or post_type.

WordPress's built-in interface to querying against posts are the criteria available to WP_Query.

What if gutenberg_ramp_load_gutenberg simply accepted any WP_Query arg, and in the background constructed a WP_Query with those criteria in addition to the ID of the post being edited (in the case of an existing post) or the post type of a new post. Any result would mean "yes" -- load the editor -- while an empty result set would mean "no" -- don't load. The performance tax would be non-serious, since this would occur on the admin only, and only for requests that would result in an edit screen.

Some notes:

• we would need to provide backward compat. to support the arguments as they are now.
• we should check if there are any pitfalls here -- performance, load-order or otherwise. This is an unverified idea.
• could the loading decision be cached somehow (maybe in a postmeta?) cc @justnorris

Any implementation ideas or other input around this is very welcome. I'll begin by assigning to @no-sws for his take.

cc @maevelander

no need to have all of those functions lying around

A user on the wp.org forum has suggested some improvements - either to the plugin itself or to clarify better within the README.

As a non-developer (ie a user with little programming knowledge) I would welcome some more help in the FAQs with how to do the following (or an enhancement to the plugin to enable the following).

Instead of listing every single post ID that I want to apply Gutenberg to, I would like to be able to apply it to:

• a numerical range of IDs; and/or
• all IDs greater than or less than a particular number;
• a particular post category; and/or
• all posts except an ID (or a range of IDs etc).

One particular option I would like to achieve, as a starting point, is to apply Gutenberg to new posts/pages (ie those with an ID number greater than [X]) but have all existing pages and posts remain in the classic editor, until I have been able to go through and check out what editing, if any, is needed when they are in Gutenberg.

https://wordpress.org/support/topic/excellent-but-would-welcome-some-extra-help-for-non-developers/

I'll keep the wp.org forum updated with any comments made here.

Ramp plugin was approved for .org repo with slug gutenberg-ramp. We had intended it would be ramp-for-gutenberg (inline with the plugin guidelines on project names). Thus we used the prefix ramp_for_gutenberg_ in the plugin. To remove inconsistency, we should:

• Rename files
• Update option stored in r_f_g key
• Update prefix to gutenberg_ramp_
• Update text domain
• Add a wrapper for the old helper function for backwards compatibility
• Update readmes

I use the Classic Editor as a fallback. That is, I check this option:

Use the Gutenberg editor by default and include optional links back to the Classic editor.

This (1) lets me have an "Edit Classic" link and (2) Allows me to pick, when I create a new post, to use the classic editor.

When I activate RAMP and flag it to allow Gutenberg on a post type, it removes that create option.

This means I cannot use Gutenberg as "Recommended but yeah, use the Classic editor if you've gotta" scenario, which is currently the default behaviour with Gutenberg. I know it's not preferable, but in order to on-ramp users more granularly, this allows me to steer them towards Gutenberg while still giving them a comfortable fallback.

Would it be possible to support that?

https://wordpress.org/plugins/manager-for-gutenberg/ does this by making heavy use of removing filters, which I know isn't optimum, but provides a better balance for my medium to advanced technical users who are in the process of ramping up :)

Hey

I just want to cross link this issue as a possibility...
Making it easier to transition to Gutenberg
WordPress/gutenberg#7060

Using Gutenberg on some specific post types it would be good to have the opportunity on the frontend when clicking edit to have it open in either Gutenberg or the classic editor.

Need to make sure edge cases are covered before releasing:

• Does it work in multisite with a sub-directory? site.com/website1
• Does it work in a in a regular WordPress installation with a sub-directory? site.com/website1
• Does it work with a customized wp-admin path ? ( https://digwp.com/2009/07/move-your-wordpress-files-out-of-the-root-directory/

It's nice that we can provide ID's of particular posts to enable Gutenburg on, but I would think in the spirit of "ramping", it would be cool to enable Gutenberg on any post/page/post_type GREATER than a certain ID (or date?). Legacy content gets old editor, new content gets Gutenberg.

Is this possible now? Or would the params that gutenberg_ramp_load_gutenberg takes have to change?

Currently, when Ramp plugin is activated it autoloads gutenberg_ramp_load_critera on each and every page in the admin, including pages like the /wp-admin/ root and wp-admin/plugins.php

As a result, this query happen on each admin page load:

SELECT autoload
FROM wp_options
WHERE option_name = 'gutenberg_ramp_load_critera'

I see 2 possible improvements we can make here:

1. Don't use autoloading for Gutenberg Ramp options - we only need the option in edit.php

2. Only check for Gutenberg in pages where it's likely that Gutenberg can appear, like edit.php and posts-new.php, etc.

Any thoughts on this?