Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We just opened the 3.x branch with some very useful functionality to add property widgets through the field UI to any property.
We also have a handful of features in our radar for 3.x, including:
- Property formatters
- Configurable behaviors
- Better permission management
- Entity revisions
- And full multilingual support
- Export as code functionality
- Tests
- Solid Feature support
If you have any ideas or suggestions on what ECK should do, please let us know. We want to implement better cycle management for the 3.x branch, so any new features that we don't decide upon right now, will have to wait until 4.x.
Comments
Comment #1
acrazyanimal CreditAttribution: acrazyanimal commentedComment #2
dagmarWould be nice to have some 'export as code' (not as features) so we can use ECK to actually autogenerate the code for our entities and be able to disable ECK after all entities were created.
Comment #3
acrazyanimal CreditAttribution: acrazyanimal commented+1 here for dagmar's 'export as code' idea.
Comment #4
fmizzell CreditAttribution: fmizzell commented:) This was one of the very first feature request I got when eck first started, and back then, after a lot of thought, it became very hard for me to see how we could give a user all of the capabilities of eck in a module (code export). I am all ears though, if someone can figure out how this should work. I would also like to hear what the benefits would be, beyond being able to turn eck off.
We are currently not using features like we should, in theory after we move something to code we should be able to use it as is, but instead eck recreates things in the db from the feature. If we were to fix that, I think that would be as good a partial solution as any I can think of.
Very anxious to hear some ideas on how exporting and making entity-types/bundles independent of eck would help users.
Comment #5
dagmarI think the only feasible option is to provide a one time export option. I mean, I'm not sure if re-export the feature will be an option, after all entities may have special customizations that are hard to map.
Instead of that, I'm thinking more in a way to help developers to get some initial code that define the entity type and avoid them start from scratch (or copying and replacing code from something like profile2).
Comment #6
dagmarAlso, regarding to the 3.x features. It would be nice to have some tests for this module.
Comment #7
fmizzell CreditAttribution: fmizzell commented@dagmar thank you so much for your feedback, now the follow up question: why would anybody not use eck for their custom entities? Why would users still choose to copy and paste?
+1 on testing
Comment #8
dagmar@fmizzell well, that depends, some users may not trust enough in ECK or think that there is too much to include another dependency to its system. Other may not be aware of ECK.
Also, custom code allows organize the work in different files, use VCS, etc. Is a good choice for development with larger teams.
My 2 cents.
Comment #9
Renee S CreditAttribution: Renee S commentedSecond export functionality, or at least solid features support. For us it's not a matter of trust at all: I just want to keep architecture functionality in code, not in the database, and want to be able to manage versions, too! Using ECK as a construction kit is great, and perfect, and awesome: but when making a move to production, you want (need) a different model. Given the audience for ECK I suspect this will be a common request.
And, turning off unneeded modules never hurts in production either.
Comment #10
Renee S CreditAttribution: Renee S commentedAlso, having "own" permissions like in node entities would be rad. I see there's a patch already for 7.x-2.x, so, that :)
Comment #11
kaizerking CreditAttribution: kaizerking commentedSupport request for entityreference property and entity behaviors.
Comment #12
webadpro CreditAttribution: webadpro commentedWell, I'll add in the following feature: adding more flexibility for paths ;)
Comment #13
kaizerking CreditAttribution: kaizerking commentedFunctionalities planned can be moved to a separate issue to follow up rather than keeping it here as list item. Now we do not not know the status of the planned items i.e whether some things have been finished.
new requests could be added here, if maintainers feel it can/will be taken up then move to new issue and link back.
this prevents duplicate/similar requests.keeps this issue current, developers could contribute in the individual issue if they want to.
Comment #14
circleoflife CreditAttribution: circleoflife commentedis that possible to let me select if I need to add index to property when add a property to my entity?
Thanks
Comment #15
yorguey31 CreditAttribution: yorguey31 commentedFirst this is a great add for drupal, thx.
It s first avantage is to be light in regards of node for instance.
It's light overhead in DB is a huge avantage if there is lot of instance (thousands...).
Please keep it light and don't transform it in new "node" clone.
Please don't introduce comments, revisions and so on in core without the habilities to completely disable them...
Comment #16
yorguey31 CreditAttribution: yorguey31 commented+1 support for entity reference
+1 "own" permissions like in node entities
Comment #17
yorguey31 CreditAttribution: yorguey31 commentedFirst thx for this great module !
Is there a roadmap for the 3.x version.
When do you think it will be released for production ?
Thx
Comment #18
hughworm CreditAttribution: hughworm commented+1 for entity property indexes e.g. where there is a join to a node or user.
Comment #19
acbramley CreditAttribution: acbramley commentedThis all looks very interesting, I'm looking into using ECK for an upcoming project which requires several custom entities with various bundles and references between. My very first consideration is something that is mentioned in #9 with regards to different environments (i.e releasing development of these entities to staging and production as well as other development environments) is this something that is not currently easy to do with ECK? Is there currently no way to easily export what ECK creates for you and "featurise" it?
Basically I know for a fact this project will require custom code so I'm looking for a way to create the boilerplate code with ECK and continue from there custom coding it with the ability to use features to export the changes in the db (new fields, configuration etc) but from this issue it sounds like it's not currently possible? If so, +1 for features integration!
Comment #20
fmizzell CreditAttribution: fmizzell commented@acbramley ECK 2.x does have features integration, so you can create your entity types, add properties to them, add bundles, and add fields and move it all between dev, stage, and prod. We are adding a few more configuration options and we want to make sure those are working well with features in 3.x, but features is supported and I personally use it extensively. In another comment it was mentioned to add functionality to use ECK as a boilerplate system, but I think having the features support is enough for most cases.
Comment #21
acbramley CreditAttribution: acbramley commented@fmizzell thanks a lot :)
Comment #22
aanjaneyam CreditAttribution: aanjaneyam commentedPathauto integration!!!
Comment #23
moshansky CreditAttribution: moshansky commentedHey,
Could the submit button and associated actions be moved to the $form['actions'] array as per...?
https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen...
Comment #24
kriboogh CreditAttribution: kriboogh commentedIs it possible to use ECK to create a new entity definition and map it onto an existing database table? And more importantly can this be an external database (which you define in your settings.php file?
I'm currently doing this through code and was looking into ways to abstract this a bit more so i could reuse this in other projects. Then i saw ECK, so it would be cool if you could just create a entity definition through your module, have the choice to either create the tables or attach it to existing table(s) and tell the entity which properties map onto which database table and column.
Comment #25
fmizzell CreditAttribution: fmizzell commented@kriboogh.. that is a very interesting idea, and it is definitely possible.
Comment #26
klonos...as of today the latest 7.x-3.x-dev (2013-Aug-07) shows up as an unsupported version ...with itself as a recommended version? What's up with that??
Wouldn't even bring it up, but it throws a "Module and theme update status/Unsupported release" error in the site status report.
Comment #27
fmizzell CreditAttribution: fmizzell commented@klonos I did that. There are some major changes brewing in the 3.x branch, and I am afraid that if people is building stuff on top of that dev branch that it will be difficult to upgrade once an alpha comes out. I am very happy to see people testing it out and playing with it, but I don't want people building anything serious with that code. Did I handle my concerns incorrectly?
Comment #28
klonosWell, I guess it is a right way to do it. It puts some emphasis on the fact that it is an unsupported version and I'm definitely not the person to judge if this emphasis is too much or not. Just want to say that having a branch with only a dev and no stable or recommended releases -to me- is enough to signify that people should be cautious with it.
Anyways, fair enough explanation I guess. Thanx for taking the time to reply ;)
Comment #28.0
klonosIncluded new items from comments.
Comment #29
MustangGB CreditAttribution: MustangGB commentedExport as code is a must have.
Comment #30
Anonymous (not verified) CreditAttribution: Anonymous commentedExport (and Import) would be very nice.
Comment #31
fmizzell CreditAttribution: fmizzell commented@drupal-coder thanks for your feedback. When you talk about import/export, do you mean something separate from features?
Comment #32
fmizzell CreditAttribution: fmizzell commented@akamustang when you mention 'export as code' do you mean features-like functionality, or actually producing Entity classes that reflect what has been configured in the UI?
Comment #33
Renee S CreditAttribution: Renee S commentedFeatures-like functionality for me. (In fact, Features functionality would be ideal.) Even if it was just like Panels or Views with an Import tab and an export option, that would be really valuable.
Comment #34
Anonymous (not verified) CreditAttribution: Anonymous commentedposibility in the UI for import and export (like in views -> clean class) for easy exchange (#6 from the first post but with export).
Comment #35
MustangGB CreditAttribution: MustangGB commented@fmizzell
No I'm not talking about features-like functionality, I'm talking about producing code as it would be as if I'd created a standalone module from scratch.
Essentially allowing developers a way to quickly create, modify and delete entities for testing purposes or whatever, then when they're happy, or want to move from a site specific solution to something that's cross-site capable, or share their code with others, or create a new project on D.O. then it's a a simple process to export the code to a standalone module and amalgamate with exisiting custom code without the need to #include eck or features.
So yea, I guess that's "actually producing Entity classes that reflect what has been configured in the UI".
I hope it's a possibility.
Comment #36
fmizzell CreditAttribution: fmizzell commented@Renee S @drupal-coder @akamustang thank you for the clarification
Comment #37
MustangGB CreditAttribution: MustangGB commentedI have another request, property types should be a dropdown select input rather than a textfield.
Comment #38
fmizzell CreditAttribution: fmizzell commented@akamustang noted, there is an open issue for that.. and a handful of other UI fixes #2138477: Get an options widget working
Comment #39
joelpittetThese all look great!
Export to code would be awesome for VCS, but as long as features can do that job well, I think that would probably solve that.
Comment #40
dfletcher CreditAttribution: dfletcher commentedI would love to see some better control over the title field (and I guess the other default fields as well, though I haven't had much use for those). Renaming the label, supplying a description, changing the position in the fields form. Often I end up putting numbers in the weights fields by hand because of that last one, and doing custom form alters for the first two. Seems like these would be fairly straightforward to have in the UI, since this is pretty much what Admin -> Structure -> Content types already does.
Comment #41
DamienMcKennaCould you please update the todo list on the project page with links to the issues, maybe add a meta issue with links to the tasks you are deem requirements for 3.0? Thanks.
Comment #42
MustangGB CreditAttribution: MustangGB commentedI would like to help with "Export as code", but I don't know where to start =)
Comment #43
DamienMcKenna@akamustang: Regarding the "create a module" thing, have you tried exporting an ECK type / bundle via Features and then copying the hooks into a separate module? Most of what Features does is provide wrappers around existing hooks, e.g. CTools exportables, that can be used independently of Features.
Comment #44
alexanderpas CreditAttribution: alexanderpas commentedRegarding Functionality for 3.x:
Considering the fact that the node module has been made optional in Drupal 8, it would be very cool if we could re-implement all functionality from the node module with ECK, resulting in a more flexible system. (with everything being optional.)
Comment #45
herd45 CreditAttribution: herd45 commented+1 for Pathauto integration
Comment #46
philsward CreditAttribution: philsward commentedWould love to see the entire admin interface for ECK converted over to views.
Unless I'm missing something or overlooked this request already, the ability to change what shows up for each of the ECK containers, is extremely limited. Having the ability to add fields to the admin interface table would be awesome. Similar to how the Drupal Commerce admin area is setup to handle the backend through views instead of a proprietary hard coded admin interface. Theoretically, it will also help pave the way for transitioning into D8 since all of the admin interface is now handled through views.
Comment #47
raoulcoo CreditAttribution: raoulcoo commentedDirect use of entities properties as database tool:
I think that like me, lot of people use entity because the want to manage (existing) database-like data.
So property of entity should be used as reccord management Tools (change color of the car, get car features, etc...)
Comment #48
mengi CreditAttribution: mengi commentedI saw a few people mention pathauto. The module pathauto_entity provides that integration.
Comment #49
brad.bulger CreditAttribution: brad.bulger commentedIf you introduce revisions, make them optional, and make sure that they work with Entity UUID.
I very much need an admin UI for bundle types, to be able to edit properties and such. (The Edit tab now is a blank page.)
Support for Bundle Copy or similar to be able to export/import/clone entity types and bundle types through the UI. I have circumstances where clients need to be able to do this sort of thing directly, without any requirement for code changes. A similiar functionality at the field level would be great but I guess that's a core thing, yes?
An entity-level export/import capability - entity content, I mean - would be a nice-to-have addition as well.
We get a number of cases of "we need a new thing that's like this old thing but then also has X and doesn't have Y". The low overhead of ECK is a big plus for us. Maybe a division of ECK vs ECK UI (like Context and Views) might be useful along those lines.
Comment #50
computerbarry CreditAttribution: computerbarry commentedAs mentioned in my active issue: https://www.drupal.org/node/2323061
Better urls with - (example.com/whats-on/events) not (example.com/whats_on/events) generally more control creating paths.
Also mentioned above by webadpro #12
Another big problem for me is deleting old entities, we need a way to delete in bulk. As things stand, we can only delete one entity at a time, unless we download another module. Very time consuming.
Sorting Entity Lists, like with content types, you can sort the list of nodes by Name or whatever columns are present. No links are available in the Entity lists for sorting A/Z-Z/A by Name, Created date or Changed.
This would be a big time saver and allow users to organize the entities much quicker if we have thousands of Entities to check through. This would tie in very well with the bulk deletion as mention above.
In short:
Looking forward to new releases, good work :)
Barry
Comment #51
ar-jan CreditAttribution: ar-jan commentedThere are many nice ideas here, and I notice there's quite a bit of activity in the 3.x branch, so I'm wondering what the status of it is, and how (un)usable 3.x would be for adventurous users currently.
@fmizzel, what do you think of creating a 3.x Meta/Roadmap issue, with targets for alpha/beta releases and links to corresponding open and completed issues? That would give a good idea of the current status, and point people to issues where they could help out.
Comment #52
yannickooI would like the functionality to completely remove paths for a specific entity type.
Comment #53
fmizzell CreditAttribution: fmizzell commentedThanks everybody. I will create a roadmap issue as has been suggested by a couple of you, and list all of the mentioned desired-features there. I will prioritize from easiest to hardest issues, but will create or link to existing issues for each of the requests from the roadmap.
Once again, thank you for your input.
Comment #54
fmizzell CreditAttribution: fmizzell commentedHere is the first pass at the roadmap #2382255: ECK D7, D8 roadmap