I don’t want to train something else to code, I want to learn and teach myself how to, including how to continue learning how to break down and dissect the logic and processes and patterns.

If I don’t understand the code that has been spit out at me, I can’t be certain that it will for sure work at all, work well, work efficiently, work securely.

I don’t want to train something else to write, I don’t want to feed other peoples works to train something else. I want to continue to learn how to clearly and effectively write and communicate myself. I would never be able to train some AI to effectively communicate with a client better than I already know and work with the client.

Tools come and go, fads get in style and then quickly get out of style. What will always be persistent is myself with my knowledge at that time, and my ability to grow myself, instead of some machine.

One of the joys with my day job at WebDevStudios is the chance to work with and support Algolia Search. I’ve even posted about it a few times in the past here on the site. You can check those with the “algolia” tag.

Not only did I get to work with it for clients, but I also get to be a primary developer of the WP Search with Algolia plugin, and the Pro extension that is bringing in some extra functionality so that you don’t need to do some of the coding. Both plugins keep me on the front lines of working with Algolia and helping site owners power their own site’s search experiences.

However, there have been times where I’ve found it a little difficult to accurately troubleshoot things, or wished that I had a quick way to check on the current status of content inside any given Algolia index and it’s configuration. This got me thinking, and I remembered how I created my own plugin that extended the Query Monitor plugin for the GiveWP donation platform.

Thus, with #5FTF time, I came up with Query Monitor Algolia. You can download it at the link below.

https://github.com/tw2113/query-monitor-algolia

However, before you go do that, let’s go over what it gathers and shows you all in a couple places.

Constants

You will be able to see the value of these available constants:

• ALGOLIA_HIDE_HELP_NOTICES
• ALGOLIA_SPLIT_POSTS
• ALGOLIA_CONTENT_MAX_SIZE
• ALGOLIA_INDEX_NAME_PREFIX

Index settings

You will also be able to see the currently configured settings for:

• Settings for each index associated with the site, or for the current site, if you have a multisite.
•  

Statuses

Lastly you will see a panel that provides all the information below.

• Used template path
• Currently viewed content post type
• Currently viewed content’s index-able status. Can it be indexed?
• Currently viewed content’s indexed status. Is it indexed already?
• Searchable post index enabled
• All of your Index-able post types
• Current indices, including last updated time.
• If the API is reachable
• Autocomplete configuration(s)
• Search style. Is it backend, is it Instantsearch?
• The prefix set for your indices.
• Is “Powered by” enabled.

In terms of client work, I haven’t had a chance to really give it a try, but in terms of just testing things out locally, it seems to be working pretty well.

I know we have another #5FTF coming up on the 29th, so hopefully I can start focusing on getting some integrations added around WP Search with Algolia Pro.

When setting up WP Search with Algolia you will see various available content types to include with your Autocomplete configuration. Most of them are available post types, many are also going to be various taxonomies, and even users can be indexed.

However, one of the available post type based options is one labeled “All Posts”. This is a bit of a “shortcut” that will index and utilize all of the post types that are registered as searchable. If you’ve configured your search settings, this Autocomplete setting will use the same $prefix_searchable_posts index..

If you’re only wanting specific post types to be considered for autocomplete, you should not also include “All Posts”.

Out of box, the Autocomplete template is going to show each content type in its own section. If you were to select “All Posts” as well as other individual post types at the same time, you’re going to be doubling up on content being indexed, as well as risk showing duplicate results in the different sections.

In short, if you want to have the widest search with the least amount of work, when it comes to post type content, use “All Posts”, however, if there are any that you don’t want to include, either set them to non-search able, or selectively choose which to include in your Autocomplete configuration.

In the past year, I really got to up my experiences and skillsets with Algolia Search, specifically through WebDevStudios’ maintained plugin WP Search With Algolia. This is thanks to a nice little handful of clients that all brought their own needs and usecases for the search application and Saas.

