fix (update center): remove stale config keys and fix misleading badge when switching plugin source

[TiTidom-RC]

Description

Problem

When a plugin is switched from one source to another (e.g. GitHub → Market), the
configuration keys specific to the previous source (user, repository, token for GitHub;
market for Market, etc.) are never removed from the database. They become orphaned data.

Example of configuration persisted in DB after switching from GitHub to Market:

{"version":"beta","market":1,"doNotUpdate":"0","user":"TiTidom-RC","repository":"Discordlink","token":""}

while source = 'market'.

Visible consequence: the Update Center displays beta - TiTidom-RC for a plugin now managed
by the Market, because the JS renders the version - user badge whenever the user key
exists in the configuration, without checking source.

---

Fix 1 — core/ajax/update.ajax.php

In the save action, purge all configuration keys not belonging to the new source after
utils::a2o() merges the submitted data. array_diff ensures that keys shared between
sources (e.g. path for both samba and file) are never purged on a transition between
those two sources. Shared keys (version, doNotUpdate) are never affected. This also
cleans up any pre-existing orphaned data from multi-hop transitions (e.g. GitHub → URL →
Market, where only url would have been purged with a source-comparison approach).

Fix 1b — core/ajax/repo.ajax.php (install button from Market / repo store)

The install action sets the new source but never purged the old source's exclusive keys
either. Same purge logic applied here, before setSource(), covering the case where a plugin
previously added via GitHub is reinstalled directly from the Market store UI.

Fix 1c — core/repo/market.repo.php (pullInstall())

pullInstall() installs plugins pushed automatically from the Market but only nullified user,
leaving repository, token, url, and path as potential orphaned data. Full purge of
all non-market keys applied before setSource('market').

Fix 1d — core/php/jeecli.php (CLI plugin install without --user/--repository)

The plugin install <id> branch without GitHub arguments sets source = 'market' but never
purged any prior source keys. Same full purge applied.

Fix 2 — desktop/js/update.js

Guard the version - user badge display with _update.source !== 'market'. This fixes the
visual for all existing installations that already have orphaned data in DB, without requiring
any reconfiguration.

---

Tested transitions

From	To	Keys purged	Covered by
github	market	user, repository, token	Fix 1 + Fix 1b + Fix 1c + Fix 1d
market	github	market	Fix 1 + Fix 1b
github	url	user, repository, token	Fix 1 + Fix 1b
samba	file	(none — path is shared)	Fix 1 + Fix 1b
url	github	url	Fix 1 + Fix 1b
github → url → market (multi-hop)	market	user, repository, token, url	Fix 1 + Fix 1b
New install (no prior record)	any	(none — purge is inoffensive on empty config)	Fix 1b + Fix 1c + Fix 1d

Suggested changelog entry

Amélioration de la gestion des clés liées à une source spécifique pour un plugin, ainsi que l'affichage dans le centre de mise à jour.

Related issues/external references

Fixes #

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[zoic21]

Hello,
I'am not sure it's the best way to do that, for me repo class don't have to deals with that, all change need to be on update.class.php.

[TiTidom-RC]

Hello,

Thanks for the review.

To make sure I'm going in the right direction: would a dedicated purgeOrphanedConfigKeys() method on the update class work for you?

The $allSourceKeys map and the purge logic would live only in update.class.php, and each callsite (update.ajax.php, repo.ajax.php, jeecli.php, market.repo.php) would simply call $update->purgeOrphanedConfigKeys() — no logic duplication, and it keeps the explicit call at the right moment for each flow.

Or did you have a different placement in mind ?