Plugins Library is writing the wrong Plugin ID into downloaded zips

I want to flag two related problems with the Plugin ID that the Plugins Library writes into manifest.phpbecause together they mean that Plugin Manager can't provide accurate update notices for most of my encapsulated plugins when they're installed from the Library.

1. Correct Plugin IDs are being replaced with wrong ones. For three of my listings, the ZIP the Library serves has a different Plugin ID from the one I uploaded, with nothing else changed. The IDs I uploaded are the ones the listings show, and the version server at ping.zen-cart.com answers each of them with the right plugin. The replacements belong to other people's plugins:

- Scheduled Events v2.0.1: uploaded 860, Library zip says 849 (Recycle Sidebox)

- Trademark v2.0.0: uploaded 2378, Library zip says 2183 (bidorbuy Store Integrator)

- Multiple Ship-To Addresses v3.0.0: uploaded 1823, Library zip says 1723 (Require Phone at Checkout for Specific Countries)

Admin Add Customer v1.2.2 was changed too, from 2445 to 2247, but the server happens to answer both numbers with Admin Add Customer, so that one still works.

2. New submissions get Plugin IDs that already belong to legacy records. The version server still answers these with the migrated plugin:

- Dashboard Boxes is 2263 (server answers with BitPay)

- Authorize.Net Accept.js Payments is 2261 (Audit)

- Attribute Pricing Manager is 2258 (Bank Transfer Indonesia)

- Automatic LLMs.txt Generator is 2257 (Finnish Language pack)

I uploaded the first three with the Plugin ID set to 0 so they wouldn't ask the server anything, and the Library wrote the colliding ID into each zip.

Why it matters. As of today (September 29), nothing is broken for store owners, but only by luck. In every case, Plugin Manager either sees the other plugin's version as older or drops the notice because that plugin's record lists only Zen Cart 1.3.x to 1.5.7. Those legacy records are still being updated, several of them in the last week, and if any of them get a newer Zen Cart version added to their compatible list, stores running my plugins will be told a new version is available and pointed to somebody else's download. It also works the other way: a real update to any of these seven plugins will never appear in Plugin Manager for anyone who installed it from the Library.

A caution for the fix. On Zen Cart 2.0.x and 2.1.x, Plugin Manager crashes with a PHP 8 error if the version server answers an ID with an empty result, because those versions don't check for one before reading the first record (2.2.2 and later do). A user on 2.1.0 hit exactly that in September with a build that mistakenly carried a release ID. So if IDs are reassigned, please make sure each new one is live on the version server before the Library writes it into zips.

Separately, 2.0.1 is missing from the version checkboxes. The 2.x options on a listing are 2.0.0, 2.1.0, 2.2.0, 2.2.1, 2.2.2 and 2.3.0. Plugin Manager matches the store's version exactly against that list, so a store running 2.0.1 can never be notified of an update to any Library plugin, and authors can't fix that on their end.

Could the Library write the listing's own Plugin ID into the zip, or leave the manifest alone when it already carries one, and could new submissions get IDs outside the legacy range? If any of my IDs change, let me know the new numbers and I'll re-cut my releases to match.

Thanks
dbltoe

Thanks for reporting this, @dbltoe. You were right, and it affected more plugins than the ones you listed.

What went wrong. Between 29 July and 10 September, the library stamped the wrong number into manifest.php on some downloads. It used the plugin's internal row number instead of its real plugin ID. That's why Scheduled Events, Trademark and Multiple Ship-To came out as 849, 2183 and 1723 instead of 860, 2378 and 1823. A separate fault gave some new plugins an ID already belonging to an older plugin.

What we've fixed. The affected downloads are corrected. New plugins can no longer be given a number another plugin already uses. 15 plugins that were given a clashing number have new IDs.

What this means for you.

Your plugin's ID is the number shown on its plugin page. The library writes it into manifest.php when a release is approved, so you don't need to set it yourself.

If you uploaded a release between 29 July and 10 September, please check that your own copy of manifest.php has the right pluginId.

Store owners who downloaded one of the affected zips in that period still have the wrong ID in their copy, so they will not see update notices. Please download the current release again and replace the files. A new version number alone won't repair it.

If you think a download of yours is still wrong, post here with the plugin name and we'll check.