[wp-trac] [WordPress Trac] #55917: Fatal error in WP6.0 when calling get_current_screen on the pre_get_posts action

[WordPress Trac]

#55917: Fatal error in WP6.0 when calling get_current_screen on the pre_get_posts
action
-------------------------------------+-----------------------------
 Reporter:  lumpysimon               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Query                    |     Version:  6.0
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+-----------------------------

Comment (by antonvlasenko):

 TLDR: I've spent some time investigating, and I don't see any issues with
 the current implementation of the Fonts API.

 A more detailed explanation:

 The [https://core.trac.wordpress.org/attachment/ticket/55917/55917.2.diff
 patch] proposed by @SergeyBiryukov  resolves the "issue" in one place, but
 since then, another section of the code has emerged that creates a similar
 issue: https://github.com/WordPress/gutenberg/pull/42454/files#diff-
 28f36bb64fbbc8ce728db401b1e4cf30c9f44db7f5dcce1b7b0cc9ce60b1a209R191.
 That PR introduces a new function called
 `build_template_part_block_instance_variations()`, which also causes a
 fatal error when using the code snippet above.

 For reference, here are the call stacks for both fatal errors (i.e., the
 "old" and the "new" one):
 [[Image(https://cldup.com/ff0pdZwTeL.png)]]
 [[Image(https://cldup.com/fLOtvYIUaL.png)]]

 It can be observed that in both cases, the fatal error occurs when the
 `WP_Query::get_posts()` method is called and the `pre_get_posts` action is
 fired within that method.

 It is logical to assume that the `get_current_screen()` function may be
 undefined when the `pre_get_posts` action is fired,
 [https://developer.wordpress.org/reference/hooks/pre_get_posts/#a-warning-
 about-conditional-functions based on the description of the
 `pre_get_posts` filter]: the action fires after the query variable object
 is created but before the actual query is run.

 From my perspective, `pre_get_posts` is 100% backend logic unrelated to
 the frontend.
 During the Core initialization, the list of posts may be needed long
 before the current page and corresponding "screen" are known.

 The fact that the code provided in the example above worked in earlier
 WordPress versions is more of a coincidence than a rule.
 I see two ways to solve this issue:
 1. Do not rely on `get_current_screen()` being defined and use some low-
 level PHP function to determine the current page.
 2. Use another action to sort posts, which is guaranteed to be fired after
 the `get_current_screen()` function is defined.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55917#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform