WooCommerce Admin’s code is going to be incorporated into a restructured monolithic WooCommerce repository where it will be maintained going forward. The current feature plugin and repository for WooCommerce Admin will be deprecated.
As we mentioned in a previous post, WooCommerce Admin’s features have become increasingly interwoven into the merchant experience in WooCommerce, both via the core plugin and the growing number of extensions that use the features it exposes. In short, WooCommerce Core and WooCommerce Admin have become inextricable because both are necessary for running a WooCommerce store.
With that in mind, we have begun the process of bringing the code for WooCommerce Admin into a redesigned, monolithic repository where its development will continue alongside WooCommerce Core. This post is meant to provide a high-level overview of what that unification will look like, to share a bit of the rationale behind this decision, and to capture important feedback and input from you before the unification takes place.
What is changing?
While we are aiming to execute this unification with as little disruption as possible, there will be noticeable changes that could impact your work in various ways, depending on how you use WooCommerce and WooCommerce Admin.
A redesigned file architecture in the WooCommerce Core repository
If you use the raw code for WooCommerce Core or WooCommerce Admin as a development reference, or if you contribute work to either of these repositories, there will be changes to the organization of files in these projects, and you may need to acclimate to the new structure in order to retain your productivity.
Adoption of shared developer tooling and workflows
Because they have historically been built and maintained separately, WooCommerce Core and WooCommerce Admin each have their unique sets of developer tools and workflows for things like build processes, testing, and releases. As these two projects unify, the teams who maintain both projects will be working to standardize the tooling and development workflows used across the entire core codebase. For some developers who build with WooCommerce or its bundled packages, this will mean becoming familiar with tools that you may not have used much yet.
Streamlined code review and issue triage
As part of the unification, there will be additional focus put into supporting the code review process through automation and streamlining Pull Request checks to make sure that developers can efficiently work on parts of the code that matter most to them. We’ll also be working to reconcile two separate processes for issue triage and finding ways to improve those processes through automation. We plan to transfer existing issues from the WooCommerce Admin repository to the WooCommerce Core repository, but folks who want to file new issues will need to open them in the Core repository going forward.
Deprecation of the feature plugin and repository
As mentioned above, with the integration of the code from WooCommerce Admin into the Core repository, we will be deprecating the existing feature plugin for WooCommerce Admin and archiving its repository. For developers who contribute to WooCommerce Admin or who use its features, this change means that ongoing maintenance will simply be happening in a different repository. For folks who use the feature plugin to take advantage of new and experimental features, this benefit is something that you’ll access via feature flags rather than installing an additional plugin.
Why are we doing this now?
There are a number of outcomes that we are working to achieve by unifying the repositories for WooCommerce Core and WooCommerce Admin.
- The development and maintenance of WooCommerce Admin and WooCommerce Core should reflect the seamless experience we want merchants and customers to have when they use WooCommerce. These projects constitute a singular user experience and it naturally follows that development of the experience should be free from technological boundaries.
- Developing more collaboratively will improve platform stability. Given the increased interdependence of both projects, working from a shared code base will help reduce duplicated solutions and help identify potential incompatibilities before they are shipped and adopted.
- Shared infrastructure and tooling will make it easier to build and extend the platform. Adopting shared tools and standardizing the way we use them doesn’t just make it simpler for developers to contribute to both projects. It also provides more congruous guidance around best practices for building other things with Woo.
- Feature flagging will provide a smoother pathway for vetting and encouraging the adoption of new features and platform improvements. By eschewing a heavy-handed plugin-level approach in favor of a more granular one, we can provide merchants and developers greater control when they want to try new features, and we can accelerate adoption of battle-tested improvements without forcing folks to live with features they don’t want.
- Eliminating unnecessary or redundant work frees up more engineers to focus on improving the platform rather than routine operational tasks. Maintaining separate plugins effectively multiplies many of the administrative steps that each plugin must be subjected to during its release cycle. By reducing the complexity of the release process, we can reclaim some of that time and energy and redirect it into more impactful engineering efforts.
The tentative next steps for the unification are below. The timeline still has some fluidity and may change based on feedback we receive.
- There will be a code freeze for WooCommerce 5.9 today, October 14, 2021.
- After that freeze, we plan to merge a number of Pull Requests that restructure the
woocommerce/woocommercerepository, configure automation, and make sure everything is working in time to begin the release process for WooCommerce 6.0, which is currently slated for release on December 14, 2021.
- This restructuring will happen over several steps, each of which will ensure it leaves the repository in a functional state, to help prevent disruptions to ongoing work.
- During this transition, we’ll be putting together additional documentation about automation and new tooling.
- Once the core repository is restructured and the corresponding support processes have been put into operation, we will migrate the code from WooCommerce Admin into its new home in the WooCommerce Core repository.
- As mentioned above, we also plan to transfer existing issues for WooCommerce Admin to the WooCommerce Core repository. We plan to migrate Pull Requests as well, but this step is more complex and will require a combination of automation and manual work.
- To help preserve the historical timeline of development, we also plan to migrate the entire commit history of WooCommerce Admin and intend to update any references to issues or Pull Requests in commit messages to their absolute URLs.
Request for Comments, Questions, and Concerns
As is the case with any undertaking of this scope, there are many moving parts and many factors to consider. One of those factors is the feedback that we receive from folks in the WooCommerce community who are reading this. Please leave us a note in the comments below or reach out to us in the
#developers channel of the WooCommerce Community Slack and let us know what questions and concerns you have about the merge, the deprecation of the feature plugin, or even the broader unification effort overall.
We are eager to hear from you, and we want to make sure you feel supported as WooCommerce and WooCommerce Admin continue to converge.
12 replies on “RFC: WooCommerce Admin is Merging into Core”
My comments are: “yay!” and “good luck!”
LikeLiked by 3 people
It it possible then to still deactivate Woocommerce Admin by use of the filter? Like shown on an earlier post, most users dont want Woocommerce Admin in the current way – it puts a lot of pressure on our shared hosting plans.
LikeLiked by 1 person
Hi @keramikoch, as far as I can see in the public WooCommerce Admin repository, the ability to fully deactivate WooCommerce Admin via the “woocommerce_admin_disabled ” filter was removed from WooCommerce Admin in version 2.5.0 (and consequently in Core in version 5.6) and was replaced by the ability to allow users to remove specific features such as Woo Commerce Analytics and the Woo Commerce navigation experience. You can find more details here:
In other words, I don’t think that the merging of these two repositories will have an effect on the particular filter you mentioned. However, if you are still working on a version prior to WooCommerce Core 5.6, then an upgrade may result in you having to manually disabled each feature of WooCommerce Admin in order to keep the CMS lean.
Hi @keramikoch, may I ask what hosting are you folks using that is struggling with WC Admin? It might help us test it in scenarios where it struggles and subsequently improve the performance where needed. Thanks!
Hi @keramikoch! Just following up here to confirm what @stephmpi mentioned in an earlier comment. The Pull Request in that comment includes more rationale about why the filter was repurposed and how it works versions of WooCommerce from 5.6 onward.
In other words, in versions of WooCommerce from 5.6 onward, this filter still works for disabling optional features in WooCommerce Admin but not the features that have become essential in WooCommerce Core. You can find an array of those features here: https://github.com/woocommerce/woocommerce-admin/blob/c15254d788ec904b619d82e4db882d076fe3b927/src/Features/Features.php#L21-L31
The merge of WooCommerce Admin into WooCommerce Core’s repository shouldn’t affect the behavior of this filter.
LikeLiked by 1 person
Please don’t make major changes to WooCommerce during the busiest shopping period of the year. Save the new bells and whistles for 2022. 🙂
LikeLiked by 1 person
Hi @kaydigitelleno. 👋 I definitely hear you. As a merchant, it’s unsettling to be headed into such an important part of the year and learning that the underlying software powering everything is undergoing significant changes. The changes outlined in this announcement are predominantly tied to development workflows and file architecture, and while we don’t anticipate this unification introducing bugs the way that new features might, we are still working hard to test these next two releases with diligence and attention to detail to ensure any disruptions that may occur have minimal impact on merchants and their customers.
You don’t see that the [repeating] problem with this entire subsystem (and a few other things) has been that “we don’t anticipate”?
I don´t like to have too many plugins, so I always thought the admin plugin should be part of woo.
Thank you, go on, youre the best 😀
You claim “both have become integral to running an online store.”
That is an assumption not in evidence, as shown by the majority of comments here – and most everywhere else – expressing concern about this. A LOT of people just want the ability to post what is effectively a “for sale” ad and take online payments. They manage their business THEIR WAY and simply do not need any software eating their server for data they neither want nor need.
Also, segmenting the disable filter, while a good idea, but is stating, in effect, “we’ll let you disable the bloat that we think you might think is bloat, but the parts that the development gods think are important will not be controllable – and we’re not telling us which parts they are” reeks of “we want to do things to your store that you will never know about – until you get the bill for excess resource usage from your hosting provider”. 😦 .