Il #problemino (tra i tanti!) delle #webapp è che saranno anche facili da #archiviare o #clonare spesso, ma non per questo anche semplici… (o per caso non sono neppure facili e la mia #esperienza mi fa sottovalutare la cosa?) 😫
🅰️ Per quelle meno complesse, il metodo migliore è senza dubbio un bel wget -kp $URL, cioè scaricare la pagina #HTML con tutte le sue risorse collegate, e convertire i link da assoluti a relativi.
🅱️ Quel #metodo però non è a conoscenza di tutte le risorse caricate dinamicamente, cioè dichiarate in posti diversi dall’HTML. Per prendere anche quelle (ed è spesso necessario, tutte le app moderne caricano roba così), bisogna aprire la app nel #browser, e guardare le richieste di #rete che macina con il normale uso.
1️⃣ A questo punto, si può usare la funzione del browser per esportare le richieste in formato HAR, e poi tool come har-extractor o Har Extractor Online per ricavare i file effettivi da quel blob.
Ho notato però che Firefox in alcune situazioni genera #HAR corrotti (2 giochi fatti in Phaser avevo provato a scaricare, ed una volta estratti gli script tiravano errori; ho riprovato con Chromium, ed è andato tutto liscio), quindi a prescindere io userei l’altro#navigatore per questa cosa. 🥴
Poi, non ho ben capito se per via di come il file HAR in sé è generato, se come quegli #strumenti lo interpretano, o un misto delle cose, ma le risorse cross-domain (e credo anche caricate da iframe?) tendono a non venir estratte, quindi si deve andare poi a pescarle prelevando l’URL di ognuna a manina dai DevTools già aperti… 🤧
🆎 Si potrebbero usare primo e secondo metodo insieme in linea di principio (copiando i file del primo passaggio su quelli del secondo, sovrascrivendo gli esistenti), ma nella pratica è inutile… se c’erano link assoluti da convertire in relativi nell’HTML, con spaventosa probabilità questi sono presenti anche nel #JavaScript o chissà dove, per cui, dato che bisognerà comunque andare a mano a modificarli da qualche parte, 1 o 2 file in più non cambiano (spesso) nulla.
2️⃣ Se si è usato il secondo metodo, bisogna a questo punto effettivamente verificare che i link siano tutti corretti, le #risorse effettivamente scaricate, e la app funzionante indipendentemente dal dominio originale… il modo più efficiente che ho trovato è aprire già da subito un webserver locale sui file, navigarci nel browser, e controllare sia che tutto funzioni nel pratico, sia che tutte le #richieste di rete per risorse effettive (ossia, non contano chiamate di telemetria o simili) vadano al mio #server, anziché al dominio originale (attivando la colonna omonima della tabella nei #DevTools lo si vede a colpo d’occhio).
Quando ci sono richieste che falliscono o che vanno su altri server, bisogna capire da dove nel codice queste partono, e fare le opportune #modifiche per usare URL relativi. Quelle che partono dall’HTML o dal CSS (turns out, non molte, altrimenti avremmo usato direttamente wget) sono appunto una scemenza da sistemare… ma quando partono da #script, c’è poco da fare, con l’aiuto del debugger del browser (di nuovo, meglio Chromium, perché de-mininifica il JavaScript aggiungendo whitespace in automatico) si va a capire da che punto partono, e in base alla situazione si valuta che modifiche fare al #codice. Poi, si testa ancora, e ancora si applicano #fix, finché tutto non funziona. ♻️
In genere questo non è un problema, e anche per app più ostiche (come quella che ho ricaricato sulla #SalaMuseoGames ieri, Little Alchemy 2) si fa tutto in un quarto d’ora ben ristretto. Tuttavia, bisogna fare attenzione a quei programmi che caricano le risorse man mano che ne hanno bisogno e non tutto subito (in genere, maggior parte dei giochi, oppure parecchie #app React)… lì si può potenzialmente perdere un bel po’ di tempo, perché bisogna mettersi ad usare il #software raggiungendo idealmente il 100% del codice; cioè, cliccare tutti i bottoni, usare qualunque azione, giocare tutti i livelli… fino ad ora non ho mai incontrato #ostacoli, ma se succede, l’unica è navigare tra il codice già scaricato per vedere cos’è che manca (da qualche parte ci sono scritti i nomi delle risorse ancora da scaricare, per ovvi motivi). 🗡️
🔚 Aggiustamenti finali: in base alla situazione, vanno fatte altre modifiche al source per ovviare a #problemi banali ma frequenti. La maggior parte riguardano i domini, che in certi casi sono hardcodati, e quindi o ci sono iframe che comunicano con la Messaging API e gli va cambiato il dominio (come per il gioco di ieri), o c’è del DRM che ostacola il #rehosting (come il giochino dell’altro ieri) ecc… con #pazienza si risolve tutto.
E alla fine di tutto, una cosa che mi piace fare ma che non sarebbe obbligatoria, è disattivare tutte le componenti potenzialmente dannose dell’ #applicazione, ossia commentare via eventuali inclusioni e chiamate a sistemi di analitiche o pubblicità. 🚯
Un po’ di #rosik e #delusione ora che mi rendo conto che la #ricerca di #WordPress non è poi così tanto epica e funzionale come speravo, credevo, e dicevo… rimane comunque mooolto meglio di quella di Telegram, su questo punto ci rimango perché lo avevo detto con cognizione di causa, e perché su quella #piattaforma la ricerca di #messaggi specifici (che ricordiamo, non ha operazioni avanzate) fa spesso così incredibilmente cilecca; però ecco, migliore non vuol dire perfetto. Ci sono due #mancanze principali: il fatto che la ricerca non sia veramente agile, e non aggiorni i risultati immediatamente durante l’input, ma bisogna sempre ricevere la pagina nuova dal server, e poi il fatto che sia limitata in termini di #filtraggio dei #dati. 🦍
Il primo #problema direi che almeno un pochino l’ho risolto installando semplicemente il plugin Relevanssi Live Ajax Search; ho anche modificato il codice in relevanssi-live-ajax-search/templates/search_results.php, modificando l’HTML sotto il blocco the_post(); per far apparire anche un estratto del contenuto di ogni risultato, aggiungendo <?php the_excerpt(); ?>, che avere solo il titolo non è cosa buona (alcuni miei post neanche lo hanno il titolo). ☢️
Quello che mi fa impazzire è il secondo! Ho cercato e provato tanti #plugin, ma nessuno fa cosa mi serve, cioè #filtrare i #risultati con #query complesse includendo ed escludendo certi termini, specificando magari anche il tempo, e così via. Insomma, vorrei avere una ricerca simile a quella che Twitter ha da un secolo, o che, addirittura, ormai anche Mastodon ha (seppur con alcune sue limitazioni arbitrarie di design, che personalmente meh, però sul livello tecnico è ottima)! Su Twitter ricordo che si potessero usare operatori logici AND e OR per formare #richieste molto complesse, mentre su Mastodon vedo sicuramente che si possono usare i simboli più (+) e meno (-) per forzare l’inclusione o l’esclusione di alcune #parole, oltre ad esserci #filtri specifici per il prima o dopo una data, ed altre robe. 👑
Il vantaggio di un normale sito web è che almeno posso #arrangiare con motori di ricerca generali quando quello integrato sul mio non mi basta (ammesso che il sito non sia bistrattato dagli algoritmi e dai crawler, fortunatamente questo su dominio Altervista è indicizzato), ma fa #schifo: non è detto che esca davvero tutto in ordine cronologico come a me serve, e non escono nuovi #post se non dopo ore o giorni. 🐌
Dovrò vedere come giostrarmela, perché al momento per quanto io personalmente riesco a ritrovare singoli post vecchi per qualunque scopo, mi è impossibile condividerne molti insieme con la semplicità che vorrei: 1 solo link verso una pagina di ricerca con una comanda appositamente costruita. 🦴