Closed ghost closed 4 years ago
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...
function my_custom_image_path($path) {
return '/path/to/your-site/wp-content/plugins/your-plugin-name/images';
}
add_filter('codepotent_update_manager_image_path', 'my_custom_image_path');
...to this...
function my_custom_image_path($path) {
if (strpos($path, {plugin-slug}) !== false) {
$path = '/path/to/your-site/wp-content/plugins/your-plugin-name/images';
}
return $path;
}
add_filter('codepotent_update_manager_image_path', 'my_custom_image_path');
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]):