Closed viruthagiri closed 2 years ago
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.
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 !
@2jstudio Loop fields are not available in Pods 2.4.
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.
No problem, thanks very much for your answers, I understand it all now :) Can't wait to have this feature working, seems great !
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.
@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.
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 notifications@github.com 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
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:
PODS_TABLELESS
is turned on.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.
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.
excellent work! excellent plugin.
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.
Loops fields already in Pods 3.0, still some things to do with Admin UI and implementing our UI for CMB2 integration.
Would you recommend 3.0 is stable enough to use on a live site?
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.
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.
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.
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 ?
Last comment from Scott was in December, saying it's not far off. Are we any closer?
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.
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.
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.
@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.
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.
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):
Is the nature of the bounty public?
label removed ^^ but take a look at https://www.bountysource.com/teams/pods-framework
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?
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.
Thank you.
Great. So looking forward to it
Updated the main to-do task list in the main description for CMB2 tasks
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
Is this ever going to be completed and released? This thread was originally created on 25 Feb 2012.
@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!
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.
Isn't Pods funded by Automattic? Aren't they stumping up enough moolah?
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.
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.
Pods is a free plugin, we have no intentions of becoming a commercial plugin or having a pro version.
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.
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.
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.
In 2015?
Or bust
@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.
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.
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 < notifications@github.com> 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 .
Ok, it's not a lot, but we've just signed up as a Green member for $5 a month. Every little counts huh?
Description modified September 1st, 2015 and July 4th, 2022 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 (needs to be revisited)
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?