Pods: Loop Field Type

[viruthagiri]

Description modified September 1st, 2015 by @sc0ttkclark

Feature Summary

A loop field will be a field that contains other fields. For example a Pod called 'book' could have a loop field called 'chapters', which had its own set of fields such as, 'chapter_title', 'chapter_content', 'chapter_start_page' and 'chapter_end_page'. An item in the book Pod, could have as many entires in the chapters field as necessary, and each one would have its own set of fields, with their own values.

A lot of planning has gone into this feature, but its implementation has been delayed. Performance improvements that we plan to address in 2.3.19 and 3.0 have been prioritized over loop fields as they are essential for proper implementation of loop fields.

Work to be done

• [x] Design Loop Field workflows (@curtismchale)
• [x] Mockup Loop Field workflows (@curtismchale)
• [x] Develop prototype, minus JS for fields (@curtismchale)
• [ ] Refactor and clean up CMB2 structures to support nested fields (@pglewis, @sc0ttkclark)
• [ ] Refactor and clean up field type JS for group fields to support better nesting (@jtsternberg, @sc0ttkclark)
• [ ] Test and finish up saving process and storage handling for table/meta storage types (@sc0ttkclark)
• [ ] Test and finish up field() / display() for getting data out of loop field (@sc0ttkclark)
• [ ] Add field traversal for loop field data arrays (@sc0ttkclark)
• [ ] Create Unit tests (@pglewis, @sc0ttkclark)
• [ ] Write Documentation page (@shelob9)

We are actively seeking contributors for any of the open tasks above, please hop in and help out if you're interested! If you are unsure of how to get started or have any questions, feel free to ask @sc0ttkclark here or at http://pods.io/chat/) for help getting started.

Original issue summary

Hello pods team,
I'm using magic fields 2.0 which contains features like "add another field" and "add another group" type of fields.
Yesterday one of my internet friend recommended pods 2.0. I tested it and i really love it. Magic fields 2.0 stores the data as metadata. I'll get performance issue. Thats why i would like to use pods 2.0. Pods satisfies me everything except that "add another field" and "add another group" type of field.

Here is the snapshot of what i'm asking
Before duplicating the field:
http://wiki.magicfields.org/lib/exe/fetch.php?media=v2_field_duplicate_post.jpg

After duplicating the field:
http://wiki.magicfields.org/lib/exe/fetch.php?media=v2_field_duplicate_complete.jpg

Before duplicating the group:
http://wiki.magicfields.org/lib/exe/fetch.php?media=v2_group_duplicate_post.jpg

After duplicating the group:
http://wiki.magicfields.org/lib/exe/fetch.php?media=v2_group_duplicate_remove.jpg

Does pods 2.x has that feature and as a pods newbie am i missing something?

[sc0ttkclark]

Yes this is planned for Pods 2.0, I wasn't sure if I could pull it off in time, so it may be pushed into 2.1

[viruthagiri]

Thanks. I would be very happy if you include that feature in Pods 2.0 :)

[sc0ttkclark]

Mike, this one is on you (further down already discussed priority list), let's look at Attachments (can provide you the code) for how we'll handle repeatable fields themselves. Admining of repeatable fields is going to get sticky, so we'll tackle that as a separate thing in the admin area.

[Pezzab]

Apologies for reviving this thread. Having started tinkering with Pods 2.0 beta in anger this is so far the only feature that I'm missing. Other than here I see it has been mentioned on the podsframework.org blog. I hope it is still on the roadmap somewhere.

Otherwise Pods 2.0 is unbelievably good. The flexibility and power has always been astounding - the additional ease the new UI in 2.0 adds to the mix knocks it out of the park :)

[sc0ttkclark]

Yeah, this is queued up for Pods 2.1, we've got @dontfeedthecode on it and he's already designing some pretty great looking screens.

[Pezzab]

Sweet, that'll another plugin I can wave bye bye to once it's implemented :)

[dandv]

Awesome feature, I'm interested in it too.

[sc0ttkclark]

Looking good so far!

[sc0ttkclark]

Unfortunately we have to push this one into 2.2, more details coming soon on the plans for this one. Not opposed to this landing for 2.1 but it doesn't look like there's enough time to implement now.

[roosterjm2k2]

I put off a project as long as I could waiting on this, so I guess its either the ugly magic fields interface, or paying for ACF ... (still, awesome work, and i'll be using pods later)

[sc0ttkclark]

Sorry Josh, we wish we could push it up, we'll try to get it done and in beta ASAP, just had a few things come up that made it too tough to ship it in time for 2.1

[Pezzab]

No worries - worth waiting for :)

[franz-josef-kaiser]

+1

[eccentricpixel]

Did this functionality make it into the latest commit?

[sc0ttkclark]

No, we adjusted the release schedule and instead of releasing 2.1.1 for bug fixes, we're releasing that as 2.2 as it includes additional features and enhancements. This is now slated for 2.3, still technically our next major release. It's nearly done in design, so we should start seeing pieces of it make it's way into the code in January.

[kelfy]

can't wait to see this loop field.

[kelfy]

Couldn't find this function on the latest alpha release. Would that be more delay for this?

[sc0ttkclark]

It's in progress, but hidden for developer testing. It's at about 20% right now, held up in design/ui work. Pods 2.3 in currently in Alpha, so there's still a lot going into it. Our goal is to release Pods 2.3 on or before WP 3.6 (see http://make.wordpress.org/core/version-3-6-project-schedule/)

