Risposte:
Sento che questo è uno scenario "limite". Una gran parte degli utenti di Joomla sarebbe sicura e protetta senza questi file, ma alcune persone eseguono Joomla su un host configurato in modo errato (e alcuni su un host configurato in modo errato che non consente loro di riconfigurare) che visualizzerebbe il contenuto della directory se la directory fosse richiesto. Questo file lo impedisce.
A livello personale, se non hai bisogno dei file, nel cms è inutile gonfiarsi e puoi rimuoverli.
A livello di CMS, penso che risolva un problema che può avere importanti problemi di sicurezza con un gonfiamento relativamente minore. (I file sono generalmente vuoti o contengono una minuscola riga di HTML.)
Non posso parlare con l'esatta ragione per cui il PR non è stato accettato (dal momento che non ho nemmeno quel potere, tanto meno chattare con le persone che lo fanno); Penso che il vantaggio relativo per la comunità superi il peso.
Detto questo, esiste un metodo alternativo di cui ho sentito parlare in alcuni eventi di Joomla sullo spostamento della maggior parte dei file "a un livello". L'idea è di ottenere tutti i file sopra la public_htmldirectory in modo che non sia possibile accedervi direttamente. Vorresti solo accedere al index.phpfile, al .htaccessfile e alle cartelle imagese media(per mantenere accessibili CSS, JS e immagini).
A questo punto, fai meno affidamento sulla configurazione di un server di base e puoi più garantire che i file non siano accessibili in modo inappropriato. Ciò avrebbe i suoi problemi di configurazione (da ora abbiamo bisogno di accedere ai file sopra la nostra "radice").
Tutto sommato, non sono sicuro che esista un piano più sicuro per proteggere le persone senza problemi rispetto all'uso dei index.htmlfile. Quindi, se avessi rilasciato una piattaforma in generale, mi sarei attenuta ai index.htmlfile.
Il motivo di un index.html in ogni cartella è proteggerlo per divulgare informazioni sull'ambiente di hosting configurato in modo errato.
Se questo è un vero problema e il cms dovrebbe considerare che è un'altra domanda.
Per quanto ne so, non c'è mai stato un PR per quello. C'è un tracker di funzionalità ( http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30192 ) che è "pronto per la revisione". La patch esiste solo in un ramo e non è un PR. Quindi questo è probabilmente il motivo per cui non è mai stato unito.
O ti riferisci a un'altra PR?