A little under six years ago, I wrote up a post for the WebDevStudios blog celebrating and retrospecting having achieved one million all time downloads. I also went into some details about growing pains experienced and lessons during that process. It is a post that I feel still holds up today and I am definitely proud of it.
Today I am writing a new followup to celebrate another milestone. At the time of this writing, Custom Post Type UI is on the verge of achieving one million active installs.
In my post above, we were at 200,000 active and sporting a 4.6 out of 5 rating, with 87 5-star ratings.
Right now at the time of this writing, we have moved up to a 4.7 out of 5 rating, and 199 5-star ratings.
On top of that, we’re now at 7,960,438 all time downloads.
I think it is a testament of a solid product and support system that we have continued the stellar reviews and increased our overall calculated rating of the course of six years.
Observations and reflections
I can never claim this plugin as my own, as it very much is owned by WebDevStudios. However, I am able to say that I’m still the only active core developer of Custom Post Type UI. We really don’t need a lot of hands on deck for its development, and I’m happy to maintain this role.
There’s not a huge amount of moving and shaking by WordPress core around the topic of post types, so Custom Post Type UI has managed to remain largely stable with each release. Usually the biggest changes are in the form of newly available labels for post types or taxonomies.
One million active installs is most definitely nothing to sneeze at, and I need to stay vigilant with what new features and development I do make. While it never actually happens, can you imagine suddenly having one million new support forum threads or replies chiming in about how a detail broke their website? Or caused them to lose a healthy amount of income that they rely on each day? NO PRESSURE MICHAEL!
New lessons learned
One thing that has always intrigued me is how people use Custom Post Type UI, or are lead to it as a plugin of choice.
Every now and then, myself or our Marketing Specialist Laura Coronado will stumble upon a media mention or a tutorial of some sort that is making use of custom post types. Custom Post Type UI gets utilized for easing the tutorial readers into a quickly spun up post type, so that they can continue onto the rest of the tutorial.
Sometimes people, myself included, make use of it as a code generator, using our “Get Code” functionality that outputs the post type and taxonomy chosen settings into a ready-to-paste format for a custom plugin or the
functions.php file for their active theme. We’ve long valued helping keep your content yours with portability as a consideration. People just happened to also realize that this is also a form of a generator.
Then, sometimes, people are “lazy” in good ways. They know full well how to register their own content types via code, and perhaps even have their own helper libraries to achieve that and like having these version controlled. But, they still sometimes make use of Custom Post Type UI for their own purposes or their clients sites.
I know through my own time with Maintainn it can very often be preferred to make use of settings and UI based options for changing settings and configuration, over dropping a bit of code in a file somewhere, that may or may not be easily found. If you’re not guaranteed to always be the one handling a site, making it easier for the people after you to find configuration is a big help. This is no different than utilizing Custom Post Type UI as well.
Continued superb support is no doubt a key driving force for a growing active install base. If the support is sub-par or worse, people are not going to want to keep using it, and they are not going to recommend to their friends or their clients. Content writers who are helping others learn how to make the best use of WordPress are not going to use and recommend the plugin within their tutorials. It just would not be good.
This is why I always strive to provide the best support I can with every person who starts a thread or contacts via the support form over at Pluginize. It comes with the territory that a healthy amount of the questions we get asked are along the lines of “How do I do this with custom post types?” and not always “How do I do this with custom post types registered with Custom Post Type UI?”. From the very start, we inherited the need to be knowledgeable about post types and taxonomies in general, and we happily accept this responsibility.
We know our plugin does not handle everything under the sun with content types. We are going to be a piece of the solution, we are not the entire puzzle. Regardless, with every support request we receive, if it’s for something we don’t handle with the plugin itself, we still try our best to provide resources and potential solutions that the person can explore further. If it’s potentially an issue with a different part of the site, for example integration with a third party page builder or tool, we recommend reaching out to those products’ support channels but remind that if there’s something we need to do on our end, this person can come back with the feedback so we can lend our help as best possible.
A product is never going to sustain a perfect 5 rating forever, and sometimes it’s just not going to be what a person is expecting, necessitating a lower rating. It’s my personal goal to always maintain that the lower rating is not received in part because of subpar support attempts.
What is in store for the future of Custom Post Type UI is a great question.
It’s very tempting to just hold the proverbial fort here, and keep things as stable and rock solid as they already are. At the same time though, that’s not as fun. I know of one primary “sticking” point that come up from time to time in our support requests, and that is internationalization.
I want to state this upfront that it is not a promise, but is an intent to more actively see what we can do and what can be done.
Keeping things internationalization friendly with Custom Post Type UI, most specifically the labels as well as the rewrite fields presents a challenge because of the fact that we do store our settings in the database.
I know that tools like WPML and Loco Translate exist, among probably various others. However, I don’t necessarily want to directly tie Custom Post Type UI to any of them and create a dependency. All those other tools may also be moving at a quicker pace than we maintain, which is awesome for them, but not necessarily for us.
Longer term, I believe I’d prefer a more homegrown solution that we provide on our own. We don’t have a huge amount of fields to worry about which helps keep maintenance costs minimal. The bigger question is how to build it all out.
Perhaps I’ll dust off this very early attempt below, to start internationalization in Custom Post type UI as part of an upcoming #5FTF
If things went well, it wouldn’t be permanently an extension of Custom Post Type UI, it would end up getting merged in to the core plugin for everyone.
At the time of this writing, we are on version 1.9.1 of Custom Post Type UI. Beyond the internationalization topic above, I’m not quite sure what I may want to have as part of a version 2.0.0 release. Typically changes in the first number for a product’s version indicates “HUGE” changes. WordPress core got the block editor with 5.0.0 for example, and that’s no doubt had ripple effects we will see for awhile.
What could Custom Post Type UI do in the same vein? Do you have any ideas? Cause I’d love to hear them.
I remember it being a proverbial wild ride at the one million all time download mark back in 2015, and that hasn’t changed in the years since. Out of everything with my time at WebDevStudios, the ongoing development and support of this one plugin is something I’ve always taken great pride in and will continue to take pride in for the foreseeable future. I appreciate the trust and faith that Brad Williams and Lisa Sabin-Wilson have continued to put in me to represent WebDevStudios here.