So this isn't going to get delayed, it's slated for Pods 2.3 and that's my full intention. Worst case, I may have to stop work on all other features to get this one out.

[dikaso]

+1 for this.

This is what's holding me to swap to pods. I'll start with slow migration to pods... but till this come out i won't be satisfied.

Anyway great work people ;)

[sc0ttkclark]

Unfortunately, the time has come, I've gotta punt this one to Pods 2.4, everything's held up right now on design and we're working on getting that lined up. Until then, the #1095 should be useful for many uses that the loop field would have normally been used for.

[Pezzab]

I'm working on something right now using ACF repeatable fields as a placeholder for this functionality. No biggie - I can press on using that. I'd rather you got it right than ship something that won't work as it should.

[kelfy]

Same here. Have to use ACF instead

[sc0ttkclark]

Sorry, wish there was something more I could do to get this out in time, out of my hands unfortunately. I've set in motion a solution to get this out in time for Pods 2.4 though, it'll just cost me us a bit more.

[sc0ttkclark]

Also, alternatively, Pods and ACF work together, so you can use ACF for the loop fields, and Pods for everything else. Again, sorry for the inconvenience.

[Pezzab]

No worries,. I'm using an ACF/Pods combo already :)

[Halvard]

Can't wait for this!

[Dechowmedia]

So now 3.6 have been released... Are there any news? :)

[sc0ttkclark]

Pods 2.4 has an official date of the end of September now, I've brought in an additional resource to work on the html/css/js side of this, which I'll be unable to complete as I have other areas of 2.4 that need my focus (lower memory footprint for low memory environments, etc). We may be beta-able by mid-September if all goes to plan.

[Dechowmedia]

So this means repeatable group/fields are set of end September? :)
—
Im Mobile, if I reply later than expected I apologize

On Thu, Aug 8, 2013 at 3:34 PM, Scott Kingsley Clark
[email protected] wrote:

Pods 2.4 has an official date of the end of September now, I've brought in an additional resource to work on the html/css/js side of this, which I'll be unable to complete as I have other areas of 2.4 that need my focus (lower memory footprint for low memory environments, etc). We may be beta-able by mid-September if all goes to plan.

Reply to this email directly or view it on GitHub:
https://github.com/pods-framework/pods/issues/109#issuecomment-22323526

[sc0ttkclark]

Right, this is the main feature we're focusing on for Pods 2.4.

[lapidus]

+1

[sc0ttkclark]

Back on track with this feature, @curtismchale is again on the case!

Big question for those who have a vested interest in using this feature though -- what code would you want to use for your loop field data? Is it as simple as a multi-dimensional array or do you think it needs to be something more?

// This may or may not be what we want
// Let's think about it and figure out what's best
$chapters = $pod->field( 'chapters' );

foreach ( $chapters as $chapter ) {
    echo '<h2>' . $chapter[ 'name' ] . '</h2>';

    $page_num = 1;

    foreach ( $chapter[ 'page' ] as $page ) {
        if ( 1 < $page_num ) {
            echo '<hr />';
        }

        echo '<h3>Page ' . $page_num . '</h3>';

        echo '<div class="page-content">';
        echo apply_filters( 'the_content', $page[ 'content' ] );
        echo '</div>';

        $page_num++;
    }
}

[jchristopher]

I love a good ol' multidimensional array. What you have is exactly what I'd envision.

[sc0ttkclark]

@jchristopher the only issue is that these would all be 'field' outputs, not 'display', so while you loop through the content, you'd have to have your own processing (see above), vs what you'd normally use with $pod->display( 'content' )

So I'm not 100% sure what we'd want here, maybe we need a new object-based output type for loop fields too:

// This may or may not be what we want
// Let's think about it and figure out what's best
$chapters = $pod->field( 'chapters', 'fields' );

foreach ( $chapters as $chapter ) {
    echo '<h2>' . $chapter->display( 'name' ) . '</h2>';

    $page_num = 1;

    $pages = $chapter->field( 'pages', 'fields' );

    foreach ( $pages as $page ) {
        if ( 1 < $page_num ) {
            echo '<hr />';
        }

        echo '<h3>Page ' . $page_num . '</h3>';

        echo '<div class="page-content">';
        echo $page->display( 'content' );
        echo '</div>';

        $page_num++;
    }
}

So for the new field object, it would basically be a mini-Pods object that you'd only use display/field from. Still a lot more to be considered on the backend to make this possible for _relationship fields_ traversal handling.

[mastef]

how would relationship fields be addressed in the loop?

$chapter->display( 'book.author' ) ?

[sc0ttkclark]

@mastef That's the tricky part, we need new traversal handling for tableless fields within loop fields, relationships can't be stored in wp_podsrel the same way.

[mastef]

loop fields could be a separate pod simply displayed inline inside a pod?

[sc0ttkclark]

@mastef that's #291

[mastef]

Oh yes! That would actually solve the whole issue. If a repeatable field would simply automate this process, wouldn't it?

[sc0ttkclark]

It will allow for automating this process if we can get the initial code done first.

[sc0ttkclark]

We need to figure out how we're going to handle loop field tableless fields and their relationship traversal. I don't see an easy way of using wp_podsrel for this, because these are fields within a field, and it can be multiple levels deep, we don't have the columns to handle that and it wouldn't be efficient.

