WP_Debug_Data::debug_data() is overly complex

[apermo]

The function WP_Debug_Data::debug_data() starts at line 37 and ends at line 1490, this does not yet include the 13 lines of phpDoc above itself, which results in a total of 1466 lines including documentation for a single function.

This breaks with so many programming best practices. And even though I know the rule "Don't refactor, just because you can" I do think, that this one needed refactoring.

The function does generate the complete output at /wp-admin/site-health.php?tab=debug, including all 12(13) accordions.

As of writing this ticket, I have already refactored the function, so I can at this moment already point out some design flaws.

Most noticeable is a hidden bug inside the function at line 1302. For documentation reasons I will create an additional trac ticket for this. But basically in line 1302 the value of $parent_theme_auto_update_string is overwritten by the content of $auto_updates_string, which was likely never found due to two reasons, it barely changed the result and due to the massive complexity of the function, no one ever ran into it by accident.

Also the structure of the whole function is counter intuitive. In some cases the label and structure is created first and a several/hundreds lines later the fields will be populated.

In other cases all is done in a single place.

This makes extending the function within core already quite challenging. From what I've researched, this code grew inside a featured plugin for 2 years before it was copied into WordPress core, without any noticeable refactoring. And after that, the number of lines and it's complexity grew by a few hundred lines.

Another thing, which the current filter does not easily provide. If you want to inject own debug content through the filter 'debug_information' you will either append your debug information to the end, or you are force to manually restructure the array, which could potentially create conflicts if plugin authors do not pay attention here. Having one author doing a poor job here, could potentially mean, that debug informations by others could be removed by the attempt to insert his/her content at a precise place.

I am aware that this would be the plugin authors fault, but by using the filter from the beginning to inject all core debug information, will provide a safe, easy and robust way, for authors to inject their debug information at other places than at the very end.

Due to the massive size of the function, it is absolutely impossible to ever write any reasonable unit test for this.

In my PR I have done the following things:

• Bumped compatibility to 7.2 by adding types where suitable to the file.
• Fixed the mentioned bug
• Refactored code to distinct function, so that nearly all accordions are handled by a single function. Only exception to this rule is active/inactive plugins, since these are heavily tied together.
• using add_filter( 'debug_information', CALLBACK ); to populate the debug information array, which provides a robust way to inject contents at places other than the end.

Refactored WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string

Tested the code multiple times, to ensure that the output is identical to before, as expected only server time did change.

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[apermo]

Separate Ticket for the mentioned bug https://core.trac.wordpress.org/ticket/61649

This PR includes a fix for it.

[SergeyBiryukov]

In 58716:

Site Health: Correctly display auto-update status for parent theme.

Follow-up to [47835], [48731].

Props apermo.
Fixes #61649. See #61648.

This seems like valuable work; thanks @apermo for putting this together.

At the same time, it's definitely challenging to review, probably for the same reason it might have been challenging to refactor: size and scope.

Since I'm not familiar with this subsystem I would be happy if others (who _are_) would be able to examine this and evaluate it.

In the case that nobody is available, I might offer breaking this into multiple smaller changes. The raw size of the diff is one thing, but also the renames all combined make it more difficult to follow changes to the control flow. I wonder if we could address each sub-function one at a time where it's easier to isolate the changes and consider each one on its own. For example, there is a lot of code in there working through imagick limits - it would be nice to be able to focus solely on that change and not have to consider it within the scope of all of the others.

This is more work on you, which I find unfortunate, so please take this only as one voice suggesting a way to get it through faster, if that's your goal. This is often how I like to structure my work.

Thanks @dmsnell for the comment. Do understand you correctly that you suggest to basically have 1 PR per added/refactored function/add_action()?
If so, I can surely break that into single commits per new function.

[dmsnell]

That's right @apermo. One PR for each atomic change, sharing the reference to this ticket, closing this ticket once they are all through.

