CMS Tree Page View has been adopted — by me!

I’ve been a part of the WordPress ecosystem for a long time now. Such a long time in fact, it’s been the platform upon which I’ve built my livelihood. That’s come in many forms: consulting, custom development, and products like SearchWP.

I got started wedging my way into the WordPress world primarily by blogging what I was learning, but quickly found myself intrigued by the Plugin ecosystem of WordPress.

It took me quite a while to start publishing though, primarily because of impostor syndrome and fear of SVN, Trac, et al. In my opinion it’s still intimidating to contribute code to WordPress whether that be in core, a plugin, or a theme, but that’s not what this post is about.

I’ve always been happy that contributing to WordPress is a direct contribution to people all over the world who have goals to do things on the Web and it’s WordPress that makes that happen. Plugins were where I felt I could have the biggest impact, and I still feel that way.

I also feel like WordPress is still trying to overcome the stigma of being limited to blog-like sites as opposed to “real” sites, whatever that means. The plugins I build and work on are directly related to making content management more… manageable when using WordPress.

I feel like a big area in which WordPress lacks controls and tools in that regard is the Admin Menu. It’s a straightforward and accommodating system that works, but it’s also one that’s taken advantage of by way of top level menus where there arguably shouldn’t be, and an overall limitation when it comes to managing the site vs. managing the content of the site.

It’s a tough nut to crack. One that’s being worked on as the entirety of the WordPress admin is being reexamined through the development of Gutenberg (side note: I think Gutenberg is what we should call it even though not many other people do, I think I should write up those thoughts, but I digress) but at this stage it’s experimental and exploratory and we have work to do now.

The lowest hanging fruit I see when it comes to managing management of content in the WordPress Admin starts with how you interact with your content before you get to the edit screen. How do you find the link to click to edit the Page you want to edit?

Right now that process is a bit convoluted, limited, and outdated. There are many good reasons for that but it’s also why I really like the Plugin system — you can change it when you want to!

Hierarchy, OrganizeWP

I’ve take a couple of cracks at solving this problem over the years. First was Hierarchy, which facilitated grouping your content in a way that made more sense to me and a few hundred other people as per the installation stats.

Hierarchy was never widely adopted, but it was exactly what I had in mind as a solution to a problem I saw. I convinced myself it was a real problem and one that caused pain to others as well, but there wasn’t much adoption because the learning curve was too high, too developer oriented.

After having a few years of product development under my belt I thought I’d take another crack at it. From that came OrganizeWP, which is a rethinking (and rewriting) of Hierarchy with a focus on user experience. OrganizeWP is an exponentially better implementation of Hierarchy and I’m glad it exists in the world.

CMS Tree Page View

In trying to spread the word about this solution to prospective problem-havers, I remembered a plugin I hadn’t seen in a few years and came to rediscover CMS Tree Page View.

CMS Tree Page View has become a staple reflection of how working with even a single post type in the WordPress Admin can be improved in many ways. It hadn’t been updated in a couple of years, so I reached out to Pär to find out if he’d be interested in putting the plugin up for adoption. After a bit of discussion about intention/plans with the plugin, he agreed!

I’m really happy to have adopted CMS Tree Page View. It’s the first plugin I’ve officially adopted and I’m looking forward to familiarizing myself with the code base and continuing to iterate on the plugin, clean a few things up, modernize a few other things, and start chatting with the existing users to find out what other features can be added to the plugin to make their lives easier when it comes to managing Pages in their WordPress sites.

The Plan

We’ve seen this type of thing happen before. A popular plugin gets scooped up by someone and quickly becomes a loud gong trying to sell you something by way of banners, emails, and tracking pixels.

I’m not going to do that.

In operating with full transparency: I will be working on CMS Tree Page View so as to communicate with the existing user base about how CMS Tree Page View can be improved over time to better facilitate content management. With that knowledge I hope to improve OrganizeWP. I also plan on using the knowledge I’ve gained from building Hierarchy and OrganizeWP to improve CMS Tree Page view over time.

The world, especially the WordPress world, and even more-so the JavaScript world has changed a few times over since CMS Tree Page View was last updated. I’m going to familiarize myself with the existing technology and determine what the best course of action will be going forward.

That said, I’m very curious to hear from you if you’re using CMS Tree Page View! Do you have any feature requests? Is there a bug you’ve found that can be properly logged and fixed in an upcoming release? I’d encourage you to star the GitHub repository, I’d like to move development there so we can better collaborate, file Issues, and handle PRs as well.

There’s a lot for me to do over the coming weeks to get the workflow established, links updated, documentation updated, and all of the other details that come along with adopting a long-used and long-loved code base.

The first order of business is to make sure that CMS Tree Page View won’t have any issues when jQuery is updated in the next release(s) of WordPress.