So traversal in find() is out of the question, but for ->display( 'chapters.pages.characters.name' ) we'd need to pull the related ID(s) from the field's array itself. I think that sounds right, just need some validation here :)

[sc0ttkclark]

Sounds like #1661 is going to be a prerequisite to handling relationship traversal and field/display methods for the loop field 'fields' output type.

[sc0ttkclark]

Latest progress on loop fields can be seen in this video: https://www.youtube.com/watch?v=6Zf26fAEBRw

[kelfy]

That is awesome.
A long awaited function finally there. Look forward to see the next release.

[kenwiesner]

Fantastic! So excited to start using it!

[Halvard]

I've been waiting for this for years. Brilliant stuff!

Halvard L. Simonsen
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Saturday, September 7, 2013 at 12:18 AM, Ken Wiesner wrote:

Fantastic! So excited to start using it!

—
Reply to this email directly or view it on GitHub (https://github.com/pods-framework/pods/issues/109#issuecomment-23973036).

[mhhansen]

awesome, can't wait! I'm also waiting for this stuff, thanks for all efforts guys!

[mastef]

still eagerly awaiting it! :)

[Katamo]

Hi sirs.
Any uptate on this?

[mastef]

I think it's time to get this finished, it's really a big blocker.

Otherwise please suggest a viable work-around to have loop-fields in wp-admin only ( e.g. as part of a linked other pods ). We just need SOME way to make loop fields work for our daily projects. ( Pretty please )

[sc0ttkclark]

Updating this ticket shortly with the final checklist. Would love to get some help, we've been distracted with getting an interim Pods 2.3.19 release out and with some performance improvements. Admittedly, Pods 2.x wouldn't be able to handle loop fields well at all due to it's memory footprint, 3.0 solves this in a big way so we had to tackle some big things prior to getting back onto this as a priority. Now we just need to finish out 2.3.19, merge the changes in manually to the 3.0-unstable branch, then get back on this.

Posting the list to the ticket summary instead of a comment, look for it within the hour.

[airzebeth]

Sorry to ask but I can't figure out if this feature is available yet... : i've seen videos on youtube showing how it works, understood that it supposed to be part of the 2.4 release, but I can't find it anywhere in my wordpress admin after installing pods. After reading this issue comments, I understand it might in fact not be ready yet... So here's my question : is this feature still under development or is it available, if so, would you let me know how, please ? Thanks in advance for your answer !

[Shelob9]

@2jstudio Loop fields are not available in Pods 2.4.

[sc0ttkclark]

Sorry about the confusion, Pods 2.3.19 became Pods 2.4, and Pods 2.4 became Pods 3.0 due to some other changes in scope of each of those releases.

[ghost]

No problem, thanks very much for your answers, I understand it all now :) Can't wait to have this feature working, seems great !

[RPDeshaies]

Any news for this awesome features ? Using Wordpress database with ACF is very slow and is using many of the servers ressources.

Using the repeaters fields with the "Advanced Content Types" would be great to create simple user interface and would be faster to get because they are in their own indexed tables.

[Shelob9]

@Tareck117 This feature has been delayed as we need to address performance issues first so that loop fields will work well no matter what the storage method. Loop fields as well as addressing those performance issues are focus features for 3.0 that we are working on now.

[Dechowmedia]

Josh I totally disagree with delaying the feature... Even further...
I do not believe it should be delayed to performance issues if they are not
servere.
If the team keep on pushing the feature you guys can never truly debug the
output, or tweak so that it performs better without getting data upon how
it is used beforehand.

I think (from my understanding) that the performance issues only occur on a
large increased amount of fields, while as I believe the common usecase is
probably only going to span 3-8 fields. We do not ask that the feature
performs well under a lot of pressure. Only that it just simple is there
for use.
Post it to a beta channel if there are worries about a big performance leak
or such.

All in all I just believe that it is due time to ship the feature and tweak
the performance as you go.
If it is not a broken feature there is no reason not to ship it.

Thats my take on it.

On Wed, Jun 11, 2014 at 7:37 PM, Josh Pollock [email protected]
wrote:

@Tareck117 https://github.com/Tareck117 This feature has been delayed
as we need to address performance issues first so that loop fields will
work well no matter what the storage method. Loop fields as well as
addressing those performance issues are focus features for 3.0 that we are
working on now.

—
Reply to this email directly or view it on GitHub
https://github.com/pods-framework/pods/issues/109#issuecomment-45774200.

_Lucas Dechow_
Digital Media Integrator
/w 1508 http://1508.dk/

@dechowmedia https://twitter.com/dechowmedia

[sc0ttkclark]

Delay isn't really the best way to explain it, we've been working on this feature for Pods 2.4, but while working on it, we needed to make some architecture changes because there were severe performance concerns with sites using extensive configurations of Pods and fields. While working on Pods 2.4, we worked on a bug fix release for Pods 2.3.19 at the same time. It came to a point where we had actually had a few small features and improvements to Pods 2.3.19 that made sense to just release Pods 2.3.19 as Pods 2.4, and make what we had been working on (Pods 2.4) become Pods 3.0.

We basically had to go through the infrastructure of Pods and make sure it could handle Loop Fields structures as well as the new #799 Meta box structures we've introduced at the same time. Both are complicated, but doing them together made us realize we needed to make sure the solution was solid.

