Good day.

Today, a fascinating idea has come to mind that I would like to discuss: the possibility of implementing it. Essentially, I have a website hosted (the content is irrelevant; what you need to know is that it is functional and visited). I'm not considering shutting down the site for a specific/indefinite duration.

To be more specific, the changes I need to make to the website include coordinated structural changes: correcting controllers, removing unnecessary functions, adding new ones to models, and rewriting views. It's a significant system upgrade, but changes to the database aren't in the works—only changes to site files. This project is closed internally within a particular company, so disabling the site would have negative effects on employees and authorities.

I had an intriguing thought today—what if I could use some kind of flag in the site's settings (either in the code or the database) to enable 'Developer Mode' with the capability to make changes to the site invisible to everyone except the system administrator? Then, after using the "magic" button, all the changes that were made would be applied to all other system users.

One might ask, why not clone the entire system onto a local server and work on it before uploading everything back onto the network? Why did I dismiss this option? Because not only do I need access to changes that haven't been officially confirmed yet, but there will also be additional people overseeing, coordinating, and approving these alterations. Therefore, it's necessary to implement such functionality within a single system.

P.S. I don't use frameworks (yet).

It's technically feasible to write code like this anywhere:

if ($test_mode == true)
{
//introducing new functionality
}
else
{
//offering old functionality
}

However, it's not ideal. The best approach is to create a separate site for testing purposes. Even if you're working on a local server and testing alongside your main site, providing access via another URL will make things much clearer. Otherwise, you'll end up with a mountain of if statements.

One alternative might be to handle this at the page routing level, which could cut down on the number of conditions required. Nevertheless, this approach still isn't ideal.

People often create separate websites for specific purposes, but this doesn't necessarily require a new server or domain. The website can still function properly whether it's located in the root folder site.com or in a nested folder like site.com/testing, as long as the code is written properly.
If working in a subfolder is difficult, one can use test.site.com instead.

Git is an incredibly helpful tool for implementing changes throughout the testing process and even at the end with just one action.

Using nginx tools, I am able to perform this task regardless of the engine type. The configuration has already designated the folder in which the file indicating the technical service can be found.

During the actual maintenance, all I have to do is remove the comment from the line that redirects all IPs except mine to that folder. It may seem artisanal, but it functions well - as the saying goes: "if it ain't broke, don't fix it!"

This method proves to be convenient as there is no need to make any alterations to the engine, framework, or code itself.

Your idea of implementing a "Developer Mode" with the capability to make changes to the website invisible to everyone except the system administrator is indeed intriguing. This would allow you to work on the necessary changes without disrupting the functionality of the live site for other users.

To achieve this, you can consider adding a flag in the site's settings, either in the code or the database. The flag could be used to enable or disable the "Developer Mode." When the mode is enabled, the system administrator can make changes without affecting the rest of the users. Once the changes are finalized and tested, you can use a button or mechanism to apply those changes to the rest of the system users.

Since you mentioned you don't use frameworks yet, you may need to handle these modifications manually, making sure to coordinate the structural changes, correct controllers, remove unnecessary functions, add new ones to models, and rewrite views. It might be helpful to have a thorough testing plan in place to ensure that the changes made during the "Developer Mode" do not introduce any issues or bugs.

considerations and suggestions for implementing a "Developer Mode":

1. Access Control: Ensure that only the system administrator has access to enable or disable the "Developer Mode." This could be achieved by implementing authentication and authorization mechanisms.

2. User Interface: Design a user-friendly interface or dashboard where the system administrator can easily toggle the "Developer Mode" on or off. This could include a simple checkbox or switch in the settings section of the admin panel.

3. Change Management: Develop a process for tracking and managing the changes made during the "Developer Mode." This could involve dоcumenting the changes, keeping a version control system, and regularly backing up the website to avoid losing any critical data.

4. Communication: Clearly communicate the purpose and limitations of the "Developer Mode" to all stakeholders involved. It's important to manage expectations and inform users that temporary disruptions or downtime may occur during the implementation of changes.

5. Testing and Validation: Establish a thorough testing protocol to ensure that the changes made during the "Developer Mode" function as intended and do not introduce any bugs or issues. It is crucial to thoroughly test the modified functionality before applying it to all other system users.

6. Rollback Mechanism: Implement a rollback mechanism or a backup plan in case any unforeseen issues arise. This will allow you to revert back to the previous version of the website if needed, ensuring minimal impact on users.

7. dоcumentation: Maintain clear dоcumentation of the modifications made during the "Developer Mode." This will help future developers or administrators understand the changes that were implemented and make it easier to troubleshoot any issues that might arise.