Originally Field Collection was built to replace the limitation of Field Group, where site builders needed a way of having repeating collections of fields. Field Collection combines a custom field type that points to a custom entity type, rather than trying to kludge together a solution to add groups of repeatable fields onto a base entity. This ultimately ended up with modules that provided different portions of the use case:

  • Custom entity types, e.g. ECK, Fieldable Panels Panes, Bean, etc,
  • Custom reference fields to connect the new entity types to other types, eg. References, EntityReference, etc,
  • Improve the reference field UX, e.g. Inline Entity Form, References Dialog, Media, etc.
  • Combinations of the above, e.g.Field Collections, Paragraphs, Field Entity, etc.

At this point some of these have fallen into disarray with limited or no maintenance, while others are continuing to work along steadily.

Two problems that all of the solutions end up having to deal with are revision tracking and translations. Most of the solutions were built without consideration for either, but they almost all end up being used on sites that need them, hence the ongoing efforts to add this functionality to all of the modules.

Field Collections has outstanding issues related to revision handling because it wasn't built with them in mind, while EntityReference has a long-standing debate about how to handle it (the maintainers are basically saying "we don't want to"). OTOH, Paragraphs on D7 contains a reference field that tracks revisions and the maintainers had the presence of mind to split it off into a separate module (Entity Reference Revisions) for D8, solving this problem.

As for language handling, while each entity system is translatable (or has available patches to add this), there's outstanding problems with the reference fields.

At this point, with Field Collections undergoing its second rewrite but still only having an alpha release available, while competing solutions like Paragraphs have solid 1.0 releases, I'd like to make the following proposal:

  • Stop duplicating functionality already provided by other modules.
  • Deprecate Field Collections on D8.
  • Work on migration scripts to convert Field Collection fields to Entity Reference Revisions and Paragraphs.
  • Work with the maintainers of Entity Reference Revisions and Paragraphs to make them better.

To the maintainers: Please believe that I do not intend any disrespect to your efforts or intentions, I'm very grateful you've stepped up to put time into improving it. I just feel that we don't need yet another entity reference architecture when one has already taken over the hearts, souls and codebases of our D8 sites, namely Entity Reference Revisions and Paragraphs. With the finite time that we, the Drupal community, have to maintain our tools, I believe we should be more focused with our efforts and sparing with our time.


DamienMcKenna created an issue. See original summary.

DamienMcKenna’s picture

Issue summary: View changes
DamienMcKenna’s picture

Issue summary: View changes
DamienMcKenna’s picture

Issue summary: View changes
heddn’s picture

To the maintainers: Please believe that I do not intend any disrespect to your efforts or intentions, I'm very grateful you've stepped up to put time into improving it.

Hearty thanks!

But I'm also +1 for pointing folks to use paragraphs. I'm currently in crunch time on a project that I inherited where early on the decision was to use field_collection. That is now coming to bite them, since field_collections doesn't have proper i18n support, and that wasn't known at the time. If I'd been around at the beginning of the project, I might have pointed folks to paragraphs, but now I'm stuck with trying to bolt some features onto this module.

sylus’s picture

I might be wrong as haven't delved too deeply in paragraphs but I thought much of the functionality can be replicated by ECK + IEF still leveraging entity reference revisions. If that is the case can this be taken into account as well?

DamienMcKenna’s picture

@sylus: Absolutely. However, Paragraphs has a 1.0 release, whereas neither ECK nor IEF do.

miro_dietiker’s picture

Thank you for pointing people to Paragraphs. I'm excited that we were able to release Paragraphs 8.x after so much work of our team and all the community participants.

ERR and the specific concept of a composite relationship in ERR originated in our Paragraphs activities. It influenced many related areas and is indeed a missing piece in D8. I'm happy IEF also is considering to add special support for this.

Polishing up everything around the composite relationship storage and a rock solid multilingual setup was delaying our release for months. Paragraphs are already perfectly integrated in TMGMT for multilingual workflows, diff to outline changes, and many more solutions.

We have never intended to replace Field collections with Paragraphs, although it resulted for us in not needing field collections in D8 anymore.. I don't know if paragraphs could replace the field collection completely, we would need to learn about all the different use cases. But we don't want to add complex features to Paragraphs that add complexity for our use case. Instead we are thinking how to simplify and reduce options because we can offer a great UX without options, now that we shaped our minds to understand how people used Paragraphs and how we can push it into a new dimension.

IEF and ECK however are clearly different worlds. They are more originated in building new entity types with some relationships. The genericity of the situation requires much more configurability and covers many more use cases than Paragraphs.

Paragraphs is for content creators and not for generic data modelling. The stable milestone was just the first step in a large plan to push content creation experience to a max with a the paragraphs content component (paragraph types) approach. There is huge room to improve the backend UX and also introduce nice frontend editing UIs. Also we have the vision to build a collection of default paragraph types that are a common collection for d.o distributions or custom solutions. Before jumping into all these fields in depth, we switched focus to the diff module, since a proper revision management and a nice UI is an important piece for our vision in content management.

If this all is aligned with field collections, we are totally open for a collaboration and happy for the joint speed we could generate together.
Drupal also needs different modules with approaches to evolve healthily. If our visions don't overlap enough, we need both worlds.

Elijah Lynn’s picture

This may apply to Multifield too.

#2401975: Drupal 8 version

jmuzz’s picture

I sent @fago a message about this shortly after it was posted but I haven't heard word from him yet.

Multifield is a more lightweight approach to a similar problem, but it doesn't cover all the use cases that the entity based approaches do. See the limitations section on the multifield project page for more details.

I'm not sure I agree that ECK, IEF, Field Collection are a different world from Paragraphs. I'll admit I haven't dug into Paragraphs too deeply but from what I have seen it does the same thing and is more flexible. Could you be more specific about the complex features you are trying to avoid adding to Paragraphs? Or something that the genericity of other approaches would require people to be able to configure that Paragraphs won't?

The Drupal Way is to prefer collaboration over competition and avoid having different modules that do the same thing, or similar things in slightly different ways. I agree with that approach and I would prefer to look for reasons to combine efforts when possible rather than reasons not to.

gcharles’s picture

+1 on this.

Field Collection is a great module but i think Paragraphs is an effective and reliable replacement. I initially started using a combination of both FieldCollections and Paragraphs in a project, but I've totally committed to Paragraphs and have been using it in production for about 5 months.

Paragraphs does have a couple tiny issues, but with the help of the field collection team; Paragraphs might be shipped with Core :) in Drupal 9.

miro_dietiker’s picture

I'm not sure I agree that ECK, IEF, Field Collection are a different world

Paragraphs only supports ERR fields that define a composite relationship.
All ECK, IEF, ... also support creation of entities that are not composite.

The idea to introduce reusable paragraphs exists. It will be a new entity that allows you to clone any paragraph of choice into a library (plus adding a label) to then place it as a reference - as an optional module.

If you need to create non-paragraphs entities in the context of a node, you can still do this, but you would place IEF inside an ER field of a paragraph. Paragraphs will not support other own options.

Could you be more specific about the complex features you are trying to avoid adding to Paragraphs?

No i can't as i don't know all the other Field Collections use cases and how they might exceed what Paragraphs wants to be. That's what i asked for.

I think we should setup some sync call for a strategy on this collaboration, expectations and to figure out if it's a go. :-)

jmuzz’s picture

@miro_dietiker You're right the composite relationships do set Paragraphs and Field Collection apart from the other ones.

I can't think of any Field Collection use cases that seem like they might be outside the bounds of what Paragraphs is trying to do.

For a sync call it may be worth sending @fago a message directly. I'm not sure he's keeping an eye on this issue queue currently.

Jigar.addweb’s picture

Issue tags: +Field collection
naveenvalecha’s picture

Issue tags: -Field collection
michaellander’s picture

I don't necessarily think Paragraphs and Field Collections serve the same purpose(yet).

To me, you have(from least opinionated to most opinionated):
IEF/ECK ---- Paragraphs ---- Field Collections

IEF/ECK makes no assumptions about the referenced entities or their host. You can share referenced entities, or treat referenced entities as belonging to their parents based on how you configure each field. You can also potentially create relationships where an entity is shared by multiple hosts and one host will delete the shared entity if deleted and the other one will orphan it. IEF/ECK is powerful, but it's lack of opinions can create additional complexity. It also didn't used to handle revisions, but this may have since changed.

