Media Library URL’s change after plugin update #139
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have tried without success to replicate the problem although I have implemented the Media library in a different URL and directory combination than standard.
The Featured Image process loads the image using the same mechanism as used for the document, but their interfaces are not both exposed to the program.
Its implementation was therefore to set a cookie that would differentiate between them.
I have to surmise that Troy's use is that the document library is the standard one and the issue is that information is some assigning the Media Items as being in the document directory.
As far as I could see, the use of the cookie is always after I have established that the post is for a Document so it really does not matter the value outside our scope.
This set of fixes is essentially defensive in that it:
a) Makes the default value in the absence of the cookie to be the image indicator (true) instead of document (false)
b) Sets the cookie to false only when the user clicks on the Upload Document button and to true only when the user clicks on the featured image area (other plugins can add buttons)
c) Deletes/Expires the cookie when the user clicks the Submit/Publish button; or when they quit via the Admin Menu or Bar. So that in normal exit cases, the cookie is no longer present.
With no detailed use case, I cannot guarantee that this will have addressed Troy's problem but it certainly will have reduced the possible issue.