Fixed
Project:
Drupal core
Version:
11.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 May 2014 at 03:41 UTC
Updated:
7 May 2026 at 17:56 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
marcingy commentedMoves show() and hide() into a more sensible place. This will have a follow up to remove the actual functions themselves.
Comment #3
marcingy commentedComment #4
slashrsm commentedLooks good to me.
Comment #5
webchickThis is fairly pedantic, but in most cases OO functions are "Capitalized::thing()" (only exceptions being internal objects like self:: or parent::) so it's weird in this instance to see "element" vs. "Element." Could we get a quick re-roll to fix that?
Comment #6
marcingy commentedChanging case!
Comment #7
slashrsm commentedComment #8
alexpottWe need an issue summary to explain at least why we are doing this.
Comment #10
xjmReroll for #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4. However, we still need that issue summary update.
Comment #11
mile23Is this still a thing?
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... Element still doesn't have a
show()orhide(), but it was a year ago.Comment #12
mile23Needs a reroll.
Comment #13
nitesh sethia commentedComment #14
nitesh sethia commentedRerolled the patch successfully as per the latest release.
Comment #16
Arnion commentedRecover method isEmpty i Drupal\Core\Render\Element.
Corrected reference to Drupal\views\Plugin\views\row\RssPluginBase.
Comment #17
Arnion commentedComment #19
Arnion commentedReplace drupal_render($element, TRUE) by \Drupal::service('renderer')->render($element) in render().
Comment #20
andypostComment #22
Arnion commentedRerolled the patch.
Comment #23
andypostAt this point we probably need to just deprecate this wrappers.
Patch should just replace usage of old functions with new ones and deprecate them
looks unneeded changes
Comment #26
andypostThere's separate issue to manage "position of comment links"
Comment #27
Arnion commentedRemoved the modifications made to /core/modules/comment/src/Plugin/views/row/Rss.php and /core/modules/node/src/Plugin/views/row/Rss.php
Comment #28
marcingy commentedComment #29
andypost"Element" should fully qualified class pass
not sure this change, interface more descriptive
@xjm probably 9.x?
Comment #30
mile23Comment #36
MerryHamster commentedComment #37
MerryHamster commentedElement still doesn't have methods 'show()' and 'hide()'.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...
I tried to make reroll patch for 8.6.x

