Né davvero. Dovresti avere un framework per il routing. In questo modo l'utente ha URL come example.com/home e puoi usare home come variabile per caricare diversi controller. È migliore di example.com/?page=home o example.com/home.php in molti modi, come flessibilità del codice, SEO e esperienza utente. Dal momento che usi PHP, dai un'occhiata a Fat Free Framework o CodeIgniter per alcuni framework di base che gestiscono il routing per te.

Una nota aggiuntiva, sembra che tu stavi considerando di avere la logica per una pagina in un unico file. Più comune e molto più facile una volta capito è un modello di progettazione MVC di qualche tipo. Ecco come funziona CodeIgniter. Le richieste vanno a un file router, che chiama un file controller con i segmenti url come parametri, che riceve i dati da un modello che si collega a un database se necessario, e quindi dopo aver manipolato i dati secondo necessità utilizza il risultato per rendere un file di visualizzazione che è principalmente HTML con variabili echeggiate dove necessario. Questo è solo un esempio di come può essere fatto. Cerca MVC per ulteriori informazioni su questo modello di progettazione.

Se stai facendo qualcosa di più di un sito di 2 o 3 pagine con contenuti in continua evoluzione che nessun altro programmatore potrà mai toccare, è altamente raccomandato.

Ma per rispondere alla domanda come richiesto

Se devi scegliere uno di questi due metodi, è probabile che si verificheranno molte sovrapposizioni di logiche tra le pagine, almeno ad un certo punto, quindi avere un file che utilizza le richieste get per gestire le richieste è molto meglio che separato File. Se ogni pagina richiede un'intestazione, un piè di pagina, una variabile o l'accesso ad alcune funzioni personalizzate, il codice verrà scritto una volta in un unico posto, anziché dozzine di volte tra i file. Gli svantaggi sono che avrai un file enorme con un pasticcio di istruzioni if se è difficile capire e mantenere. Questo è sicuramente ancora preferibile al dover modificare ogni file per apportare piccole modifiche globali.

Semplicemente aggiungendo alla risposta fornita da Goose che è abbastanza dettagliata e parla dell'argomento per la mia risposta: il routing.

Voglio solo ricordare che è possibile utilizzare solo le librerie di routing senza dover utilizzare un intero framework MVC, che potrebbe essere troppo confuso per i principianti.

Manutenibilità significa molte cose. Ma usare una libreria di routing ti darà la maggior parte (se non tutti) i vantaggi di manutenibilità che stai cercando! Sarà veloce, pulito e non dovrai apportare molte modifiche ogni volta che cambia la navigazione. Inoltre, non è molto difficile e ha una curva di apprendimento piuttosto piatta (IMHO).

Mettendo da parte tutti questi consigli, le tue opzioni suggerite hanno questi pro e contro.

singolo file php

• (+) un punto centrale di esecuzione; puoi includere parti comuni di app, controlli di sicurezza, configurazione di env, ecc ... in un unico posto e per tutti
• (-) un punto centrale di esecuzione; devi indirizzare il traffico in un posto. questo potrebbe ingombrare il codice
• (-) fondamentalmente un url per tutto (certi parametri di query diversi); questo può essere un handicap quando i crawler / gli indicizzatori vengono sul tuo sito

separati file php principali

• (+) probabilmente più url per crawler e indicizzatori
• (-) devi includere esplicitamente parti comuni in ogni script di livello superiore

Ma c'è un altro modo tra questi due, continua a leggere.

Forse c'è un motivo per cui non vuoi usare una struttura consolidata, forse vuoi imparare esplorando. Non voglio giudicare, è una tua scelta.
Solo tu puoi mangiare la torta e averlo anche tu. Raccogli i vantaggi di entrambe le soluzioni ed elimina i principali svantaggi.

Propongo due (e metà) soluzioni, entrambe basate sullo scenario in cui stai utilizzando file .php separati con i propri URL pubblici, diciamo:

/index.php
/section.php
/article.php?id=123

E vuoi includere implicitamente parti comuni in tutti gli script.

