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:

  1. Property formatters
  2. Configurable behaviors
  3. Better permission management
  4. Entity revisions
  5. And full multilingual support
  6. Export as code functionality
  7. Tests
  8. 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.


Version:7.x-2.x-dev» 7.x-3.x-dev

Would 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.

+1 here for dagmar's 'export as code' idea.

:) 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.

I 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).

Also, regarding to the 3.x features. It would be nice to have some tests for this module.

@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

@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.

Second 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.

Also, having "own" permissions like in node entities would be rad. I see there's a patch already for 7.x-2.x, so, that :)

Support request for entityreference property and entity behaviors.

Well, I'll add in the following feature: adding more flexibility for paths ;)

Functionalities 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.

is that possible to let me select if I need to add index to property when add a property to my entity?


First 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...

Category:task» feature
Priority:Normal» Major

+1 support for entity reference
+1 "own" permissions like in node entities

First thx for this great module !

Is there a roadmap for the 3.x version.
When do you think it will be released for production ?


+1 for entity property indexes e.g. where there is a join to a node or user.

This 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!

@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.

@fmizzell thanks a lot :)

Pathauto integration!!!


Could the submit button and associated actions be moved to the $form['actions'] array as per...?


Is 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.

@kriboogh.. that is a very interesting idea, and it is definitely possible.

...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.

@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?

Well, 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 ;)

Issue summary:View changes

Included new items from comments.

Export as code is a must have.

Export (and Import) would be very nice.

@drupal-coder thanks for your feedback. When you talk about import/export, do you mean something separate from features?

@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?

Features-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.

posibility in the UI for import and export (like in views -> clean class) for easy exchange (#6 from the first post but with export).


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.

@Renee S @drupal-coder @akamustang thank you for the clarification

I have another request, property types should be a dropdown select input rather than a textfield.

@akamustang noted, there is an open issue for that.. and a handful of other UI fixes #2138477: Get an options widget working

These 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.

Issue summary:View changes

I 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.

Could 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.

I would like to help with "Export as code", but I don't know where to start =)

@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.

Regarding 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.)