Introducing wProject and what it means for Task Rocket
What is wProject?
A long time coming, is what it is. Specifically, wProject is intended to be the successor to Task Rocket, which for various reasons (noted further into this post) is long over due for an update. It will feature many of the current features of Task Rocket plus more, and be built on a more robust foundation to make it easier for me to update and maintain going forward.
Why start now?
I think a little history is in order before I answer this question.
A couple of years ago, I casually announced that I had started work on Task Rocket 5. At the time it seemed like the right move, given that Task Rocket 4 was becoming a little long in the tooth – from an engineering standpoint – making it difficult to manage or expand upon.
Circumstances as they were prevented me from making any real progress, and the more I looked at the task ahead the more discouraged I became. When I first engineered Task Rocket in 2013 I did not have any expectation it would be used by so many today, and looking back I wish I’d taken more care with some of the initial development decisions. To give some context to that statement, I originally made Task Rocket just for myself because I wasn’t happy with any of the other free solutions available, and also because I wanted the option to build my own features when it became apparent I needed them.
This mindset led to what you might know as the mechanics car syndrome (or sometimes referred to as the cobblers shoes). In this situation, a mechanic who usually does an exemplary job when working on his customers cars, also takes less care when working on his own. The mental bargaining that takes place is that fundamentally only he can make himself accountable for his own actions, which he is willing to accept, and so theoretically there are no repercussions.
And while I have certainly made some improvements to Task Rocket over the years, fundamentally the code really needs significant refactoring if project management on WordPress is to evolve.
To cite an example of just one consequence of this, each plugin I have made for Task Rocket since has been far more challenging that it should have been. With this in mind, I decided the best move at the time was to just shelve Task Rocket 5 completely.
Fast forward a couple of years and I have found the motivation to look at it again. But this time I came to the decision that the only way to not repeat past mistakes was not to refactor the existing code, but to rewrite it from scratch, including the front-end layer. And so for the past few weeks I have been working on wProject every chance I get.
But it didn’t take long to realise that I needed to make a decision that will possibly affect existing Task Rocket users.
The legacy code challenge
Legacy code is not inherently bad, but it’s also not ideal. When you first code something it does what it needs to do at the time, but after years of being expanded upon and patched it becomes more difficult to understand and maintain. It’s made worse if the code has some questionable decisions made from the outset, creating a good chance of introducing unintended bugs elsewhere.
As an aside, any good developer would never write code today to the same standard he or she did several years ago.
I can attest to having made some questionable decisions early on (post meta naming conventions, storing project data in the options table instead of termmeta, and not using a custom post type and taxonomy are a few regrets that immediately come to mind), and consequently am more or less ‘forced’ to deal with those past choices today by maintaining its code in the same fashion as I did all those years ago, lest I risk breaking something crucial or at the very least introduce bugs.
The aim is to be in a situation where having to maintain the code, fix bugs or add new features doesn’t come with a certain amount of dread and anxiety.
With all this in mind it was a no-brainer decision to do things better with wProject, in a way that makes sense to ensure a maintainable product by avoiding past mistakes. But this comes with a compromise…
What this means for upgrading from Task Rocket 4
As you can probably already guess this creates a problem when upgrading from Task Rocket 4, because nearly everything in your existing database will either be somewhere unexpected and contain data with different post meta. While activating the wProject theme won’t cause you to lose any data, none of your existing projects and tasks will appear on the front-end either, which obviously is not ideal.
Does this mean it will be impossible to upgrade from Task Rocket 4? Not impossible, but extremely difficult and fraught with danger. I’ve tried several times to make the Task Rocket database work with wProject, but they are both fundamentally applications that are too different from one another, and so I consequently could not come up with a suitable solution.
I did get close once, but I quickly realised that I would still needed to solve compatibility problems with the Task Rocket plugins.
I won’t dwell on this any more, suffice to say there will not be an upgrade path from Task Rocket to wProject.
Will Task Rocket still be supported once wProject is released?
Yes. Nobody will be forced to use wProject, and as always I will offer support and fix any bugs that are reported for the foreseeable future.
Will the Task Rocket plugins work with wProject?
When wProject launches it will be before any dedicated plugins for it are ready. Task Rocket plugins will not be compatible with wProject, but new wProject specific plugins will eventually have to be rewritten from scratch, and some plugin functionality will be baked into wProject anyway.
When can we expect wProject to launch?
That’s up in the air. If I’m being honest, I would say a beta might be ready sometime in March, but without any plugins or the proposed Task Rocket upgrade solution. I’m a one-man-army with other responsibilities and a medical condition that sometimes puts me out of action, but what I will say is that I’m super amped to be working on it every chance I get.
Will wProject have the same features as Task Rocket?
Some of the features will be the same or enhanced, and many new. I’m re-thinking the experience and making suitable changes where required, including extensive use of Ajax for a slick productive experience.
Will wProject be free?
No. Because this is a completely new product with significant time and resources dedicated to it. But I may release a ‘lite’ version at some point.
Can we see it in action?
Yes, but bear in mind this is still an evolutionary work in progress and not everything ‘makes sense’ if you look close enough (some of the values are static placeholders). These videos represents about 4 weeks work so far. Crank it up to 4K if you’ve got the pixels.
Will it be made available for beta testing?
Absolutely. And if you’d like to be among the beta testing team, just send me a message and I’ll let you know when it’s ready for the first round of testing. It’ll be a hosted demo so you won’t need to do any of the heaving lifting.
As always if you have any questions about any of this, you know how to reach me.
September 2021 in review
A lot has happened this month. Here’s a summary of updates, features and tweaks across several products.Keep reading
What to expect in wProject 1.4.0
wProject 1.4.0 is not far away and should be safe to push out next week.Keep reading
wProject has launched and you can get it right now
As of today wProject is available for purchase, and there are implications for Task Rocket.Keep reading
wProject feature demonstration
Subtasks are arguably the biggest deal. As is often with any task, there can be a number of smaller tasks that need to be accomplished within it.Keep reading
Why I eat my own dog food
For the uninitiated, I, nor any other developer, actually eats dog food (not that I know of anyway).Keep reading
Open Graphite Pro now has an enhanced Slack sharing option
With the release of 2.0.0 today, Open Graphite Pro has a new option to enable enhanced Slack sharing.Keep reading