Improve support for CPT and CTT

[bredecl]

Hi
I made some improvements for the bones cli and content

• Added support to ask yes or no and returns a string to be used directly in stubs
• Better code for CPT, so now generates automatically the default name, plural, slug based on name
• Added a function to avoid create a post_type name larger than 20 characters (as described here: https://developer.wordpress.org/reference/functions/register_post_type/ )
• Added support to set showInRest and showUI directly supports in CPT
• Added a default icon for the stub of CPT, so we avoid the empty space
• fix to avoid loop the menu -> items when is empty
• Added support to show an example on ask method
• Added support to pre-fill the data on CTT
• Allow multiple Post Type support to CTT
• Added support to set showui by default on CTT
• Added support to manage CPT trash event.

[gfazioli]

@bredecl hey, thank you for the PR 🙏 - where is your previous PR about the database?

[bredecl]

@gfazioli I deleted it, it wasn't working as I expected, but I will work it again in it.

[bredecl]

@gfazioli hi!
I was wondering, why we should use an own database class instead of illuminate/database?
Is there any scope about the package size?
I manage to solve partially the relations (WIP), but still think the illuminate/database is the best approach (so we don't need to do again something that already exists).

I look forward to your feedback

[gfazioli]

@gfazioli hi! I was wondering, why we should use an own database class instead of illuminate/database? Is there any scope about the package size? I manage to solve partially the relations (WIP), but still think the illuminate/database is the best approach (so we don't need to do again something that already exists).

I look forward to your feedback

Yes, illuminate/database is definitely better. However, I chose to leave it out as a separate package to install because the issue is that being in a WordPress environment, this can cause some problems:

1. Package size issue: not all users require complex database-level features. They can use the functions already provided by WordPress or utilize the lighter Bones part, which still allows for many of the basic operations that most plugin developers need

2. The latest version of illuminate/database requires PHP 8+ and some users have hosting and plugins that only work with PHP 7.4+ (All wp bones boilerplates require only PHP 7.4+)

3. Since illuminate/database is public and managed by Composer, no renaming is done on the namespace. Using Composer packages in a WordPress environment can cause issues. For example, if there are two plugins that both use illuminate/database, only one of these will be loaded and used

[bredecl]

hi @gfazioli
Perfect! I will work based on that, also to try to achieve better relationships between tables in WP Multisite.
Also, regarding the namespace renaming… wouldn't it be better to keep the wpbones namespace separate and allow the user to construct with their own plugin namespace?
I'm also thinking about working on a kind of Storage (based on WP Settings) to keep Laravel's methods like disk, put, sizes, and others.

[gfazioli]

@bredecl

Also, regarding the namespace renaming… wouldn't it be better to keep the wpbones namespace separate and allow the user to construct with their own plugin namespace?

What do you mean exactly?