I have an application I want to distribute however, I’m starting to think about how would I approach the fact that the application will need updating and when I update something and put a patch out. Now the more I think about it, would it just be safe to make an update file, compare the version that the client has and if there’s a new version to update it to, the update file will automatically just download all the necessary files and extract it to the client’s host.
Basically what I’m trying to get at is make the script download and extract and overwrite the necessary files to keep the application up to date.
Would that be a good approach? I know that there are tons of applications that just tell their user base straight out that they have a new version for them to download and update. However, I find that a hassal for the client to do because
A. They have to download the actual files, find out what they need and don’t need based on what they have modified.
B. The new files will most likely overwrite the old files anyways so this takes even more time. Why put all the hard work on your clients if you are suppose to update the software, not the clients.
That’s just my thoughts, please let me know what you think so I know what approach to take when it comes to updating and distributing versions.
Unless your application handles the installation of PHP and it’s extensions, automatically pushing updates to unknown environments is a BAD idea.
Let’s say PHP 7 rolls out. You’ve got a whole bunch of updates you push out but… uhoh, one of the functions you used in your shiny new updates wasnt in 5.5.
Your script pushes out the new code… onto a 5.5 system. You just broke your customer’s application, without them doing a thing to know it’s happened or why. What if the client’s on vacation? What if their IT guy is? Clients want to be able to control WHEN the updates happen, so they can be ready for outages or problems.
Now, can you design your updates to be one-button simple jobs? sure. But you need someone to push the button.
I’ve seen things like
“enter your email address if you would like to be notified of updates”
apps that have a “check for updates” option
and apps that “ping” the source and inform the user that “an update is available”
But I agree with StarLion, I know I wouldn’t like it, as I imagine most wouldn’t, if an app automatically updated itself without giving me the final decision.
If I decide to update and it breaks, oh well, I knew the risk and I did anyway, so I may get upset but I wouldn’t get angry.
And chances are I will update when I know I have some time to do some hurried fixing, not when I’m swamped with a full plate.
I see. You guys both have good points, but let’s say my application requires PHP 5.4 or higher. Most functions that are used have been tested to only suit PHP 5.4 and higher, this includes ircmaxell’s password_hash alternative. There are no functions being used from older PHP versions below 5.4.
With the new updates, it will only be using 5.4 +. In the near future when my application is ok to use and not too buggy, I will look into moving all functions from PHP 5.4 to PHP 5.5.
Should I take your guy’s words and allow the clients to update when they want? I’m a bit confused because if it’s a PHP version function problem, I’ve already looked into this and have only used functions that are available for PHP 5.4 +.
But just because you say 5.4+ doesnt mean you know what willl happen in PHP 7. or 8. or 9…
Example: In 5.4 and 5.5, mysql_query is perfectly valid. in 7? Not in the language anymore. You cant future-proof environments you dont control. What if someone has to update their system from 5.5 to 7 for another application? What if someone wants to stay on 5.5, but you change your code to fit 7?
That’s why my application finds mysql_* functions in all of the file and if that keyword exists without a comment, you will be shown an error telling you to switch over to MySQLi_* or PDO. This message won’t disappear until you have removed or commented the line that it is complaining about.
I know this is not a smart way for beginners, but in the long run. They’ll have to switch over anyways. Plus, the PHP documents already said it’s deprecated, but people still use these functions because they find 10 year old tutorials and they just copy&paste them. This helps encourage them to at least copy&paste newer codes.
So you want me to take my live enviroment, that my customers are using, and because YOU pushed a code change, my live site is broken until -I- realize the problem and fix it, when i’m not looking for a problem because I didnt do the update.
…
If this scenario doesnt sound INCREDIBLY bad to you… then there’s deeper issues.
If PHP did automatic rollouts in this way; your application would break one day. No idea why, just…doesnt work. You wont put error messages in a live environment, right? so… it just comes up blank. You dont know when this happens. Was it a week ago? a month? Would you want to keep using PHP? Or find something that lets you have control?
I can see what you’re saying. That’s why I am debating about if I should make the update just notify the client instead of automatic updates, extract, .etc. Also, this might annoy the client as well if they get automatic notification about new updates in their email if we also put this “automatic” notification into play.
I can see where it will annoy the client because if they have modifications and if their other files relies on the modified main files, it would cause a huge problem.
However, I would just take this into consideration and decide which is the best approach.
Again, i see absolutely nothing wrong with having the upgrade process be automated from the moment someone pushes the “update” button. Throw up a list of “this is a list of current environment requirements” or “changes expected in the environment are…” would be good, with a button underneath it that says “go”. But your customers will much prefer being able to schedule their possible downtimes (always run updates expecting the worst case scenario!)
So the only best way to go about this “update” thing is to allow the user to hit a button and check for updates rather then checking for updates automatically and telling them that there’s new updates?
Alright, sounds like a good idea then. There’s about 5% of me that still wants to do the automatic update, extract, .etc, but the other 95% tells me that I should look for updates automatically and tell the client there’s new updates and allow them to update their software if they want.
The simple rule goes, if you can’t control the system the upgrade will be applied to, you cannot do automatic upgrades. You can automate it, just don’t override the owner of the software/ system. She must make the conscious decision to allow the upgrade.
The only time automatic upgrades are feasible are in a SaaS environment and even then, you usually leave it up to the customer to “turn on” new features, especially when the changes or added features may cause some sort change in user experience (and even when they are good changes!).
Yes! Perfect. That never even crossed my mind to allow backups before updates. I’ll put this in my todo list.
So speaking about update packages, should I have a list of what has been changed on the automatic update check?
Example: Let’s say the update automatically checks for updates. It will display on the admin panel what has been changed in the newer updates. Nothing will be executed until the admin hits a button to update their software. If they decide to hit the submit button, it will
Make a backup of all files first.
Then download and extract the files and place them where they belong.
Does this sound like a good idea or should I just make it so that the client has to download the package, extract it themselves, and then allow them to upload it to their server?
Well, WordPress has a “one-click” update.
It doesn’t backup any files or the database, but it does Warn the admin to do so. (how many actually do is likely similar to how many people actually “have read and agree to the terms”)
But the Warning is there.
I guess a lot depends on how techy the users are and how much support you’re willing to provide. Making the process easier is a good goal, but making more work for yourself, not so much.
As for what the update entails, it could be a bit lengthy so maybe a link to a list would be best. eg. imagine putting this list in every user’s ACP
My only hesitation about saying “let them hit a button” was that you mentioned your customers are customizing the code themselves.
If a client has made a change to their code, how is your system going to reconcile it? Or will it simply overwrite the customer’s modifications with the default codebase?
Hmm, I see what you’re saying. It could be too long if it’s going to be a list of updates.
Well, I was going to make the update file add in new lines of codes to their modified files. This way, they can have their own customized codes plus the new updates. However, looking at this, it could go wrong as well because what if someone changes that line that adds in new lines? Would it be a problem? Another thing, what if the server doesn’t allow new lines of codes to be added, what then?
Hopefully your system will be built in a way, so your clients won’t be touching the base code (like most frameworks are built). If changes in core code is necessary, it makes the upgrade process super ugly for the client.