Paragraphs on the other hand are opinionated about their relationship. They belong to their host, and will be deleted if the parent is deleted. They are revisionable, and the revisions are easy to track because the referenced entites are never shared. Paragraphs, like IEF, also allow you to create and edit multiple types of bundles in the referenced bundles.

Field collections, like Paragraphs, belong to the host entity, however are even more opinionated about what they do. There is no choice of bundle, and ultimately they allow you to group fields within a field(with the possibility of having multiple group values). If this field is reused, it still has the same associated bundle, making it easier to attach any additional logic to.

Part of the problem right now in paragraphs is the paragraphs name space can get pretty crowded. Even if you are just using it for layout components, you can easily have 20+ paragraph bundles, if you start using it for groups of fields(where you never want more than a single bundle), you're going to create even more paragraphs. Can it do it, yes, is it a good fit? Not necessarily. In some sense, this is a similar problem to what happened in older versions of Drupal with nodes. In Drupal 5 and 6, nodes were used for everything, even when they weren't necessarily a good fit. If you wanted a slide show, you might have a 'Slide' node. If that node had an image on it(with meta data), you might have an 'Image' node. Over time, additional entity types came about to separate out responsibilities. To some extent we are coming full circle because we have such an awesome tool in paragraphs, but now people are stretching the Paragraph entity type too thin. Perhaps finding better ways to name/organize paragaphs would help. Alternatively maybe we open up paragraphs to work with multiple entity types. If this issue is solved, I might see more reason to join these efforts.

miro_dietiker’s picture

ultimately they allow you to group fields within a field(with the possibility of having multiple group values). If this field is reused, it still has the same associated bundle

Paragraph types support nesting and limitation of allowed paragraph types inside a paragraph field. We support the very same thing.

Alternatively maybe we open up paragraphs to work with multiple entity types.

You can attach a paragraph to any entity type. A paragraph type itself is always a composite and you can limit what paragraph types are allowed per ERR field. Why would we ever need multiple paragraph type entities? And why should this an argument against collaboration with Field Collections?

jmuzz’s picture

Before I looked at paragraphs I hadn't even considered separating the fields from the bundles. I thought paragraphs added nice bit of flexibility in that and with a bit of extra configuration it can be made to behave similarly to field collection during content creation.

Now it's being suggested that the link between a field and the target bundle may be a desirable feature for some. It can simplify setting up content types. I could add that it promotes the addition of features that operate on a single entity bundle, for example to aggregate some of their fields.

I don't think the implementation is different enough to require a separation of efforts for it. It amounts to a paragraph with some of the configuration done automatically. My opinion is paragraphs basically have the use case covered, but if there is enough demand for it perhaps one day we will see

class FieldCollectionItem extends Paragraph ...
michaellander’s picture

@jmuzz, I think that's good point, and you're right that it would be a rather easy thing to build onto paragraphs in contrib. I dislike that when reusing a field, you may select different paragraph types than the original instance, which makes it more difficult to add strict behavior to said fields. Additionally, the paragraphs overview page can get rather long when bundles are being used for so many purposes. These are rather small things, I know.

You've made me see the light and I agree that the base functionality is similar enough that it may be worth it to combine efforts. It seems like contrib can solve many of my personal nitpicks.

DamienMcKenna’s picture

Just to be clear - IEF is based upon EntityReference, which does not support revisions and never will; that's why other data structures exist, specifically Paragraphs (i.e. Entity Reference Revisions). Basic Field Collection on EntityReference is imho a waste of time, you're just going to be duplicating the work that was already done in Entity Reference Revisions.

ECK doesn't matter in this scenario, it's just an entity type that is being referenced in an EntityReference field, it could just as easily be a content type, a block type or even a paragraph type.

At this point the only difference between what Field Collection 8.x-3.x wants to be and what Paragraphs & Entity Reference Revisions already provide is a tight limit on which referenced bundles are available for each field, something that could be achieved via site builder's naming convention, and which could be provided via a custom field widget, certainly not something that needs a while duplicate module effort.

I'm looking forward to seeing some efforts being put towards this.

jmuzz’s picture

@DamienMcKenna I understand your points and I am leaning towards agreeing with your conclusion. When I opened Field Collection 8.x-3.x I didn't know how similar Paragraphs and ERR was to this. Since this issue has been brought up I have been active in the issue queue for both Paragraphs and ERR.

