Possible conflict with update manager images?

Oh, upgrade notes! Who reads those? :wink:

Actually I did see that and I noted this part:

the new version of the file will need to be pushed out into your own plugins at some point . The old file remains compatible with the new version of Update Manager; no breaking changes.

So, since we didn’t need theme support I didn’t worry about it.

I was thinking more of having it in a place where someone like me might easily find it. I don’t tend to delve too deeply into code. :slightly_smiling_face:

2 Likes

Hahaha… I guess you’ve arrived at that at some point point! I suppose the version number could be added to the top of the file in the code comments – is that what you meant?

Yep, exactly. That would make checking really quick and easy.

I should have known it was important… it was in italics!

Well, at least we now know that @anon95694377 isn’t trying to hack into everyone’s plugins and gradually infiltrate the entire ClassicPress environment. :wink:

4 Likes

I’ve created an issue for this. Note that it probably won’t get added for some time; it’s a rather inconsequential change to push out as a point release. But, at least it won’t be lost.

2 Likes

Dangit, my cunning plan was foiled! :rofl:

Glad you worked out what the issue was.

3 Likes

A post was split to a new topic: Adding Update Manager as a dependency

Hmmm… I just copied the new 2.0.0 client file into my test site, configured the variables as before and it still does exactly the same thing. Zigpress header is replacing CC header.

:thinking:

1 Like

And it does the same thing on my Utility plugin. And that one does have the latest version of the Update Client installed. Might need to remove that “solved” tag @anon71687268.

1 Like

Try doing a hard refresh in the modal window.

I’ve hard refreshed a hundred times. Just tried a different browser. Still the same.

Maybe it’s some weird issue with my host, or my setup. I’m not using any caching plugins. Can anyone else reproduce this problem?

1 Like

Just a bit of extra info. I’ve got a site with both Classic SEO and Classic Commerce installed and the plugin details display correctly for both.

So, I installed ZP Image Control and activated it but did not look at the plugin details.

When I looked at the plugin details for Classic SEO, I also got the Zigpress banner, so it can’t be a cache issue as I’ve never loaded the Zigpress banner before.

I think it may possibly be to do with CSS and/or the loading of filters.

When I have the details popup open for Classic SEO (with ZP Image Control active), this bit of CSS is in the frame source:

<style type="text/css">
  #plugin-information-title.with-banner {
    background-image: url( http://example.com/wp-content/plugins/zp-image-control/assets/img/banner-772x250.jpg );
  }
  @media only screen and ( -webkit-min-device-pixel-ratio: 1.5 ) {
    #plugin-information-title.with-banner {
      background-image: url( http://example.com/wp-content/plugins/zp-image-control/assets/img/banner-1544x500.jpg );
    }
  }
</style>

The same happens with CC.

Bizarre. :confused:

3 Likes

Ah, thanks for checking Tim. So it’s not just me.

2 Likes

Looks like a filter issue?

The function get_plugin_images in the update manager class provides the filters, but filters in WordPress are global so you have more than one plugin competing to change the filtered data.

So maybe the filters need to be renamed so that they contain the plugin slug or something?

EDIT: Hmm, not sure if I’m right actually, considering there’s a namespace involved.

2 Likes

That’s what’s throwing me too. I’ve checked and all three plugins have their own namespace.

But adding the plugin slug might not be a bad idea anyway.

1 Like

Sorry if my answer is wrong but i’m checking it all over mobile. When using filters provided by update manager for assets you must check if the initial value deals with your plugin (search for plugin slug inside path).

Changing the image dir globally will result in changing it for every plugin using UM. Namespaces are not involved in this process.

6 Likes

Thanks Simone, that makes sense.

But perhaps the responsibility is with the updatemanager class to keep the filters unique?

4 Likes

Well, no matter what the ‘best’ solution is, I’ve released 1.0.3 of ZP Image Control so that we can see if it solves the problem.

This version uses Simone’s suggestion of checking the path in my filter functions.

To see if it solves the problem, there should be no other ZP plugin active while testing.

Get it here: https://www.zigpress.com/plugins/zp-image-control/

Or of course Update Manager should push it anyway.

4 Likes

That works for me @anon95694377.

3 Likes

OK that’s great, Thanks for checking it out.

I’ll push the same tweak to my other plugins when I get a chance (right now I’m up to my ears in client work).

4 Likes

Thanks all for rooting out the issue and coming up with a workaround. I’m not at my workstation, but, will take a closer look at solving this at the root in the coming week. I’ll keep you posted. :slight_smile:

6 Likes