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.


acrazyanimal’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev
dagmar’s picture

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.

acrazyanimal’s picture

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

fmizzell’s picture

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

dagmar’s picture

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

dagmar’s picture

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

fmizzell’s picture

@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

dagmar’s picture

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

Renee S’s picture

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.

Renee S’s picture

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

kaizerking’s picture

Support request for entityreference property and entity behaviors.

webadpro’s picture

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

kaizerking’s picture

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.

circleoflife’s picture

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


yorguey31’s picture

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

yorguey31’s picture

Category: task » feature
Priority: Normal » Major

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

yorguey31’s picture

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 ?


hughworm’s picture

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

acbramley’s picture

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!

fmizzell’s picture

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

acbramley’s picture

@fmizzell thanks a lot :)

aanjaneyam’s picture

Pathauto integration!!!

moshansky’s picture


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


kriboogh’s picture

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.

fmizzell’s picture

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

klonos’s picture

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

fmizzell’s picture

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

klonos’s picture

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

klonos’s picture

Issue summary: View changes

Included new items from comments.

MustangGB’s picture

Export as code is a must have.

drupal-coder’s picture

Export (and Import) would be very nice.

fmizzell’s picture

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

fmizzell’s picture

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

Renee S’s picture

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.

drupal-coder’s picture

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

MustangGB’s picture


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.

fmizzell’s picture

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

MustangGB’s picture

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

fmizzell’s picture

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

joelpittet’s picture

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.

dfletcher’s picture

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.

DamienMcKenna’s picture

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.

MustangGB’s picture

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

DamienMcKenna’s picture

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

alexanderpas’s picture

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

herd45’s picture

+1 for Pathauto integration

philsward’s picture

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

raoulcoo’s picture

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

mengi’s picture

I saw a few people mention pathauto. The module pathauto_entity provides that integration.

brad.bulger’s picture

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

computerbarry’s picture

As 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

adding more flexibility for paths

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:

  1. Better control creating paths
  2. Deleting and updating entities in bulk
  3. Sorting entity lists by activated links to the column titles

Looking forward to new releases, good work :)


ar-jan’s picture

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

yannickoo’s picture

I would like the functionality to completely remove paths for a specific entity type.

fmizzell’s picture

Status: Active » Closed (fixed)

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

fmizzell’s picture

Here is the first pass at the roadmap #2382255: ECK D7, D8 roadmap