Re: apache php e problemi nell' upload dei file
On Wed, 17 May 2023, Lorenzo Breda wrote: Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli On Wed, 17 May 2023, Giuseppe Naponiello wrote: (…)mi permette di costruire una piattaforma ben strutturata e con interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue Le interfacce fighe sono il sistema migliore per creare sistemi instabili, esigenti di risorse e lente. Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da che devi fare. Che portino a sistemi instabili non lo trovo particolarmente vero (certo, sono una cosa in più da gestire, ma se si deve si deve), che richiedano maggiori risorse dipende quali risorse. Di solito i sistemi per "interfacce fighe" riducono di molto la necessità di risorse di rete mentre aumentano la necessità di risorse di calcolo sul client. A volte è follia, a volte è fondamentale. Basta sapere cosa si sta facendo e perché. ed è giusto questo: di solito i limiti sono lato client o lato rete, lato server solo in certi casi, se davvero molto carichi o che necessitano di risposta in tempo quasi reale. Ti faccio due esempi che supportano la mia opinione: Un sito che per rispondere a un messaggio, dove basterebbe un form con un campo txt e un paio di checkbox, se non li hai nella cache ti carica circa 1.7 MB di script che non fanno assolutamante nulla se non abilitare un editor che ti crea più problemi che vantaggi: mi trovo spesso in un luogo servito da un ripetitore locale (perché in zona d'ombra) che al massimo offre GPRS. il risultato è che caricando la pagina si ottine un timeout, rendendo impossibile l'accesso. un altro sito che fa le stesse cose, ma ottimizzato per light client funziona perfettamente e senza attese. Altro sito "fancy": quando fai una ricerca al terzo carattere ti mostra una lista di tutti i valori possibili. Bello, solo che se non appare nei primi 20 non hai la possibilità di andare oltre e devi continuare a scrivere senza suggerimenti sperando di beccare quello giusto, e quello che è peggio non ti dice se la lista è completa o non ce ne sono altri, di fatto nulla più che se avessi inserito alcuni caratteri e poi premuto "search" (in quel caso te ne fa vedere 20, ma esplicitamente di dice se ce ne sono altri, invitandoti a aggiungere altri caratteri) -- Leonardo Boselli Firenze, Toscana, Europa
Re: apache php e problemi nell' upload dei file
Ok, giusto, allora chiedo scusa e faccio un mea culpa, diciamo allora che in ambito web php è ancora il più usato? Ovviamente non prendo in considerazioni webapp ibride. Non ho scritto che non ci sono alternative ma che non ce ne sono tante, sinceramente ho sempre creduto che ASP.NET fosse ormai in disuso e che Java fosse troppo "avida di risorse", quindi non raccomandabile per progetti di piccola e media grandezza/complessità (almeno così me l'hanno sempre raccontata). Comunque grazie davvero, è sempre bello ascoltare pareri diversi, impari sempre qualcosina in più...dai fino ad ora siamo stati bravi a non far degenerare la discussione!!! 😂 Il 17/05/23 17:16, Federico Di Gregorio ha scritto: On 17/05/23 16:54, Giuseppe Naponiello wrote: In ogni caso, i framework php hanno zero a che fare con le questioni di interfaccia, php è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue). Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di vue.js, forse la libreria più leggera in circolazione...fatto sta che se hai bisogno di PHP non puoi prescindere da librerie javascript, a meno di rinunciare alla comodità delle funzioni asincrone. Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo sul fatto che se vuoi una piattaforma web solida, complessa, sicura e robusta non ci sono tante alternative al nostro caro e vecchio php...si ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto ciò che ha a che fare con node ecc. Dire che non ci sono alternative è veramente sbagliato. Diciamo che se parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io, che supportino tutte le tecnologie moderne, dai websocket in su) ci sono almeno due alternative: Java (con tutte le sue varianti di librerie e framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime. federico
Re: apache php e problemi nell' upload dei file
Il mer 17 mag 2023, 17:16 Federico Di Gregorio ha scritto: > > Dire che non ci sono alternative è veramente sbagliato. Diciamo che se > parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io, > che supportino tutte le tecnologie moderne, dai websocket in su) ci sono > almeno due alternative: Java (con tutte le sue varianti di librerie e > framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime. > Esatto, Java soprattutto con Spring e C#, ma anche Swift non è da buttare fatte le dovute considerazioni. E non butterei alle ortiche Node.js, suvvia. -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
On 17/05/23 16:54, Giuseppe Naponiello wrote: In ogni caso, i framework php hanno zero a che fare con le questioni di interfaccia, php è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue). Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di vue.js, forse la libreria più leggera in circolazione...fatto sta che se hai bisogno di PHP non puoi prescindere da librerie javascript, a meno di rinunciare alla comodità delle funzioni asincrone. Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo sul fatto che se vuoi una piattaforma web solida, complessa, sicura e robusta non ci sono tante alternative al nostro caro e vecchio php...si ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto ciò che ha a che fare con node ecc. Dire che non ci sono alternative è veramente sbagliato. Diciamo che se parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io, che supportino tutte le tecnologie moderne, dai websocket in su) ci sono almeno due alternative: Java (con tutte le sue varianti di librerie e framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime. federico -- Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it Il panda ha l'apparato digerente di un carnivoro (e.g., di un orso). Il panda ha scelto di cibarsi esclusivamente di germogli di bambù. Quindi, il panda è l'unico animale vegano del pianeta. Il panda merita di estinguersi. -- Maria, Alice, Federico
Re: apache php e problemi nell' upload dei file
In ogni caso, i framework php hanno zero a che fare con le questioni di interfaccia, php è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue). Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di vue.js, forse la libreria più leggera in circolazione...fatto sta che se hai bisogno di PHP non puoi prescindere da librerie javascript, a meno di rinunciare alla comodità delle funzioni asincrone. Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo sul fatto che se vuoi una piattaforma web solida, complessa, sicura e robusta non ci sono tante alternative al nostro caro e vecchio php...si ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto ciò che ha a che fare con node ecc. Il 17/05/23 15:25, Lorenzo Breda ha scritto: Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli ha scritto: On Wed, 17 May 2023, Giuseppe Naponiello wrote: > (…)mi permette di costruire una piattaforma ben strutturata e con interfacce > fighe, magari usando Vue, ma allora devo imparare anche Vue Le interfacce fighe sono il sistema migliore per creare sistemi instabili, esigenti di risorse e lente. Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da che devi fare. Che portino a sistemi instabili non lo trovo particolarmente vero (certo, sono una cosa in più da gestire, ma se si deve si deve), che richiedano maggiori risorse dipende quali risorse. Di solito i sistemi per "interfacce fighe" riducono di molto la necessità di risorse di rete mentre aumentano la necessità di risorse di calcolo sul client. A volte è follia, a volte è fondamentale. Basta sapere cosa si sta facendo e perché. In ogni caso, i framework php hanno zero a che fare con le questioni di interfaccia, php è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue). -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
On 5/17/23 14:06, Diego Zuccato wrote: [...] Esattamente quello che dicevo: oltre al linguaggio, che comunque devi conoscere, devi studiarti anche il framework. Tra l'altro prima stavo proprio creando un'app di esempio con Laravel e ha iniziato malissimo: due warning per componenti non mantenuti. Col primo comando di esempio! :( questo secondo me è il problema del framework, se fai software che deve durare anni, che devi manutenere, poi aggiornarlo è un bagno di sangue fra componenti non più mantenuti, obsoleti... poi c'è sempre il timore che il framework muoia... ho visto però che laravel resiste dal 2011, 12 anni come non sentirli mi sembra, viene voglia in effetti di provarlo. Piviul
Re: apache php e problemi nell' upload dei file
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli ha scritto: > On Wed, 17 May 2023, Giuseppe Naponiello wrote: > > (…)mi permette di costruire una piattaforma ben strutturata e con > interfacce > > fighe, magari usando Vue, ma allora devo imparare anche Vue > > Le interfacce fighe sono il sistema migliore per creare sistemi > instabili, esigenti di risorse e lente. > Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da che devi fare. Che portino a sistemi instabili non lo trovo particolarmente vero (certo, sono una cosa in più da gestire, ma se si deve si deve), che richiedano maggiori risorse dipende quali risorse. Di solito i sistemi per "interfacce fighe" riducono di molto la necessità di risorse di rete mentre aumentano la necessità di risorse di calcolo sul client. A volte è follia, a volte è fondamentale. Basta sapere cosa si sta facendo e perché. In ogni caso, i framework php hanno zero a che fare con le questioni di interfaccia, php è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue). -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Il giorno mer 17 mag 2023 alle ore 13:02 Leonardo Boselli ha scritto: > > Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi > permettere inefficienze, per cui sempre basso livello. figuriamoci un > framework, Se si cerca l'efficienza, php va buttato per intero :P Un framework ne aggiunge davvero poca di inefficienza (ne toglie se uno programma da cani, cosa non infrequente nell'ambito). > che ho ancora da trovarne uno ben documentato. Laravel. Questo comunque è un problema pure nel mondo dei linguaggi di programmazione, purtroppo. > personalmente è meno difficile intendere un programma scritto tutto con le > funzioni standard che con un framework che uno non conosce. > E non lo dico solo io ... > Su questo dissento decisamente. È meno difficile intendere un programma scritto in un linguaggio che conosci che uno scritto in un linguaggio che non conosci, ma questo non ha assolutamente nulla a che fare con i framework. Conoscendo sia vanilla che un framework non c'è gran differenza di leggibilità, e dove c'è è decisamente a vantaggio del framework molto spesso (Laravel ad esempio fa largo uso di un approccio funzionale in cui php è deficitario e che è molto più leggibile). -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Finora mi pare siamo stati tutti civili e maturi, sarà l'influenza Debian (per la quale sarà meglio che non creino vaccini!) :) Esattamente quello che dicevo: oltre al linguaggio, che comunque devi conoscere, devi studiarti anche il framework. Tra l'altro prima stavo proprio creando un'app di esempio con Laravel e ha iniziato malissimo: due warning per componenti non mantenuti. Col primo comando di esempio! :( Poi l'annoso problema di dover avere una parte al di fuori della webroot (già incompatibile con molti servizi di hosting) e oltretutto con relative path fissati! Certo, si può spesso giocare sulla config del server web (se lo si gestisce in casa), ma non è proprio una cosa simpatica. Quando poi ci si inizia a mettere di mezzo JS la complessità esplode, soprattutto se si vogliono cose astruse come la graceful degradation (qualcuno vuole provare a navigare qualche sito con Arachne? O:) ). Vabbè, mi ritiro nella mia grotta a cercare di lisciare qualche spigolo a questa cosa... credo la chiamerò ruota :) Diego Il 17/05/2023 13:12, Giuseppe Naponiello ha scritto: È una di quelle cose che rischia di scatenare flame, spero non avvenga. Era il mio timore iniziale, ma confido nella maturità e nell'approccio "scientifico" alla discussione dei membri del gruppo! 😁 In generale sono d'accordo con te, dipende davvero cosa ci fai. In questo momento mi è stato chiesto di sviluppare dei moduli per un CMS "semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi piace assolutamente ma questo è un altro problema! Il fatto è che la tecnologia sta facendo davvero passi da gigante, e spesso questo complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un ambiente più javascript (e lì ti ci puoi perdere tra le mille possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi convenga utilizzare Laravel...d'altra parte Laravel mi permette di costruire una piattaforma ben strutturata e con interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin! Il 17/05/23 10:32, Lorenzo Breda ha scritto: Il mer 17 mag 2023, 09:15 Giuseppe Naponiello ha scritto: Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno È una di quelle cose che rischia di scatenare flame, spero non avvenga. Da persona che ci lavora, trovo che in generale dipende da cosa ci fai, se tiri su qualche script per hobby probabilmente non ha molto senso, se invece fai applicazioni di livello professionale è imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit testing and esempio sia gratis, eppure è fondamentale e si fa. Il costo di formazione è l'unico vero svantaggio. La questione della sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un framework rende un'applicazione molto più sicura, altro che meno sicura. C'è più gente a trovar falle, ci sono protocolli di testing rigidi, la risoluzione delle falle è centralizzata. Certo, le falle una volta trovate sono note, ma non credo di dover spiegare qui che la security through obscurity sia un'illusione. Un framework moderno, persino in PHP, non offre particolari problemi di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 8.2 senza particolari sforzi. I framework semplificano anche questo, dato che raramente si utilizzano le funzioni "di PHP" più soggette a cambiamenti ma si usa la loro versione fornita dal framework, che non cambia facilmente API (e quando lo fa è ben documentato nella sezione upgrading della documentazione). Persino sa chi fa solo script, consiglio Laravel Zero. -- Lorenzo Breda -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: apache php e problemi nell' upload dei file
Il 17/05/2023 13:42, Leonardo Boselli ha scritto: (…)mi permette di costruire una piattaforma ben strutturata e con interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue Le interfacce fighe sono il sistema migliore per creare sistemi instabili, esigenti di risorse e lente. pero' hai sempre l'utonto davanti che si lamenta se l'iconcina non e' tre pixel piu' sopra dell'altra, con i colori fighi e le form perfette purtroppo. Mauro
Re: apache php e problemi nell' upload dei file
On Wed, 17 May 2023, Giuseppe Naponiello wrote: (…)mi permette di costruire una piattaforma ben strutturata e con interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue Le interfacce fighe sono il sistema migliore per creare sistemi instabili, esigenti di risorse e lente. -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it
Re: apache php e problemi nell' upload dei file
On Wed, 17 May 2023, Giuseppe Naponiello wrote: Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno (…) Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato ha scritto: Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o più), (…) e chi viene per aiutarti (lo sbarbatello che "sa programmare il web") non conosce quel framework perché troppo vecchio e fuori moda e quindi comunque deve studiarlo da zero. Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi permettere inefficienze, per cui sempre basso livello. figuriamoci un framework, che ho ancora da trovarne uno ben documentato. personalmente è meno difficile intendere un programma scritto tutto con le funzioni standard che con un framework che uno non conosce. E non lo dico solo io ... -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it tel:+393287329225
Re: apache php e problemi nell' upload dei file
È una di quelle cose che rischia di scatenare flame, spero non avvenga. Era il mio timore iniziale, ma confido nella maturità e nell'approccio "scientifico" alla discussione dei membri del gruppo! 😁 In generale sono d'accordo con te, dipende davvero cosa ci fai. In questo momento mi è stato chiesto di sviluppare dei moduli per un CMS "semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi piace assolutamente ma questo è un altro problema! Il fatto è che la tecnologia sta facendo davvero passi da gigante, e spesso questo complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un ambiente più javascript (e lì ti ci puoi perdere tra le mille possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi convenga utilizzare Laravel...d'altra parte Laravel mi permette di costruire una piattaforma ben strutturata e con interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin! Il 17/05/23 10:32, Lorenzo Breda ha scritto: Il mer 17 mag 2023, 09:15 Giuseppe Naponiello ha scritto: Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno È una di quelle cose che rischia di scatenare flame, spero non avvenga. Da persona che ci lavora, trovo che in generale dipende da cosa ci fai, se tiri su qualche script per hobby probabilmente non ha molto senso, se invece fai applicazioni di livello professionale è imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit testing and esempio sia gratis, eppure è fondamentale e si fa. Il costo di formazione è l'unico vero svantaggio. La questione della sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un framework rende un'applicazione molto più sicura, altro che meno sicura. C'è più gente a trovar falle, ci sono protocolli di testing rigidi, la risoluzione delle falle è centralizzata. Certo, le falle una volta trovate sono note, ma non credo di dover spiegare qui che la security through obscurity sia un'illusione. Un framework moderno, persino in PHP, non offre particolari problemi di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 8.2 senza particolari sforzi. I framework semplificano anche questo, dato che raramente si utilizzano le funzioni "di PHP" più soggette a cambiamenti ma si usa la loro versione fornita dal framework, che non cambia facilmente API (e quando lo fa è ben documentato nella sezione upgrading della documentazione). Persino sa chi fa solo script, consiglio Laravel Zero. -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Neanche io vado matto per PHP, ma alla fine fa il suo sporco lavoro. Come il C, si può usare in modo pulito o lercio. Sarà che oramai tendo all'old (non solo school :) ) ma fatico sempre più a capire gli assunti alla base di certi framework. Altre soluzioni (Python e RubyOnRails, per es.) IMO hanno dalla loro una maggiore pulizia, ma presentano un grosso scoglio iniziale (studiare il linguaggio, studiare le convenzioni, studiare le librerie) e oltretutto si "sposano" malissimo a sistemi di shared virtual hosting (nel mio caso ISPConfig, ma in ogni caso è molto più difficile trovare un servizio di free hosting che li supporti, mentre praticamente tutti offrono PHP). Diego Il 17/05/2023 09:22, Federico Di Gregorio ha scritto: On 17/05/23 09:15, Giuseppe Naponiello wrote: Non vorrei andare off-topic ma trovo questo discorso molto interessante e mi piacerebbe sentire la vostra opinione. Negli anni ho provato ad usare vari framework, sia php che javascript, ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando con vari programmatori ho notato che c'è un grande gruppo di sostenitori di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo "old school", tanto (secondo loro) un framework php usa comunque le funzioni di php ma è più complesso ed ha più vulnerabilità. Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno Più che altro c'è un intero mondo al di fuori del PHP (che io personalmente considero uno dei più orrorifici linguaggi di programmazione mai inventati). Il mi consiglio è, anche solo per cultura personale, di provare a dargli un'occhiata (poi puoi sempre decidere di rimanere col PHP). federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: apache php e problemi nell' upload dei file
Il mer 17 mag 2023, 09:22 Federico Di Gregorio ha scritto: > > Più che altro c'è un intero mondo al di fuori del PHP (che io > personalmente considero uno dei più orrorifici linguaggi di > programmazione mai inventati). > C'è sempre JavaScript. Il mi consiglio è, anche solo per cultura personale, di provare a dargli > un'occhiata (poi puoi sempre decidere di rimanere col PHP). > Da programmatore prevalentemente PHP concordo, ma dico anche che pur con i suoi problemi residui php8 è un altro linguaggio rispetto a quello che ha presente il grosso dei critici di PHP. -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello ha scritto: > > Pur essendo io "old school" sono molto incuriosito ma ammetto la mia > ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero > la pena investire tempo per imparare ad usarne uno È una di quelle cose che rischia di scatenare flame, spero non avvenga. Da persona che ci lavora, trovo che in generale dipende da cosa ci fai, se tiri su qualche script per hobby probabilmente non ha molto senso, se invece fai applicazioni di livello professionale è imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit testing and esempio sia gratis, eppure è fondamentale e si fa. Il costo di formazione è l'unico vero svantaggio. La questione della sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un framework rende un'applicazione molto più sicura, altro che meno sicura. C'è più gente a trovar falle, ci sono protocolli di testing rigidi, la risoluzione delle falle è centralizzata. Certo, le falle una volta trovate sono note, ma non credo di dover spiegare qui che la security through obscurity sia un'illusione. Un framework moderno, persino in PHP, non offre particolari problemi di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 8.2 senza particolari sforzi. I framework semplificano anche questo, dato che raramente si utilizzano le funzioni "di PHP" più soggette a cambiamenti ma si usa la loro versione fornita dal framework, che non cambia facilmente API (e quando lo fa è ben documentato nella sezione upgrading della documentazione). Persino sa chi fa solo script, consiglio Laravel Zero. -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
On 17/05/23 09:15, Giuseppe Naponiello wrote: Non vorrei andare off-topic ma trovo questo discorso molto interessante e mi piacerebbe sentire la vostra opinione. Negli anni ho provato ad usare vari framework, sia php che javascript, ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando con vari programmatori ho notato che c'è un grande gruppo di sostenitori di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo "old school", tanto (secondo loro) un framework php usa comunque le funzioni di php ma è più complesso ed ha più vulnerabilità. Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno Più che altro c'è un intero mondo al di fuori del PHP (che io personalmente considero uno dei più orrorifici linguaggi di programmazione mai inventati). Il mi consiglio è, anche solo per cultura personale, di provare a dargli un'occhiata (poi puoi sempre decidere di rimanere col PHP). federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra
Re: apache php e problemi nell' upload dei file
Non vorrei andare off-topic ma trovo questo discorso molto interessante e mi piacerebbe sentire la vostra opinione. Negli anni ho provato ad usare vari framework, sia php che javascript, ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando con vari programmatori ho notato che c'è un grande gruppo di sostenitori di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo "old school", tanto (secondo loro) un framework php usa comunque le funzioni di php ma è più complesso ed ha più vulnerabilità. Pur essendo io "old school" sono molto incuriosito ma ammetto la mia ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la pena investire tempo per imparare ad usarne uno -beppe- Il 16/05/23 23:33, Paride Desimone ha scritto: Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato ha scritto: Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o più), poi regolarmente ci si scontra con incompatibilità (era per PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di dipendenze infinite (con relativi problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa programmare il web") non conosce quel framework perché troppo vecchio e fuori moda e quindi comunque deve studiarlo da zero. Per non parlare di un problema di sicurezza: un bug nel framework ti lascia esposto a molti più attacchi automatici. Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una nuova ruota. /paride
Re: apache php e problemi nell' upload dei file
Ok, smanettando mi sono accorto che il problema era davvero "banale".
Il problema del caricamento file non era dovuto (nel mio caso) a
qualcosa di particolarmente strano, non era legato alla direttiva
PrivateTmp (ho provato a settarla false ma non è cambiato niente) e non
era legato all'encoding del form...molto più semplicemente
move_upload_file non riusciva a spostare il file dalla tmp alla cartella
definitiva perché, ad un certo punto dello sviluppo e in seguito a
chissà quale aggiornamento, la cartella di destinazione deve essere
scritta con percorso assoluto e non più relativo, come avevo sempre
fatto in passato.
Mi dispiace avervi fatto perdere tempo per una cagata simile ma la
faccenda dei percorsi non l'ho proprio presa in considerazione visto che
ha sempre funzionato!
-beppe-
Il 15/05/23 17:12, Federico Di Gregorio ha scritto:
On 15/05/23 17:04, Giuseppe Naponiello wrote:
vecchio problema a cui non ho trovato una soluzioni "pulite".
Con l'introduzione di systemd i browser (e tutte le altre
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre
perché tanto lo sapete meglio di me di sicuro.
Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il file
da spostare in /tmp/ e non in systemd
sys_get_temp_dir e altre funzioni simili di php mi danno come
risultato sempre /tmp/, se però provo "new
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive
correttamente in systemd-private.xxx..xyz/tmp/
In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non
specificato, di default punta alla cartella tmp di sistema. Non ho
provato a modificarlo perché ho letto da qualche parte che non è la
soluzione più corretta (ma non ricordo perché).
...ma allora, come diavolo faccio a far caricare agli utenti i loro
file, visto che i vecchi script non funzionano più?
Sembra che php venga eseguito in un processo differente da quello di
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi
dirci se sul sistema c'è anche un service che fa partire PHP? Come
viene gestito?
federico
Re: apache php e problemi nell' upload dei file
Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato ha scritto: > >Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 >anni o più), poi regolarmente ci si scontra con incompatibilità (era per >PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che >però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti >introduce dei bug subdoli), catene di dipendenze infinite (con relativi >problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa >programmare il web") non conosce quel framework perché troppo vecchio e fuori >moda e quindi comunque deve studiarlo da zero. > >Per non parlare di un problema di sicurezza: un bug nel framework ti lascia >esposto a molti più attacchi automatici. > Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una nuova ruota. /paride -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Re: apache php e problemi nell' upload dei file
Ciao,
Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto:
[...]
> sys_get_temp_dir e altre funzioni simili di php mi danno come risultato
> sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt",
> "a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/
Puoi confermare che lo trovi in /tmp/systemd-/tmp e non in
/tmp/systemd- (senza l'ulteriore /tmp finale)?
Ciao,
Giuseppe
Re: apache php e problemi nell' upload dei file
Il giorno mar, 16/05/2023 alle 12.54 +0200, Giuseppe Sacco ha scritto: > Ciao Giuseppe, [...] > Per come la vedo io, il sistema dovrebbe funzionare in questo modo: > apache2 > parte con una /tmp sempre diversa perché nel file > /lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo > punto, quando systemd fa partire il processo di apache, gli imposta una > specie di file system privato (un namespace) nel quale il path /tmp/ > corrisponde ad una directory che dal punto di vista globale è > /tmp/systemd A quel punto, qualsiasi altro processo avviato da > apache2 > vedrà la stessa /tmp. [...] Puoi anche fare la controprova disabilitando PrivateTmp per apache2 e verificando che questo sia proprio la causa del problema. Per disabilitarlo, crea il file /etc/systemd/system/apache2.service.d/noprivatetmp.conf con le due righe seguenti: [Service] PrivateTmp=false e poi dai i due comandi, da root, per rileggere i file e riavviare apache2: systemctl daemon-reload systemctl restart apache2 Ciao, Giuseppe
Re: apache php e problemi nell' upload dei file
Beh, anche le mie classi di interfacciamento al db fanno abbastanza ridere, di base (p.e. le query mi ritornano comunque un array coi risultati, no iteratori, ho preferito la semplicità, non avendo tabelle enormi). Però mi è riuscita direi abbastanza bene la gestione delle join :) Il problema è che gli applicativi o sono fire&forget o tendono a crescere stratificandosi, o partono come F&F e dopo qualche anno te li fanno estendere (meno male che avevo previsto una discreta modularità in partenza :) ). Purtroppo i framework che avevo guardato al tempo mi avrebbero richiesto, per iniziare ad usarli decentemente, più tempo di quello che avevo a disposizione per realizzare l'applicativo... Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o più), poi regolarmente ci si scontra con incompatibilità (era per PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di dipendenze infinite (con relativi problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa programmare il web") non conosce quel framework perché troppo vecchio e fuori moda e quindi comunque deve studiarlo da zero. Per non parlare di un problema di sicurezza: un bug nel framework ti lascia esposto a molti più attacchi automatici. Diego Il 16/05/2023 12:56, Giuseppe Naponiello ha scritto: oddio che bello, non sono solo!!! Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) che i vari framework sfruttano davvero poco le potenzialità di un db come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco a fondo le potenzialità di un framework come laravel Il 16/05/23 11:47, Diego Zuccato ha scritto: Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi sono ritrovato che era insufficiente o troppo pesante per le mie esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a capire come usarlo sarebbe già stato obsoleto). Visto che lo sviluppo di applicativi web è per me molto secondario, ho finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che alla fine è compatibile con tutto (da 5.6 a 8.1) :) Sarebbe però interessante un confronto dei vari framework maturi in circolazione. Diego Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto: Ciao Lorenzo, Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da modificare!!! La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Passando i dati (e il file) via FormData() non mi sembrava fosse necessario specificare l'enctype del form, comunque molto interessante, approfondisco! Grazie Il 16/05/23 10:44, Lorenzo Breda ha scritto: Il lun 15 mag 2023, 17:04 Giuseppe Naponiello ha scritto: Il problema è che non trovo una soluzione per caricare un file da interfaccia web in una cartella del server: con fetch API e formData mando il file da caricare al server, che con un funzione php dovrebbe spostarlo da tmp alla destinazione finale con la classica funzione "move_upload_file", l'errore, come previsto, è che php cerca il file da spostare in /tmp/ e non in systemd Buongiorno, Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta. La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Buona giornata! -- Lorenzo Breda -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: apache php e problemi nell' upload dei file
oddio che bello, non sono solo!!! Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) che i vari framework sfruttano davvero poco le potenzialità di un db come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco a fondo le potenzialità di un framework come laravel Il 16/05/23 11:47, Diego Zuccato ha scritto: Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi sono ritrovato che era insufficiente o troppo pesante per le mie esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a capire come usarlo sarebbe già stato obsoleto). Visto che lo sviluppo di applicativi web è per me molto secondario, ho finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che alla fine è compatibile con tutto (da 5.6 a 8.1) :) Sarebbe però interessante un confronto dei vari framework maturi in circolazione. Diego Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto: Ciao Lorenzo, Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da modificare!!! La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Passando i dati (e il file) via FormData() non mi sembrava fosse necessario specificare l'enctype del form, comunque molto interessante, approfondisco! Grazie Il 16/05/23 10:44, Lorenzo Breda ha scritto: Il lun 15 mag 2023, 17:04 Giuseppe Naponiello ha scritto: Il problema è che non trovo una soluzione per caricare un file da interfaccia web in una cartella del server: con fetch API e formData mando il file da caricare al server, che con un funzione php dovrebbe spostarlo da tmp alla destinazione finale con la classica funzione "move_upload_file", l'errore, come previsto, è che php cerca il file da spostare in /tmp/ e non in systemd Buongiorno, Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta. La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Buona giornata! -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Ciao Giuseppe, Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto: > Buongiorno, > vecchio problema a cui non ho trovato una soluzioni "pulite". > > Con l'introduzione di systemd i browser (e tutte le altre applicazioni > che ne usufruiscono) non scrivono più in /tmp/ ma in > /tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre > perché tanto lo sapete meglio di me di sicuro. [...] Per come la vedo io, il sistema dovrebbe funzionare in questo modo: apache2 parte con una /tmp sempre diversa perché nel file /lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo punto, quando systemd fa partire il processo di apache, gli imposta una specie di file system privato (un namespace) nel quale il path /tmp/ corrisponde ad una directory che dal punto di vista globale è /tmp/systemd A quel punto, qualsiasi altro processo avviato da apache2 vedrà la stessa /tmp. Ora, se l'interprete php è quello della libreria di apache, vienne eseguito dallo stesso processo (credo) e quindi vede la stessa /tmp; se invece è un fast cgi, allora comunicano via socket. In questo caso dovresti controllare quale servizio attiva il fast cgi e, a quel punto, hai la possibilità di modificare la /tmp del processo fast cgi in modo che sia la stessa di quello di apache usando il comando JoinsNamespaceOf=apache2.service nel primo dei due. Per capire come apache avvia il php devi controllare il sito che hai configurato. Ciao, Giuseppe
Re: apache php e problemi nell' upload dei file
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi sono ritrovato che era insufficiente o troppo pesante per le mie esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a capire come usarlo sarebbe già stato obsoleto). Visto che lo sviluppo di applicativi web è per me molto secondario, ho finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che alla fine è compatibile con tutto (da 5.6 a 8.1) :) Sarebbe però interessante un confronto dei vari framework maturi in circolazione. Diego Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto: Ciao Lorenzo, Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da modificare!!! La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Passando i dati (e il file) via FormData() non mi sembrava fosse necessario specificare l'enctype del form, comunque molto interessante, approfondisco! Grazie Il 16/05/23 10:44, Lorenzo Breda ha scritto: Il lun 15 mag 2023, 17:04 Giuseppe Naponiello ha scritto: Il problema è che non trovo una soluzione per caricare un file da interfaccia web in una cartella del server: con fetch API e formData mando il file da caricare al server, che con un funzione php dovrebbe spostarlo da tmp alla destinazione finale con la classica funzione "move_upload_file", l'errore, come previsto, è che php cerca il file da spostare in /tmp/ e non in systemd Buongiorno, Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta. La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Buona giornata! -- Lorenzo Breda -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: apache php e problemi nell' upload dei file
Il mar 16 mag 2023, 11:41 Giuseppe Naponiello ha scritto: > Ciao Lorenzo, > > Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni > (lavoro con i framework) > > Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho > provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da > modificare!!! > Un altro mondo davvero. Passando i dati (e il file) via FormData() non mi sembrava fosse necessario > specificare l'enctype del form, comunque molto interessante, approfondisco! > FormData dovrebbe usare l'encoding corretto. Comunque un'occhiata alla request per vedere se c'è tutto dalla, se c'è dovrebbe correttamente funzionare passando come primo parametro il nome effettivo del file: move_uploaded_file($_FILES["nome_campo"]["tmp_name"], $destinazione) -- Lorenzo Breda >
Re: apache php e problemi nell' upload dei file
Ciao Lorenzo, Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da modificare!!! La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Passando i dati (e il file) via FormData() non mi sembrava fosse necessario specificare l'enctype del form, comunque molto interessante, approfondisco! Grazie Il 16/05/23 10:44, Lorenzo Breda ha scritto: Il lun 15 mag 2023, 17:04 Giuseppe Naponiello ha scritto: Il problema è che non trovo una soluzione per caricare un file da interfaccia web in una cartella del server: con fetch API e formData mando il file da caricare al server, che con un funzione php dovrebbe spostarlo da tmp alla destinazione finale con la classica funzione "move_upload_file", l'errore, come previsto, è che php cerca il file da spostare in /tmp/ e non in systemd Buongiorno, Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta. La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Buona giornata! -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
Ciao, Diego le 2 direttive che mi indichi sono commentate anche nel mio caso. Il 16/05/23 10:46, Diego Zuccato ha scritto: Io uso php-fpm e non ha nessun problema a trovare la cartella dove apache mette gli UL... Nel php.ini sys_temp_dir è commentata. Magari verifica anche upload_tmp_dir (anche questa da me è commentata). In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per DavLockDB all'interno dei vhost. Il mio sistema è stato installato seguendo (abbastanza fedelmente) la guida "the perfect server" per ISPConfig3. Diego Il 16/05/2023 09:42, Federico Di Gregorio ha scritto: On 15/05/23 18:53, Giuseppe Naponiello wrote: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Temo di no. Quando Apache viene riavviato la directory usata come /tmp potrebbe cambiare e il PHP non la troverebbe più. federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it.
Re: apache php e problemi nell' upload dei file
Ciao Federico, Quando Apache viene riavviato la directory usata come /tmp potrebbe cambiare e il PHP non la troverebbe più. Infatti, questo era il mio grande dubbio! Il 16/05/23 09:42, Federico Di Gregorio ha scritto: On 15/05/23 18:53, Giuseppe Naponiello wrote: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Temo di no. Quando Apache viene riavviato la directory usata come /tmp potrebbe cambiare e il PHP non la troverebbe più. federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it.
Re: apache php e problemi nell' upload dei file
Ciao Piviul, non sono molto pratico ma non credo tu sia sulla strada giusta io invece sono sicuro di NON essere sulla strada giusta!!! 😅 cat $(ls /etc/apache2/mods-enabled/php*.load) # Conflicts: php5 # Depends: mpm_prefork LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so Il 15/05/23 20:03, Piviul ha scritto: Il 15/05/23 18:53, Giuseppe Naponiello ha scritto: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ dove punta il .load per php? In altre parole posta l'otput di $ cat $(ls /etc/apache2/mods-enabled/php*.load) Piviul
Re: apache php e problemi nell' upload dei file
Io uso php-fpm e non ha nessun problema a trovare la cartella dove apache mette gli UL... Nel php.ini sys_temp_dir è commentata. Magari verifica anche upload_tmp_dir (anche questa da me è commentata). In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per DavLockDB all'interno dei vhost. Il mio sistema è stato installato seguendo (abbastanza fedelmente) la guida "the perfect server" per ISPConfig3. Diego Il 16/05/2023 09:42, Federico Di Gregorio ha scritto: On 15/05/23 18:53, Giuseppe Naponiello wrote: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Temo di no. Quando Apache viene riavviato la directory usata come /tmp potrebbe cambiare e il PHP non la troverebbe più. federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: apache php e problemi nell' upload dei file
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello ha scritto: > Il problema è che non trovo una soluzione per caricare un file da > interfaccia web in una cartella del server: con fetch API e formData > mando il file da caricare al server, che con un funzione php dovrebbe > spostarlo da tmp alla destinazione finale con la classica funzione > "move_upload_file", l'errore, come previsto, è che php cerca il file da > spostare in /tmp/ e non in systemd > Buongiorno, Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella temporanea invece di quella reale è un effetto ottico di systemd, in realtà legge e scrive correttamente in quella giusta. La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova il file caricato" è dovuto al fatto che il form html non ha correttamente settato l'enctype a "multipart/form-data", e quindi invece del file viene caricato il suo nome. Buona giornata! -- Lorenzo Breda
Re: apache php e problemi nell' upload dei file
On 15/05/23 18:53, Giuseppe Naponiello wrote: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Temo di no. Quando Apache viene riavviato la directory usata come /tmp potrebbe cambiare e il PHP non la troverebbe più. federico Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it.
Re: apache php e problemi nell' upload dei file
Il 15/05/23 18:53, Giuseppe Naponiello ha scritto: ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ dove punta il .load per php? In altre parole posta l'otput di $ cat $(ls /etc/apache2/mods-enabled/php*.load) Piviul
Re: apache php e problemi nell' upload dei file
ok, quindi in php.ini devo decommentare la sezione che gestisce la cartella tmp: ; Directory where the temporary files should be placed. ; Defaults to the system default (see sys_get_temp_dir) ;sys_temp_dir = "/tmp" e invece di /tmp inserire il percorso corretto, cioè quello del servizio di apache? Giusto? Il 15/05/23 18:36, mauro morichi ha scritto: dipende tutto da come viene gestito php. Se viene caricato come libreria di apache viene eseguito come apache, se eseguito in fcgi, allora e' un servizio a parte con un suo namespace. Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto: Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe essere legato ad Apache...nel senso che per far ripartire o ricaricare php devo agire sul processo che gestisce Apache.
Re: apache php e problemi nell' upload dei file
dipende tutto da come viene gestito php. Se viene caricato come libreria di apache viene eseguito come apache, se eseguito in fcgi, allora e' un servizio a parte con un suo namespace. Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto: Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe essere legato ad Apache...nel senso che per far ripartire o ricaricare php devo agire sul processo che gestisce Apache.
Re: apache php e problemi nell' upload dei file
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe
essere legato ad Apache...nel senso che per far ripartire o ricaricare
php devo agire sul processo che gestisce Apache.
Credo sia l'installazione standard
Spero di averti risposto
-beppe-
Il 15/05/23 17:12, Federico Di Gregorio ha scritto:
On 15/05/23 17:04, Giuseppe Naponiello wrote:
vecchio problema a cui non ho trovato una soluzioni "pulite".
Con l'introduzione di systemd i browser (e tutte le altre
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre
perché tanto lo sapete meglio di me di sicuro.
Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il file
da spostare in /tmp/ e non in systemd
sys_get_temp_dir e altre funzioni simili di php mi danno come
risultato sempre /tmp/, se però provo "new
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive
correttamente in systemd-private.xxx..xyz/tmp/
In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non
specificato, di default punta alla cartella tmp di sistema. Non ho
provato a modificarlo perché ho letto da qualche parte che non è la
soluzione più corretta (ma non ricordo perché).
...ma allora, come diavolo faccio a far caricare agli utenti i loro
file, visto che i vecchi script non funzionano più?
Sembra che php venga eseguito in un processo differente da quello di
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi
dirci se sul sistema c'è anche un service che fa partire PHP? Come
viene gestito?
federico
Re: apache php e problemi nell' upload dei file
On 15/05/23 17:04, Giuseppe Naponiello wrote:
vecchio problema a cui non ho trovato una soluzioni "pulite".
Con l'introduzione di systemd i browser (e tutte le altre applicazioni
che ne usufruiscono) non scrivono più in /tmp/ ma in
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre
perché tanto lo sapete meglio di me di sicuro.
Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il file da
spostare in /tmp/ e non in systemd
sys_get_temp_dir e altre funzioni simili di php mi danno come risultato
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt",
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/
In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non
specificato, di default punta alla cartella tmp di sistema. Non ho
provato a modificarlo perché ho letto da qualche parte che non è la
soluzione più corretta (ma non ricordo perché).
...ma allora, come diavolo faccio a far caricare agli utenti i loro
file, visto che i vecchi script non funzionano più?
Sembra che php venga eseguito in un processo differente da quello di
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi dirci
se sul sistema c'è anche un service che fa partire PHP? Come viene gestito?
federico
apache php e problemi nell' upload dei file
Buongiorno,
vecchio problema a cui non ho trovato una soluzioni "pulite".
Con l'introduzione di systemd i browser (e tutte le altre applicazioni
che ne usufruiscono) non scrivono più in /tmp/ ma in
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre
perché tanto lo sapete meglio di me di sicuro.
Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il file da
spostare in /tmp/ e non in systemd
sys_get_temp_dir e altre funzioni simili di php mi danno come risultato
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt",
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/
In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non
specificato, di default punta alla cartella tmp di sistema. Non ho
provato a modificarlo perché ho letto da qualche parte che non è la
soluzione più corretta (ma non ricordo perché).
...ma allora, come diavolo faccio a far caricare agli utenti i loro
file, visto che i vecchi script non funzionano più?
Grazie
-beppe-
