I can imagine that in larger projects some things tend to get redundant in most PHP scripts. From the top of my head: Including classes, authentication, including a configuration file, setting include path etc.
As far as my imagination has run, this should be done in absolutely every PHP script in the project. This would then be simplified by adding a "core" PHP script that handles all this.
However, from this very site, I can quote
"I am planning on creating a PHP file "core.php" that will be included at the top of EVERY SINGLE PHP file in the project. This file will handle authentication and include base functions. Thoughts?"
I cannot stress enough ‘do not do this’. There is a rule among experienced PHP developers that any project with a large core.php file that it’s a warning sign of bad development and should be best avoided.
Which leaves me at a loss. Is it better to redundantly write the same 20-30 lines of code on top of every file than to embrace DRY coding?
Any clarification would be appreciated!
I’ll quickly clarify here. The "Front Controller pattern" which I actually use when writing most websites and applications does not really fit the type of project I’m talking about. Well actually it does, and I already intend to use it, but my project also contains a lot of PHP scripts that should return content for Ajax requests. It is those PHP scripts that my question regards.
If you need to include 20-30 lines on top of every page, it sounds like it’s time for a better architecture. Look into Dispatching/Routing for example. Every request is handled by a central .php file, the Dispatcher, which parses the request and decides which files need to be invoked and loaded.
This is implemented in most PHP frameworks. Play around with one to get a feeling for it.