Cristian

@clorith I’m using WordPress as a headless CMS for a React app which fetches the content from WordPress using the WP REST API so using the show_in_rest setting to “opt-out” of Gutenberg is a bad idea.

@keraweb I totally agree with you that Gutenberg is a step in the right direction for bloggers writing blog posts but Gutenberg developers need to understand that a lot of people also use WordPress as a CMS with ACF fields. And the current implementation of custom fields is pretty poor.
Gutenberg will never replace custom fields because saving everything in the post_content field doesn’t work for websites that require structured data.
For example, if you were to build a website like IMDB or GoodReads then Gutenberg will only get in the way.

@ogalinski

I don’t see how clicking a “+” button that never changes its position is slower than clicking buttons in different positions in the past.

In the Classic editor I don’t need to click any buttons to write text.

Time-consuming: a click for each block instead of just writing. More clicks equal wasted time.

I totally agree with this.

I personally always use the WordPress Classic Editor in Text mode – nobody wants to waste time inserting paragraphs or creating <p> tags.

• This reply was modified 6 years, 3 months ago by Cristian.
• This reply was modified 6 years, 3 months ago by Cristian.
• This reply was modified 6 years, 3 months ago by Cristian.

I had the same issue. Unfortunately the name of the sitemap is hardcoded so the only way is to change it in the plugin code. And if you change it in the code then it will get overwritten every time the plugin is updated.
The proper way would be for the plugin author to add an option in the plugin settings or define the sitemap name in a constant so that at least you will only need to change it in one place.

I have Elasticsearch 6.0.0-rc1 installed and I get the same warning. I’d also like to know if ElasticPress will work or not.

@bcworkz How can I generate a nonce from the front-end using React and will the WP REST API recognize that nonce?

@t-p Thanks for the suggestion but I don’t want to disable the REST API as my web app is actually using it

I’m referring to exposing “_wp_old_slug” in the REST API.
I tried using register_meta like below but it didn’t work for custom post types:

add_action( 'rest_api_init', 'expose_old_slugs_in_api' );

function expose_old_slugs_in_api() {
  // Get list of all post types except 'attachment'
  $post_types = get_post_types( array( 'show_in_rest' => true, 'show_in_nav_menus' => true ) ) ;
    
  $args = array(
    'type'          => 'string',
    'single'        => false,
    'show_in_rest'  => true
  );
  
  foreach ($post_types as $type) {    
    register_meta( $type, '_wp_old_slug', $args );
  }
}

@bcworkz WordPress automatically saves the old post slugs in the database.

• This reply was modified 7 years, 3 months ago by Cristian.

Here is a screenshot of the error message: https://www.tiikoni.com/tis/view/?id=f26bae7

The error might have something to do with that I originally created that field of a Numeric Type and later changed it to Image Type.

I just got the same exact error:

Warning: Cannot modify header information – headers already sent by (output started at /home/www/mycompany/company_page.php:1) in /home/www/mycompany/wp-content/plugins/bad-behavior/bad-behavior/screener.inc.php on line 9

Yes the error disappears when W3TC is deactivated.

The Plugin page says “This plugin is in the very beginning stages of development.” so it sounds like it’s definitely being built.
It’s pretty exciting!

Hi Frederick,

It would be great to have hooks to allow W3TC to not cache static components.
Will this feature be released in the next version of W3TC?

Thanks.
Cristian

Hi Frederick,

yes W3TC cached the page again after I emptied the browser cache which makes sense.

Thank you