Also if you take this approach I recommend starting by doing one small change first, getting it through, and only then doing the next one. This is a recommendation to guard your time in case something turns up during that first PR.

@azaozz @SergeyBiryukov I would be interested on your thoughts with this too. I don't want to ask @apermo to do a bunch of work if people are able to confidently review the patch as proposed.

Hm. I thought for sure that I responded to this but maybe my connection was bad and the comment was lost. Yes, @apermo I was thinking that one PR for each incremental atomic piece would be helpful simply because it shrinks the surface-area of the review.

For instance, there is a lot of code dedicated to finding limits of Imagick. That could all be isolated in one change that only addresses the Imagick pieces. You are invited to _cc_ me on any splits or follow-ups to this.

Thanks for this work @apermo! I agree with @dmsnell that addressing this in separate PRs would be ideal. I'd recommend starting with one PR for one piece. We can then review this and ensure the approach is supported and is ready for inclusion in Core. From there, the remaining PRs can be created that follow the same approach.

I noticed that some existing methods had return type declarations added to them. I'd suggest that the scope of this work is limited to splitting WP_Debug_Data::debug_data() up to improve maintainability.

@costdev I sure will, i will break this down into multiple commits so that we can do multiples PRs out of it. I will leave this open until I have the first new PR

I have renamed the original branch.

But this PR can now remain closed.

​https://github.com/apermo/wordpress-develop/tree/refactor-wp-debug-data-old

Changed: Moving $infowp-filesystem? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

To keep the structure intact over all PRs, we will start moving content from the $info array into own function from the bottom up, this way the result will always be identical and combarable.

Summary of the coming steps:

1. wp-filesystem (we are here)
2. wp-constants
3. wp-database
4. wp-server
5. wp-media
6. wp-plugins-active & wp-plugins-inactive
7. wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

I decided to move the add_filter() calls from WP_Debug_Data::debug_data() to a new function WP_Debug_Data::init_filters() which is called on admin_init this way the filters be altered in a non hacky way by plugin authors easily.

Update: I had to move that around a bit, in order to minimize dependencies. To allow plugin authors a convenient way to rearrange debug information, I introduced a new action pre_debug_information that will be fired directly before the filter debug_information, I decided to do this, instead of relying on plugin authors to use the filter to achieve the same, since I understand that it is a kind of hacky approach to use a filter to do an actions job.

In branch ​refactor-wp-debug-data-old is the original PR, with a minor update, to integrate changed approaches and more phpDoc from the new refactoring.

In ​refactor-wp-debug-data/all-parts there is already one commit for each refactored function prepared as stated above.

Thanks @apermo! I think this looks like a good approach for making things more maintainable.

Hopefully @afragen and @clorith have some time to take a look at this and review as Site Health component maintainers.

LGTM 👍

Prepping to merge.

[dmsnell]

In 58830:

WP_Debug_Data: Extract wp-filesystem data into separate method.

This is the first part in a larger modularization of the data in WP_Debug_Data.
Previously this was a single massive method drawing in debug data from various
groups of related data, where the groups were independent from each other.

This patch separates the first of twelve groups, the wp-filesystem info,
into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible
for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7065
Discussed in https://core.trac.wordpress.org/ticket/61648

Props: afragen, apermo, costdev, dmsnell.
See #61648.

Merged in [58830]
​https://github.com/wordpress/wordpress-develop/commit/345699c0711d00dc15a1f3090694c2c8a114a29b

[jorbin]

Post commit housekeeping

Changed: Moving $infowp-constants? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. wp-constants (we are here)
3. wp-database
4. wp-server
5. wp-media
6. wp-plugins-active & wp-plugins-inactive
7. wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[SergeyBiryukov]

Replying to dmsnell:

One PR for each atomic change, sharing the reference to this ticket, closing this ticket once they are all through.

Also if you take this approach I recommend starting by doing one small change first, getting it through, and only then doing the next one. This is a recommendation to guard your time in case something turns up during that first PR.

