Render API: Differentiate internal from user-settable renderable array attributes

This gets a HUGE +1 from me. Nothing is lost, as all the properties in question are still accessible if someone ever really needs to hack them. Setting apart the internal 'flags' and so on that the API uses helps keep as much brain space as possible clear for the important things.

nice patch ... i tested and nothing broke. i rendered and submitted a whole bunch of forms.

Very nicely done. BTW. I learned my lesson and the menu patch uses _mid, _pid and such in the building process.

Just bumping this - I think this is a great idea, and much more consistent with our _internal naming system for functions.
I'll reroll if there is interest :)

This indeed breaks the API, and while we can fix all instances in core, some early contrib modules would get broken.
I'd make this move early in D7.

This doesn't break the API, as all the properties being changed are in fact internal and should not have been used by developers in the first place. Again, though, it's bee months and the patch is out of date. something to kick around for D7.

This doesn't break the API

should not have been used by developers in the first place

Okay, for 99% of modules you are right.Still there are some use cases, where for example #processed or #spawned are needed on the outside. If developers used those properties, their modules will get broken.

So if this is not considered an API break, it's absolutely okay for me. I just didn't expect this to be commitable anymore, but am otherwise a strong supporter of "The drop is always moving"!

Bumping back to D6 for now - let others decide.

There is absolutely no way this will get into Drupal 6, even though it is not an API change (really!) ;)

I agree -- apologies if my post confused matters. I agree wholeheartedly that it shouldn't go in for D6.

Bump. (And +1).

I hope it's not too late to add this to D8

FWIW - I disagree that #sorted is "internal". I've used it a few times in the past and the docs say this:

The child elements of this element are sorted by weight using uasort() in \Drupal\Core\Render\Element::children(). Since this is expensive, when passing already sorted elements to drupal_render(), for example from a database query, set $elements['#sorted'] = TRUE to avoid sorting them a second time.

I haven't done much research to see what this would change, if anything, but the scope of this issue should be the Render API in general and not just the FAPI. It would just add to the confusion if some renderable arrays had "internal properties" and others did not. I presume we'd include:

drupal_render():

#_defaults_loaded
#_printed

_theme():

#_directory

Somewhat related issue #2024743: Document "reserved variables" for renderables to avoid conflicts with drupal_render(), the FAPI, and _theme().

Patch needs a reroll:

tdm:d8 thedavidmeister$ git apply 111079-13.patch 
error: patch failed: core/includes/common.inc:3741
error: core/includes/common.inc: patch does not apply
error: patch failed: core/includes/form.inc:2931
error: core/includes/form.inc: patch does not apply
error: patch failed: core/includes/menu.inc:1154
error: core/includes/menu.inc: patch does not apply
error: patch failed: core/lib/Drupal/Core/Entity/EntityViewBuilder.php:230
error: core/lib/Drupal/Core/Entity/EntityViewBuilder.php: patch does not apply
error: patch failed: core/lib/Drupal/Core/Form/FormBuilder.php:326
error: core/lib/Drupal/Core/Form/FormBuilder.php: patch does not apply
error: core/modules/aggregator/lib/Drupal/aggregator/Controller/AggregatorController.php: No such file or directory
error: core/modules/field/lib/Drupal/field/Plugin/views/field/Field.php: No such file or directory
error: core/modules/system/lib/Drupal/system/Controller/FormAjaxController.php: No such file or directory
error: core/modules/system/lib/Drupal/system/Tests/Common/RenderTest.php: No such file or directory
error: patch failed: core/modules/system/system.admin.inc:139
error: core/modules/system/system.admin.inc: patch does not apply
error: patch failed: core/modules/tracker/tracker.pages.inc:154
error: core/modules/tracker/tracker.pages.inc: patch does not apply
error: patch failed: core/tests/Drupal/Tests/Core/Form/FormBuilderTest.php:427
error: core/tests/Drupal/Tests/Core/Form/FormBuilderTest.php: patch does not apply

I'm going to reroll patch from #13.

I'm Matt, a new contributor in the Sprint at Austin DrupalCon. I've attached the reroll from #13. Fingers crossed.

Removing changes to default.settings.php that likely caused the failures.

Switching to needs review.

Adding in some new (or moved) uses of #sorted that I found.

Found a few more usages. One last try.

I still really don't think #sorted is "internal". If #sorted is internal we should consider making #weight internal too as they both address similar use cases (from the perspective of the "external" developer).

I could go either way with it, but I'm not really in the position to make the determination. If someone can give a definitive answer I'll fix the patch.

OK sure. Well, for the next person who comes along, the summary of my take on #sorted is:

- The documentation for drupal_render() directly mentions using it for a common use-case (rendering anything pre-sorted by a db query)
- #sorted provides a clear and practical alternative for #weight, which is an attribute I don't think anyone would argue is "internal"
- Setting #sorted before calling drupal_render() improves site performance, and so should be encouraged
- I have personally used it multiple times, and advised other people to use it (especially when altering existing data structures), so there are definitely use-cases "in the wild"

The attributes we mark as "internal" with a _ will likely be considered "discouraged" or "scary" by developers who might be considering using them and will inevitably be treating them with a degree of suspicion (well *I* don't know what this attribute does or why it's marked internal, better leave it to The Core Guys and figure out some other way to fix my problem). #sorted is not scary or discouraged at all, in fact it's very easy to understand/use and definitely encouraged!

#sorted and #weight is not internal.

Removed any changes to #sorted.