So far from what I have seen people who are using field collection either didn't look closely at paragraphs first or they prefer something about the field collection UI. The tight limit on bundles, the pages for adding / editing individual field collection items... One person mentioned that he liked how a blank field collection item is displayed on the host form by default without any need to hit an add button.

To be honest though, I can't help but be skeptical about the claims people make about these other solutions. Even before I started working on field collection there were people saying that it has too many problems and it should be replaced by entity reference and that will solve everything, but since then the reported usage of field collection has doubled or maybe tripled. I just feel like the problems are inherent in the complexity of the requirements, and any other solution that starts getting used as much is going to have just as many issue reports about the same kind of stuff.

I think you can see this starting to happen already. There are multiple issue reports about data inconsistency surrounding the "rock solid" ERR module.

If I had my way I'd still be working on field collection 8.x-1.x. I believe it was further along than any other solution when 8.x-2.x got opened.

So these are the main reasons I haven't put up deprecation notices on the field collection project page yet. I still think there may be some way to undo the 8.x-2.x damage and that it might be worth doing.

Despite all that I have been contributing what I can to ERR and Paragraphs, and even recommending Paragraphs in this issue queue.

Also, even if ERR and Paragraphs do end up taking over the structural concerns here there might still be a place for the field collection UI.

8.x-4.x: class FieldCollectionItem extends Paragraph { ?

DamienMcKenna’s picture

@jmuzz: I could definitely agree with a v4 being an alternative UI for Paragraphs; I have some coworkers who also have discussed making improvements to it but have yet to put time into documenting what changes they'd actually like to see, and I know there are some modules to add e.g. a grid-style edit interface. Kudos on getting involved in ERR and Paragraphs' issue queues. I'm hoping the bugs in ERR can be resolved fairly soon, and obviously there'll get fixed sooner if with more collaboration.

jmuzz’s picture

Fair points. I have to say though collaboration goes both ways. MD is doing a great job and certainly accomplishing what he's set out to do but he's also maintaining a lot of different modules and stuff like ERR isn't that high on his priority list.

Maybe you can help out too and try to RTBC some of the fixes I have sitting there in the ERR queue.

DamienMcKenna’s picture

@jmuzz: I'll try to make some time for them next week.

miro_dietiker’s picture

@jmuzz Thx for all the valuable feedback. I'll try to start to pick up your proposals for discussion with Berdir next week.

We pushed for months for the Paragraphs release and yes, it was not perfect. We knew about limitations in ERR and i tried to track all known issues, still forgot to open some issues. Mostly about delete / cleanup... There aren't that many issues coming up and we spent months in beta calling multiple agencies for tests on their production projects. We solved all issues and IMHO nothing really unexpected came up. We have been active in multilingual domain since years and have a good sense of smells and risks.

Default paragraph instances is a known limitation. We initially offered default value selection in paragraph types but there were problems. We thus removed it and i would be very happy to add it with proper test coverage:
#2770507: Allow to select a default paragraph type that will be shown for an empty field
The problem is that the reference is to a default source that needs cloning when the widget loads first or while saving to make sure the host entity ownership is preserved and we are not stealing ownership... Plus there is a default config/deployment problem since the default paragraph instance (includign prefilled values?) is content and not config. But we could skip that and just offer the type selection for adding the default paragraph type.

Not sure about the stability of the Widget to subclass it. We will maintain what we understand as API. But we have big plans to improve the UX of the default widget. It's even likely we will drop some settings because the UX is so much improved that it no more clutters the UI and thus disabling is not needed. We will need the right balance between vision - change - opportunity and (soft) break / limitations due to dept. I want to excite our users and i feel like we can.

Paragraphs is one of the top tools on our priority list. Before jumping into implementing the next big milestone, we just made a pitstop to get diff up and ready. It's amazing... A puzzle piece that perfectly fits into our vision of content creation between Paragraphs, ERR, and TMGMT for multilingual workflows, and Media management, because changes matter, and it helped us to deeper analyse the revision problems inside Drupal. We are eager to jump into deep UX topics, but first want to have the fundamentals ready.

I spent a full week on UX design and thinking / visually developing variations of the Paragraphs UI future. I found many answers and will make them ready so people can participate in the discussion and help to make it happen. John (yongt9412) will start again next week and even multiple others will join soon to get this started. I will start to present the plans next week at DUG https://www.meetup.com/Zurich-Drupal-Meetup/events/234775188/

BTW: i'll organise Sprints at the drupalmountaincamp.ch in Feb 2017 and there will be focus topics like content creation. I truly hope that we can create great momentum after preparing another cycle with months of work on our side, with lots of people collaborating to make it perfect, test it, provide feedback, and shape the vision of its future. I'm looking forward to see you? :-)