This does indeed seem like a reasonable approach here, making the changes easier to review. Thanks!

[dmsnell]

In 58855:

WP_Debug_Data: Extract wp-constants data into separate method.

This is the part two in a larger modularization of the data in WP_Debug_Data.
Previously this was a single massive method drawing in debug data from various
groups of related data, where the groups were independent from each other.

This patch separates the second of twelve groups, the wp-constants info,
into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible
for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7106
Discussed in https://core.trac.wordpress.org/ticket/61648

Props: apermo, costdev, dmsnell.
See #61648.

Merged in [58855]
​https://github.com/wordpress/wordpress-develop/commit/8aca1cf6bc78a4e9a32dd47e37e74ea8e24d0a62

https://core.trac.wordpress.org/ticket/61648

Follow up to #7106

[dmsnell]

In 58964:

WP_Debug_Data: Extract wp-database data into separate method.

This is the part three in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the third of twelve groups, the wp-database info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/7143
Discussed in https://core.trac.wordpress.org/ticket/61648

Props dmsnell, kebbet, apermo.
See #61648.

Merged in [58964]
​https://github.com/wordpress/wordpress-develop/commit/68805bfe3d05c0789fbe62f6bdb21230c945d295

Changed: Moving $infowp-server? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. wp-server (we are here)
5. wp-media
6. wp-plugins-active & wp-plugins-inactive
7. wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

Next step: move wp-server debug info to it's own function

https://core.trac.wordpress.org/ticket/61648

Close in favor for ​https://github.com/WordPress/wordpress-develop/pull/7283

During a refactor to modularize the debug data class, it came up that the ordering of the sections inside of the returned debug info is relevant to existing UIs, as they iterate the array, which happens in insertion order.

This patch presets each section at the start to ensure that the ordering remains consistent even as code within the method is rearranged.

See Core-61648.

[dmsnell]

In 58996:

Debug Data: Encode section ordering in debug info.

During a refactor to modularize the debug data class, it came up that the ordering of the sections inside of the returned debug info is relevant to existing UIs, as they iterate the array, which happens in insertion order.

This patch presets each section at the start to ensure that the ordering remains consistent even as code within the method is rearranged. As the mini-project progresses, this assignment will be the final place all the sections are referenced.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/7289
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell, sergeybiryukov.
See #61648.

Merged in [58996]
​https://github.com/wordpress/wordpress-develop/commit/af239aee1bee6686c6eec5ee7b87e65ca9c00898

Changed: Moving $infowp-mu-plugins? to own function

I've started a second parallel PR, a little lower, so that we should not get too many merge conflicts.

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. wp-media
6. wp-plugins-active & wp-plugins-inactive
7. wp-mu-plugins (we are here)
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

@dmsnell since we have our structure now, I've opened a second PR, I've opted to have it a little in the middle, so that we can easily rebase if needed with hopefully little to no merge conflicts.

[dmsnell]

In 59002:

WP_Debug_Data: Extract wp-server data into separate method.

This is the part four in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the fourth of twelve groups, the wp-server info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/7283
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, costdev, dmsnell, kebbet, mukesh27.
See #61648.

Merged in [59002]
​https://github.com/wordpress/wordpress-develop/commit/19fc9c7aadcaf24b51b3479dd62121b74213a7d7

@apermo I've merged trunk into this and hope I did that properly. how does it look? is this ready in your opinion for merging?

@apermo I've merged trunk into this and hope I did that properly. how does it look? is this ready in your opinion for merging?

Looks good to me. @dmsnell

[dmsnell]

In 59011:

WP_Debug_Data: Extract wp-mu-plugins data into separate method.

This is the part five in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the fifth of twelve groups, the wp-mu-plugins info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/7305
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
See #61648.

Merged in [59011]
​https://github.com/wordpress/wordpress-develop/commit/38243be931f7e3829b8cae96cedfb61a0d9c34fe

This is step 5, wp-media.
https://core.trac.wordpress.org/ticket/61648

