Use Fields to store text variables, especially those that require text format support

Thanks for the comments. Here are some responses:

1. Agreed that it makes more sense for each variable to be a bundle. I'm guessing it's not even that hard to convert the patch to do this now, regardless of whether #368082: Non-numeric object ids and revision ids gets in. Because we already has to store an array of the variable names, so storing an integer with those too shouldn't really be any harder.

2. Regarding check_markup() vs field_attach_view(), my general goal here was to use as much of the Field API as possible, since that makes things consistent. For example, field_attach_view() calls a hook which lets other modules modify the field after it's rendered... do we want to prevent them from doing that here?

3. It might indeed make sense to expand this to all text fields, not just format-enabled ones. The only complication I can think of there is what to do about system_settings_form(). For now, I have it pretty simple -- module developers who use system_settings_form() don't get a choice about how their data is stored. (Text-format enabled data gets stored and accessed using the Field API, and everything else is done with the variable_get/set API.) If we expanded this to include everything, it seems like we might have to/want to give them more of a choice?

4. Also agreed that allowing this for non-text variables would be good too, but yes, let's save that for a followup patch :)

5. Thanks for the pointer to #365934: Handle big texts / module text files / readable and localizable / get rid of _user_get_text() -- good to know about that. I think there's a tiny bit of overlap, but mostly it seems very complementary -- since that focuses on how the default values of variables are stored, whereas this focuses on how the user-entered values are stored. I'll add a comment to the other issue, though.

6. Agreed this doesn't really belong as a Field API issue, but I don't know where else it belongs either ("base system" ... "other"? ... ugh). My main goal in filing it under the field system was to get some of the "Fields people" to look at it, which I seem to have accomplished :)

Also, Gabor pointed out that the site mission statement might not really be a good candidate to convert to this system, since if we convert it to anything we could convert it to a block instead, and that way you get the layout/visibility features along with the text format.

However, I just did it as an example, so no worries for now :) There should definitely be plenty of other text variables throughout core and contrib that could benefit from this.

Adding tag.

I'm thinking of postponing work on this for at least a little while (ha, as if it hasn't already been postponed for the last few weeks!!) to see what happens with #414424: Introduce Form API #type 'text_format'. A lot of the ugly hacks that this patch requires for system_settings_form() would no longer be necessary if that goes in.

Regarding @yched's concern with settings.php overrides, I'm not sure if it's that big of a deal, since this will usually be used for long strings of text that people are probably not going to want to override in settings.php too often anyway? However, if it is a concern, I think it's probably easy to deal with, as long as we enforce the restriction that both types of "variables" live in the same namespace. Then, I think functions like drupal_get_text() could just call variable_get() at the beginning, and if they find anything there, return that? I think that would do it.

What I'm more worried about in general with this patch is the case of upgrades from Drupal 6. Some of these variables were previously using things like filter_xss() or filter_xss_admin() to output their text. If we're converting them over to use text formats, what do we do about that? Do we have to add a new text format to Drupal during the upgrade, that gives the same output as filter_xss_admin()? Not sure if there's a simpler way to handle this...

Yeah, back while I was working on this, right at that same time people were already starting to convert a lot of those one-off variables (mission statement and the like) to other things, like blocks, and more of that will be possible as time goes on.

I still think this would be useful, though. There are a lot of places - especially in contrib - that have e.g. a single admin screen with a one-off textarea that might make sense to have text format support.

This patch stalled for D7 because it really needed the #type 'text_format' stuff in order to reasonably proceed, and that didn't happen until too late in the cycle. I'm definitely interested in trying again for D8, though. There's a fair amount of work left to do, but I think it could still be very interesting.