Comment #38
MerryHamster commentedComment #44
andypostComment #46
andypostNeeds work for 9.3.x and collision with #2794261: Deprecate render() function in common.inc
Comment #47
karishmaamin commentedRe-rolled patch for 9.3.x. Please review
Comment #48
karishmaamin commentedComment #49
longwaveThe deprecation message needs updating to mention 9.3.x as the deprecation version and to match our standards, see https://www.drupal.org/pift-ci-job/2159191 for the codesniffer output.
Comment #51
nnevillComment #52
nnevillComment #53
andypostthis changes are unrelated to deprecation
it should point to 9.4.0
needs deprecation test and new issue to remove deprecated functions like #3260778: Remove deprecated code from bootstrap.inc
Comment #54
nnevillPoints 1,2,3 from previous comment have been fixed.
Thanks for such a quick review!
Comment #55
andypostThank you! looks mostly ready
Deprecation messages should include link to https://www.drupal.org/node/3261271
So when it will be found in logs users can navigate to the link
Comment #56
andypostDetails could be found at https://www.drupal.org/about/core/policies/core-change-policies/drupal-d...
Comment #57
andypostComment #58
nnevillDone. Hope this will be the last iteration :)
Comment #59
andypostYay! looks ready for commiters' eyes
Comment #60
volegerBump, 3 weeks - no response. Patch still applying over 9.4.x branch.
Comment #62
volegerComment #63
volegerWrong status
Comment #64
lauriiiThe change record is empty, so is the issue summary.. Would be great if someone could update those with necessary information.
Comment #65
volegerUpdated Functions hide() and show() are deprecated.
Comment #68
nod_Patch or MR doesn't apply anymore
The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.
D10 version needed
At this time we would need a D10.1.x patch or MR for this issue.
Also the issue summary could still use some text, at least a few sentences.
Comment #69
bhanu951 commentedComment #71
bhanu951 commentedComment #72
spokjeRandom test failure, ordered retest.
Also updated CR to 10.1.x/10.1.0.
Comment #73
spokjeUpdated IS.
Comment #74
andypostTest should make sure that functions returns same result
Comment #75
spokjeThanks @andypost, tests changed.
Comment #76
andypostThank you!
Comment #77
alexpottAdded some comments on the MR. Also if we are changing the documentation to show and hide - then we need to re-flow it to 80 chars. There are some short lines now.
Comment #78
bhanu951 commentedAddressed review comments by @alexpott
Comment #79
spokjeOne PHPCS error
Comment #80
bhanu951 commentedFixed PHPCS error.
Comment #81
andypostThank you! looks ready again
Comment #82
xjmI left some comments are the MR that shoukd help move forward.
Comment #83
xjmI added several suggestions on the MR to improve the new APIs, the deprecations, and the documentation.
If you're unable to accept suggestions in the UI even with push access, respond to the thread with 👍 and I or the original PR author can accept the suggestions on your behalf.
Thanks everyone!
Comment #84
bhanu951 commented@xjm
Thanks for the review and suggestions.
I have applied the suggests. Ready for review again.
Comment #85
volegerAdded few suggestions
Comment #86
bhanu951 commented@voleger Thanks. Committed them.
Comment #87
xjmMerged HEAD so that retesting will work.
Comment #88
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #89
volegerRerolled against 10.1.x branch. Addressed last review comment.
Comment #90
rinku jacob 13 commentedHi @volger, Reviewed your patch on drupal version -10.1.x.It was successfully applied and after the patch both methods moved to class \Drupal\Core\Render\Element. Adding Screenshots for the reference . Need RTBC +1
Comment #91
smustgrave commentedReviewing MR 3011
Deprecation tests are there
Change record makes sense and offers the alternative to use.
The 1 open thread has been resolved by renaming to ProceduralApiDeprecationTest
Think this is good to go.
Comment #92
catchCouple of minor comments on the MR.
Comment #93
andypostFixed both nits
Comment #94
smustgrave commentedSeems comments in the MR have addressed so moving to RTBC.
Comment #95
longwaveI am wondering now if we should just deprecate these with no replacement. These were first introduced in #455844: Allow more granular theming of drupal_render'ed elements to simplify life for PHPTemplate themers so they could exclude parts of render arrays directly from a template.
Now we are using Twig, I am not sure we need these at all? We have the
without()filter in Twig to serve this purpose already.template_preprocess_file_widget_multiple()could be refactored so it doesn't use them. I can't find any uses in contrib either - http://grep.xnddx.ru/search?text=hide%28&filename= only finds false positives in JavaScript files.Comment #97
vladimirausGood point by @longwave.
Should we keep methods for backwards compatibility even if not in use?
Comment #98
andypostPushed commit which inlining usage without replacement, moved documentation to
\Drupal\Core\Render\RendererInterface::render()as it still explains how elements and children are traversed using#printedsemaphore.CR needs update and +1 to deprecate without replacement
Comment #99
andypostTo prevent collisions with @VladimirAus here's a patch I suppose, maybe it needs better wording instead of
#printed=TRUEin deprecation messageComment #100
longwaveTagging for FEFM review.
Comment #101
longwaveComment #102
andypostUpdated IS and CR
Comment #103
andypostRe-roll after #2602326: Unused local variable $key (at line 49) in file.field.inc
Comment #105
andypostunrelated failures in head
Comment #106
daffie commentedAll code changes look good to me.
Deprecation message testing has been added.
For me it is RTBC.
Comment #108
andypostknown failure
Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTestComment #109
longwaveLooks good, just some nits on the comments and deprecation:
"Drupal\core\lib" is incorrect, and not even sure we need this comment, given we are removing it anyway and there is a change record. This needs changing in two places.
"Set the #printed element property to TRUE instead." reads better to me. This needs changing in all places that refer to the deprecation.
Let's use real code: $element['#printed'] = TRUE
Comment #110
andypostFixed, I find the comment useless as well, also there's a fixed
@seelinks to render method docsComment #111
smustgrave commentedSeems to have build failures.
But checked interdiff and points #109 appear to be addressed.
Comment #112
andypostIt was caused by reverted #3268809: Fix class comment doc blocks in tests for 'Drupal.Commenting.DocComment.ShortSingleLine'
Requeued
Comment #113
bnjmnmDeprecating these seems worthwhile. I'd like to see a little bit of additional docs just to make it easier to grok if someone is dealing with code that now uses #printed instead of hide() / show(), which may not be the most consequential thing but a relatively simple change.
core/lib/Drupal/Core/Render/Element/RenderElement.phpto clarify that it can be set to TRUE to prevent rendering as well, similar to what was added inRendererInterfaceSince changing #printed is a little less self-explanatory than a hide() method, could this comment be expanded slightly to describe how the rendering is being delayed?
Comment #114
alexpottFWIW these methods are used by contrib and probably custom - see
http://grep.xnddx.ru/search?text=+hide%28&filename=.php
http://grep.xnddx.ru/search?text=+hide%28&filename=.module
http://grep.xnddx.ru/search?text=+show%28&filename=.module
There's loads and in popular modules. Are we really sure about this?
Comment #115
smustgrave commentedLooking at that list saml and editorally would be disruptive.
Comment #116
alexpottThis issue summary claims that there are no contrib usages - this in correct as per #114 - I'm not really sure how to update it.
Comment #117
longwaveApologies for the mistake in #95, I should have filtered by extension. I went through the lists in #114 and while there are a handful of genuine uses, some are form elements that should probably be hidden by setting #access instead, and others are false positives:
#accessinstead#accessas this is hiding a form element#access#access#access#access#access#access#accessAs it looks like the many of the cases in contrib are actually using this to hide form elements, while this works, it's not really how it was intended to be done as far as I am aware - form elements should set
#accessto FALSE instead. If this is correct, to me this is a good reason to deprecate this and point users in the correct direction.I think the options are:
#accessand render elements should use#printedhide()andshow()to static methods on ElementComment #118
andypostI think it just needs better documentation for
#printedas #113 said and deprecationGreat points about mixing it with
#accessbut usage in contrib tells that no reason to keep it as public APIComment #123
volegerRerolled
Comment #124
vladimirausThank you. Applied and tested.
Comment #125
nod_For contrib impact, list of contrib using the methods, interestingly enough, nobody uses "show", only "hide".
Comment #128
longwaveHappy 12th birthday to this issue, time to finally get this committed. As usual with long issues credit is tricky, apologies if I missed anyone.
Committed and pushed afe536a7949 to main and 72ab77833c5 to 11.x. Thanks!
Also published the change record.