Changed: Moving $infowp-mu-plugins? to own function

I've started a second parallel PR, a little lower, so that we should not get too many merge conflicts.

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. wp-media (we are here)
6. wp-plugins-active & wp-plugins-inactive
7. ​wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

Changed: Moving $infowp-core? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. ​wp-media
6. wp-plugins-active & wp-plugins-inactive
7. ​wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins
12. wp-paths-sizes
13. wp-core (we are here)

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

@dmsnell Looks good to me.

[dmsnell]

In 59060:

WP_Debug_Data: Extract wp-media data into separate method.

This is the sixth part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the sixth of twelve groups, the wp-media info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7356
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
See #61648.

Merged in [59060]
​https://github.com/wordpress/wordpress-develop/commit/5168e1933af6e2e753b5fce4ed0f6fc29bd4fec1

Changed: Moving $infowp-dropins? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. ​wp-media
6. wp-plugins-active & wp-plugins-inactive
7. ​wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. wp-dropins (we are here)
12. wp-paths-sizes
13. ​wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[dmsnell]

In 59100:

WP_Debug_Data: Extract wp-dropins data into separate method.

This is the seventh part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the seventh of twelve groups, the wp-dropins info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7418
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo.
See #61648.

Merged in [59100]
​https://github.com/wordpress/wordpress-develop/commit/835f864d4ea376eb79844eb6a941250762de3c12

Changed: Moving $infowp-paths-sizes? to own function

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. ​wp-media
6. wp-plugins-active & wp-plugins-inactive
7. ​wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. ​wp-dropins
12. wp-paths-sizes (we are here)
13. ​wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

Trac ticket: https://core.trac.wordpress.org/ticket/61648

[dmsnell]

In 59104:

WP_Debug_Data: Formatting update to code in wp-dropins method.

Resolves an indentation issue introduced while extracting the wp-dropins data into a separate method from the main debug_data() method.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7446
Discussed in https://core.trac.wordpress.org/ticket/61648

Follow-up to [59100].

Props mukesh27.
See #61648.

Merged in [59104]
​https://github.com/wordpress/wordpress-develop/commit/2550224a0c1c186fb0eb0e9fa1dbaced18c3279d

Added get_wp_plugins_raw_data()
Moved wp-plugins-active definition to get_wp_plugins_active() Moved wp-plugins-inactive definition to get_wp_plugins_inactive()

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. ​wp-media
6. wp-plugins-active & wp-plugins-inactive (we are here)
7. ​wp-mu-plugins
8. wp-themes-inactive
9. wp-parent-theme
10. wp-active-theme
11. ​wp-dropins
12. ​wp-paths-sizes
13. ​wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints
• fixed an error with $parent_theme_auto_update_string showing the value from $auto_updates_string (This will be handled only in Step 9)

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[davidbaumwald]

With 6.7 Beta 1 releasing shortly, I'm closing this ticket as Fixed. Any follow-up work can happen in new tickets. If there's additional iteration needed here specifically, this can be reopened as a Task (Blessed) in 6.7.

Fixed visibilty for newly added functions prior 6.7 release.

CC @dmsnell

Namely:

WP_Debug_Data::get_wp_dropins()
WP_Debug_Data::get_wp_server()
WP_Debug_Data::get_wp_media()
WP_Debug_Data::get_wp_mu_plugins()
WP_Debug_Data::get_wp_constants()
WP_Debug_Data::get_wp_database()

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[dmsnell]

I'm re-opening to merge a visibility fix, which slipped past us in review. Some of the new methods are private and some are public, when they all ought to be private for now.

[dmsnell]

In 59164:

WP_Debug_Data: Normalize visibility of new methods.

In ongoing work to modularize the WP_Debug_Data class, several methods were added with public visibility. This patch sets the new methods to private as a measure to ensure optionality as the changes progress, since it's easier to move from private to public than the other way around.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7482
Discussed in https://core.trac.wordpress.org/ticket/61648

