ehm - Potacchione

tema di default, un pezzo di me è appena morto - Craiv

Ma sai almeno cosa è quello ed a cosa serve? - Guido Eugenio

A me pare bellino - reloj

Responsive design non ti dice niente? - Alessiobblà

accendendo il parser php per infilare i commenti nel codice? - Craiv

Tanto lo dovevi accendere comunque, prima o dopo... :D - Alessiobblà

every nanosecond is sacred. - Francesco Mosca

Leggi la bibbia http://codex.wordpress.org/Main_Pa... - Guido Eugenio

risposte senza domanda - Craiv

Come rispondo al supporto inglese: If you can post a link to the site you're working on I can take a look and give you more info about what is going on.. O se preferisci in russo.. - Guido Eugenio

nun posso postare il link sta tutto nella mia mente - Craiv

ma non esistevano i commenti anche per l'HTML? <!-- ? - Gatto Nero

da cui il mio "che cos'è quella cagata" - Craiv from Android

grazie piplos non lo sapevo, mi levo il cappello - Craiv

ora spiegami perché quel commento è così segreto da doverlo nascondere al client - Craiv

lato server, si, certo - Craiv

Probabilmente, visto che credo che sta robetta sia scritta a più mani, è stato deciso per convenzione che i commenti a funzioni php siano in commenti php? - L'astronauto

visto che il commento riguarda una cosa scritta nel codice HTML direi di no - Craiv

Craiv +1: è un commento all'attributo role. L'unica motivazione che vedo è preferire un carico innocuo sul server per alleggerire l'output html - cedmax

output html che esce compresso, ricordiamolo (no, in realtà è un commento alla parte dopo, che contiene un link "skip to content") - Craiv

se il mondo non volesse i commenti html creerebbe server che li tolgono - Craiv

(il problema non è mail il linguaggio, è sempre il programmatore) - A. Morloi Grazioli

Piplos, senti a me: perché spiegare in un commento php un pezzo di codice scritto in html? Che senso ha? - Craiv

Soprattutto che senso ha creare un'apposita stringa php per commentare. - TED©

Craiv: in realtà lo "skip to content" dovrebbe essere inutile se ci sono i role che identificano le sezione della pagina... afaik per lo meno - cedmax

in teoria si, ma magari è li per fallback. Piplos, il tuo discorso regge se sviluppi da solo, di notte e alla luce di una candela. Se devi lavorare con altre persone in un'ottica di separazione fra chi fa il codice e chi scrive il markup e la grafica, quella cosa è una puttanata mondiale. Anche solo per il fatto che chi fa il markup potrebbe battersene il cazzo di avere sotto php, python o una squadra di cinesi che fanno il parsing del codice a mano ad ogni richiesta. - Craiv

Craiv: separazione contesti e wordpress? seriously? - cedmax

Ced, vabbè, ieri stavo mettendo le mani nel "loop" e dovevo pure sfogare la rabbia su qualcosa. - Craiv from Android

Quindi tra tutti gli esperti nessuno ha spiegato perché quello è scritto così.. Mecoiò che chiaviche di programmatori girano su leganerd! L'ho sempre detto: meglio i cingalesi! Gli unici ad accennare qualcosa di sensato son stati Piplos, cedmax e Francesco Mosca. - Guido Eugenio

Con la premesso che parli di un tema: L'utilizzo di commenti nel PHP non appesantisce l'esecuzione dello script poiché l'interprete PHP salta tutte le parti che riconosce come commenti, nè il trasferimento della pagina al browser; infatti i commenti, essendo contenuti all'interno del codice PHP, fanno parte di ciò che non viene inviato al browser. Quindi quel commento sta dentro al codice per queste ragioni. Salverà un nanosecondo? Non importa, ma l'approccio è corretto. - Guido Eugenio

Quindi è corretto mettere un commento che riguarda il codice HTML dentro il codice php. Va bene, i programmatori siete voi, mica io :) - Craiv

Se ragiono che non lo devo stampare, che devo velocizzare l'esecuzione e che non devo mandarlo al browser, in quel caso sì. Se non fosse dentro al codice il risultato è che perderei 1 nanosecondo; ma se i commenti son parecchi.. Come già ho detto, l'approccio è corretto. - Guido Eugenio

Suppongo che tu l'abbia trovato in un file con estensione php, per cui... :D - Signor ф​ранк (Frank) from FFHound(roid)!

