Possible conflict with update manager images?

ozfiddler · August 29, 2020, 11:19pm

I have a site that uses both Classic Commerce and ZP Image Control by @anon95694377. Both use the Update Manager by @anon71687268. We recently did an update to the CC version and when I was checking the images I found something strange happening in the “View details” section of the plugin. The one for CC looked like this:

If I deactivate ZP Image Control it displays correctly:

In fact, I can consistently switch between the two different headers by activating and deactivating ZP’s plugin.

Any ideas why this is happening?

ozfiddler · August 29, 2020, 11:32pm

I’ve just been looking at the update client files for both and CC seems to be using an older version. (2019?).

anon95694377 · August 29, 2020, 11:55pm

As far as I’m aware I’m using the latest version of the Update Manager plugin and class, and I’m using the asset path hooks correctly (codepotent_update_manager_image_path and codepotent_update_manager_image_url).

ozfiddler · August 30, 2020, 12:27am

I guess the first step is to update the client manager file to the latest version and see if that fixes it. It’s not something we can fix any time soon as we have just released RC2.

Question for @anon71687268 - when you do an update to the Update Manager plugin do we always also need to push an update with a revised UpdateClient.class.php file? And if it’s not always, then how do we know when it is required? It looks like we are using the latest version of the plugin, but an older version of that file.

anon71687268 · August 30, 2020, 12:40am

Yes, the latest release for the Update Manager plugin is what you need. You will find that it also contains the updated version of the client file which you’ll need to push out into your plugin(s).

Good question.

The version 1.x.x Update Manager files are fine for versions through 1.x.x.

The update client file (in version 2.0.0) contained a breaking change (namely, theme support), which meant the newly updated client file would have to be pushed out into any plugins it was used with. Since I’m using semantic versioning, you can be sure that anything less than a major version update (of the Update Manager plugin) would not contain any changes (at all) to the update client (because it would automatically be a breaking change.) To say it another way: you would only need to push a new client file out into your plugins when the Update Manager receives a major new release (ie, 1.x.x > 2.0.0) and if there were actually any changes to the client file.

ozfiddler · August 30, 2020, 12:47am

OK, thanks. That makes it a lot clearer. Looks like we will need to add this change into the next update (and I will need to update my personal plugins too )

One suggestion… could something be added to the header in the client php file to say what version of the plugin it corresponds to? At the moment all I can see is ZP’s has “Copyright 2020, Code Potent” and our’s says “Copyright 2019, Code Potent”.

anon71687268 · August 30, 2020, 12:56am

Here’s a link to the post I made for the release. See the Upgrade Notes section, in particular.

Take a look at the constructor in the UpdateClient.class.php file. You’ll see the config property contains the api version number. This number corresponds to which version(s) of Update Manager it applies to. For example, if your file has 'api' => '1.0.0', it’s for versions 1.x.x of Update Manager. As seen in the code snip below, the updated client file has 'api' => '2.0.0', indicating it’s for version 2.x.x of Update Manager.

github.com

xxsimoxx/codepotent-update-manager/blob/43c7653bfe35d1fb9a113923a0f885e856529d4a/classes/UpdateClient.class.php#L91-L103


      
          		// Configure the update object.

          		$this->config = [

          			// The URL where your Update Manager plugin is installed.

          			'server' => UPDATE_SERVER,

          			// Leave as-is; may add support for theme updates later.

          			'type' => UPDATE_TYPE,

          			// Plugin identifier; ie, plugin-folder/plugin-file.php.

          			'id' => $this->get_identifier(),

          			// Leave as-is.

          			'api' => '2.0.0',

          			// Leave as-is – tutorial can be created with enough interest.

          			'post' => [],

          		];

ozfiddler · August 30, 2020, 1:02am

Oh, upgrade notes! Who reads those?

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.

anon71687268 · August 30, 2020, 1:06am

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?

ozfiddler · August 30, 2020, 1:13am

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.

anon71687268 · August 30, 2020, 1:16am

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.

anon95694377 · August 30, 2020, 2:07am

Dangit, my cunning plan was foiled!

Glad you worked out what the issue was.

anon71687268 · August 30, 2020, 4:59am

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

ozfiddler · August 30, 2020, 6:01am

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.

ozfiddler · August 30, 2020, 6:10am

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.

anon71687268 · August 30, 2020, 7:03am

Try doing a hard refresh in the modal window.

ozfiddler · August 30, 2020, 7:21am

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?

1stepforward · August 30, 2020, 10:36am

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.

ozfiddler · August 30, 2020, 11:01am

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

anon95694377 · August 30, 2020, 11:29am

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.