NancyDru’s picture

I have tried Paragraphs. It worked okay, but it is UGLY. I cannot imagine my users ever liking the UX unless there were many complicated content types, but I try to avoid that myself.

On the other hand, they like and are used to Field Collections.

miro_dietiker’s picture

@NancyDru Thx for trying Paragraphs and providing feedback. I would prefer inputs that make us understand what this "UGLY"ness is in your eyes. We have spent weeks if not months already to improve the UX.

ExTexan’s picture

I tend to agree with @NancyDru. Frankly, it has been a while since I tried Paragraphs (and I only tried it in D8), but I found the UX to be cumbersome and not very customizable (i.e. much of the wording that appears on the page is, from what I could tell, not changeable). I think it would be a very bad idea to eliminate one module (field_collections) just because another "similar" module is a bit ahead of the curve on a D8 version.

Let both maintainers continue with their own modules, and let us developers choose which one we prefer. Just sayin'.

ExTexan’s picture

Perhaps I should elaborate a bit... My biggest complaint about Paragraphs is that it actually refers to "Paragraphs" on the page (and that's not able to be hidden or overridden). If I'm putting a collection of related fields on the page, with the option for multiple instances, you can be sure they will most likely be presented in a table-like list. I can't imagine anyone would look at a list of that type and call it a "paragraph". With Field Collections, I can name the field as I wish (including the label that appears on the page), and even put it in a fieldset and/or div wrapper to include instructions or descriptive information above the collections.

flocondetoile’s picture

Paragraphs is a complex module which offer to structure complex content. This is not due to Paragraphs that our content edit form can be sometimes "ugly" but because we used it to offers multiple components to compose a content. It's a real strength to permit to users to use several paragraph type, but it's can become a weakness because paragraphs type can be everything, and so UX is difficult to be mastered.

My tiny 2 cents.
In some uses cases where paragraphs is used to reference only one paragraph type, this should not ask an unreasonable investment for offering a lighter UX, as field collections offers. But port field collection to D8 for only this reason seems to me somewhat disproportionate. I can't imagine the work, the blood and tears needed to port field collections to D8 (but i certainly don't have the same skills as the field collection 's maintainers). Whereas almost work is already done in paragraphs. Joining force to improve paragraphs UX seems more efficient.

ExTexan’s picture

If no work had been done yet to port field_collection, I would agree that it doesn't make sense to do a *lot* of work to replace one feature of Paragraphs. But field_collection is at alpha1 state. I have it installed on a dev site and, so far, it seems to be working just fine.

If I could make Paragraphs transparent - i.e. change or remove the wording that the module presents to the user - I might consider it, but I actually prefer field_collection. My point before was, let's not throw out the baby with the bathwater (just because Paragraphs seems to be slightly ahead in the D8 port process).

DamienMcKenna’s picture

@ExTexan: Which user are you talking about - the site builder building the structures or the content editor creating & modifying content? BTW look up the sunk costs fallacy regarding the notion of not collaborating now just because there's an alpha release out.

NancyDru’s picture

@miro_dietiker: As some of pointed out, "Add another Paragraph" is really confusing to my users. At the very least something like "Add another section" would be more meaningful. I managed to form_alter some of the UI, but some would have taken hacking the module, and I don't want to do that.

While I am a developer and can appreciate the flexibility of the module, my users just want a site that is easy to use and where the choices facing them are clear.

In my first attempt, I took a content type that had five sections, one of which needs to be of the revision-specific type; there are issues for doing this not only in FC, but also in Core. The current implementation does not allow them to change the order of those fields, even when it occasionally would allow greater emphasis on one section over another, which they would like to see. Paragraphs did that well. But they had trouble understanding how "Add another Paragraph" was what they wanted to do, especially when the section they wanted to add might have several paragraphs (small P).

And then to mix the type of things that could be selected was confusing to them. It was fine to add a description, an abstract, and audience field - all simple text. But when the choices also allowed add event dates and speaker references, they got lost. I tried to alleviate this some by using multiple fields, but they each contained an "Add" button that was just like the others. Totally confusing.

In the end, I left most of the fields as they were and changed the speaker field (the revision specific one) to a Field Collection with Entity Reference Autofill. The users are very happy with that. It is familiar and simpler UX for them.

miro_dietiker’s picture

I do understand that the UX could be improved if only a simple paragraph type is selected. In fact, most Paragraph users don't use it that way and that's why there isn't even an issue about it. I created it and i would love to get feedback, screenshots and UX proposals there:
#2823907: Optimise UX if only one paragraph type is permitted

An issue is already pending for longer to add a paragraph (type) by default to a paragraph field.
#2770507: Allow to select a default paragraph type that will be shown for an empty field

The feedback about the sticky term "Paragraphs" confuses me. There should be absolute freedom on naming by the site builder:
- The host field (commonly named "Paragraphs") is the top level label that is displayed on the content type. You can pick any name here.
- The permitted paragraph type is used in the label of the "Add XYZ" button.
We always use the paragraph type and the host field in UX when possible, so that the term "Paragraph" is not necessarily visible to the user. I only realised that the empty text is "No Paragraph added yet." and makes this term visible. Thus created issue:
#2823909: Consider field / paragraph type name for empty message

There is an issue to add field group support, just waiting for test coverage:
#2675136: Field Group not working on node edit inside paragraph

If you want to help us move forward, make sure all issues and all cases you describe have automated test coverage. This is a strict requirement for every commit.

@NancyDru I don't get that problem you describe. You decided to allow users to create multiple paragraph types. You could easily create a host field that only allows a single paragraph type - see above. Paragraphs already does a great job in offering slim UX to pick a type when adding a paragraph. It's up to you as a site builder to configure it and understand the users' needs. If they don't want multiple paragraph types, then we should configure it appropriately.

All the items mentioned are really tiny issues (compared to what it took to get here) and can be easily covered in Paragraphs. The problem here is simply that those cases were not on our requirement list, no one reported them (when we asked), or it was totally not a priority for the people working on Paragraphs. There is good reason to address them in Paragraphs, since many Paragraphs users will also benefit from them. This is where all Field Collection related developers can help us greatly.

One final thing about configurability: We are not up to throw more configurability into the widget. It grew in D7 with so many new optional features - and we successfully also reduced some settings. We believe that good UX should be possible with default behavior and the UI should be adapting. With the next steps, we try to make the UI more lightweight and will iterate on many aspects of it to optimise the content creation experience. If you have specific concerns, please open a new issue to discuss and find solutions.

gcharles’s picture

From my use of Paragraphs thus far, i think much of the UX problems would be solved when Field Group is fully compatible with the Paragraphs Module. Every site would have lots of different and unique Paragraph Types and it would be up to the Site Builder to organize these fields into Collapsibles and Grids to Improve the UI for content creators.

In my case, i've got a Video, Map, Text + Image, Slideshow, Gallery, Stats Table and a couple other Paragraph types. The flexibility of this module is one of its main strengths. I think the trade-off between good UX and power is great.....Field Group would really help with the majority of simple use-cases.

jmuzz’s picture

@miro_dietiker Don't get me wrong... I posted some thoughts in those queues with some ideas but really I'm more concerned about getting it working. I believe tests are important too. That's why I made all those patches to convert the tests off of WebTestBase like core is doing. Once those are committed there will no longer be a question of whether or not a new patch should extend what is in webtestbase because it already has the setup even though the conversion patches will have to be updated for it. As it is it seems like it's "make it webtestbase or browsertestbase, we'll sort it out later" and there could be a better plan.

I think it would be more beneficial to fix the data loss / integrity problems in ERR than to theorize about composite entities. I have been ready to continue looking at more of those issues once some of the fixes are committed.

miro_dietiker’s picture

@jmuzz Yeah i appreciate that conversion work. But i'm also not that deep into Drupal core internal long term strategy / maintenance things. I will follow Berdir' advice regarding that - so i will ping him to guide us.

Data loss is critical for sure. Cleaning deleted data (revisions, composite entities) wasn't that a priority and also is not. Most users are creating new things and some debates in core are also more into the direction of flagging as deleted instead of actually delete.

Where do you see the composite over-theorized? We introduced the concept and it helped to solve many Problems in Paragraphs and now we just cleanly want to stick to it. Separation between ERR and Paragraphs is hard... Some people are even asking for better documentation because it's not yet well documented... We should do that. :-)

jmuzz’s picture

@miro_dietiker I was referring to my own posts about composite entities. You commented that you would look at some of my issues and my hope is more that the patches get committed than those discussions be continued.

I believe that there should be a composite entity solution that does highly prioritize the integrity of the data, so perhaps there will be a place for field collection after all.

drobnjak’s picture

We created new META issue for discussion in Paragraphs module, on which we are currently working on. Here is the link to the issue #2831131: [META] Outperform field collections

drobnjak’s picture

miro_dietiker’s picture

I presented about our Paragraphs strategy proposal on our last Drupal user group meeting after weeks of research by our team.

The presentation contains >15 major milestones for Paragraphs, including one dedicated to feature parity with Field Collections. That's why we have created an own META issue at Paragraphs. You can also find there some items we identified from discussions.

Most items seem simple compared to the total progress and some are already in progress or even committed.

Some items need feedback from Field Collections user as we don't exactly understand the problem.
@NancyDru please help with more user feedback as i didn't figure out what is so ugly with our paragraphs UI, see comparision at #2828077: Compare Field Collection UX with Single Paragraph Type UX

Just now, we are also working on going into new directions such as replacing the "Remove" button with a "X" like the seven styleguide always proposed, but core never implemented. #2829676: Change remove button by an "x"

Happy to provide more updates soon.

NancyDru’s picture

@miro_dietiker: I will try to put together another test site and go through this again. It is difficult for me to judge based on the examples given.

To be fair to Paragraphs, I did my initial testing with multiple P types, not single, as that seemed to me to be more in keeping with the design and intended use of Paragraphs. Also, I am still working in 7.x and that is where I will test.

miro_dietiker’s picture

@NancyDru Thx for feedback, but testing in D7 won't help. I'm only maintainer if Paragraph for the D8 lifecycle and started all our work at MD Systems with the D8 port. The whole thread is related to the 8.x status that is superior to D7 by months of work.

Feature parity is clearly a thing that needs to be compared with equal operation, such as one paragraph type per field.

jmuzz’s picture

I can see you guys really want to do the job. Paragraphs is solid and to be honest my time for this stuff comes and goes on a week to week basis. I've been thinking about this and I believe paragraphs is bound to turn out well. Field collection should be deprecated for Drupal 8 in favor of paragraphs. I am not sure when I will have time to get back to developing seriously for Drupal contrib but unless something has changed by then I plan to look at migrations to paragraphs when I do get time.

imclean’s picture

#38 jmuzz:

I believe that there should be a composite entity solution that does highly prioritize the integrity of the data, so perhaps there will be a place for field collection after all.

Depending on use case, we use Field Collection or ECK. ECK is great for reusing the same (referenced) entity type multiple times with an entity and other more complex use cases. Field Collection is great for tightly implementing a field which contains multiple fields. We've used multifield internally but it doesn't yet have the broad support needed for most projects.

We haven't looked at Paragraphs yet so I can't make a fair comparison. Initially it looks like the main purpose of paragraphs is to structure a site in a certain way, but after reading this issue it appears it can be used for other purposes with a bit of configuration.

jmuzz’s picture

the main purpose of paragraphs is to structure a site in a certain way

That's what I thought before this issue was opened too. I think that was the goal when the project was started. I've since looked at it a lot more closely and the essential functionality of paragraphs in Drupal 8 isn't all that different from field collection.

eelkeblok’s picture

Yup. In essence, Paragraphs is just a more generic case of field collection, where the values of a field are not restricted to a single bundle of the referenced/embedded entity type (either paragraph item or field collection item). Because field collection does have this restriction/assumption, it can do certain user interface things a bit differently, but that's the gist of it. Especially in D7, the code is highly similar, I think Paragraphs must have started out as a fork of field collection, actually. (Maybe that's already public knowledge, but I'm not aware of any; that observation is simply based on having had to dig through these code bases looking for obscure bugs - many of which are actually shared.

That last bit is also the reason that I think deprecating Field collection in favour of Paragraphs is a great idea. At least, functionally. From a naming perspective, it's starting to become fairly arbitrary, as this thing is going to have so many use cases that it's going to be hard to stick a label on it that covers it completely. "Field collection" might in fact still be the more generic term, as they are, actually, collections of fields.

jmuzz’s picture

I have placed a notice to this effect on the field collection front page.

m.stenta’s picture

Just stumbled across this conversation after seeing the deprecation notice on https://www.drupal.org/project/field_collection

I am using Field Collection in the farmOS distribution (https://www.drupal.org/project/farm) for a few different "compound fields" (as I have been calling them), so I figured I would add my two cents here as a current use-case.

I have an issue that I am using to discuss D8 upgrade ideas in general for farmOS, and here is the comment I just wrote specifically with regard to Field Collection vs Paragraphs (vs potentially just making some custom fields): https://www.drupal.org/node/2361735#comment-12045904

To summarize, I primarily use Field Collection in two specific use-cases: 1) to create a compound field (with multiple subfields) that is used on multiple log types ("Logs" are an entity type with bundles for different record keeping purposes like "seeding", "harvest", "input" etc), and 2) to create compound fields that may need multiple values (where the same subfields are grouped on each instance).