Ricapitolando: Gatto Nero e TED© non sanno una mazza di queste cose, per loro il commento andrebbe fatto in HTML (o si equivale) cosi al browser mandiamo il doppio dei dati e perdiamo velocità. Piplos e cedmax han centrato il motivo. Francesco Mosca ha detto bene ma un po' breve. Gli altri ne capiscono poco.. - Guido Eugenio

Chiudo il mio intervento dicendo che quando uno conosce queste cose la prima cosa che fa, per migliorare le performance, è proprio quella di de-commentare quei plugin (scritti con i piedi) che si ostinano ad utilizzare commenti HTML.. Idem per alcuni temi fatti da dilettanti. Oltre a tutte le altre correzioni naturalmente.. - Guido Eugenio

ah ma era un contest a chi ce l'aveva più lungo! (l'HTML) - GeekQueer

Piplos. Ci sei andato vicino perché hai detto molte cose giuste ma non hai centrato il motivo.. Nascosto per velocizzare e non solo per nascondere. - Guido Eugenio

Lol - Guido Eugenio

OK, ma potresti averlo corretto adesso.. non lo avevo visto prima. Comunque correggo la votazione.. Piplos e cedmax han centrato il motivo. Francesco Mosca ha detto bene ma un po' breve. Gli altri ne capiscono poco.. - Guido Eugenio

Vorrei fare il modesto.. Ma di queste #robetoste di programmazione in C# e php, di HTML, ecc., potrei farvi da professore.. - Guido Eugenio

scusi capo supremo del php, la invito a rileggere il mio primo commento (il +1 é relativo al fatto che il commento riguarda il markup e non una funzione php) - cedmax from Android

Craiv hai detto: se il mondo non volesse i commenti html creerebbe server che li tolgono. Per WordPress se utilizzi il plugin di cache W3tc (ai più resta difficile configurarlo), attivi il minify e l'immondizia scompare.. Ha anche un campo dove puoi inserire ciò che deve lasciare e non ripulire. - Guido Eugenio

cedmax - Ho corretto e ti ho inserito tra coloro che han detto qualcosa di sensato. - Guido Eugenio

+1 alla squadra di cinesi che fanno il parsing del codice a mano ad ogni richiesta - mik

piplos, *guido lo devi bloccare*. Io l'ho fatto, è così piacevole. - Gatto Nero

Ora posso ritirarmi a vita privata - cedmax from iPhone

Che palle che siete. Si parlava del l'opportunità di commentare il markup dentro il codice php, e nessuno ha ancora risposto. "performance" non è una risposta, siccome quel commento è perfettamente inutile se si volevano migliori performance bastava non metterlo. Visto che per trasmettere una riga di html compresso si impiega lo stesso tempo che serve al parser per riconoscere il commento e saltarlo, la domanda era "per quale motivo il commento relativo al markup non sta dentro al markup"? Liberi di continuare a non rispondere. - Craiv from Android

