Problem/Motivation
Theme development for Drupal is too complicated, with too many layers. This is part of the movement to clean up rendering of content in Drupal.
The process layer was only created because we needed a place to flatten complicated data structures such as objects or arrays into strings. In practice, render arrays themselves allow for late rendering via theme function or template file (and can be manipulated in other preprocess functions), and objects can implement __toString methods for printing. There is no longer a need for this whole extra layer of processing before rendering.
Proposed resolution
Removal of the entire process layer.
Remaining tasks
None!
Completed
#2004286: Defer calls to drupal_get_* functions until printed inside a template by adding a RenderWrapper class
#1843728: Remove template_process_field()
#1941286: Remove the process layer (rdf module)
#1939066: Convert theme_breadcrumb() to Twig
#2003814: Remove Bartik process layer functions, refactor color module alterations
#1843768: Remove template_process_overlay()
#1843788: Remove template_process_username()
#1811828: Use #attached to find the css/js of a view
#1843712: Remove template_process_book_export_html()
#1843678: Move building of messages render array from template_process_page() to template_preprocess_page()
#1843668: Move building of breadcrumb render array from template_process_page() to template_preprocess_page()
#1589968: Move Title from process to preprocess, remove template_process_page()
User interface changes
None
API changes
Removal of the following functions:
- hook_process
- hook_process_HOOK
Comment | File | Size | Author |
---|---|---|---|
#37 | drupal-meta-remove-the-process-1843650-37.patch | 29 KB | markhalliwell |
#37 | interdiff.txt | 8.65 KB | markhalliwell |
#34 | drupal-meta-remove-the-process-1843650-34.patch | 25.64 KB | markhalliwell |
#34 | interdiff.txt | 1.72 KB | markhalliwell |
#29 | drupal-meta-remove-the-process-1843650-29.patch | 25.93 KB | markhalliwell |
Comments
Comment #0.0
jenlamptonadd issue
Comment #0.1
jenlamptonblockers
Comment #0.2
jenlamptonadded process_html
Comment #0.3
jenlamptonissues
Comment #0.4
jenlamptonbook
Comment #0.5
jenlamptonfield
Comment #0.6
jenlamptonoverlay module
Comment #0.7
jenlamptonuser module
Comment #0.8
jenlamptonviews
Comment #0.9
jenlamptonRDF
Comment #0.10
jenlamptoncolor
Comment #0.11
star-szrdrupal -> Drupal
Comment #0.12
c4rl CreditAttribution: c4rl commentedUpdated issue summary.
Comment #0.13
ltrainprocess_entity did not need to be on this list - it has nothing to do with rendering
Comment #0.14
ltrainAdded an issue for removing process functions from Bartik
Comment #1
dasjowe have had some discussions with sdboyer, because getting rid of process is kind of tricky in combination with drupal_add_*
joelpittet therefore came up with a proposal: #2004286: Defer calls to drupal_get_* functions until printed inside a template by adding a RenderWrapper class
sam basically would prefer using controllers instead of the logic that happens within pre/process_page and the maintenance version of it.
see this (outdated) gist: https://gist.github.com/c4rl/4780229
and #1843710: Remove template_process_maintenance_page()
Comment #1.0
dasjoadd another blocker for the drupal_add_css and drupal_add_js late rendering.
Comment #1.1
jenlamptonremove remove rdf
Comment #1.2
jenlamptonblocker
Comment #1.3
jenlamptonremove blocker
Comment #1.4
jenlamptonremove breadcrumbs
Comment #1.5
jenlamptonadd back breadcrumbs issue
Comment #1.6
jenlamptonother issue
Comment #1.7
jenlamptonreorder
Comment #1.8
jenlamptonmore separation
Comment #1.9
jenlamptondupe
Comment #1.10
jenlamptonremove
Comment #1.11
jenlamptonupdate
Comment #1.12
jenlamptonalso
Comment #2
jenlamptonOkay, this patch is mostly docs updates, but there are some code changes in here as well that will KILL PROCESS. I'm sure it will need a reroll once our blockers are out of the way to pass tests, but I got excited and had to start on this :)
Comment #4
joelpittet#2: core-remove_process_phase-1843650-2.patch queued for re-testing.
Comment #5.0
(not verified) CreditAttribution: commentedrearrange
Comment #6
scor CreditAttribution: scor commentedsystem/theme.api.php will also need to be updated to REMOVE any kind of documentation about hook_process().
Comment #6.0
scor CreditAttribution: scor commentedrearrange
Comment #6.1
jenlampton.
Comment #6.2
star-szrRefresh
Comment #6.3
star-szrReorganize
Comment #6.4
star-szrColour change
Comment #6.5
jenlamptonturn green!
Comment #7
jenlamptonAlso removed all the process hooks from theme.api.php :)
Comment #8.0
(not verified) CreditAttribution: commentedUpdate problem/motivation section - we didn't end up converting render arrays to objects but render arrays themselves work well for our aims.
Comment #9
catchWhile this is in progress, could we get a quick patch to mark process as deprecated in the API documentation?
Comment #10
star-szrSomething like this?
(If anyone prefers I can move this patch to a new issue.)
Comment #11
catchLooks right to me. I'm OK with commit ->active but if someone strongly wants a new issue that's fine too.
Comment #12
jenlamptoncommit ->active sounds good to me :)
Comment #12.0
jenlamptonup
Comment #13
YesCT CreditAttribution: YesCT commentedThis issue was RTBC and passing tests on July 1, the beginning of API freeze.
Comment #14
catchCommitted/pushed to 8.x, thanks!
Could do with a change notice to point out these have been marked deprecated, which can be updated when it's removed.
Comment #15
Wim LeersThis is not really a meta issue anymore, and now needs a change notice.
Comment #16
catchComment #17
star-szrChange notice draft:
The template process layer is deprecated and will be removed
The template process layer and process functions (e.g. template_process_HOOK(), MODULE_process_HOOK(), THEME_process_HOOK()) have been deprecated and will be removed in Drupal 8.
In the Drupal 7 theme system, process functions were used to flatten variables into strings for printing (see template_process() from Drupal 7 for an example). With the shift towards using (more) render arrays and renderable objects (objects with __toString() methods), in Drupal 8 we can remove this additional layer of processing and complexity from the theme system in favour of "lazy rendering" as late as possible and only when necessary.
Render arrays and renderable objects can be manipulated throughout the preprocess phase without needing to worry about the variable already being turned into markup or a flattened string. The render array or renderable object can then be printed in a template file without first flattening it into a string. With the Twig template engine (the default template engine in Drupal 8), you simply print the variable in your template and the Twig engine determines whether it is a render array, renderable object, string etc. and renders it appropriately.
The following example prints an Attribute object with a __toString() method in a Twig template:
Impacts:
Comment #18
star-szrAny feedback on the above before I post?
Comment #19
star-szr…
Comment #20
joelpittetIt makes me almost as happy as if we had renderable objects:)
Comment #21
star-szrPosted change notice:
https://drupal.org/node/2038981
Going back to active + major + meta issue for now.
Comment #22
joelpittetSorry for the cross post
Comment #22.0
joelpittetapi changes
Comment #23
jenlamptonremoval :)
Comment #25
markhalliwellRerolled. Also did a S&R for
template_process
and removed/changed additional documentation. This patch will probably fail until #1589968: Move Title from process to preprocess, remove template_process_page() is committed. Then we can retest/reroll if needed.Comment #27
markhalliwell#25: drupal-meta-remove-the-process-1843650-25.patch queued for re-testing.
Comment #29
markhalliwellReroll
Comment #29.0
markhalliwellupdate
Comment #30
Fabianx CreditAttribution: Fabianx commentedOnce testbot comes back green, lets get this in!
This is according to my understanding:
RTBC
Comment #32
markhalliwellWeird... only 1 error?? Tested this failing test locally and it passed with patch... sigh testbot fail, retest!
#29: drupal-meta-remove-the-process-1843650-29.patch queued for re-testing.
Comment #33
star-szrOne question and one nitpicky bit :)
Can (some of?) these parts be simplified by not treating the process phases as an array when we don't need to?
Let's not add these back, see #2013094: [policy adopted, patch needed] Stop saying '@see template_preprocess()' in every twig file.
Comment #34
markhalliwellRe #1: I would rather just remove just the implementations here so we can quickly, loudly and completely remove the process layer from core. This will all, more than likely, get refactored anyway with #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK().
Re #2: I was not aware of that issue, took them out.
Comment #35
steveoliver CreditAttribution: steveoliver commentedMark, I think we should go with Cottser's suggestion to stop treating the one phase here as an array.
Comment #36
markhalliwellI'd rather leave that logic in place here and just remove the process phase. The
$phases
array will still be utilized by #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK().Comment #37
markhalliwellOk, I went ahead and refactored it to not use arrays. Turns out with the proof-of-concept patch in #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK(), it's not going to be needed after all.
Comment #38
jenlamptonJust gave it another quick test and (now that it's green) setting it back to RTBC. Good work team!
Comment #39
Fabianx CreditAttribution: Fabianx commented+1 for RTBC
Comment #40
star-szrGave this another review, I agree it looks good. Nicely done @Mark Carver!
Comment #41
catchOK. Committed/pushed to 8.x. Will need a change notice.
Comment #42
star-szrThanks! I just updated the existing change notice:
https://drupal.org/node/2038981
See also #2004286-101: Defer calls to drupal_get_* functions until printed inside a template by adding a RenderWrapper class for the newly proposed RenderWrapper change notice.
Comment #43
jenlampton<3
Comment #44.0
(not verified) CreditAttribution: commentedUpdated issue summary.
Comment #45
sun