One thing that I felt WebDevStudios was kind of leaving on the table was WooCommerce integration. However, that doesn’t mean that we’re necessarily going to add WooCommerce portions to the core plugin. Instead I grabbed the brass ring with a specific client project to learn how to do WooCommerce integration with what was already available out of box. I then turned that into a three part post that was posted to the WebDevStudios blog. Thus the purpose of this post there. Cross posting!

You can find the three parts at the following links:

• Settings and Configuration for WooCommerce
• Autocomplete and Instantsearch Customization
• InstantSearch Widget and Facet Customization

It is most definitely not the end-all-be-all of WooCommerce customization, but I definitely hope it’s a solid starting point that can be iterated on and built upon based on everyone’s needs.

I am very proud of my own education and knowledge development in regards to Algolia Search and know that I’ve learned even more since I worked on the project that birthed the blog posts. I’m excited for what I can document and provide in the future.

Over the past year and a half, I’ve gotten to work with Algolia Search a lot. Whether it’s been through client work wanting to integrate their content through Algolia, or myself helping handle support on the WP Search with Algolia Github and Support Forums, I’ve been able to dig in a lot more with how it all works.

About five months ago at the time of this post, someone posted a thread named “Use of Algolia in two different parts” and what they were looking for is summed up as such:

I have 2 separated search boxes.
one search box for products.
one search box for blog posts.

Admittedly, I didn’t have an answer for him at the time, but I didn’t rule out whether or not it was possible. I’m also not posting here today saying that I’ve finally sat down and worked out how to do what this person was asking about. I am posting a similar solution that sort of fits what they were going for.

What I’m going to do here is show how to conditionally change the sources that Algolia AutoComplete will consider, depending on WordPress conditionals.

Setting up our conditionals

For our tutorial here, I only have Autocomplete configured for the post post type and the page post type. You’ll need to configure things further in the event you have more than just those two, to make sure the rest are still considered.

Say that I only want to have Autocomplete suggest blog posts when viewing the blog posts page, a single post, or the category and tag archive. To achieve this, we’re going to add some inline script that stores a javascript constant of Autocomplete indexes to search.

function algolia_support_conditional_sources() {
    $desired_sources = [];

    if ( is_home() || is_single() || is_category() || is_tag() ) {
        $desired_sources[] = 'posts_post';
    }

    wp_add_inline_script( 'algolia-autocomplete', 'const wanted_autocomplete_sources = \'' . json_encode( $desired_sources ) . '\'; ');
}
add_action( 'wp_enqueue_scripts', 'algolia_support_conditional_sources' );

Here we are constructing a PHP array that stores the index ID for the posts autocomplete index. You can find the index IDs listed as “index name” when you visit /wp-admin/admin.php?page=algolia in your own website, and check the “Index” column.

Now, say I want to do the same for pages, where when on a page, only make suggestions for other pages. We do very similar to what we did above. Below is an amended version of our callback.

function algolia_support_conditional_sources() {
    $desired_sources = [];

    if ( is_home() || is_single() || is_category || is_tag() ) {
        $desired_sources[] = 'posts_post';
    }

    if ( is_page() ) {
        $desired_sources[] = 'posts_page';
    }

    wp_add_inline_script( 'algolia-autocomplete', 'const wanted_autocomplete_sources = \'' . json_encode( $desired_sources ) . '\'; ');
}
add_action( 'wp_enqueue_scripts', 'algolia_support_conditional_sources' );

Customizing the autocomplete.php template

Now we’re ready to make use of this information. You will need to customize the autocomplete.php template file that we ship with the plugin. You can read more about how to do that at Customize the Autocomplete dropdown wiki page

By the time you read this blog post, version 2.3.x of WP Search with Algolia will very likely already be released, and for the tutorial I’ll be using the autocomplete.php copy from that release.

We want to find the lines that look like this:

/* Setup autocomplete.js sources */
var sources = [];

and add the following right below it.

/* Setup autocomplete.js sources */
var sources = [];
var desired_sources = [];
if (typeof wanted_autocomplete_sources !== 'undefined') {
    desired_sources = JSON.parse(wanted_autocomplete_sources);
}

Here we are setting up an empty array, which will be important, and then also checking for our inlined constant declared earlier. If we have the constant, we are parsing its value out from its JSON. This should give us a populated desired_sources array now.