Follow-up to [58830], [58855], [58964], [59002], [59011], [59060], [59100].

Props apermo, jonsurrell.
Fixes #61648.

Merged in [59164]
​https://github.com/wordpress/wordpress-develop/commit/7d3c4888d8431ecc2db2c92c76ff8f9539ee6df4

[desrosj]

In 59166:

Coding Standards: Committing changes after composer format.

This commits some minor changes made when running composer format.

Follow up to [58975], [59011], [59115].
See #61103, #62014, #61648.

[dmsnell]

@desrosj should we be making these formatting changes in separate tickets? I've wondered this question, because in order to ensure limited scope, the changes here have been focused on extracting code from the single large debug_data() method into separate task-specific sub-methods.

there are a number of existing patterns in the code that I'm sure people want to change, but I'm worried that making those at the same time, or at least on the same ticket, as moving code from one place to another, will dilute the focus and history of what's happening.

asking just in case the context wasn't clear - this ticket is not about introducing new code or changing coding patterns apart from splitting code off into chunks that can be more safely analyzed, reviewed, and tested in isolation.

@davidbaumwald I'm going to re-open this as a Task (Blessed) for 6.7 and focus on getting the remaining work through before RC1, which I believe should be easy. thankfully, most of the questions arising from the refactor have been addressed, and while some additional ones may show up, I think the remainder of the sub-tasks will go smoothly.

if this is not the right thing to do then I'm happy to change or create a new Ticket, such as Finish the work of #61648 before RC1 or whatever is appropriate.

@apermo I've updated this branch by reverting the past two commits/merges and then merging in trunk. it took a bit of manual work because @aaronjorbin, @peterwilsoncc, and @SergeyBiryukov also made changes to the wp-core code in the meantime, but I think I properly resolved the conflicts and incorporated their changes.

this is now ready for final review, and if you are one of those others, can you double-check that I didn't accidentally undo your changes because I wasn't aware of them?

@apermo I proposed an alternative mechanism for removing sections. please let me know what you think of it. this change is bigger, and as experience tells us, more sensitive to review. but I think ultimately it will be nice to give the new methods the ability to remove their own section, and helps avoid recreating the stack of conditionals for section inclusion or removal. in other words, it encourages keeping the logic for each section local to that section.

[dmsnell]

In 59172:

WP_Debug_Data: Extract wp-plugins data into separate methods.

This is the eighth part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the eighth and ninth of twelve groups, the wp-plugins-active and wp-plugins-inactive info, into separate methods focused on that data.

Unlike the other patches in this series, the plugins data comes from a single source and is separated out into separate debug sections, so the active and inactive methods call a new shared method which provides raw data for both. Optimizations and refactors may occur in follow-up tickets.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7458
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
See #61648.

Merged in [59172]
​https://github.com/wordpress/wordpress-develop/commit/6c1d60453ab0b4d689f94673f8e6b530ff4b7cbc

@dmsnell looking good to me.

Makes sense and is more flexible in the future.

[dmsnell]

In 59174:

WP_Debug_Data: Extract wp-core data into separate methods.

This is the ninth part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the tenth of twelve groups, the wp-core info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7357
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
See #61648.

Merged in [59174]
​https://github.com/wordpress/wordpress-develop/commit/c4752a11cfc53a49b63d4b786bac9fe62eba1604

'wp-active-theme' => self::get_wp_active_theme(),
'wp-parent-theme' => self::get_wp_parent_theme(),
'wp-themes-inactive' => self::get_wp_themes_inactive(),

---

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/7027 as discussed with @dmsnell and @costdev

Summary of the coming steps:

1. ​wp-filesystem
2. ​wp-constants
3. ​wp-database
4. ​wp-server
5. ​wp-media
6. ​wp-plugins-active & wp-plugins-inactive
7. ​wp-mu-plugins

8-10. wp-themes-inactive, wp-parent-theme & wp-active-theme (we are here)

