I tried to find some tips in the forum but was unable to so need to ask.
I am keen to create sites with little to no additional plugins - let the theme do all the work. But I’m not sure about custom post types. I like the idea of creating these in the theme but if the theme were to ever be replaced, it would all need doing again. So, would it be wiser to use a CPT plugin like Metabox or Advanced Custom Fields to handle them? Are there any downsides to this, apart from plugin bloat of course?
If it’s better to use a plugin, which one(s) work best with Pinegrow? Or do they all fit nicely?
Did you know that: With Pinegrow, you can build blocks plugins, but also utility plugins with this kind of feature?
New Page or Project > Plain HTML > index.html > will be a perfect choice
Save Page in a dedicated (empty) folder
Confirm that you want to open the folder as a project
From the WordPress tab, Activate WordPress > This will open the WordPress Theme Settings
Set the project type as Plugin
Set the plugin name and plugin slug
The plugin folder > local folder on your computer > ideally a folder located in the plugin folder of the local WordPress instance you use during the development phase.
Add any HTML element to your index.html document (a DIV for example, see the following screenshot)
Add the Register Post Type action (and configure it according to your needs)
Export your plugin
Activate the plugin
@sitestreet While I like @Emmanuel’s creative approach, I’m not sure it makes sense to try to use Pinegrow to create a plugin that only adds a CPT. The last time I checked, there were eleventy-bajilion WP Code Generators that can spit out CPT code for you. Creating a plugin to install it is a piece of cake.
Of course, Emmanual is an official Pinegrow voice, and I’m just some random internet dude. So take that for what it’s worth
Of course, using the same process, you can integrate as many custom post types you want/need, your gutenberg blocks, your taxonomies and so on in the plugin. In short, everything that fits in a plugin rather than a theme.
I just wanted to say that it is not always necessary to look elsewhere for what you can find in Pinegrow. But the opposite is obviously neither forbidden nor inadvisable @adamslowe there are no small voices and big voices here, all advice is good to take
Thanks @Emmanuel and @adamslowe for the excellent replies. I like the idea of splitting the project into a theme and a plugin so I can create the CPTs without a huge plugin but also keeps it separate from the theme. I’m sure there will be other elements which the site needs which would sit better in a plugin, too, so I can just build it up as needed.
Just to check on my other question. If I were to use a CPT plugin, are there any preferences as to which to use with Pinegrow? I’m thinking the options are Advanced Custom Fields, Metabox, JetEngine or Toolset. I’ve used all four in the past but not with a Pinegrow-built theme.
I don’t think ACF offers the creation of post types. I don’t know about the others.
Otherwise, you also have Custom Post Type UI – WordPress plugin | WordPress.org
You’re right. I always use CPT UI with ACF as a combination so that’s what I was referring to.
Does Pinegrow play nicely with them all or would there be lots of custom code requirements? I’m trying to see if there is a variable syntax for using them on a page.
Pinegrow will not cause any problems with CPTUI, but will not offer the opportunity to retrieve post types that it has not created in smart actions (for example to create custom queries).
You will have to enter by hand the name of the custom post type you want to use/display.
Im using metabox together with Pinegrow and it works like a charm.
I normally also create CPTs and fields inside metabox just because of the purpose to visually edit it. But that can only be done if you don’t plan to reuse your theme.
I think it’s more a matter of what you like and to what you’re used to than anything else
In one project i also had to export a plugin, so what I did was requiring metabox via composer and created all necessary fields and CPTs and so via the php function, that ensured that I can install the plugin on other websites and still have everything available i need on plugin install
ACF and CPT UI user here… I have a local install with those plugins. I set up the fields and CPT’s in the local install. Use the export (or copy) functions in either plugin and paste/update my own plugin to client sites.
I have not yet, but I will try out the Pinegrow way @Emmanuel showed (I think it tried it once while following an early PGWP tutorial and it worked great) because… less dependencies, less (hopefully) risk of conflict and in general, it’s probably just faster for the basics and why not build everything in PGWP (I’m speaking of the PG desktop editor, I just got access today to the PGWP plugin and am about to dive in to that).
And if you’ve never bought a subscription to MetaBox, Toolset, ACF Pro, why bother if you can handle what you need in the PG subscription.
Whatever you decide don’t use Toolset. It is an amazing plugin that I’ve used for over 10 years but they have stopped developing it and are only providing bug fixes. It’s on its last legs, unfortunately.
Yep, I have a lifetime license for Toolset and have used it for nearly as long as you. They seem unsure as to how to work with Gutenberg Blocks so have put a hold on everything until more is known. My take is that they might resume things. However, once you show any signs of a possible end, everyone abandons ship and you can never really get back to where you were.
I also have licenses for Metabox and ACF but am still undecided on which I prefer but using none of them when using Pinegrow really appeals to me.
In slight defense of Toolset (I’m also an owner, it’s great for some specific projects), they did say that they are watching and waiting to see what is going on with WP (Gutenberg) and I expect they are going to do a major rebuild/upgrade. They already kind of split how Toolset can be used, and I’m sure they don’t want to maintain multiple versions (ways of doing the same thing really) until a few things play out. Perhaps their sales and love for it all have slowed to the point that they don’t see fit to stay in it, but I more suspect they are just waiting out the reinvention of the (WP) wheel before adding any more cogs to it.
And along that line, they did say in this following blog post, that we should not expect anything new, only fixes and general updates, for the next 18 months (post was from about 6 months ago, June 2022): What's Next For Toolset - Toolset — that’s more than most would say.
In the meantime, if you haven’t used Toolset before, I’d probably not start now. Especially if you use Pinegrow.
Meant to ask this of you at the time I first saw your post but got sidetracked.
I’ve used Metabox in various little plugins I’ve built via the composer route and it works nicely but I hit issues when one WP site I loaded my plugin into as part of the build later hit issues because the end user went on to install MetaBox themselves. It bought back ‘happy’ memories of the old .nett dll hell days of old.
Now it’s entirely possible that I really didn’t structure my own plugin to work properly but nowadays I tend to create all my MetaBox stuff directly in code and then just install a fresh copy of MetaBox for the end user. That way my stuff can’t be altered and they have the freedom to use it if they want.