emanuelegori/eg-forgejo-updater
1
0
Fork 0
Code Issues Pull requests Projects Releases 9 Packages Wiki Activity Actions
9 releases 40 tags
  • v3.3.1 70c361cb9a

    v3.3.1
    All checks were successful
    Auto Release on version bump / release (push) Successful in 8s
    Details
    Stable

    Ghost released this 2026-10-11 22:31:30 +02:00 | 1 commits to main since this release

    Changed

    • Pulsante "Automatic" → "Use WordPress.org" (IT "Usa WordPress.org"), tooltip "Forced to Forgejo. Go back to updates from WordPress.org". Il pulsante (canale auto dopo "Use Forgejo") non cambia comportamento. "Automatic" era ambiguo: l'utente l'ha letto come Automattic, la società; ora è simmetrico a "Use Forgejo". Caso limite non coperto dall'etichetta: se il plugin esce da WordPress.org mentre è forzato su Forgejo, il ritorno ad auto lo lascia su Forgejo.
    • Link "Documentation" (riga del plugin e footer della pagina admin) verso la pagina del plugin sul sito invece che verso il repository: eg_forgejo_updater_docs_url(), URL traducibile (EN /en/plugins/eg-forgejo-updater/, IT /plugin/eg-forgejo-updater/), come in eg-social-timeline ed eg-repo-card. "Repository" resta sul repo.

    Fixed

    • CHANGELOG.md: titolo della sezione 3.2.0 rotto ( - 2026-10-11 senza ## [3.2.0]).

    Why

    • Pagine del plugin pubblicate l'11 ottobre (41238/41239); l'etichetta è emersa rileggendo la sezione "Plugin presenti anche su WordPress.org".
    Downloads
  • v3.3.0 5bce0cbb63

    v3.3.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 8s
    Details
    Stable

    Ghost released this 2026-10-11 19:57:45 +02:00 | 2 commits to main since this release

    Added

    • Compatibilità nell'oggetto di aggiornamento (inject_updates()): requires, requires_php e tested dal readme.txt della release, prima usati solo nella scheda "Visualizza dettagli". WordPress ora mostra l'avviso di incompatibilità, disattiva il pulsante e salta l'auto-update se PHP o WordPress non bastano. Idea dal confronto con Git Updater, che li passa.
    • Icona (images/icon.svg) nell'oggetto di aggiornamento: in Bacheca → Aggiornamenti i plugin gestiti non hanno più l'icona grigia generica. Servita dal sito: niente icona geometrica di s.w.org (il browser avrebbe mandato a WordPress.org i nomi dei plugin privati) né icone dal repo (illeggibili dal browser nei repo privati, e una richiesta in più per plugin).

    Fixed

    • "Questo plugin non è stato testato con la tua versione di WordPress" sulla 3.2.0 in produzione (WP 7.1.3, Tested up to: 7.1): WordPress confronta 7.1.3 <= 7.1, falso. WordPress.org restituisce invece l'ultima minor della major dichiarata. normalize_tested(): se Tested up to è solo major e coincide con quella del sito, restituisce la versione del sito. Usata sia nella scheda sia nell'oggetto di aggiornamento.

    • clear_cache() svuota solo i plugin appena aggiornati ($options['plugins'] / $options['plugin']) invece di tutti: il controllo successivo faceva ripartire insieme le richieste di ogni plugin e il rate limit di NPM rispondeva 503. "Controlla ora" continua a svuotare tutto.

    • 2026-10-11

    Added

    • Cestino (ultima colonna): per i plugin disattivati porta alla conferma nativa di WordPress (plugins.php?action=delete-selected&checked[]=…, nonce bulk-plugins), che elenca i file ed esegue uninstall.php. Plugin attivo → cestino grigio con "Deactivate the plugin first" (WordPress filtra comunque i plugin attivi). Niente cestino per l'updater stesso e senza delete_plugins (che copre anche DISALLOW_FILE_MODS).
    • Istanza in tabella: sotto owner/repo, l'host in grigio.
    • Anteprima, passo "Update source" (avviso giallo, non blocca): l'header punta a un repository diverso da quello da cui si installa, e gli aggiornamenti seguiranno l'header. La checklist ha ora lo stato warn.
    • Anteprima, cartella già esistente: se wp-content/plugins/<repo>/ c'è già, la checklist si ferma subito (prima WordPress falliva dopo aver scaricato lo zip, con un errore generico).

    Fixed

    • Anteprima: il file principale e il ripiego sul branch usano il default_branch del repo (dal passo 3, nessuna richiesta in più) invece di main fisso. Primary Branch nell'header resta prioritario.
    • Il passo "Forgejo Updater compatibility" nomina l'header trovato davvero (Gitea Plugin URI compariva come Forgejo Plugin URI).
    • Anteprima: un header nel vecchio formato breve (owner/repo), che l'updater dalla 3.0.0 non legge, ora ferma l'installazione con un errore chiaro ("Update source"); prima il plugin si sarebbe installato senza mai ricevere aggiornamenti. Caso reale: eg-ranking-repo. L'anteprima usa lo stesso parser dell'updater (EG_Forgejo_Updater::parse_repo_uri(), ora statico e pubblico).
    • Il messaggio "file principale non trovato" dice in quale branch ha cercato.

    Docs

    • readme FAQ e README: istanze che non generano archivi (forgejo.it risponde 500 a ogni /archive/): lì servono release con lo zip allegato.

    Verified

    • handle_preview() eseguita davvero come amministratore (redirect intercettato): repotest da forgejo.it → "Destination folder" e stop senza richieste; eg-ranking-repo con header breve reale → errore "Update source"; header falsato verso forgejo.it → avviso giallo, anteprima pronta; header uguale con maiuscole e slash finale → nessun avviso; default_branch simulato a develop → file letto da ?ref=develop.

    Why

    • Emerso dall'installazione di repotest da forgejo.it (11 ottobre): header che puntava a git.emanuelegori.uno, file principale rinominato, archivi in errore. Il cestino è una richiesta dell'utente.
    Downloads
  • v3.2.0 c11342d1c9

    v3.2.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 7s
    Details
    Stable

    Ghost released this 2026-10-11 19:13:31 +02:00 | 3 commits to main since this release

    Added

    • Cestino (ultima colonna): per i plugin disattivati porta alla conferma nativa di WordPress (plugins.php?action=delete-selected&checked[]=…, nonce bulk-plugins), che elenca i file ed esegue uninstall.php. Plugin attivo → cestino grigio con "Deactivate the plugin first" (WordPress filtra comunque i plugin attivi). Niente cestino per l'updater stesso e senza delete_plugins (che copre anche DISALLOW_FILE_MODS).
    • Istanza in tabella: sotto owner/repo, l'host in grigio.
    • Anteprima, passo "Update source" (avviso giallo, non blocca): l'header punta a un repository diverso da quello da cui si installa, e gli aggiornamenti seguiranno l'header. La checklist ha ora lo stato warn.
    • Anteprima, cartella già esistente: se wp-content/plugins/<repo>/ c'è già, la checklist si ferma subito (prima WordPress falliva dopo aver scaricato lo zip, con un errore generico).

    Fixed

    • Anteprima: il file principale e il ripiego sul branch usano il default_branch del repo (dal passo 3, nessuna richiesta in più) invece di main fisso. Primary Branch nell'header resta prioritario.
    • Il passo "Forgejo Updater compatibility" nomina l'header trovato davvero (Gitea Plugin URI compariva come Forgejo Plugin URI).
    • Anteprima: un header nel vecchio formato breve (owner/repo), che l'updater dalla 3.0.0 non legge, ora ferma l'installazione con un errore chiaro ("Update source"); prima il plugin si sarebbe installato senza mai ricevere aggiornamenti. Caso reale: eg-ranking-repo. L'anteprima usa lo stesso parser dell'updater (EG_Forgejo_Updater::parse_repo_uri(), ora statico e pubblico).
    • Il messaggio "file principale non trovato" dice in quale branch ha cercato.

    Docs

    • readme FAQ e README: istanze che non generano archivi (forgejo.it risponde 500 a ogni /archive/): lì servono release con lo zip allegato.

    Verified

    • handle_preview() eseguita davvero come amministratore (redirect intercettato): repotest da forgejo.it → "Destination folder" e stop senza richieste; eg-ranking-repo con header breve reale → errore "Update source"; header falsato verso forgejo.it → avviso giallo, anteprima pronta; header uguale con maiuscole e slash finale → nessun avviso; default_branch simulato a develop → file letto da ?ref=develop.

    Why

    • Emerso dall'installazione di repotest da forgejo.it (11 ottobre): header che puntava a git.emanuelegori.uno, file principale rinominato, archivi in errore. Il cestino è una richiesta dell'utente.
    Downloads
  • v3.1.0 88496543cb

    v3.1.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 7s
    Details
    Stable

    Ghost released this 2026-10-11 16:45:17 +02:00 | 4 commits to main since this release

    Added

    • Colonna Installata: sotto la versione, la data in cui il plugin è stato installato o aggiornato l'ultima volta su questo sito (filemtime() del file principale), formattata con wp_date() e il formato data del sito; data e ora nel tooltip. Nessuna richiesta HTTP; vale anche per i plugin di WordPress.org. Senza data leggibile resta solo la versione.

    Why

    • Scelta dell'utente fra due date: installazione sul sito (gratis) e pubblicazione della versione (gratis solo se installata = remota, altrimenti una richiesta in più per plugin contro il rate limit di NPM). Data dentro la colonna esistente e non in una colonna nuova: la tabella ha già 6 colonne a larghezza fissa, e un titolo "il" non si traduce.
    Downloads
  • v3.0.0 06d9afb8a1

    v3.0.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 10s
    Details
    Stable

    Ghost released this 2026-10-11 16:03:49 +02:00 | 5 commits to main since this release

    Changed

    • Token per istanza: EG_FORGEJO_UPDATER_TOKENS in wp-config.php, mappa https://host[:porta] → token. Più istanze Forgejo/Gitea insieme senza configurazione per plugin: l'istanza di ogni plugin si ricava dall'URL nell'header. Chiavi normalizzate (schema https obbligatorio, host minuscolo, percorso e slash ignorati, porta 443 implicita); voci non valide scartate e contate nel pannello.
    • Il token va solo alla sua istanza (confronto esatto di schema, host e porta) e solo con le richieste dell'updater: le chiamate API lo prendono da EG_Forgejo_Updater_API::request_args(); il filtro http_request_args lo allega solo agli URL dei pacchetti scelti dall'updater (download in cache dei plugin gestiti, o quello in installazione via EG_Forgejo_Updater::allow_package()), e con il token spegne i redirect.
    • Prefissi = slug completo: eg_fu_* → eg_forgejo_updater_* (transient, azioni admin_post, nonce, parametri URL, campi), EG_FU_* → EG_FORGEJO_UPDATER_*, classi EG_Forgejo_API/EG_Forgejo_Admin → EG_Forgejo_Updater_API/EG_Forgejo_Updater_Admin con i file rinominati.
    • Riquadro della pagina: istanze con token (solo l'indirizzo), istanze dei plugin gestiti senza token, voci scartate, promemoria finché FORGEJO_ACCESS_TOKEN è definita.
    • Footer della pagina negli slot nativi (admin_footer_text, update_footer a priorità 20), come negli altri plugin eg-*. "Documentazione" punta al repo: le pagine /plugin/eg-forgejo-updater/ e /en/plugins/eg-forgejo-updater/ non esistono.
    • readme.txt riscritto per la directory: niente confronto con Git Updater, descrizione e FAQ aggiornate, changelog solo della linea 3.x; il resto in changelog.txt (voci della 2.10.0 tradotte in inglese). Description dell'header corretta (diceva "falls back to tags").
    • Il form di installazione dice che un repository privato richiede un token per la sua istanza (prima chiedeva un repository "pubblico").

    Removed

    • FORGEJO_ACCESS_TOKEN, FORGEJO_BASE_URL e il formato breve owner/repo nell'header. ⚠️ FORGEJO_BASE_URL resta in wp-config.php di produzione: la usa eg-forgejo-registration. Il pannello avvisa solo per FORGEJO_ACCESS_TOKEN.

    Added

    • maybe_upgrade(): al cambio di versione cancella i transient eg_fu_release_*/eg_fu_wporg_* della 2.x; option eg_forgejo_updater_version. uninstall.php pulisce nomi vecchi e nuovi.

    Why

    • Fino alla 2.13.0 il token partiva verso tutti gli host dei plugin gestiti, compreso quello dell'updater stesso: chi lo avesse installato con il token della propria istanza l'avrebbe mandato anche a git.emanuelegori.uno. In più build_request_args() lo allegava a ogni chiamata API senza guardare l'host, e il filtro globale lo regalava alle richieste di altri plugin verso la stessa istanza (eg-repo-card). WordPress (Requests) rimanda gli header anche sui redirect cross-host.
    • Git Updater gestisce più istanze con un token globale più token per repo nel database: i repo di una seconda istanza senza token proprio ricevono quello globale.

    Verified

    • Routing con token finti e richieste intercettate: token giusto per host e porta; nessun token a host.evil.com, http, porta diversa, host sconosciuti; richieste API con redirection=0; filtro: token solo su pacchetto gestito e pacchetto in installazione, mai su altre richieste allo stesso host.
    • Token vero in mappa: gli 11 plugin con Gitea Plugin URI, privati compresi, rispondono dalla release.
    • Rendering della pagina in it_IT con il .mo nuovo; il token non compare nel markup.
    • Form, handler admin_post e nonce corrispondono; hook nuovi solo quelli del footer.
    • make-pot, msgfmt --check (104 tradotte, 3 non tradotte ammesse).
    Downloads
  • v2.13.0 c2456a1a0c

    v2.13.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 10s
    Details
    Stable

    Ghost released this 2026-10-11 15:06:44 +02:00 | 6 commits to main since this release

    Changed

    • Il pacchetto arriva dall'ultima release, non più dal branch. get_latest_version() chiama GET /api/v1/repos/{owner}/{repo}/releases/latest: versione = tag_name senza la v, pacchetto = primo allegato .zip servito dalla stessa istanza (se manca, archive/{tag}.zip), readme.txt letto dal tag. Restano 2 richieste per plugin.
    • Ripiego sul branch solo per i repo senza release (HTTP 404 su releases/latest): versione dall'header Version: e zip del branch, come fino alla 2.12.0. La colonna Stato lo segnala con "Nessuna release: aggiorna dal branch". Su 401/403, 5xx ed errori di rete nessun ripiego: valgono gli stati già esistenti.
    • "Installa plugin da Forgejo" installa anch'esso l'ultima release; la checklist ha un passo "Pacchetto" (release o branch). La cartella prende il nome del repo con un filtro upgrader_source_selection temporaneo, perché lo zip di una release può contenere il nome vecchio del repo.
    • readme.txt (FAQ, External services) e i due README descrivono il flusso nuovo. Corretta anche la descrizione delle richieste dell'anteprima, che citava un /contents mai usato.

    Why

    • Con lo zip del branch, un commit su main senza bump arrivava ai siti che aggiornavano dopo, con lo stesso numero di versione della release: due siti "2.12.0" potevano avere codice diverso. Lo zip allegato dalla CI esisteva già ma nessuno lo usava. Idea presa dal confronto con Git Updater, che scarica il tag o l'asset della release.
    • Caso reale che ha deciso "primo .zip" invece della ricerca per nome: la release v1.6.0 di eg-contact-form allega eg-contact-form-privacy.zip, con dentro la cartella eg-contact-form-privacy/ (nome del repo prima del rename).

    Verified

    • Prima del rilascio, in produzione con la classe API nuova caricata sotto altro nome (wp eval-file, nessuna scrittura): i 13 plugin gestiti passano tutti a release, con la stessa versione di oggi e lo zip della release; repotest (file principale rinominato per il test 404) → 404 come prima; con il nome giusto del file → ripiego branch.
    • Risposte simulate con pre_http_request: release senza zip e zip su host esterno → archive/{tag}.zip; tag non valido e JSON rotto → errore; 401 → nessun ripiego; 500 → 3 tentativi.
    • Download reale dello zip di eg-contact-form con il token: HTTP 200 senza redirect.
    • make-pot, msgfmt --check (95 tradotte, 3 non tradotte ammesse), Plugin Check: solo l'ERROR atteso plugin_updater_detected.
    Downloads
  • v2.12.0 f0567ac5f7

    v2.12.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 8s
    Details
    Stable

    Ghost released this 2026-09-26 17:08:49 +02:00 | 7 commits to main since this release

    Added

    • I plugin gestiti che sono anche nella directory di WordPress.org vengono restituiti a WordPress: scheda "Visualizza dettagli" e aggiornamenti arrivano da lì. Il rilevamento legge il transient update_plugins che il core riempie con la risposta di api.wordpress.org: una voce con id = w.org/plugins/<slug> indica un plugin della directory. Nessuna chiamata in più per i plugin che non ci sono.
    • Verifica contro le omonimie: WordPress.org abbina i plugin solo per slug, quindi l'updater si fa da parte solo se i Contributors: del readme.txt installato hanno almeno un nome in comune con i contributors dell'API plugins/info/1.2. Esito in cache una settimana (eg_fu_wporg_*), 5 minuti in caso di errore.
    • Interruttore per plugin nella tabella admin, Usa Forgejo / Automatico, salvato nell'option eg_forgejo_updater_channels. Serve per provare su un sito una versione presente su Forgejo e non ancora su WordPress.org.
    • Stati nuovi in tabella: in Stato "Slug occupato su WordPress.org" (rosso) e "Verifica WordPress.org non riuscita" (giallo).

    Changed

    • La colonna Sorgente mostra il canale di aggiornamento, Forgejo o WordPress.org, invece del modo di registrazione (auto/forgejo), che passa nel tooltip e continua a decidere il pulsante "Rimuovi". Mescolare le due cose rendeva ambiguo auto accanto a wordpress.org, e dopo "Usa Forgejo" la colonna tornava a auto.
    • Per i plugin passati alla directory la colonna Repository punta a wordpress.org/plugins/<slug>; il link Forgejo nell'elenco plugin di WordPress resta, come accesso al sorgente.
    • Il pulsante del canale sta sempre su una riga propria: come form inline andava a capo accanto a wordpress.org e restava in riga accanto a auto.
    • La colonna Stato non è più vuota: ✓ Aggiornato, il pulsante Aggiorna, gli avvisi, e con il canale forzato la versione pubblicata su WordPress.org ("Su WordPress.org: 1.15.9"), per vedere se la directory è avanti o indietro rispetto a Forgejo.
    • readme.txt: la sezione External services dichiara la chiamata ad api.wordpress.org.

    Fixed

    • Con la versione Forgejo pari a quella installata, inject_updates() faceva unset() anche dell'eventuale offerta di WordPress.org per lo stesso plugin. Ora per un plugin gestito da Forgejo le offerte di WordPress.org vengono tolte sempre, anche quando Forgejo non risponde (prima un'offerta di un omonimo sarebbe passata).

    Why

    • Con eg-social-timeline pubblicato su WordPress.org, la scheda costruita dall'updater non aveva screenshot, banner, icone né last_updated/active_installs/rating, mostrava la tab "Upgrade Notice" e passava tested dal readme (7.1), da cui l'avviso "not tested with your current version" su WordPress 7.1.x. E i siti aggiornavano da Forgejo invece che dal canale con cui il plugin arriva a tutti gli altri.

    Verified

    • Simulazione in produzione con la classe nuova caricata sotto altro nome (wp eval-file): 13 plugin gestiti, solo eg-social-timeline passa a WordPress.org (1.15.9); plugin_info restituisce il risultato intatto. Su un transient costruito ad arte: offerta di WordPress.org conservata per il plugin delegato, omonimo (akismet) respinto con stato mismatch, slug inesistente → unverified e plugin rimasto su Forgejo; canale forzato → scheda Forgejo.
    • make-pot, msgfmt --check (87 tradotte, 3 non tradotte ammesse), caricamento reale del .mo.
    • Plugin Check sul pacchetto: solo l'ERROR atteso plugin_updater_detected.
    • Tabella renderizzata in produzione con le classi di prova: canale automatico → WordPress.org, link alla directory, ✓ Up to date; canale forzato → Forgejo, link al repo, "On WordPress.org: 1.15.9".
    • Provata sullo stage dall'utente.
    Downloads
  • v2.11.0 0e222119c6

    v2.11.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 9s
    Details
    Stable

    Ghost released this 2026-09-16 21:58:46 +02:00 | 10 commits to main since this release

    Added

    • Internazionalizzazione completa del plugin: tutte le stringhe visibili all'utente (pagina admin, wizard di installazione, notice, colonna Stato, link azione nella lista plugin) passano dalle funzioni di traduzione WordPress, con l'inglese come lingua sorgente.
    • Header Text Domain: eg-forgejo-updater e Domain Path: /languages, che finora mancavano: senza di essi WordPress non avrebbe caricato alcuna traduzione.
    • Cartella languages/ con il template eg-forgejo-updater.pot (77 stringhe) e la traduzione italiana eg-forgejo-updater-it_IT.po/.mo. Nessuna chiamata a load_plugin_textdomain(): WordPress carica le traduzioni just-in-time dal 4.6.
    • Commenti translators: su ogni stringa con placeholder.

    Changed

    • Le stringhe che interpolavano variabili nel letterale ("Errore inatteso (HTTP {$http_code}). Riprova più tardi." e altre 4) sono state riscritte con sprintf() e placeholder. Erano il punto piu' fragile: come letterali con la variabile dentro non sarebbero mai state traducibili, e sarebbero sparite in silenzio dal .pot.
    • Le due sole chiamate __() preesistenti avevano msgid in italiano (Impostazioni, Documentazione), contro la convenzione dei plugin eg-*: ora sono Settings e Documentation. Chi avesse traduzioni esterne basate sui vecchi msgid deve rimapparle.
    • Description dell'header del plugin portata in inglese; la resa italiana arriva dal .po (msgcmp la pretende tradotta, a differenza di Author e Plugin URI).
    • I messaggi di log_debug() sono ora in inglese e restano fuori da gettext: sono diagnostica per il log, non testo d'interfaccia.
    • readme.txt: Tested up to portato a 7.1 (Plugin Check segnalava 7.0 come non piu' attuale).

    Why

    • Il plugin era interamente in italiano hardcoded: 2 sole chiamate a __() su 1565 righe. Chiunque non parli italiano vedeva un'interfaccia italiana, e non c'era modo di tradurla.
    • La traduzione it_IT riproduce alla lettera i testi della 2.10.0: l'interfaccia in italiano resta identica, così qualsiasi differenza visibile e' un bug e non una scelta estetica.

    Verified

    • wp i18n make-pot senza warning; msgfmt --check pulito; msgcmp segnala solo Plugin URI, Author e Author URI, le uniche voci ammesse come non tradotte.
    • Caricamento reale del .mo in WordPress via wp eval: le 77 stringhe rispondono in italiano.
    • Plugin Check 2.1.0: nessun errore di i18n o di escaping.
    Downloads
  • v2.10.0 3ae1eabcad

    v2.10.0
    All checks were successful
    Auto Release on version bump / release (push) Successful in 6s
    Details
    Stable

    Ghost released this 2026-06-15 22:34:46 +02:00 | 12 commits to main since this release

    Added

    • Retry automatico sui HTTP 5xx in EG_Forgejo_API::api_get_raw(): fino a 3 tentativi con backoff lineare (250 ms × tentativo). Risolve i 503 transitori che eg-forgejo-updater riceveva durante il burst di richieste al pool reverse proxy saturato.
    • Property privata last_status_code nella classe API + getter get_last_status_code().
    • Colonna Stato dell'admin: 4 messaggi distinti basati sull'HTTP code memorizzato nel transient _failed:
      • HTTP 404 — file/branch errato (rosso): config sbagliata (remote_file, branch, nome repo)
      • HTTP 401 / 403 — token rifiutato (rosso): token Forgejo non valido o repo fuori dallo scope
      • HTTP 5xx — server occupato (giallo): outage Forgejo transitorio
      • Errore di rete (giallo): timeout/DNS
        Prima la colonna mostrava sempre lo stesso ⚠ Repo non raggiungibile qualunque fosse la causa.

    Changed

    • Il transient sentinel di errore ora ha struttura ['_failed' => true, 'http' => int] invece di ['_failed' => true]. I caller della logica is_array($cached) && isset($cached['_failed']) continuano a funzionare invariati.

    Why

    • Il fallimento singolo su 5xx (visibile nei log Query Monitor durante un burst di check) non perdeva update — il check successivo riprovava — ma generava rumore. Il retry locale dentro api_get_raw() lo elimina prima che diventi rumore esterno.
    • Il messaggio Stato generico non aiutava a diagnosticare i veri errori di configurazione (404 su remote_file errato). Ora distingue.
    Downloads