Subscribe to this thread if you want the module to be promoted to a full project. Otherwise I have no idea if anyone is using it and it will never leave the sandbox area.

We are currently using this ourselves on a production site.

Comments

andrewmacpherson’s picture

Title: Promote! » Promote Empty Fields module!

Fascinating module Alan. It just cropped up on the sandbox modules twitter stream and I came to take a look at the code. Pleasantly surprised to get a mention in the readme. Thanks, it's made my day <8•)

I've not made use of it on a site yet, but it's a totally generic use case, and the callback feature should make it very flexible. Based on the usage stats for the other modules which are using the API, I expect it will attract a moderate user base quickly enough. I'll take it for a proper spin soon, but looks like a good candidate for promotion.

If you do promote the module, be sure to file an issue with field formatter settings API. Dave Reid has been updating a list of modules which use the API.

I've expanded the issue title to make it easier to keep track of.

Alan D.’s picture

I think that there was minimal new IP added (~20% maybe), rather it was cutting n pasting various components together and coordinating these, Your module provided 65% of the code so I had to give credit where credits due :)

I personally think that this one is useful as a full project, and I couldn't find anything similar when searching, but there are now 16,000 projects in total, so finding these is getting really hard!

@callbacks
I developed this without too much thought and tried it on the very first live field and it instantly showed up the limitation by only using static text.

While the code we used is a bit long to replicate here, the example is off the live production site that the callback was developed from. It has a text field for entering event dates, but real date fields for the events searches, et al. So if the text field is empty, we parse the dates to find the earliest and latest dates and generate formatted string that states that the event is held between x and y.

Another option that I just thought of is token support, that would provide some integration with the entity without the need for any programming callbacks.

btw, I have just committed a couple small bug fixes.

Alan D.’s picture

I got a feature request to implement a fallback to the field instances default value. This was just committed.

Alan D.’s picture

And 5 subscribers so promoting :)

Alan D.’s picture

Status: Active » Fixed
rypit’s picture

Version: » 7.x-1.x-dev

Alan, could you perhaps elaborate on the feature request to fallback to the field instances default value? I think that by default this should render if we're not already overwriting it, is that the case? The reason I ask is that I'm trying to pear down the core module to its bare minimum and come up with a way that consistently behaves properly so that all "submodules/plugins" can reliably render when needed.

Thanks,
RJ

Alan D.’s picture

I got the request from a guy at work, apparently the default value doesn't come through on existing nodes if you add the default value after creating the node

Another use-case is that I can think of is the Better Formats module, it enforces an empty text value in the database somehow, so it comes though with a rendered field at the front end. So on view, I was seeing either the instances default value (that was empty) or the empty field as saved by the user. So if the second happens, changing the default to a real value would mean that these empty ones wouldn't be used.

Guess I will need to test a few use cases to see what is happening with each core field type

But I still think that if the Better Formats module exists, we need the check on #markup strlen() == 0 on delta 0 items if count(items) == 1. Something similar should already be in place

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.