-
Notifications
You must be signed in to change notification settings - Fork 79
DocBlocks for filters inside a conditional expression are not imported #185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
PHPParser loops over the body of a conditional statement (the part between the curly brackets), before looping over each node in the expression. Because we were only saving the last docblock that wasn't associated with a documentable element, if there was also a documented filter within the condition body, the docblock for that filter would be picked up, and the docblock for the first filter in the condition expression would be discarded. So by the time we got to the node for the filter in the condition expression, there was no docblock saved to associate with it. This is now fixed by keeping a stack of stray docblocks for non-documentable elements, so that instead of the docblock for the first filter being discarded it is just pushed down the stack. The docblock for the second filter within the condition block will be pushed on top of it, and then popped off once it has been used. So when we come around to actually looping over the node for the filter in the conditional expression, its docblock will be at the tip of the stack once again, and can be associated with the filter as expected. See WordPress#185
Discovered while working on WordPress#185.
I've created in #186, which addresses the first example (2 documented filters, first doc not picked up). The second example (first filter documented, second not, but docs imported for second one) is really more difficult to handle, and I'm not sure that it is worth the work. If it is really needed, I suppose that there may be some way to do it, but it is not straightforward, as far as I can see. I know that this may seem odd, but it works this way because the second filter is actually parsed first, then the first one. |
I've tested your patch on the wp-includes folder to see if there would be any differences between the current way docblocks are imported and with the patch. The only differences found are for the filters The filter As all hooks should be documented this shouldn't be a problem. I've already created a ticket for this filter https://core.trac.wordpress.org/attachment/ticket/39130/39130.12.patch |
I've now tested your patch on trunk and it correctly adds the DocBlocks for these hooks:
These undocumented hooks get a wrong DocBlock assigned:
All other DocBlocks for hooks (and functions, classes, methods) get imported the same as without the patch. The issue with the undocumented hooks should be fixed by adding the 6 missing DocBlocks to the hooks in WP itself. |
DocBlocks for In this example DocBlock 2 will never be imported for filter /**
* DocBlock 1
*/
function test_docblocks() {
if ( 1 == 1 ) {
/**
* DocBlock 2
*/
} elseif ( apply_filters( 'in_conditional_expression', true ) ) {
}
} |
DocBlocks outside a conditional are not imported if there are other filters (with DocBlocks) within the conditional.
Example 1
In this example DocBlock 2 is not imported for the filter
in_conditional_expression
Example 2
In this example the (wrong) DocBlock 2 is imported for the filter 'in_conditional`.
The wp_save_post_revision_check_for_changes filter doesn't get its DocBlock imported because of this bug.
See this filter in trac
The text was updated successfully, but these errors were encountered: