Built-in field types accept all content types

Hi Bryan,

Understandable. The problem with us explicitly naming add-ons to be compatible with in the code is we don’t want to leave out any add-ons, such as yours, that might want to start supporting these fieldtypes. Low Variables for example is a content type, but he was able to implement right away without us explicitly adding LV as an accepted content type, and he just picks and chooses which fieldtypes he actually wants available. If you don’t want a certain first-party fieldtype to work with Blocks, then it may be best to explicitly handle that on your end. We just don’t want to have to maintain a list of third-party add-ons that choose to support or not support certain fieldtypes in their content types and hold up developers while they wait for us to release those changes, plus we tend not to put third-party-specific code in to EE. Does that make sense? Let me know if I’m misunderstanding your request.

The fieldtypes that do have “return TRUE” SHOULD work with any content type because they are simple, but more complex ones like Relationships explicitly only allows Grid and Channel as content types. So it’s not all fieldtypes that accept all content types, just the ones that are able to. If you think one is “lying” as you say, let us know which one does not work with generically with other content types.

Kevin

Sorry, I wasn’t asking to be specifically mentioned in core code. I, like the Low example you provided, specifically opt in the built-in fields that I have tested against Blocks. I agree that there is no way EllisLab could ever possibly keep up with all of the add-ons that might ask to be included.

Based on your response, I’m guessing it’s just a difference in philosophy.

When Grid was released in EE2.7, you had third-party field types explicitly opt-in because you didn’t want to break existing field types.

With Blocks, I’d like to follow the same path. Third-party field types need to explicitly opt-in, because even though they SHOULD work (like you mentioned), I still don’t want to run the risk of breaking existing field types. So the best way to do that should be to pass a new string (I went with “blocks/1”) to accepts_content_type and to see if the field-types explicitly opt-in.

And this conservative method works if field-types are conservative about what they accept. The recommendation in the docs is to be conservative, so I think it should work for most third-party add-ons. In my opinion, or my philosophy, EE field types should be conservative too. I’d like to see that they only accept the content types that they’ve explicitly tested against (which would only be first-party content types). If a third-party add on wants to work with the first-party add-ons, it should be the third party’s responsibility to shoulder the burden of testing the first-party field types against their add-on, and opting them in.

But I can see your point, too, so I can be OK with how you do it. Like I said, I already have it solved by excluding liberal field types (whether they are first- or third-party) by default, and opting in the ones that I’ve explicitly tested against.

But you also asked for ones that I don’t think work generically with other content types. Grid claims to to work generically with other content types by virtue of returning ($name != 'grid'). As complex of a beast as Grid is, I doubt it works generically with other content types. It certainly doesn’t work to be embedded in a Blocks field.

I hope we’re not talking in circles here. Does my point of view make sense? If it is just a matter of EE’s opinion against mine, then I’ll accept it. But I thought I should at least raise the question.

Thanks, Bryan. I think I’m a little confused. First you say:

…I wasn’t asking to be specifically mentioned in core code…I agree that there is no way EllisLab could ever possibly keep up with all of the add-ons that might ask to be included.

But then you say:

I’d like to see that they only accept the content types that they’ve explicitly tested against (which would only be first-party content types).

How do we achieve that without explicitly whitelisting add-ons? Or are you saying we should close off all fieldtypes to third-party content types and only accept first-party?

If a third-party add on wants to work with the first-party add-ons, it should be the third party’s responsibility to shoulder the burden of testing the first-party field types against their add-on, and opting them in.

I agree, I think that’s what I was getting at, you should decide which first-party fieldtypes you want to work with your add-on.

Grid works generically enough to work in Low Variables so I wouldn’t be ready to disallow everyone from using it, but yes I can see how it would be tricky for Blocks where the fields are dynamic, though I’m not sure how you want us to handle that ourselves. Like you said, the third-parties should opt Grid in.

Like you said, the third-parties should opt Grid in.

Yes. Rather than Grid opting itself in by returning true when asked about a third-party it doesn’t know.

But I think we’re just talking past each other. Given a question that doesn’t have a clear right or wrong answer, you guys fell one way and I would have fallen the other. I’ll mark one of your comments as a solution.

Thanks for the discussion!

Ok sorry Bryan. Yeah the way we’ve fallen is the way it is right now. But we do think there are better ways to solve this problem of reusing fieldtypes, so it is on our radar for improvement.

You’re welcome, and we’ll get to your other questions soon.