Closed jeremyfelt closed 2 years ago
I'm going to review this further. I might turn to a bit more normalization.
I'm verifying thoughts, but the plugin takes the form-encoded input and converts it to JSON to match the JSON encoded input, which should have no single properties.
I've committed a function that ensures even if a property in JSON syntax comes in without an array, it is converted so everything is standardized.
This introduces test coverage for what I believe to be the possible combinations for the
visibility
andpost-status
properties whenMicropub_Endpoint::post_status()
is used to set post status.The tests flagged an issue where if
visibility
is set topublic
and there is nopost-status
property, thennull
would be returned an an error generated. It seems safe to assume a default post status whenvisibility
is set topublic
, so I added another commit to help tests pass.I originally looked into this issue and thought (🤦🏻) the issue was a string/array mix up. After digging further, I see now that this plugin requires an array value for both
visibility
andpost-status
even though the spec seems to imply a string. Other portions of the plugin check for a numeric array in addition to the string. This seems like something that could be done here, but I wanted to check before going any further.