Roadmap to 1.0

Oh, yeah. Another advantage of leaving "attached to" in the hands of Entity Reference is that we can have multiple such relationships without necessarily having to privilege any one of them.

So say in the case of an issue tracking feature, an issue Micro would belong just as much to the user it's assigned to as to the project the issue relates to.

(And yes, if you plan to use Micro like this, you might instead want to consider Relation.)

Clarified what code provided by Entity Reference is currently unnecessarily implemented in Micro.

It's odd. When I first came across this module, a whole lot of uses seemed obvious to me, but the Field Collection-like one never occurred to me. If anything, I'm pleased the consensus is that Field Collection rocks, because I'm currently merrily ripping out the UI stuff in Micro that facilitates that kind of use (but has never worked for me).

It's probably best to describe what I have used Micro for. The most straightforward one is a microblogging feature I'm using on a couple of sites, where each post is a Micro "attached" to a user (the author), but also to one or more other users (recipients of messages), other posts of this Micro type (i.e. posts you're replying to) and potentially taxonomy terms (hashtagging) or other entities on the site that posts can refer to.

I've also developed a simple node update moderation feature where privileged users see the latest "real" revision of a node, but anonymous users see the last approved revision. All I'm doing is using the core node revision system and referring to a micro attached to the node that holds our extra revision metadata to pull in the appropriate revision content in hook_node_view().

Most interestingly, a friend of mine is using it on a site he's developed for a marine research group who collect debris (garbage, to non-scientists) from the ocean floor in the local marine park. Every bit of garbage is logged as a Micro, and in conjunction with Views and Google Chart API, they can produce pretty charts of rubbish they've collected viewed by date, type, geolocation, depth, habitation type; however they like, basically. It's pretty cool, and I'm sure paints a very depressing picture of the state of Earth's oceans.

So I'm thinking of Micro not as something to complement Field API, but as a tool for people like myself; site builders who can hack together a bit of code to get the last 10% of the functionality they need, but find entity type creation in code too overwhelming. The problem is that during the development of D7 the idea of "everything is an entity" led to the expectation that we'd be able to do things like:

$entity_type = new entityType('thing');
$entity_type->fields['field_description'] = new field('text', 'longtext');
$entity_type->save();
$entity = new entity('thing');
$entity->field_description->set('Wouldn\'t this be cool?');
$entity->save();
// Note: Don't try this. It doesn't work.

But the reality instead is "Here's hundreds and hundreds of lines of code, copy and paste it into your own module and then start tweaking," which is not practical on low-budget projects. The inclination then is to switch back into D6 everything's-a-node mode and say "I'll just make it a node type". I admit "I'll just make it a Micro type" isn't that much of a conceptual leap forward, but it is an improvement.

I think that even with Entity Construction Kit there will still be cases where you just want a simple little fieldable thing to store data, but you don't need multiple bundles with shared properties, and you want sensible overridable default ways of querying and displaying that data in the context of other entity types the data relates to, and Micro can inhabit that niche quite happily.

Have got the original few features functional enough to be usable. Have added just one last thing to my wishlist before I'm happy enough with the feature set to recommend it to people to test:

#1618484: Default display methods for list of micros from a referenced entity.

Hope to get that done in the next couple of days. Shouldn't jinx myself by saying so, though.

Micro 7.x-1.0-alpha1 is out! Test away!

I fully expect a significant amount of bugfixes and refactoring before a stable release, and a lot of obsolete code still needs to be ripped out, but it's feature-complete enough to be useful now.

If you're running a very old dev version you should be able to upgrade, but some functionality may break in the process, notably any Views you may have created which depend on micro properties that don't exist any more. I have some update code which converts those properties to fields, but you'll have to adjust your Views manually to use these.

Added extra little task.

Fine idea in principle. The only reason I started using Micro was that at the time it looked closer to production-ready than ECK. I soon realised my mistake, but by the time I fixed it, broke it, fixed it again, etc. I felt obliged to push my (arguable) improvements to d.o.

I'm also starting to think that the "backreferences" functionality (which is basically just a design pattern I got tired of reproducing manually on almost all my sites with Views and a bit of custom code) might belong in entityreferences, or an add-on to that module. Come to think of it, the same applies to the special field behaviours. If I were to move that stuff to another module (or modules), we can practically consider Micro stable and "finished".

I'm just about to revisit the site that I started using Micro for (also have a few others I've done since), so I'll have to upgrade it to either the "new" Micro, ECK, or some combination of modules old and new, so I'll have to work out what approach is most sensible over the long term. I'll take a fresh look at ECK, put my feet up, stare out the window, and have a deep ponder.

Definitely if you start on ECK you won't want to migrate to Micro, as this would be a significant downgrade in functionality (except maybe for some superficial niceties).

I'm committed to maintaining Micro for the lifetime of D7 because I have quite a few sites now depending on it, but I expect ECK or something like it will be the future for D8, so I imagine Micro for D8 will just be an upgrade module (like CCK for D7).

The aforementioned superficial niceties currently in Micro will probably be moving to separate modules, so you'll be able to use them with ECK or other entity providing modules. I haven't suggested it to the ECK guys yet, but I think their property behavior plugins should do likewise and be abstracted to work with fields as well, since in D8 fields and properties are going to be the same thing and we might as well get used to thinking that way (the D7 concept of pseudo-fields was a step in that direction). Obviously that's a far less trivial task, and I've been reluctant to put in a feature request without having some proof of concept code.