Craiv quello che dici non é del tutto vero: anche se compresso un html più corposo occupa di più. che sia risibile e che wordpress abbia ben altri problemi di performance é vero e sono anche d'accordo sull'inutilità di certi commenti (se non a fini "educativi"). sulla semantica di un commento al markup scritto in php ti dò ragione di pancia, perché tendo al nazismo su certe cose, ma microttimizzare le performance é spesso, fatto salvo quanto detto, altrettanto importante (forse più importante perché lo é per l'utente finale vs importante per lo sviluppatore). scusate la lunghezza del commento. - cedmax from Android

Sarà che lavoro su cose diverse, ma la microottimizzazione dalle mie parti si tende a evitare (alle volte costa di meno affittare un core in più che perdere ore a limare dei millisecondi). Ma ti parlo di hpc, non lavoro su queste cose dell'internets da tempo. Comunque appena ho tempo da buttare faccio un benchmark per capire quanto influisce il commento in php ;) - Craiv from Android

Craiv: di core ne puoi aggiungere finche vuoi, ma la latenza della connessione non ne beneficia affatto, anzi con un ragionamento come il tuo (se è vero che i commenti in php richiedono più risorse, aspetto il benchmark) questo tipo di approccio è ineccepibile: meglio caricare il server su cui hai controllo che la rete che dipende da tipo di connessione, gestore, distanza dal server etc etc. - cedmax

(ma infatti le mie applicazioni se ne stanno buone buone sul server senza uscirne, per questo la mia visione è un po' distorta) - Craiv

(ma infatti le mie applicazioni se ne stanno buone buone sul server senza uscirne) - Craiv

http://www.codinghorror.com/blog... - spider

Il parser è "acceso" comunque, se l'app gira con apache/mod_php; in quel modo il commento non sporca l'html (dove in effetti non serve). - Claudio Brandolino

(poi wp fa cagare comunque) - Claudio Brandolino

Ha ragione Craiv su tutta la linea. - spider

spider, muoio :D - Craiv

in linea di massima se uno ha un puntacazzismo-score abbastanza elevato da non tollerare un <?php /* commento */ ?> nel markup, non dovrebbe nemmeno immaginare di utilizzare una roba come WP che concettualmente (come sono allegramente mischiate logica e presentazione nei template, ad esempio) sembra spuntare fuori direttamente dai primi anni 2000. - Signor ф​ранк (Frank)

fortunatamente non è roba mia, è un'installazione che risale tipo al 1992 :D - Craiv

@spider: il concetto di tradeoff però potrebbe essere adottato, no? come ho già detto wp ha ben altri problemi e semanticamente un commento così anche a me fa storcere il naso, però quando si tratta di ottimizzare il frontend anche poche cose possono cambiare l'esperienza utente (sul backend è mooolto diverso). è chiaro che quella è ridicola, però è anche molto semplice da ottenere, quindi non vedo motivi per non farla (per una questione prettamente semantica???). è un po' come non ottimizzare le immagini per il web, per te è un'operazione da pochi secondi usare pngcrunch et similia, per alcuni utenti vuol dire tempi di latenza ridotti. perchè non introdurre questo tool nel workflow e continuare a usare solo "save for web and devices" di photoshop? - cedmax

cedmax - Ho visto programmi online e non, spacciati per ottimizzare immagini, che rasano completamente gli exif; utilizzarli è da principianti nonché penalizzante. Magari non lo avete mai pensato ma noi in Yandex (dal 2006/7 ed idem Google ultimamente) valorizziamo i contenuti con immagini (foto) originali. Spaccare gli exif significa penalizzare, di un certo valore percentuale, contenuti originali.. Ovviamente questa cosa Matt Cutts (addetto alla macchina trita HD di Google) non la dice. xD - Guido Eugenio

Guido: quando si tratta di immagini di layout (background e sprite) gli exif sono totalmente inutili, io non sono un content manager, ma un frontend developer. spero anche io che un content manager non usi imageOptim, non avrebbe senso - cedmax

Piplos, chi ha mai detto installazione vecchia? Che cazzo c'entra il SEO ora? Chi si è mai autoproclamato esperto SEO o programmatore? - Craiv

Sul SEO immagino che ce l'avesse con GuideugeGno. Che nell'occasione, ma forse solo per puro caso, stavolta ha azzeccato argomentazioni decenti. - Questo&Quello&Quellaltra from Android

Craiv - La velocità di caricamento delle pagine[1] è una delle innumerevoli questioni che influiscono nel posizionamento, quindi c'entra eccome il seo. L'approccio del template di WordPress (che hai affermato essere una cagata) di alleggerire il contenuto fornito al client (commentando all'interno del PHP invece che in HTML) è valido anche per questo aspetto. [1]Google Webmaster Tools da tempo tiene traccia della velocità con cui si caricano le pagine di un sito. - Guido Eugenio

Piplos, che cazzo c'entra l'installazione con gli aggiornamenti fa capire, ti pagano per parlare a caso? - Craiv

Guido, Google misura i microsecondi in meno nel caricamento di una pagina? Seriamente? HA HA HA - Craiv

("alleggerire il carico di server che servono miliardi di pagine al secondo" sarebbe stata un'argomentazione più sensata, direi) - Craiv

@Craiv, su questo devo dare ragione a Guido: Google, cosa affermata dallo stesso Souders (web performance optimizator a Google e organizzatore - o promotore, non ricordo se è direttamente coinvolto nell'organizzazione - della conferenza Velocity) penalizza i siti più lenti in favore di quelli più veloci quando si tratta di fare il ranking. non è una cosa recentissima, ma di sicuro è già in fase di testing dal 2010 e recentemente ha acquisito peso, tanto che in google analytics c'è anche una voce relativa alle performance delle pagine. Lo stesso lavoro su SPDY ti dice quanto google stia investendo in quel senso - cedmax

Si, ok. Ma seriamente, una riga di commento in meno quanto può influire sulla velocità di delivery di una pagina? Rispetto agli 8 milioni di altri fattori che contribuiscono alla velocità di invio di una pagina, intendo. Visto che sono velocità non percettibili dall'essere umano medio non c'è nessun motivo per penalizzare il millisecondo. Ci sono milioni di motivi invece per penalizzare siti che arrivano dopo 5 secondi rispetto a siti che arrivano dopo 1 secondo. Ma questi 4 secondi non li recuperi di certo togliendo i commenti. - Craiv

non esiste un trick che ti porti 4 secondi preso da solo. i fattori sono tantissimi, ovviamente, ma i problemi maggiori sono sicuramente clientside (la golden rule dice che l'80/90% dei problemi sono lato front end http://www.stevesouders.com/blog...). strippare i commenti può essere un inizio, concatenare e minimizzare js e css, ottimizzare le img di layout e usare sprite... ci sono tantissime tecniche che vanno in questa direzione, diciamo che non è sicuramente la cosa più importante, ma nemmeno una cagata fotonica - cedmax

@cedmax perché al prezzo di risparmiare (?) non quantificabili nano secondi (perché lato client sono ben altri i colli di bottiglia che un centinaio di byte di commento) fai casino commentando a codice una cosa che dovrebbe essere nel markup. Che wordpress già faccia di queste cose di suo non è una giustificazione per perseverare nei temi. Chi fa una cosa del genere in nome delle performance difficilmente tiene conto di cose come leggibilità e manutenibilità del codice, lavoro in gruppo, eccetera. Lavora per un bene non precisato (tempi non misurabili)(perché vi voglio vedere a fare un benchmark per quantificare il miglioramento) e ne sacrifica uno ben preciso. - spider

@spider: non quantificabili lo dici tu, ci sono tanti strumenti per quantificarli (da google analytics stesso a page speed, passando per decine di servizi online) ma al di là di questo, siamo d'accordo che wordpress non è esattamente lo strumento che più si presta al lavoro in team? la separazione dei layer di sviluppo è inesistente. inoltre probabilmente a questa pratica verranno aggiunti plugin che caricano jquery 3 volte. di cosa stiamo parlando? ma da qui a definirla una cagata ne passa, dai, è un tradeoff ragionevole - cedmax

Appunto perché i commenti possono trovarsi nel tema come nei plugins, sarebbe buona regola fare come il qui criticato tema di default di WordPress. Un commento non fa differenza ma cento sì. V'è anche da dire che sino ad oggi non ho visto un CMS, dicasi uno, che abbia un file .htaccess (per Apache) compilato come si deve, i rallentamenti quindi già partono da ciò che di default vanno a scrivere la' dentro. E' anche vero che però la personalizzazione sarà possibile solamente dopo aver messo il CMS nel server, valutando come quest'ultimo lavora. - Guido Eugenio

Quindi questa cosa dei commenti nel php è una linea guida di wp? - Craiv

in un file di template a caso per WP ti può tranquillamente capitare trovare query sql e markup a poche righe di distanza, e stai a preoccuparti dei commenti? :D - Signor ф​ранк (Frank)

Just Frank - Ovvio che tra i tanti temi disponibili molti sono fatti con i piedi e da dilettanti.. direi la maggior parte; idem per i plugins. Se uno però sa dove e come mettere le mani è liberissimo di scriversi tutto quel che gli serve, oppure di smembrare roba già fatta modificarla e migliorarla. D'altronde WordPress è diffuso per la sua semplicità di utilizzo e la facilità che offre, anche al principiante, di mettere online un sito web in pochissimo tempo. - Guido Eugenio

*proprio* perché i problemi di performance dipendono da ben altro, non cercherei l'ottimizzazione incasinando la semantica dei commenti. Poi naturalmente fate vobis. - spider

@spider: i problemi di performance non dipendono da ben altro, i problemi di performance hanno tante origini, anche questa in determinate circostanze: se hai 1 commento nell'html non fa niente, se hai molti commenti nel markup rischi di servire un sacco di Kb inutili. ti giro la domanda: se per te la semantica dei commenti è più importante delle performance... (dover performance = esperienza utente, diminuzione del bouncerate, aumento delle conversioni etc etc) - cedmax

ma poi come dicevo è questione di trade off: stiamo veramente facendo un flame dal niente, come dicevo 1 commento chissene, tutto commentato potrebbe diventare un problema e a quel punto si cercano soluzioni (e questa, a voler tenere i commenti, non è così tragica). sta tutto nell'avere elasticità mentale, buon senso e un occhio agli obiettivi di business oltre al proprio microcosmo di codice, non c'è una risposta giusta. - cedmax

e invece, anche tutto commentato non cambia una mazza -> http://friendfeed.com/lega-ne... - Craiv

chapeau, sarei curioso di vederlo con commenti di lunghezze e contenuti random e cache, ma in ogni caso i numeri dannoti ragione - cedmax from Android