riscrive

Prima di tutto, puoi sfruttare le riscritture in apache / nginx / whatever-your-httpd-is e indirizzare tutto il traffico a un singolo file php. In quel file puoi fare tutto ciò che vuoi per inizializzare l'applicazione e richiedere lo script richiesto in origine.

router.php :

<?php

$script = $_SERVER['SCRIPT_NAME'];
# add mandatory safety checks

require 'common.php';
require $script;

Ovviamente, puoi fare molto di più in router.php o common.php , ad es. impostare la connessione DB, il caricamento automatico, le opzioni di configurazione, gestire gli URL più belli, ecc ...
Fondamentalmente, questo è ciò che tutti questi framework fanno per te.

prepend / Aggiunta

Se riesci a copiare php.ini o .htaccess file, puoi impostare auto_prepend_file ( link ) direttiva per il tuo progetto. E possibilmente auto-append-file ( link ).

php.ini :

auto_prepend_file = prepend.php
auto_append_file = append.php

o .htaccess :

php_value auto_prepend_file prepend.php
php_value auto_append_file append.php

Questo ha esattamente lo stesso effetto dell'aggiunta delle dichiarazioni require all'inizio e alla fine di ogni script .php di livello superiore eseguito (cioè eseguibile con URL pubblico).

Questa soluzione ha aggiunto il vantaggio della gestione dell'interprete php nell'esecuzione di script di livello superiore, non del router. Quindi, se non è previsto che venga eseguito da una richiesta http, .htaccess et al viene fatto. Devi gestirlo a mano quando usi riscrittura / router.

404 gestore

Questa è l'ultima opzione, ma non la raccomando poiché distrugge in modo efficace qualsiasi cosa diversa dalle richieste GET. Ma può essere utile se vuoi utilizzare sia gli URL piuttosto che gli script direttamente eseguibili.

Invece di riscrivere, puoi invece impostare 404 gestori. Se httpd non riesce a trovare la risorsa pubblica (che si tratti di file statico di file .php ), esegue invece il gestore definito. Se si tratta di un file .php , è molto simile a router.php dalla soluzione di riscrittura. Ma non voglio entrare nei dettagli qui. Faresti meglio a provare a giocarci da solo.

PATH_INFO

Un'altra osservazione forse ti è utile.
Esamina la variabile di ambiente PATH_INFO (accessibile come $_SERVER['PATH_INFO'] da php). E prova a giocare con url come /article.php/123/pretty-name . Non devi limitarti ai parametri di query (a.k.a. $ _GET). Un sacco di singoli URL quasi istantaneamente.

I miei 2 centesimi sui metodi veloci e sporchi sono i seguenti: $ _GET mantiene il nav in un file che è più facile da aggiornare rispetto ai tre file nell'esempio. Alla prima aggiunta al sito, sarà necessario aggiungere la nuova voce di navigazione in tre file. Alla tua seconda aggiunta, dovresti quindi modificare quattro file ... Etc ...

Ecco l'approccio semplice e dinamico per ogni richiesta $ _GET, non c'è bisogno di controllare se page == home o qualsiasi parametro e gestire la pagina di errore o il modello se il file non esiste. Aggiunta anche l'esclusione per alcuni file

<?php
    $file = $_GET['page'];

    $path = getcwd(); // get the current directory if the file is same as index.php
    $ext = ".php"; // file extension

    $filename = $path."/".$file.$ext; // path and file combined
    $error_page = $path."/error_page.php"; // error page template

    // this is optional if your configurations are in the same folder
    $exclude = array(
                    'db',
                    'config'
                );

    if (isset($file) || !empty($file)) { // check if page parameter is not empty or set
        if (file_exists($filename) && !in_array($file, $exclude)) { // check if file exist and if we need to exclude some config files
            echo $filename." exists"; // load template
        } else {
            echo $error_page; // load 404 template or redirect to 404 page
        }
    } else {
        echo $error_page; // load 404 template or redirect to 404 page
    }
?>