11. ​wp-dropins
12. ​wp-paths-sizes
13. ​wp-core

Refactoring WP_Debug_Data::debug_data(); into smaller functions for

• better maintainability
• reduced complexity
• preparation for future unit tests
• improved extensibility (see trac for details)
• added php7.2 style type hints

Trac ticket: https://core.trac.wordpress.org/ticket/61648#ticket

[dmsnell]

In 59175:

WP_Debug_Data: Extract wp-paths-sizes data into separate methods.

This is the tenth part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the eleventh of twelve groups, the wp-paths-sizes info, into a separate method focused on that data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7445
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
See #61648.

Merged in [59175]
​https://github.com/wordpress/wordpress-develop/commit/2859999e6b0b58b4b5b34c85031dd3497e6333b3

Github's diffing utility is having a hard time with this patch. For those wanting to review it, I encourage using an external diff tool, or change the algorithm with git diff --patience, for example.

@apermo I pushed a commit with a few changes. I would appreciate your review of two in particular:

• I removed what appears to be unused variables in debug_data() - perhaps we overlooked removing those in an earlier commit.
• In get_wp_parent_theme() I replaced the if ( $parent_theme ) with an early abort if ( ! $parent_theme ). this was not only to remove the level of indentation, but I believe it was previously returning an undefined variable $fields since that was set inside the if structure.

[dmsnell]

In 59176:

WP_Debug_Data: Extract wp-themes data into separate methods.

This is the last part in a larger modularization of the data in WP_Debug_Data. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.

This patch separates the findal set of twelve groups, the wp-active-theme, wp-parent-theme, and wp-themes-inactive info, into a separate methods focused on those data.

This work precedes changes to make the WP_Debug_Data class more extensible for better use by plugin and theme code.

Developed in ​https://github.com/wordpress/wordpress-develop/pull/7507
Discussed in https://core.trac.wordpress.org/ticket/61648

Props apermo, dmsnell.
Fixes #61648.

Merged in [59176]
​https://github.com/wordpress/wordpress-develop/commit/dc6f0596db58d986ed72e02a492aa779aa609375

https://core.trac.wordpress.org/ticket/61648

Not sure about the line 32 * @throws ImagickException, it should possibly move to the media function.

[kebbet]

Docblocks needs an update to. Missed during latest commits.

@apermo Any suggestions or insights in the @throws in debug_data docblock?

@apermo Any suggestions or insights in the @throws in debug_data docblock?

That one is correct.

get_wp_media() can possibly throw that, and it will bubble up to debug_data(), since there is no try catch so it is correct to keep the @throws ImagickException in line 32.

But thanks for catching the other doc error.

cc @dmsnell

[desrosj]

Dennis is currently on sabbatical.

RC1 is due out any moment. It looks like there are only some outstanding doc changes, so marking needs-docs.

there are a number of existing patterns in the code that I'm sure people want to change, but I'm worried that making those at the same time, or at least on the same ticket, as moving code from one place to another, will dilute the focus and history of what's happening.

The commit above fixed the results of composer format, which should be run before committing to ensure the coding standards are consistently applied to all new code.

[peterwilsoncc]

In 59290:

Site Health: Update inline docs following refactor of debug data.

Updates the inline docs following the modularization of the WP_Debug_Data.

Props kebbet, desrosj, apermo.
Fixes #61648.

Merged r59290 / ​https://github.com/WordPress/wordpress-develop/commit/baf408f39e92f55acb0c12f3d052e40c78586bbf

[peterwilsoncc]

Reopening to consider [59290] for backport to the 6.7 branch pending another committers sign off.

[peterwilsoncc]

In 59296:

Site Health: Update inline docs following refactor of debug data.

Updates the inline docs following the modularization of the WP_Debug_Data.

Reviewed by swissspidy.
Merges [59290] to the 6.7 branch.

Props kebbet, desrosj, apermo.
Fixes #61648.

Thanks all for your work on this!