That would indeed explain it. Workflow’s article based actions are looking for specific items of data in the web page. If they don’t identify them or they aren’t available, then there will be unspecified data. Not quite a failure as much as a limitation.
If the post is on a platform you use regularly in this way you could probably parse the body (HTML) of the page and identify the author through use of regular expression matches. This could be used as an alternative way to populate the author on those occasions, but it effectively means you’re extending the get article details functionality with some additional actions.
If that sounds like overkill or being too complicated, consider adding in a prompt to query for the name of the author should one not be found. You could then substitute that in for the remainder of your workflow.
Indeed. Perhaps I should have been more specific in how to use the share sheet for this workflow, but it is basiclly how Safari in iOS works rather than something specific to this workflow.
Using the sharing button mentioned is exactly what this workflow uses without requiring the use of the clipboard. This means that you get retention of original clipboard content and quicker execution. Note that the OP specifically referenced use of Safari as one of the two options for utilisation at the start. therefore making use of Workflow’s built-in Safari functionality makes most sense.