So it is a very strict structure - and does not need any of the flexibility required for the common definition of "content editing" on a typical public-facing website (farmOS is a login-only app for private recordkeeping).

I need to spend some time exploring Paragraphs in D8 to see how it works, but after reading through this thread I thought it might be helpful to add my use-cases to the conversation. Thanks for all the hard work you've all been putting into both modules!

TrevorBradley’s picture

@m.stenta: Don't be spooked by the name "Paragraphs". I've recently constructed a rather complex "OO style" object using the module, and it works very well. There have also been a number of recent UI changes that removes references to "paragraphs" to make usage of the module less confusing for people who aren't creating visual content. The multiple paragraphs types per paragraphs field is optional, and you can restrict a field to only one type of paragraph.

Give it a try. I think you'll be surprised.

m.stenta’s picture

Thanks @TrevorBradley! That helps to hear! I'll play around with it - sounds like everyone is coming to agreement that it is a good replacement for field_collection in D8.

j.b’s picture

I think there is a fair enough quantity of websites that uses D8 and field collection.

Will there be upgrade paths from Field collection to Paragraphs?

I for instance migrated a D7 website which used field collection to D8 , while still using the field collection module on the D8 version. I did not know about the paragraphs module and did know that it does the same job as field collection.

Lots of views and custom codes configured and written related to field collections.

