Being honest, neither is good practice.
Both do basically the same thing, the performance gain is not so great as to justify this.
But the ideal is not to use this type of approach ... If you want to create a dynamic page, use an API that returns the data you need and do it via Javascript.
But answering your question, the only way would be if apache stopped working, but then your page would not even be served via the web.
But if at some point only the compiler appeared, its source code would be shown to the end user.
Editing: Adding new content
In terms of back-end security, aside from the fact that rendering the page and sending it based on http templates is not secure, you'll need to keep an eye out for some things that can fact impact your site if your compiler stops working.
First: Environment Security
Never ever, in any case leave users, passwords and hosts of hardcoded databases in the application, in short, do not set a constant, or anything that is visible within your source code which shows you how to access your databases.
In return, make a file env.ini
(or .env.ini
or as you wish to call it) and read the settings for this file. The .ini
template is a fairly old and accepted pattern in the community that can be parsed by php natively and transformed into an array if you follow the correct syntax:
[database]
user=seuuser
senha=suasenha
host=seuhost
See more about ini files in the links below:
And how to open and parse through PHP:
Second: Source Code Security
It is very unlikely that the PHP compiler will stop working out of nowhere and the web server (IIS, apache or nginx) will continue to work because both are very connected to each other and ultimately the PHP compiler it is just a program that runs on a file that causes it to be modified. For this webservers perform the step of running the compiler on each file that is served, so I said that it is very difficult for your source code to appear to the end user (in 7 years of experience with PHP, this has never happened to me at least) , but as always we have the possibility of that 1% there are some practices:
- Your source code should not expose all logic to a single file:
- Monolithic codes tend to be much easier to decipher if read in sequence, so try breaking into several components, because if one of them appears on the screen, the user will not find out how others behave
- Avoid any sensitive or sensitive information types directly in source code
- As I said before, this does not only apply to passwords and database information, remove all sensitive data and store in files out of reach of the webserver itself
Conclusion
I would not use the rendering of this template, but if it is not an option to remove it, I believe you would be subject to the source code in very rare situations, but still possible, what you can do is basically take action so this is not a problem.
Your source code should not be the complete description of your product, but rather independent parts of the total logic of what it should do, so a person would need to put all these parts together to contain something that really makes sense.