How to create a automatic update component in php? - php

I'm developing a web application in PHP and I need to develop an automatic update component for that software. When I thought about how to develop this, this is what came to my mind:
logic
download latest version as a zip file to the server
unzip
upload and overwrite the files already existing and if there are number of versions available:
assume user is having 1.2 version and he need to update to the 1.5 newest version
system will download all the versions after 1.2 and overwrite files one by one with the files of 1.3, 1.4 and 1.5 versions.
This seems a big overload to the server. I really don't have another idea. I hope you all can hep me out. And I also want to know what kind of PHP technologies I can use for this?

Related

Is there an easy way to watch selected local PHP files for content changes on Windows?

Is there any easy way (tool or IDE plugin or some other solution for MS Win) how to watch selected local PHP files for local changes of content?
I am developing a PHP application based on open source core which is developed independently and distributed only in zip files so I need to make update manually by overwriting of old version with the new one.
The problem occurs when I make my own changes to core PHP files and during making updates to the current version of the core I rewrite these files with their new version, I do not know which changed files were previously modified by me.
Yes, it is an easy obvious way
Any VCS, which support branches
Vendor branches + branches diff|merge

Is there a tool to monitor multiple composer based installations?

In composer.json and composer.lock, most informations about a php application's dependencies are described accurately.
I want to manage our installs (mostly CMS like TYPO3 and Craft) better and wonder if there is a tool that collects that information from multiple sites / servers and returns it in a structured, easy-to-read way. For example to answer the question: which of our sites use this xy extension.
It's ungooglable for me, but maybe you have a hint or know a script? The tool could run on cli, with a gui, locally or on a server, doesn't matter.
To monitor TYPO3 installations you could run extension t3monitoring in a single TYPO3 installation and collect information from other installations using t3monitoring_client. This monitoring solution includes reports about extension versions in all monitored installations.
There are also other monitoring solution avalaible for TYPO3.

How Are OpsWorks' Built-In Recipes Versioned?

When you set up a stack in OpsWorks, does it lock in the current built-in cookbooks version or will it use the most up-to-date version each time a lifecycle event is triggered?
For custom cookbooks, I understand that OpsWorks caches the provided recipes when they are provided rather than fetching the newest version each time, but I wonder if the same is true for the built-in cookbooks.
I'm concerned about this for a few reasons. What if the cookbooks are updated to install a different version of Apache or PHP or slightly vary their default configuration? What if I then setup a new instance in a layer in which the old recipe was used and end up with multiple servers with slightly different configurations?
Also there doesn't appear to be a way to customize which PHP5 version gets installed, so am I just at the mercy of the ubuntu package managers' decision to use the latest stable version?
I do want to continue using the latest and greatest software versions, but I would like to deploy them on my own time after I have been able to test that my application works in the new version.
When you set up a stack in OpsWorks, does it lock in the current built-in cookbooks version or will it use the most up-to-date version each time a lifecycle event is triggered?
When you provision a new machine, built in cookbook + custom cookbooks are requested onto the server at the same time. It gets updated only custom cookbook update is requested. This is why the recommendation is NOT copy the entire AWS cookbook into your custom cookbook. Only things you are modifying so you can benefit from standard community cookbook updates.
I'm concerned about this for a few reasons. What if the cookbooks are updated to install a different version of Apache or PHP or slightly vary their default configuration? What if I then setup a new instance in a layer in which the old recipe was used and end up with multiple servers with slightly different configurations?
This is not just a BANE, but a benefit too. It depends on how you perceive this. What maybe a performance improvement can be done, and also introduction of bugs. This needs to be kept in sync by your operations people.
You can override parts of the built in cookbook by just placing duplicates ( or customised ) versions in the same place in your cookbook. Converge option
OR the more complex but sure way :
implement custom recipe cookbook.
import opsworks cookbooks as a submodule into a folder inside your cookbooks folder.
symlink the cookbook that you need version controled to the main folder now
evaluate and update as needed specific ones
ie :
cd cookbook
git submodule add https://github.com/aws/opsworks-cookbooks external-cookbooks/opsworks-cookbooks
ln -s external-cookbooks/opsworks-cookbooks/rails rails
This way you can update and keep version control of your infrastructure code. Make and evaluate changes and only import the changes after you've
I still recommend using converge mode with only the minor changes you require hardcoded. It will mean LESS duplication , and your will benefit from updates that maybe in the community version of the cookbooks.
If you're using a cookbook that uses the UBUNTU way to install PHP - then you will be mercy to what is in the repo. If you are using another one that does custom compiled version, then you can compile specific versions. You may have to either write your own OR find one that does build it and let you specify version via an attribute on the cookbook.

any way to get back PEAR DB functionality from 4 years ago?

I have an application built in 2007 that makes extensive use of PEAR's AUTH and DB packages. It had been mothballed but out again now. Since those packages are not available and pear has completely changed, it no longer works in my system.
Outside of rewriting the entire software, is there anyway to get the previous functionality of DB & AUTH packages?
Thanks.
If you don't mind doing some investigative work yourself, you could look at the changelog pages for both of those packages - at http://pear.php.net/package/Auth/download/All and http://pear.php.net/package/DB/download/All to determine which version of these packages you had installed and used when you developed your application.
Once you've confirmed and installed the specific versions of these packages that you need, you might want to consider writing what's called a "PEAR Meta Package" and committing it to your version control system so that you can ensure these specific packages can be easily installed again (on other servers, whichever) with minimum hassle.

Joomla Upgrade 1.5.15 to 1.5.23

I am trying to upgrade joomla 1.5.15 to 1.5.23
I have downloaded the Joomla_1.5.15_to_1.5.23-Stable-Patch_Package from the joomlacode.org.
While trying to install this package from my administrator, the error will be displayed "Error! Could not find an XML setup file in the package.".
Or
Shall I extract this zip file and upload the files to server directly through FTP?
Please advise me..
Any help appreciated.
I would recommend a 3-step process personally to ensure the best possible outcome.
First - backup your site (I LOVE Akeeba Backups 1-touch backup solution); download the backed up site and install on a local host or development server.
Second, do your upgrade there (extract the files from the .zip and put them in the localhost/dev server installation).
Make sure that the upgrade didn't break anything, that everything still works appropriately and as expected and create a backup of the localhost/dev server site.
At that point you know the upgrade won't break anything.
Third, upload the unzipped files from version 1.5.23 via FTP into your root joomla directory (complete the upgrade as listed HERE.
Doing these steps will ensure the best possible outcome and will show absolutely ZERO disruptions on your live site in the event something you're currently using doesn't like the jump from .15 to .23 - which is a large jump and a lot of things are different (including which version of mootools is included!) So take caution and TEST FIRST!
I would advice you to do this::
Assuming you have access to all the files of website.
1.Now download directly 1.5.23 or 1.5.26 version(last update patch of this series.)
2.Extract the files and open them,you will notice them you need to only replace 4-5 files in that patch.
3.Copy each file and replace them with the current files in the existing websites.
Hope this helps.

Categories