Meta Box

Hi,

It's confusing URL structure. If a user access domain.com/information/security, is that a post or is that a category? We always don't recommend people doing that. Even if it works in some cases, it will be bad for performance, cause WP need to process through all posts and also terms.

FYI: We don't process or generate the rewrite rules. We simply pass all the parameters to WordPress's register_post_type and register_taxonomy functions. I don't think it works if you use code directly. It's mostly how to deal with the way WP handle rewrite rules than the plugin. I'll check more closely.

Hi Bluemoon75,

I replied in the other thread, I think it's useful to repost it here as I think it's related to your issue.

---

Regarding your issue, I think the problem was in the 2.6.x version of MB Custom Post Types & Custom Taxonomies plugin. We released version 2.6.0 which had a new feature to allow you to edit post types registered in WP core (like post and page) and post types registered by other plugins. The way it works is replicating those post types in the plugin's post type list, so you can edit them as usual.

I *guess* in your case, when you upgraded the plugin, it replicated some post types registered by other plugin. Those post types had some rewrite options that were available in MB Custom Post Types & Custom Taxonomies and caused the bug.

We reverted this feature in 2.6.2, but the replicated post types are still in the DB.

One way to resolve this is go to Post Types and remove all post types that were not created by you manually. The other way is what you did by updating the settings for them.

I hope this clarifies things and what happended behind the scene.

We've just released a new version with a fix for this. Please update.

Hi,

You must put the credit on your project page. If you have a product page on your website, you need to put it there. Or if you sell on Envato, you should put on the item's page.

You don't have to put on the front end of all your users's website (as you're using MB Frontend Submission extension).

If you sell the product to a 3rd party, if they only use for themselves, then it's ok. But if they release a product that is sold to users, they'll have to follow this rule as well.

Hi Arno,

I'm trying to replicate the bug on my localhost but I don't see the error. I recorded a screencast, please take a look:

https://mega.nz/file/rvgFFAbL#DRCDlXxp4MIdjAx37dpL6T0v2W_DPXavAv42GeSGTns

Hi,

I've fixed this bug on our site. Please try again.

Can you please explain why do you need other screens? I don’t see any reason here.

Hi Brandon,

Thanks for your feedback. After investigating, I found that there was a change in WP:

Previously, the block template was parsed in the following orders: do_blocks, then shortcode_unautop, then do_shortcode. But this order was changed in these 2 commits:

https://github.com/WordPress/WordPress/commit/6a077b35f15590a843ff8a6c97a135f3a34872dd
https://github.com/WordPress/WordPress/commit/2bb3a5169548d16173cf48ca9da1111efc428f86

So the order now is shortcode_unautop, do_shortcode, then do_blocks.

The problem is that the MB Views shortcode in the block template is the core/shortcode block, which applies wpautop (I have no idea why do they do that):

https://github.com/WordPress/WordPress/blob/master/wp-includes/blocks/shortcode.php

So, when parsing the a block template, the MB Views shortcode is parsed first (via do_shortcode), and then is applied wpautop (via do_blocks with core/shortcode block), and that causes the problem. Previously, they do_blocks first, and then do_shortcode, then it didn't happen.

As this is in the WordPress core, e.g. after the content of views are rendered, I think the only way to resolve it is removing line brakes in the plugin. This is what I'll do in the next version, so you don't have to do that manually.