Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.API documentation referring to non-existent function
The function taxonomy_term_view says it returns:
A $page element suitable for use by drupal_page_render()
which is a non-existent function.
Documentation patch to follow shortly
It's an easy documentation patch that I'll do. Although it's probably considered a novice task, I've never submitted to Drupal core and have a bit of time to do this now.
Remaining tasks
supply the patch mentioned abovesupply the backport patch for D7, where that pesky function is referred to intaxonomy_term_show. D6 looks ok - as render in all its glory did not yet exist.
User interface changes
None.
API changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | documentation-taxo_non-existent_function-2183461.patch | 642 bytes | siliconmeadow |
Comments
Comment #1
siliconmeadow CreditAttribution: siliconmeadow commentedAdded patch.
Comment #2
siliconmeadow CreditAttribution: siliconmeadow commentedComment #3
jhodgdonDoh! Good catch. I don't see any other mentions of drupal_page_render() in core in 8.
I'll get this in; likely the same patch can be used for 7.x.
Comment #4
siliconmeadow CreditAttribution: siliconmeadow commentedHere is the D7 version. I grepped for the string 'drupal_page_render', and this patch should remove the final vestige of that pesky function. Good riddance, I say!
Comment #5
jhodgdonPlease read
https://drupal.org/node/1319154#multiple-versions
and please do not change the version/status of an issue until the current versions has been resolved. Thanks!
Comment #6
siliconmeadow CreditAttribution: siliconmeadow commentedOk then. Should I do a separate issue for the D7 backport? I'm all for following the proper protocol, but we sure do have a LOT of protocols! I just want to change the reference from drupal_page_render to drupal_render in d8 and d7. And it's not even in the executable code. The removal of five characters. And I've spent at least two hours exploring all the documentation about how to submit a patch to core and then actually entering all this data, sweating over every character I type into this issue and the comments I make, and I'm still not doing the right thing!
Comment #7
siliconmeadow CreditAttribution: siliconmeadow commentedI'm sorry I've never seen the 'novice' section of the contributor's guide until now. Nearly eight years of loyalty to this project and I'm still having to apologise for helping in all the wrong ways.
Comment #8
jhodgdonHey, wait! I'm sorry if that came across wrong or un-thankful!
I am very glad that you posted the patch. Next time, please just wait until the 8.x patch is committed before posting the 7.x patch, and then do that on the same issue.
Actually, a lot of the time when we commit 8.x documentation patches, we can even use the same patch file for 7.x and commit it at the same time, saving you the time of even making a separate 7.x patch.
Comment #9
siliconmeadow CreditAttribution: siliconmeadow commented@jhodgdon - I didn't mean to attack you specifically, and I didn't think you came across as un-thankful. You did say thank you and gave me praise for spotting it!
I think the point I'd like to make is a more general one, but maybe it's simply my bad luck. I have been consistently enthusiastic about contributing time and effort to the Drupal project, and have done my best to over the past eight years. But the effort-to-result ratio of particular issue is the norm for my efforts, particularly when attempting to contribute code.
This issues sounds simple: get five useless characters removed from the codebase. Non-executable characters, at that. I've spent well over an hour searching through the documentation so that I could get it right first time, laboured over every word to make sure I didn't screw up the terminology, used sun's most excellent dreditor chrome add-on to provide a template of how to submit an issue and yet I still didn't find the documentation about the procedures and timings of how to do the backport. I did search. Honest.
Five characters.
I suspected that that patch might not be a direct 1-to-1 match for the d7 backport because the function signature where this appears in d7 is
taxonomy_term_show, whereas in d8 it'staxonomy_term_view. My suspicions could be completely unfounded.Thank you for bearing with me and for the link to the novice code contribution section of 'Getting involved'. :-)
Comment #10
jhodgdonThere's an "avoid commit conflicts" issue touching taxonomy.module, so I'm going to be extra-careful and wait to commit this until it's taken care of:
#1996238: Replace hook_library_info() by *.libraries.yml file
Comment #11
siliconmeadow CreditAttribution: siliconmeadow commentedI had a look through #1996238: Replace hook_library_info() by *.libraries.yml file and see that the only aspect of the taxonomy.module which is being addressed is the removal of
function taxonomy_library_info(). I did a grep through sun's latest patch (which passes and still appears to be the only bit of taxonomy.module it touches.It's not that I'm in a huge hurry - I just thought I'd explore what was the blocker. :-)
Comment #12
jhodgdonRight. I'm just being extra-careful. People get ansy about these "avoid commit conflicts" issues, and sometimes any change to the same file (even in a completely different area of the file) causes problems for people who are working on the same file, as they have to merge changes into a sandbox workplace, etc.
Anyway, that issue is at RTBC so it shouldn't be too long to wait.
Comment #13
alexpottHiding the d7 patch as it is not relevant at the moment. It can be unhidden once this has been committed.
Comment #14
jhodgdonThanks! Committed the above patches to 8.x and 7.x respectively (got permission from the author of the other issue's patch).
Comment #15
siliconmeadow CreditAttribution: siliconmeadow commented@jhodgdon: How does one go about removing the comment I made here:
https://api.drupal.org/api/drupal/modules%21taxonomy%21taxonomy.module/f...
which caused me to start this issue in the first place?
Comment #16
jhodgdonNormally, what you would need to do is to file an issue in the "Drupal.org Webmasters" project and request that they remove the comment.
However, in this case I have permission and have removed your comment for you, which seemed more expedient.
Thanks again for following through to make an issue and a patch, so that everyone can enjoy the correct documentation!