Only one more line down, you should see these:

algolia.autocomplete.sources.forEach( function( config, i ) {
    var suggestion_template = wp.template( config[ 'tmpl_suggestion' ] );
    sources.push( {
        ...
    } );

I have truncated a little bit for brevity. Here we will see a foreach loop running on all of the autocomplete sources that we’ve configured for the install. In this case, it’d be only post and page. What we need to do here is wrap the sources.push( { ... } ) calls in an if statement to start conditionally pushing our sources to look in.

if ( desired_sources.length === 0 || desired_sources.includes(config.index_id) ) {
    sources.push( {
        ...
    } );
}

Here we are checking if we have any desired sources configured at all. If no, then we push them all. This helps prevent NO sources being available in case of none conditionally set earlier. Finally we check if the currently iterated config index_id property is one of the ones in our desired sources. If yes, push that source.

If all went well, then I should now only be able to see blog posts suggested when on the blog page, single posts, or category/tag archives, and only see pages when on blog pages. Goal achieved!

Let me know of any questions you have in the comments.

I am one who has always rolled with the changes for myself at WebDevStudios, and that hasn’t changed yet, as we’re well into 2022.

Back in May of 2013, I received a mini-promotion and started taking on responsibility for support and development of WDS‘ free plugins, including the massively popular Custom Post Type UI.

In March of 2015, I went Insane in the Maintainn and was moved out of the agency side of WebDevStudios and into the support and maintenance branch of our overall services. A position that I had held well in to 2021. More on that in a moment.

Some time in 2015, the higher ups at WebDevStudios decided to finally pull the proverbial trigger and formally start a products division for WDS, and it was named Pluginize. Not only were we delving into the world of premium products, but we were also continuing the development of our free products under that banner as well. Since I was already so ingrained in many of these areas, I was brought in as one of the developers and still lead support engineer with Pluginize. We had a products manager, dedicated engineers, and I had a lot of fire in my belly because I have always enjoyed helping make tools that help others make websites.

However, I wasn’t exclusively doing work on Pluginize. I was actually splitting my time between Pluginize and Maintainn. Over time though, the Pluginize side slowed down, and while we never shut down by any means, we weren’t as actively working within that brand. It went into “hibernation” so to speak, and the team was largely just myself, continuing to work on products as need arose and when able, adding in new features. I never stopped with the support and we were still getting enough trickles to keep my finger on the overall pulse. We still had Custom Post Type UI growing at impressive rates and it’s more popular than ever (No pressure Michael!).

So Pluginize was a team of me, with majority of my time still focused on Maintainn’s client base…until late 2021. That October, decisions were made and Maintainn’s team was cut in half. This was a notable shock for everyone involved, and definitely put a fair amount of stress on me as well since I was now the sole dedicated support technician for our workload at the time. Other engineers within the company were definitely available as able to help out, but in terms of longevity and client familiarity, it was largely just me for the on the ground development work. Thankfully we still had others helping handle all the routine tasks that we advertised as part of our weekly services. Things in our support world were evolving, and as always, I did the best I could going forward, and things evened out over time. As it was put, the separate brand was being moved officially back in to WebDevStudios and instead of being a “separate entity”, it was now all part of one.

March of 2022 ushered in the next notable shift in Maintainn and our support program. We let one more person go, reducing us from four people to three, but on top of that, we were being “split up” to a degree. We were all thankfully employed, but our positions and primary focuses were going to be changing. We still have a client base who purchase ongoing support and are able to buy hours for custom development, but that base has also been reduced down as well, as there have been services partings along the way. As things come up, I’m still the one providing estimates as needed and when approved, handling the work. Others are continuing to handle routine updates and sysadmin style work as needed. So the support team not dead, per say.

Internally I have been moved to a new team on the agency side, and I will once be helping with clients and retainers on the agency side. That’s going to be part of my week. The other part of the week is allowed to focus more extensively on Pluginize and our products there. To say the least, this has me excited, because that proverbial hibernation is starting to wake up. It’s still early in this phase, but I know I have already made some great headway with Pluginize in 2022, including Custom Post Type UI Extended and its first proper WordPress block. I am loving being able to dedicate more of my time to Pluginize and give it much more active care, along with being back in the agency fold to help with retainers that my new team is being brought in to.

I’ve been with WebDevStudios officially since the start of January 2013, “unofficially” since September 2012 with a long-ish trial period. That means my 10 year anniversary is not far off in the horizon and if all goes well, I’ll still be around to celebrate it. Until that day arrives, I’ll keep rolling with the changes.

Have you ever been working with the WordPress Block Editor and your content and realized that you’re repeating a lot of the same layouts, or have routine content types that need to follow the same consistent layout? If yes, have you been doing a lot of copy/pasting of the blocks to try and make sure they’re as consistent as can be each time?

My friend, I am glad you’re here because I am about to show you how you could make your work a whole lot easier. Instead of copy/pasting and hoping that you’re getting all the details right each time, instead you could make yourself what’s called a Block Pattern, and have everything re-usable and configured upon click to insert the pattern.

In this post, I am not going to go into how to make a block pattern, you can read more about that over on How to Create and Register a Block Pattern. What I am going to discuss here is a quick difference between block patterns vs reusable blocks, and then also provide some quick examples of how I’ve used block patterns over on my movie blog Up All Night Movies.

Block Pattern vs Reusable block

Something to keep in mind is that these terms are not interchangeable. They do vastly different things. As per the “How to use WordPress Block Patterns” page over at learn.wordpress.org:

Reusable blocks are blocks or groups of blocks that are centrally managed within a site. Making changes to a reusable block affects all instances used across the site. This is particularly helpful if you have content that will be used in multiple locations across your site and want to be able to manage updates from a single location.

Meanwhile, a block pattern is this:

Block patterns, on the other hand, are registered through WordPress Core software, themes, or plugins. In many ways, block patterns act as starter content to include in a post or page.

Block patterns are created by WordPress developers with the intention that the site owner or user will update, customize, and change these patterns once inserted into a post or page.

Changes made to a block pattern do not affect the registered block pattern or any other content that using that particular block pattern.

Since we would not be wanting to have only ONE instance, and instead be able to edit for each post uniquely, we definitely want to make use of Block Patterns.

Up All Night Movies

Last summer, I decided I wanted to start a blog about movies. Not just any movies, or popular/Oscar nominated movies. No, I wanted to write about the “bad” movies from the past. Whether they be just extremely low budget, extremely campy, cult, b-side, etc. You get the idea.

With this, I also decided that I wanted to get some reader participation involved. I knew that friends Harmless Entertainment had monthly movie polls that they post for their listenership, and then Thoreau and his friends all watch the winning movie and then discuss it for their podcast. This is a Patreon exclusive thing for them for those wanting to help support the show. The reason I bring this up is because I liked the idea of user voting, instead of me just picking whatever I may feel like writing about at the time.

Links, Poll, and descriptions, oh my.

To help with this process, I create a poll that has its own block available, as well as link to corresponding IMDb pages for each movie. Eventually I also started adding in quick movie descriptions for each movie. This way, visitors can easily assess the chosen 4 movies each time, and hopefully cast a confident vote.

Because these fields were being used regularly, I turned them into block patterns for easy insertion and I just need to edit little details afterwards.

Eventually the polls end, and we get ourselves a winner. It’s at this point where I will watch the winning movie a couple of times, do some research, try to find interesting trivia and tidbits about the film, and write up a hopefully funny, not at all serious “review” of the movie. All for the sake of entertainment, and if lucky, encouraging someone else to check the movie out.

After the post is written

This is where my last block pattern example comes in. At the end of each writeup for a given movie, I will provide a few more extras including the trailer once more, as well as links to where someone can stream the movie. For this, I make use of the Youtube block and by default list out services like TubiTV, Amazon Prime, Netflix, and Shudder. In the future I may switch to just linking to a service like JustWatch.com which is a streaming aggregate service. We’ll see.

These are just some examples of ways that you could make flexible, reusable blocks for things you’re posting consistently and want to retain that layout/formatting consistency each time. Ultimately they are just individual block elements grouped together with settings being able to be saved and inserted in wherever needed.

What are some ways you’ve found block patterns useful in your own content? Or what are you thinking about making a pattern for, with your own site, after reading about these above? Would love to hear about them in the comments.

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.

https://webdevstudios.com/2015/07/17/the-custom-post-type-ui-million-download-celebration/

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.

Quality support

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.

The future

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.

Internationalization

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

https://github.com/tw2113/custom-post-type-ui-i18n

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.

Version 2.0.0

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.

Conclusion

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.

 

https://wptavern.com/a-throwback-to-the-past-introducing-the-blogroll-block-wordpress-plugin

My #5FTF participation kind of sputtered out in the last half of 2020. This is not necessarily a bad thing, as most of it was either because I had higher priority client work to take care of, or holidays and PTO happened to fall on the same days and I looked forward to the extra time away.

That said, I’ve come roaring back, so to speak in 2021, though I didn’t document January’s event. Today I feel that I accomplished quite a lot.

Blogroll Block

I recently had my Blogroll Block plugin approved for inclusion in the WordPress.org plugin repository, and after a brief delay in getting the SVN repository set up, I was able to get this handled. Blogroll Block 1.0.0 is officially available for download, and hopefully soon it will also appear in the Block Directory. It’s my understanding that this is a special area of the plugin repository for plugins that do only one thing, and that’s provide a block. The items listed there are also searchable and install-able right from the editor screen when creating content, assuming the user has the right install capabilities. I’m very excited about this prospect.

On top of releasing the code for Blogroll Block, I also decided to dust off whatever graphic design skills I still have, and create a new icon for the plugin. I tried to keep it simple, with just a scroll that’s unrolled a little, and an abstracted “list” of items on the rolled out portion. I added a small touch of shadow in the appropriate places, but nothing that’s overbearing. Lastly, I decided to go with my old high school colors of royal blue and orange for something that will hopefully pop out and attract someone’s attention.

WordPress Core

Typically, over the past number of years, I’ve generally shied away from trying to contribute to WordPress Core. This is at least in regards to looking around and trying to find some easy things to provide a fix for within a day, and certainly not something that would necessitate weeks or months of active attention to get ready for potential inclusion.

No, instead I went for some really small things in forgotten areas of the WordPress admin panel. The first one I wanted to tackle was some UI adjustments for the links/blogroll management area. So, I copied down the development repo for WordPress, got an install setup that used it, and went to find the broken UI. It wasn’t there, it was fixed and looking good. Went and checked the commit history for the file(s) in question, and sure enough someone had beat me to it, and those changes will make it in to WordPress 5.7.

I was not deterred by any means, as I had another of what I consider a bug in mind. If you try to visit the old links/blogroll area on a new install of WordPress, you get some messaging about installing Link Manager first to restore this area. They provide a link that sends you to the plugin install page in your site, and fill in “link manager” as the keyword for a search. That’s nice of them, except for the fact that there are over 2000 results returned for that query. Good luck finding the plugin they intended!

I wanted this fixed. I knew there were ways to create links that install a plugin for you, I knew there were ways to create links that activate a plugin too. Just a matter of determining how to safely and accurately create those.

After a couple hours of digging, coding, and testing, I had my patch ready that uses the same methods for installing and activating. Moseyed on over to WordPress Core Trac and opened my ticket. I was quite confident that I was not going to make it in time for the WordPress 5.7 release, as that’s in beta right now, and due pretty soon. However, I wasn’t sure if it would even be accepted since the Links area is generally forgotten at this point.

Thankfully, and to my relief, it got accepted and has a milestone of WordPress 5.8. Can’t wait to see my name in props again. While I was at it, I checked all my open tickets and remembered a small ticket regarding some of the RSS feed files. So I nudged about it and asked if it was worth considering for 5.8 as well, and not long after it got accepted too. Huzzah! Two tickets covering small details. At the end of the day here, I’m quite happy with how the day went.