Skip to content

25: Name the sub-plugin a rejected config is about - #39

Open
nikolaystrikhar wants to merge 1 commit into
24-request-valuesfrom
25-config-messages
Open

25: Name the sub-plugin a rejected config is about#39
nikolaystrikhar wants to merge 1 commit into
24-request-valuesfrom
25-config-messages

Conversation

@nikolaystrikhar

Copy link
Copy Markdown
Contributor

What: every Config_Exception from the Sub_Plugin constructor names the entry it is about and the type it received.

Usage:

Sub-plugin config for "give-recurring": key "conflict_policy" must be a
policy string or a non-string callable, array given.

Why this way:

A manifest loop is one stack frame for every sub-plugin in it. That shape is what the recipes recommend, and under it "missing required key: plugin_loaded_constant" identifies neither which of five entries was wrong nor which file it came from. The slug is already in the array being validated.

The fallback matters, because the slug may be the faulty key. bundled_plugin_file identifies the entry just as well and names the file to go and look at; when neither can be read, the message says so rather than quietly naming nothing.

The message-key rejection carries its remedy. Wrapping the text in a callable is the whole fix, and the reasoning was otherwise only in a source comment the host never sees.

get_class() for objects, so a Closure and a WP_Error under the same key are different mistakes rather than both "object".

Every Config_Exception from the constructor named the offending key and
nothing else. Registered from the manifest loop the recipes recommend, five
sub-plugins share one stack frame, so "missing required key:
plugin_loaded_constant" identified neither the entry nor the file.

All six messages take one form now, naming the entry by slug, or by
bundled_plugin_file where the slug is itself the faulty key, and reporting the
type received -- get_class() for objects, so a Closure and a WP_Error are
told apart. The message-key rejection carries its remedy, since wrapping the
text in a callable is the whole fix and the reasoning is otherwise only in a
comment the host cannot see.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant