Blog

Pods 3.0 and CMB2 — Parting Ways

You probably remember the post where we announced the Pods 3.0 integration of CMB2, but you may not be aware of some of the challenges we faced. We announced the integration on February 12th, 2015, which today now marks a full 9 months into that process. I was very excited to announce it and the CMB2 team was too.

The problem started when we wanted to integrate CMB2 as a library to take over much of our forms. What we needed was CMB2’s Loop Field (“group” field type in CMB2 terms)  and the ability to have repeatable fields. It was close, but we knew there was a few things we needed to iron out. Going through that process, we introduced Nested Fields into CMB2 for our own Loop field needs. That led to a Backbone rewrite of the form field inputs, which Micah Wood began to work on and is continuing to work on. Micah is finishing it up and soon will be getting it in front of the CMB2 team lead, Justin Sternberg, for review. We also found that the Field Type architecture was limited and wasn’t going to be efficient for us to have our own field types existing along with the CMB2 ones we’d have to put together.

Our field types and options don’t perfectly match up with CMB2 either, for instance, CMB2 doesn’t have required field handling, or support for a number of field options for each of our field types.

At this point, it looks like we’re still many months away from being at a point which we can move forward to a usable beta of Pods 3.0 with CMB2, which brings me to the decision we made this week:

Pods 3.0 will no longer be focused on integrating CMB2. 🙁

I’m not sure if we’ll revisit this in the future, or if we will instead directly integrate with the Fields API. I can say though, that we had invested months into this process which equates to development costs ($). We just don’t have the resources to continue this, and push off the release until mid-2016.

We’ve reached out to a number of people and companies involved with CMB2 or with a vested interest and have yet to receive any donations to help us continue in this endeavour. As a result, it’s just not feasible for us to continue, and suffice to say — it could sink the ship.

What about CMB2?

Where does this leave all of the work we put into CMB2? It’s not going away, and we’ll see that through, but it’s no longer a substantial blocker towards the Pods 3.0 release.

CMB2 remains an excellent library and project, supported by Justin Sternberg and WebDevStudios. There are other alternatives out there like Human Made’s CMB fork, as well as countless custom field plugins / libraries. After everything we’ve done, I still think CMB2 is a great solution and recommend it for those looking for a code-only approach to custom meta boxes and fields. I hope that our decision to not integrate with CMB2 does nothing to affect the reputation of an otherwise awesome project, which Justin has poured his free time into.

Moving Forward

We have renewed focus on our Pods 3.0 codebase, now that we’re freed from the timeline constrictions that CMB2 imposed on our plans. We’re scaling back some of the major code changes we had planned for Pods 3.0 including some of the class/file organization, and rebasing (Git) off of the 2.x branch, retrofitting a bunch of our new improvements from 3.0 into code that we know is working.

We had hoped to have Pods 3.0 released before the end of the year, but now we’re just hyper-focused on getting Pods 3.0 into a beta before the end of the year.

We are working on merging the frontend code that Curtis McHale put together for Loop Fields, now over 2 years ago. We knew that Loop Fields would be three major pieces of work: 1) Refactoring our Pod / Field object architecture to support nesting; 2) Refactoring our content form UI to support loop fields; and 3) Refactoring our Admin UI for Editing Pods to support loop fields. Now we can move forward on that, with #1 being done and #2 / #3 partially done.

This type of event isn’t uncommon, there are other software companies building things and having to backtrack for numerous reasons. However, I think this really highlights our dedication to producing a stable 3.0 release for our users in a timely fashion. Had we known what we know now, we would have probably not gone down the route we did near the start of 2015, and we’d have our release out by now. Unfortunately, no one can know what’s in store for them, until it comes time for implementation and integration of two projects.

We wish the CMB2 team the best, and we’ll continue to contribute back to their project where we can to better both of our users overall — yes, we know many of you are using both CMB2 and Pods 🙂

If you have any questions, please don’t hesitate to contact us or ask our team in Slack chat.

12 thoughts on “Pods 3.0 and CMB2 — Parting Ways”

  1. I was looking forward to this, but it seems like a smart move. Keep up the good work guys! I’m sure there will be an opportunity to merge the 2 again someday 🙂

  2. This is really sad.
    Regarding the beta you plan to release, will that include the loop field too, can’t figure it out from the post.

    • This is not on the list of tasks we have assigned to Pods 3.0 at this time, we’re trying to remain focused on loop fields and avoid delaying the release any longer than development and testing requires.

Comments are closed.