Field collection still does the job and is working fine.

miro_dietiker’s picture

@j.b Field Collections in 8.x is alpha and thus never guaranteed any stability. The maintainers of FC showed interest in creating a Migration at some point. Nothing is for free though.

Paragraphs has the same problem: The topic is widely adopted, outstanding showcases are created, people present on events, everyone builds custom solutions on top of it, but only very few people collaborate on Paragraphs itself.

You are free to use the alpha as is and help fixing it with the progres of the (sometimes not-so-stable-and-still-api-breaking) core 8.x. Or help create the migration... Or involve the maintainers in your projects so they can find support in their work. This is your turn.

Rest assured, the maintainers act responsible and an intended deprecation doesn't mean anyone is abandoning the project. But it means for sure a way lower priority in the agenda.

DamienMcKenna’s picture

FYI a coworker has some WIP code he has used to migrate D7 Field Collections to D8 Paragraphs, he's going to have some time next week to upload a patch with it and start putting together some docs.

heddn’s picture

We've also done the FC => Paragraphs migration from D7 => D8. One of these days we'll probably get a blog post up about it. It is safe to say, its possible to easily make the transition.

cruno’s picture

Linking the issue I created in the paragraphs module that contains a patch for importing field collections in D7 as paragraphs in D8:

DamienMcKenna’s picture

liquidcms’s picture

We used FC a lot in D7 and Paragraphs a bit. They certainly weren't the same thing; especially from a UX view point. Most cases Paragraphs was not suitable as it really didn't feel like a group of fields on a form; it was a thing you had to add to your form (as per @NancyDru's comments above).

Just tried out D8 Paragraphs and it feels much more like FCs was in D7 - which, for the "typical" use case is a huge improvement.

From working on i18n solutions for FC in D7; i am sure a more native approach within Paragraphs and the UX improvements makes it the path forward.

Great job guys.