Now I am totally 100% on board with releasing it to beta and working on it from there. Our current implementation is very alpha right now.

We are doing a few major things in Pods 3.0 that make this release of Pods the biggest yet and something to be excited about:

1. Massive performance improvements for large configurations of Pods and fields
2. New underlying API for Pod objects which can be used for Meta boxes and Loop fields and all sorts of internal things we've had separate custom code for
3. Loop Fields
4. Meta boxes / Groups of fields
5. Code-registered Pods, specifically for relationships - which we'll have an upgrade script you can run to let Pods operate based off of pod names and field names instead of IDs for relationship, which previously limited relationships to having to be added through our Admin UI, unless in PODS_TABLELESS is turned on.

[patrickisgreat]

Greetings guys. I'm about to upgrade to PODS 2.4.3. Did this feature make it in because I really need this! ? Many thanks.

[sc0ttkclark]

Pods 2.4 became Pods 3.0 and we threw in a few fixes that became Pods 2.4. That's because the Pods 2.4 as we knew it required memory reducing techniques in order to support sites who choose to have large amounts of fields and loop fields especially. Pods 3.0 is currently slated for December 2014, and we're working very hard at meeting that goal. We now have 4 people on our team (not including me) who are focused on making that happen, so I'm confident we can hit the mark.

[patrickisgreat]

excellent work! excellent plugin.

[pixelkicks]

Just read this whole thread from Feb 2012. Nearly 3 years later, how far off is this feature now? Been using Pods for just a couple of months now and love what it can do to extend Wordpress, but this is a big limiting feature for me now.

Hope it's close.

[sc0ttkclark]

Loops fields already in Pods 3.0, still some things to do with Admin UI and implementing our UI for CMB2 integration.

[pixelkicks]

Would you recommend 3.0 is stable enough to use on a live site?

[sc0ttkclark]

No, 3.0 is not ready for even a beta. There's lots of movement right now going on with optimizations and feature work. I'm taking time off of work this month (including today) to get Pods 3.0 beta-ready.

[pixelkicks]

Ok, good to know it's on the horizon at least. Are we thinking it could (or should) be live in the next 3-6 months? I know how these things can slip though.

[sc0ttkclark]

Hells bells, I should have it ready for beta this month or I may go insane myself :)

From there, I expect a few weeks beta period, we have a lot of unit tests already and we should be able to get the ones in place that we need to ensure backwards compatibility from release.

[StaggerLeee]

What is the deal with Advanced Custom Fields plugin ?
It is literally one man (show) plugin. Is he some kind of coding genius, or what.
He makes it look so easy.

Hope not from colleagues developers to publicly valuate quality of ACF code. But whole plugin is still enigma for me.
Seems as Pods struggle so much and he does it very "easy".

Dont want to offend someone. I appreciate all work you done in Pods. Just wondering because I made long time ago fatal mistake and all my websites were dependent of K2 extension for Joomla.

Now it is the same with ACF. If plugin dissapear troubles again, not easy to convert data.

You can ask why writing about this here. Reason is ACF has repeater field (loop) since ages ago and working very well. Groups too, and much more. Why you struggle so much to implement it in Pods ?

[pixelkicks]

Last comment from Scott was in December, saying it's not far off. Are we any closer?

[sc0ttkclark]

Sure, I can definitely provide an update here --

We've continued to have our hands full with everything ongoing in Pods 2.5.x. Right now we've got multiple things going between @Shelob9 @pglewis @jimtrue @NikV and I.

@pglewis is working on Term splitting for WP 4.2 compatibility, we're going the extra mile versus some other plugins that I've seen. After he's done with that, he'll be switching back to merging Pods 2.5.x into Pods 3.0 via #2822 which has been a big holdup on any 3.0 progress.

@Shelob9 is working on our REST API and trying to get it ready for the upcoming version change from the WP REST API folks.

@NikV is continuing to work on docs and moving forward GitHub fixes and enhancements on 2.5.x and 3.0. We setup a new requirement designed to prevent focus getting lost on 3.0 which requires all Pull Requests for Pods 2.5.x to have a Pods 3.0 patch as well before we merge. He's been doing that for doc issues and his other tasks.

