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.
I’m sad! I understand your reasons, but still…
Sad here too, I was really excited about the integration and so was everyone else. 🙁
That is sad. But can we get a Pods 3.0 beta with polylang support this month?
If we could get some help testing it, and know what integration we need to do to support the Polylang release, we’ll do our best to include it with our Pods 3.0 beta, not sure about this month given the US holiday just days away.
Hi Scott, thank you! We are waiting 10 month for this. polylang is now the best solution for translating (WPML is to slow). I find the master 3.0. is this one ready for testing with polylang 1.7.11.2 beta? what have i to do by swiching from pods 2.55.
Thank you for help!
It would be best to wait until we announce our Pods 3.0 beta, the current Pods 3.0 branch is not functioning (it was in the midst of the CMB2 work).
We also just merged some compatibility with Polylang 1.2+ into Pods 2.5.6:
https://github.com/pods-framework/pods/pull/3223
Get the latest Pods 2.5.6 (in testing) at https://pods.io/latest/
Hi Scott,
thank you for help. I will test 2.5.6 Beta. For know it looks good.
I would like to import taxonomien with a tree. Is this addon working with WP 4.4. beta 3
https://wordpress.org/support/view/plugin-reviews/csv-importer-for-pods
Or is there another importer to use. are the taxonomien-data are stored in an extra table. or is this something for Pods 3.0
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 🙂
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.
Yes, the loop field is still the primary feature focus for the Pods 3.0 release.
Hi Scott, what about this entry in 3.0 beta?
https://github.com/pods-framework/pods/issues/3191
i am searching for conditional logic. is there a way with 3.0?
thanks for help.
Henryk
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.