The current demand scenario is as follows:
I developed an extension that runs on various open-source CMS systems, such as wordpress,discuz and so on.
Now if a user installs to use our product, our this side sends the new version, prompts the user to update, the user points a button, then instantly upgrades to the new version. The user expressed satisfaction.
The user is satisfied, but we have to complete this action, we must develop automatic upgrade system for each open source CMS. This system I developed, contrast version ah, download files Ah, what, feeling still quite troublesome, a single CMS can, but later extended to a lot of CMS, we have to target this set of CMS development This thing, that workload is very huge. So, I now want to develop a common mechanism that can be applied to all CMS systems, what is the best way?
--------------------------
I think of a method now. The first difficulty in implementing this functionality is that a PHP file cannot replace itself. That is, this running PHP file can not delete or modify their own source code.
So, there must be a file that is acting as this modification to someone else's role. His own things do not move, his existence is to change others.
For example, the extension below has a, B, c three files. When the user clicks on the upgrade, sends an AJAX request, directly accesses the run C file, the C file is run independently and does not depend on other files to exist. In this way, he can be a, b these files on the line to modify, delete and so on, but also to achieve the purpose of automatic updating, and all the CMS extension, I just put a file under each directory C, that is good, this workload is not multiplied by the reduction?
Is this plan feasible?
Reply content:
The current demand scenario is as follows:
I developed an extension that runs on various open-source CMS systems, such as wordpress,discuz and so on.
Now if a user installs to use our product, our this side sends the new version, prompts the user to update, the user points a button, then instantly upgrades to the new version. The user expressed satisfaction.
The user is satisfied, but we have to complete this action, we must develop automatic upgrade system for each open source CMS. This system I developed, contrast version ah, download files Ah, what, feeling still quite troublesome, a single CMS can, but later extended to a lot of CMS, we have to target this set of CMS development This thing, that workload is very huge. So, I now want to develop a common mechanism that can be applied to all CMS systems, what is the best way?
--------------------------
I think of a method now. The first difficulty in implementing this functionality is that a PHP file cannot replace itself. That is, this running PHP file can not delete or modify their own source code.
So, there must be a file that is acting as this modification to someone else's role. His own things do not move, his existence is to change others.
For example, the extension below has a, B, c three files. When the user clicks on the upgrade, sends an AJAX request, directly accesses the run C file, the C file is run independently and does not depend on other files to exist. In this way, he can be a, b these files on the line to modify, delete and so on, but also to achieve the purpose of automatic updating, and all the CMS extension, I just put a file under each directory C, that is good, this workload is not multiplied by the reduction?
Is this plan feasible?
Think of an approximate idea:
First of all, it is recommended that the large version update and patch update, large version of the update if it is more complex to download the file to overwrite the way manual.
Minor version update, you can build a common update deployment method:
Client Unified Update request to the central server side of the processing of the updated interface or portal file, through the portal file based on the client-submitted local environment series data, dynamic generation of an upgrade package and the deployment of the JSON configuration file, the client receives the JSON and then upgrade the database, replace the file, etc. This way the server side as long as the continuous maintenance version upgrade after the various CMS upgrade rules can be.
Anyway, the workload is still huge!
composer
!
composer
!
composer
!
!!!!!!!!!
Thinking is really rigid.
Since PHP can not change itself, then change the configuration file, or change the database ah, the problem is not solved.