I love this module and am currently building a large site using it extensively. However, I've begun to wonder if it wouldn't be better to take the features Paragraphs offers and merge them into the Field Collection module, rather than keep it as a separate module.
- Even the Paragraphs project page acknowledges its similarity to Field Collection.
- I've already seen instances of the same bugs and issues popping up in both modules.
- Field Collection has 68,966 reported installs, compared to 257 for Paragraphs. That means more people testing it, providing patches, and trying to make it awesome.
Perhaps this is overly simplistic, but it seems the use case for Paragraphs could be solved if Field Collection had an alternate widget, permitting users to select multiple Field Collection bundles instead of just multiple instances of the same bundle. Would this work and is there any will to do this on the Paragraphs side of things?
Comments
Comment #1
seanbThis makes sense, but I don't know how hard this is? An upgrade path should be included though if the maintainers decide this is something they want to support.
Comment #2
jstollerI just posted a similar request in the Field Collection issue queue.
@seanB, I agree an upgrade path would be important. I assume there could be a new release of Paragraphs that was little more than an update hook to convert paragraphs to field collections, once the necessary functionality has been added to that module.
Comment #3
jeroen.b commentedI really would have to get into some discussion with the maintainer of field_collection.
I don't think paragraphs is a full replacement for field_collection, they both have their benefits.
I'll try to get a hold of the maintainer, but I won't promise anything. A upgrade path is really hard as functionality is really different at some points.
Comment #4
vbouchetI'm really interested by this module as my team had to work on this kind of problem and had to create his own paragraph "system" based on field_collection.
I think this module should use field_collection (which is used by a lot of people) and provide a user interface which can abstract field_collection interface. Paragraphs will only be an administrative module providing a field widget and will not impact how fields are created (no "custom" entity).
Comment #5
jeroen.b commentedThat's sadly not possible. Field collection does not save the bundle with the entity.
The field you use it in tells it what bundle it should use, so it only works with one bundle.
The only way to merge with field collection would be some major changes in Field Collection.
Comment #6
vbouchetBasically a bundle is "simply" a collection (or a simple field but here the cardinality should be sufficient, no need of collection). A paragraph is a collection with a select field and some existing collection (or field again). Am I right ?
Can't we imagine the same interface you created to define bundles but which will only create fields and collections (without attaching fields and collections to any entity, kind of floating fields).
Then in the content type, we can create a new paragraph. You choose the list of bundles you want and it will automatically create the collection (the select field and the reuse of existing fields).
There is probably a lot of things I didn't think about (I didn't test anything here), but it looks feasible and it's basically abstracting users from the field collection interface without creating a new entity type.
Do you think I missed some important points which make this solution impossible ?
Edit: After more reflection (maybe I should did it first), it seems it can be a performance killer. When creating or editing a node, each time you add a new paragraph, field collection will duplicate all fields from all bundles. Fields will be hidden depending on the choice done in the select list but at the end, fields are here. It will probably be a performance issue when a node has a lot of different paragraph and/or when a paragraph contains a lot of bundle. There will probably be some issue with required fields and fields with default values. If I create a new paragraph in the node and select bundle1, it will hide fields from bundle2 but will set an error on form submission if this bundle2 contains required field. It doesn't make the solution impossible but definitely not the best way. Instead of trying to merge paragraphs inside field_collection, maybe it's a better idea to merge field_collection inside paragraphs ;)
Comment #7
malcolm_p commentedI love this approach to content creation as it gives our content editors a menu of options but it does seem like it'd be a more robust integrated with or somehow built on top of field_collection, which we use all the time.
Comment #8
jeroen.b commentedI'll close this for now, I don't think this will happen in the Drupal 7, also don't think it's a good idea to merge with field_collection as the goals of the two modules are kinda different.
In Drupal 8 it's a different story, the current effort is to only create a widget for the entity reference module (which is in core), so we can skip all the parts that are tough to integrate in Drupal 7, like proper multilangual support.