Both @Shelob9 and @jimtrue are still maintaining our support queues across pods.io, wordpress.org, and our free Slack support chat. They both have also been running PodsCasts since February (http://pods.io/category/podscast/) and trying to help reduce their support load so we can focus on the code more.

We just recently launched Friends of Pods (https://pods.io/friends-of-pods/) last month, almost a month to this day. So far it's helped us get funding to let us rely less on client-projects. Up to then, @pglewis has been in a continuous series of client projects that have kept him away from helping out on Pods core much. He almost solely has been responsible for keeping the lights on, where as our Automattic sponsorship covers the other half of the bills. Friends of Pods has so far brought in more recurring donations than the we've seen in one-time donations in more than 7 months alone. I'd consider it a success, but we still have further to go -- we're not completely free of client projects and Phil is still only able to focus on Pods 3.0 tasks until we get 3.0 out the door.

Me? I've been working on helping @pglewis with the merge, various support help with @jimtrue and @Shelob9, helping out on PodsCasts with example code, getting unit tests running on Pods 2.5.x and Pods 3.0. Helping @pglewis on Term splitting. I've on hold working on the CMB2 merge which has it's own loop fields until we can finish the 2.x merge into 3.0 so we don't lose out on all the fixes and enhancements. CMB2 merge will take out a bunch of things we no longer need, but that would put a massive block on merging things that we still need so that's been prioritized under the 3.0 merge itself. Loop fields CSS/JS needs merging in, but we're also still trying to figure out how best to take advantage of everything that CMB2 gives us in form UI for that. That's along with other GitHub tweaks I've been a part of, reviewing code coming in, keeping the lights on, and planning for WordCamp DFW 2015 and a possible PodsCamp in 2015 (still not decided yet).

I can still tell you that Loop Fields will be in Pods 3.0, it's just held up by a number of tasks ongoing for Pods 2.5.x (for WP 4.2) and Pods 3.0 that would be much more time consuming post-loop-fields work.

If you want to help with code, hit us up in our #dev-core Slack channel. If you want to help give us the resources to keep hyper focused on Pods 3.0 like we've been this past month, consider becoming a Friend of Pods -- https://pods.io/friends-of-pods/ -- either as a one-time donation or recurring member.

More soon, most of our hold-ups are now on the cusp of completion: 2.x >> 3.0 merge, CMB2 merge, then Loop Fields. Our team continues to be devoted to keeping Pods going and we're all doing our part. It may not look like it at times, but you'd be amazed at how many things can keep something like Loop Fields delayed, either intentionally or unintentionally -- like when developers need bug fixes in Pods 2.x or something changes in a WP release like in 4.2 that requires a significant time investment.

[sc0ttkclark]

I also did want to give @jamesgol major props, his efforts the past many months have been a godsend. I'd go into more details about everything he's been doing, but I don't think I have enough time to gather a list of all of the notable things he's contributed to Pods.

[StaggerLeee]

Thanks for clarification and all good work.

Dont mind if I mention another plugin here. I know comparations like this are not popular in developer communities.

Despite I respect ACF developer a lot, bought a PRO licence, i would like to get rid of this dependency on my websites. No offence to developer but he could have in his life some unexpected events that prevent him developing plugin anymore.

There are many of you guys behind Pods, and would like to switch to Pods at whole. Use nothing more except it.

[lkraav]

@StaggerLeee do you mind providing a URL reference to info on what trouble ACF's Elliott is going through? Not looking to go off topic here, but I'm also trying to reduce my bus factor by supporting Pods.

[StaggerLeee]

Not any now, as I know it. But you know how it goes with "one man plugin(s)".
This is not gallery popup plugin. When it reach its end just delete it and replace it with another.
Or to take more advanced example. This is not even Jetpack, delete Jetpack and replace with other plugins.

Websites are much dependent on AFC and dont want some day go through all websites and fix them for hours and days. If it would be easy fix at all.

I had one bad experience. if it was not for one Frenchman and his 2 commercial plugins I would never be able to convert my Joomla (K2) websites to WordPress. I had more luck than knowledge there.

[sc0ttkclark]

It also doesn't hurt that many of our main team are active contributors on WordPress core.

Also there's this project I'm working on moving forward as a feature proposal (developer focused):

https://github.com/sc0ttkclark/wordpress-fields-api

[szepeviktor]

Is the nature of the bounty public?

[quasel]

label removed ^^ but take a look at https://www.bountysource.com/teams/pods-framework

[szepeviktor]

I know that it takes hard work and long nights to check one of those boxes at the top.
Do you have any plans for the progress?

[sc0ttkclark]

This is in progress as part of the CMB2 integration, but first we're getting Pods 3.0 passing all of our unit tests so we have a good basis for what we break during the CMB2 integration part.

[szepeviktor]

Thank you.

[kelfy]

Great. So looking forward to it

[sc0ttkclark]

Updated the main to-do task list in the main description for CMB2 tasks

[visualdatasolutions]

Hi guys.

I needed the grouping features in some of my projects, and recently got the idea of defining groups by the sequence of custom fields ( menu_order of fields in wp_posts table), using relationship fields named after a pattern to separate groups. This is similar to reading a table of contents from a printed book, when we see a line starting with the word "Chapter" we KNOW it is a chapter and treat it as such. We can instruct the computer to do the same.

I have uploaded the code and some screen shots to WordPress repository as proof of concept, see this link below. This is not loop field and may not suit everyone's needs, but we can use the class method to obtain an array of fields defined as part of the group. I am writing this for brainstorming as an interim work-around, and for seeing whether it fits in the big picture of future development of Pods.

Grouping of custom fields in PODS

Any field type can be used to define groups. I have chosen relationship type as the conditions to display the group can be stored in the relationship field setting. So in a WP loop, we can retrieve details of the current post and decide whether to show the group of fields. similar to location rules found in ACF.

The grouping is done using existing pods field structure and storage structure. The query for groups returns a multi-dimensional array of groups and fields contained within, along with the field settings. I
have used another field (footer) named after another pattern to define subgroups within a group.

the groups so defined can be used in pods short code and magic tags (including magic tags between pods short code, and magic tags in pods template) by adding to filters found in the functions in charge of parsing short code and magic tags. this is already done as shown in the screen shots. supported format:

[pods name="mypod" ] {@header} [/pods]
[pods name="mypod" template="my template with header fields"]

When people produces a form containing all fields, the special fields (headers and footers) will produce a label only without input cells.

$pod->display($header) will show nothing as header fields are definition only without storing any value. It should be easy to implement by adding another function in pods class to display all the fields within a group, or by extending the pods class. users may also get the array of grouped fields (with or without the header and footer), loop through the fields and display the way they want.

the query result for groups can be cached for better performance. this is on my to do list.

The groups can be easily added by creating new fields as group dividers and dragged to the right place. the plugin only asks pods to give some special treatment to fields with special name. Whatever worked in pods should continue to work.

what do you think about this approach of grouping fields?

kind regards.

Oliver

[pixelkicks]

Is this ever going to be completed and released? This thread was originally created on 25 Feb 2012.

[sc0ttkclark]

@pixelkicks yes, we're in heavy development with the CMB2 team, already have some major work headed it's way into CMB2 to support nesting fields in multiple levels of group fields (their loop fields).

Appreciate your patience, we're on the home stretch!

[sc0ttkclark]

I can also say that it has been and has always been a money issue, the amount of work involved in making this happen while also providing the project with support and maintenance fixes has been a challenge. Loop fields in Pods required a lot of changes to the codebase, all of which is in Pods 3.0 now. And we're going to be using CMB2 to power 3.0 too, so we cut out a bunch of work we no longer have to do, while strengthening both projects.

I'm personally putting up my own money to fund @pglewis through the rest of the month and into mid-October. He's been on fire with the work he's been doing with the CMB2 refactor to support nested fields. We're also involving @wpscholar for the Backbone stuff, which is another thing I'm putting in personally. There's a lot I've done for Pods and now CMB2 to push them both forward, all of which we put out for free to the world. That's something we're all very proud of.

Anyone who wants Loop fields in Pods core, who hasn't donated to the project yet, could do a great service towards making this happen sooner through becoming a Friend of Pods through one-time or recurring donations. Every bit helps, I'm putting in the rest myself because it continues to be an important feature in Pods 3.0 that's holding up the release.

[pixelkicks]

Isn't Pods funded by Automattic? Aren't they stumping up enough moolah?

[sc0ttkclark]

Automattic is a Pillar sponsor through Friends of Pods. Pods isn't fully funded by Automattic, it only goes about 70% of the way towards the expenses of keeping @pglewis @jimtrue and @Shelob9 paid and with lights on, with a very modest income they generously work with for us because they all believe in our cause. We still rely on our other Friends of Pods to help make up the difference, but we're not a fully funded project yet. @pglewis normally ends up doing some side work in the name of Pods and having clients pay Pods directly, or I eat more of my credit cards up.

[StaggerLeee]

Make it as commercial plugin and charge for it then ?
Anything just to get away from Advanced Custom Fields plugin and "one man" developing.

I have all best to say about him, but made once fatal mistake with K2 in Joomla, and later had more, more luck than knowledge to convert all my websites to Joomla Articles manager, and later to the WordPress.

[sc0ttkclark]

Pods is a free plugin, we have no intentions of becoming a commercial plugin or having a pro version.

[pixelkicks]

I'd be happy with a freemium model. I would happily pay for features such as this.

Keep the core features in the free plugin, and include extras in a paid for version. What's wrong with that model? Keep the costs low enough and you won't see many complaints. Users would have a better supported product and one with faster updates.

[StaggerLeee]

Not Pods. Make repeater field together with grouping as third party plugin.
What is a shame in it ? I dont understand.

I already have PRO licence for ACF, but honestly live in fear using it so extensively on all my websites.

[sc0ttkclark]

A loop field type has to be part of Pods core, it will not be a premium add-on. We're nearly there, just hold on and we'll have CMB2 fully integrated with Pods 3.0 and the world will be merry and everything is free.

[pixelkicks]

In 2015?

[sc0ttkclark]

Or bust

[sc0ttkclark]

@StaggerLeee and @pixelkicks -- If you're interested in paying for a commercial plugin solution, you should totally become a Friend of Pods and help make this a reality. If you're already using Pods for client projects and depend on it, and really want to see loop fields happen, that is literally the best thing you can do right now. If you're hesitant because you're worried Pods 3.0 won't be released in 2015, then I could promise that if we don't release it in 2015 then I will refund all of your donations (hopefully you become a recurring monthly friend). I believe in what we have going here, we've finally got the right people in place to make this happen, it's just a matter of having them able to work on it uninterrupted.

[lkraav]

Thanks for reminding me @sc0ttkclark. We briefly chatted about optimizing the Friends landing page back in the day. I'm going to hop on the silver bandwagon now, but I'd like to somehow get invoices to my company. Donations are a hassle from a taxation perspective. No need to reply here and take this issue further off-topic, but I thought maybe other business-owners have the same concern. I'm looking you up on podswp slack next.

[kenwiesner]

As the ONLY Silver Friend of Pods, I encourage all of you who know and love
Pods to join me in support of the amazing work that Scott and the entire
team are doing. Let's be serious here guys, Pods IS a "premium plugin" the
difference is that instead of charging everyone a flat fee, the Pods team
is asking "if you use it and you like it, help fund its development." It's
a model that makes this invaluable tool easily accessible to anyone and
expands the user base making it a more powerful tool for everyone.
https://pods.io/friends-of-pods/friends-and-partners/

On Wed, Sep 9, 2015 at 9:49 AM, Scott Kingsley Clark <
[email protected]> wrote:

@StaggerLeee https://github.com/StaggerLeee and @pixelkicks
https://github.com/pixelkicks -- If you're interested in paying for a
commercial plugin solution, you should totally become a Friend of Pods and
help make this a reality. If you're already using Pods for client projects
and depend on it, and really want to see loop fields happen, that is
literally the best thing you can do right now. If you're hesitant because
you're worried Pods 3.0 won't be released in 2015, then I could promise
that if we don't release it in 2015 then I will refund all of your
donations (hopefully you become a recurring monthly friend). I believe in
what we have going here, we've finally got the right people in place to
make this happen, it's just a matter of having them able to work on it
uninterrupted.

—
Reply to this email directly or view it on GitHub
https://github.com/pods-framework/pods/issues/109#issuecomment-138934958
.

[pixelkicks]

Ok, it's not a lot, but we've just signed up as a Green member for $5 a month. Every little counts huh?

[sc0ttkclark]

Every little bit counts a LOT. $5 adds up over time, and if we could get 520 people to become a friend out of the current 30k+ sites using Pods (https://wordpress.org/plugins/pods/) then we'd be fully funded.

[StaggerLeee]

I donated small amount.
But, still would like to see some goodies as premium plugin(s).

I am convinced it would be enough money from licences to finish this job from issue here 2 years ago.

[sc0ttkclark]

To be fully funded, we'd need:

• 463+ Green friends OR
• 93+ Bronze friends OR
• 28+ Silver friends OR
• 8+ Gold friends OR
• a mixture of the above

[sc0ttkclark]

With our 21 current friends combined, we have the equivalent of 1 gold friend.

[SGillessen]

As @lkraav said, I'd be more willing to pay on a recurring basis, if I could be invoiced. Makes it much easier on my tax reports.

[sc0ttkclark]

@SGillessen I sent you an e-mail to get more details on your company to add to our invoicing system. If anyone else needs invoices, we can definitely get those setup.

[jimtrue]

Yep, email [email protected] and we'll get you properly setup for invoicing your donations.

[ghost]

You said 3.0 will be out this year. Can you narrow it down some more?

Currently i'm using custom fields suite but i recently noticed that deleting an item from the loop in CFS doesn't work as i expected, which makes it complicated for my needs.

If you could take a look and tell me if pods will handle it the same or not.
Here is what i mean:
https://wordpress.org/support/topic/deleting-item-from-lop?replies=1

Keep up the awesome work, pods is one of the most powerful plugins for wordpress.

[szepeviktor]

GIMP developers say:

I would donate to speed it up if my salary would be anywhere near $55k/y (as stated in the pods newsletter).

[nicdford]

@szepeviktor it doesn't take making $55k/yr to help, every little bit counts! At the very least, get yourself a sticker!

[sc0ttkclark]

Just following up, CMB2 is already in progress with the nested fields refactor to support what we need for Loop fields. The PHP side of this is complete and is awaiting review by @jsternberg. And @wpscholar is in progress with the Backbone refactor as the second part of that process right now. We're all pushing for 3.0 release this year, but with those parts up in the air, we can't commit to a specific date just yet. Will continue updating this ticket as we reach milestones on development.

[iCristiano]

Any update? 2016 so?

[quasel]

Due to some recent events and the Desicions to part ways with CMB2 http://pods.io/2015/11/12/pods-3-0-and-cmb2-parting-ways/ things change things a bit http://pods.io/docs/comparisons/loop-fields-custom-vs-relationships/ - a more detailed post about the the roadmap will be relased in the next days

[sc0ttkclark]

Check our blog in just a few minutes :)

[waldbach]

sweet

[sc0ttkclark]

http://pods.io/2015/12/26/new-path-pods-3-0/

[JohnGraffio]

Loop fields / nested fields in Pods 3.0 will behave like the old Pick operating system multi-values, whose current incarnation is called OpenInsight. I used to program in that environment; when you get Pods to do that, it will be the most significant plugin available for WordPress. Can't wait.

[JoryHogeveen]

Hi all! I was just wondering... since I've used ACF for loop fields. When Pods has its own loop field. How will pods store this data? Will it be similar to ACF ( **parentFieldName**_**row**_**childFieldName** )?
I hope so since that will make it a lot easier to convert my websites to only use Pods :).

[StaggerLeee]

From 0% to 100% how much is done approximately ?

[sc0ttkclark]

Just posting an update on this, we've been working hard on our new Backbone-powered fields in #3364, specifically for #3311 and #3309.

I've been playing around with the alpha version of Pods 2.7 and it's really fantastic. Flexible relationships are going to be way better for structure than Loop fields could ever be, but this is the logical first step. So if you're looking for a % completion amount, I'd say we're about 50% right now, because 25% will be finishing up our cool new modal form syncing with the Backbone fields, and the remaining 25% will be applying this cool stuff to the Loop field type which exists as entirely custom data (not relational data that lives on their own records).

[StaggerLeee]

Give us info when 2.7 - 3.0 will be upgradeable via WordPress backend. RC, not Alpha, Beta. So we can start using it and report back problems.

[pglewis]

2.7 has been my top priority since the day I started on it. If I could give you a hard and fast date I would have already done so. The scope changes, unexpected road-blocks show up, real-life intervenes, etc. Any estimate I give you would be pulling a date out of a hat that I cannot guarantee will be accurate, like many software estimates. The only answer I have any time you ask is: as soon as we possibly can.

[kochhase]

sorry I have waited over 1 Year of loop fields. Now I have to switched to toolset (types). There development is fast and the missing struktur for many to many relation will come end of the year.

[kelfy]

@kochhase You just waited a year but I've been waited many years. Look at the date of my first comment on this thread.
The only advantage of Pods is allow you to create advanced custom fields which let you to store in a seperate table instead of WP standard one. Other then that, ACF, Toolset, Custom Post Type UI..etc are doing great job.

[JoryHogeveen]

@kochhase @kelfy
ACF would be your best pick for now if you need loop fields (though it is a premium feature). I would not recommend Toolset though.
Also note that Pods and ACF work very well together. So for example you can use Pods as your base for all your objects (CPT's etc.) and basic fields and use ACF for some extra features for example.

[kelfy]

@JoryHogeveen That's what I do too. ACF+Pods almost for all my projects over the last 2 years

[quasel]

@kelfy Sorry that it took longer then any of us expected maybe you did read some of the reasons

Pod's already has some sort of "LOOP" it's just stored in an related CPT and we are adding an UI to make it simpler / more usefull and call it "flexible relationships" #3309 - you can test an "Alpha"

[szepeviktor]

As for mixing Toolset and ACF with Pods

Toolset's code quality is _low_, no better word for it.
ACF is a one man show.

Pods is an enterprise level plugin with tests.

[kochhase]

Toolset's code quality is was low. that was before Toolset 2.
Now its good for non php user and has fast devolpment for the future. There are more than 8 developer working for it.

[StaggerLeee]

With this nonchalant attitude you are making it difficult for other developers. How it is possible ACF has more third party addons than Pods ? How on earth.

[szepeviktor]

@StaggerLeee

Pods is an enterprise level plugin with tests.

That means it is used where stability is critical.
ACF's clients are - I think - non-technical people. They see only the screen.
I usually partly audit the plugins and contact the author also.

[StaggerLeee]

Maybe you did it difficult for yourself from beginning. Let us say this way. Why should you lose time on Repeater (Loop) field, Group addon, etc... Why not make it easy to third party developers to make it.
I know now is late, just chit-chat.

Something like ACF has for instance Table field as third party addon.
I dont know any third party addon extending Pods field types. Maybe there is but I missed it.

[quasel]

well this goes a bit offtopic - to answer you last Question - Pods is and was a more developer centric tool and has less of the shiny ui for the admin page. Regarding integrations it's all there for people to use, CIO, Gravity, iThemes, Easy Pods,... last week e.g we got contacted by AdminColumns Pro they are working to fully support pods including relationships.

And the beauty you can combine Plugins to get the best of both - after all Pod's is free and opensource and sponsored by well known players out of the WordPress Community!

[jimtrue]

This discussion is devolving into a bashing this plugin and a Pods vs ACF vs Types discussion. I'm not seeing anything posted towards moving the project or this phase of the project forward. Non-constructive criticism or comparisons don't really help anyone, they just become a discussion of 'why isn't this done yet?' and 'why haven't you done what this other plugin has done?' None of which are helpful or, again, move the project forward.

Sorry to come down with the 'ban' hammer, but if there is any more discussion that isn't _constructive_ towards providing code contributions, code suggestions or actual support in the form of documentation, help to other users with workarounds (with examples) or donations to Friends of Pods so we can actually afford to hire additional developers to move the project forward, we will ask GitHub to remove your ability to comment on this project because you have become what the internet defines as a 'troll'.

This is an open source, free plugin with free support. Our driving focus has always been to provide a framework that provides a fairly painless entry into the the Custom Post Types, Fields and Taxonomy world of WordPress to take your content beyond just Posts and Pages. We also have a very stable back-end that allows for extremely powerful enterprise level solutions. Loop fields have 'on the back-end' been in Pods since version 2.0 since we support relationship fields natively between Post Types, WordPress Objects and Taxonomies both one to many and many-to-many. What we're missing is the UI to provide that simplicity in the back-end.

If you want to get involved in helping with that UI, provide code, download the feature branch (feature/2.7) and jump into the discussion in our Slack Chat on the #core channel. If you want to keep criticizing the project without providing actual, workable solutions, please step off of this discussion.

[StaggerLeee]

I know all of this. Difficult to say something without offending someone.
If whole WordPress is managed as Pods instead of 47.000 addons it would have maybe 5000 of them.
Does it mean WordPress core code is of low quality ?

---

For instance this is made yesterday. I dont know what you are doing, but maybe time to lift heads above code. I know it is high quality code, no need to repeat it.

[szepeviktor]

You may open a PR with:

#side-sortables .form-table tr.pods-field > th {
    width: 150px;
}

[sc0ttkclark]

We've got a _separate_ process going on for responsive forms, so that's off topic.

Thanks for your patience so far, we're closer than ever before to a Loop Field Type with our work in Pods 2.7, which changes all of our form field types over to Backbone + Marionette JS. It's pretty cool stuff what @pglewis has managed to do with it so far.

I think it's best to temporarily lock this thread, that doesn't close it, but allows us to focus on completing the work needed for Pods 2.7 which is basically Loop Fields but with relational objects. I'll unlock the thread after 2.7 is released as this is taking time/resources away from what's most important (and echoing what Jim said): moving the project forward.