-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to update Update Manager client file #257
Comments
Related discussion at https://forums.classicpress.net/t/possible-conflict-with-update-manager-images/2466/13 |
Yeah, I don't think this is an issue with Update Manager. Classic SEO and Classic Commerce don't have this problem and both use Update Manager . Not sure there's anything for us to do here but I'll leave this open for the time being. |
I agree. But we should keep it in the pipeline, so issue should remain open. If John releases a fix that involves changing the client file then we will certainly need to be updating to that version. |
After reviewing the issue, I'm in agreement with you both that it's not necessarily an issue with the Update Manager plugin code. In this case, I think it's a documentation issue. Andy (zigpress) implemented the image path filter in accordance with the example provided, which is what caused the issue. The solution will be to update the docs to reflect the same change Andy made to his plugin's implementation of the filter. So, from this...
...to this...
I will get the docs updated quickly. |
Thanks John. Thanks makes sense. I'll close this issue now. |
This issue has been mentioned on ClassicPress Forums. There might be relevant details there: https://forums.classicpress.net/t/possible-conflict-with-update-manager-images/2466/29 |
Describe the bug
We are using an old version of the Update manager client file. This means if there is another plugin installed also using the update manager then their header image will override ours.
To Reproduce
Steps to reproduce the behavior:
Screenshots
Zigpress activated:
When Zigpress deactivated:
Expected behavior
Our header should stay there!
Isolating the problem (mark completed items with an [x]):
The text was updated successfully, but these errors were encountered: