Fix fatal error introduced in #449

[swissspidy]

Introduced in #449

Reported in WordPress/plugin-check-action#68

To reproduce:

wp plugin check akismet --require=./wp-content/plugins/plugin-check/cli.php

cc @ernilambar

[felixarntz]

Thanks @swissspidy. Overall this looks good to me, though I'm not sure I like the idea of the caller of the Plugin_Context class constructor having to take care of the normalization.

On the one hand, it makes sense from a separation of concerns perspective, because it works differently for WP core and WP-CLI. On the other hand, it would be great to implement this internally in the class.

Maybe we could go with a pragmatic approach within the Plugin_Context constructor? If wp_normalize_path() exists, use that, otherwise if we're in CLI and the WP-CLI method exists, use that, otherwise do nothing - or maybe even throw an exception cause this should never happen? WDYT?

[swissspidy]

IDK, don't have a strong opinion. We can keep doing it in the constructor, but throwing an exception seems overkill.

[felixarntz]

The current implementation WFM, though I do think being strict here is safer than silently letting a problematic configuration continue. Not a big deal either way, so my feedback is just nit-picks.

Note that there are some lint failures due to the CLI function.

[mukeshpanchal27]

Thanks @swissspidy for the PR! Left some feedbacks.

[ernilambar]

What if we provide polyfill function for wp_normalize_path() so that it is always available.

[swissspidy]

I think a polyfill for an edge case that should never ever happen is overkill.

Here it‘s only not available because of the hacky object-cache.php drop-in