Yes, you could check for folder / file permissions, try to change them, then change them back.
But IMHO this would be shaky ground for something some might want not to happen and have more control over.
Seems if the users are tech savvy enough to have hacked files and / or added “plugins” they should be tech savvy enough to handle updating too.
If I had a dime for every question ever posted regarding fixing a broken Wordcrap site after automatically updating core or plugins I would be rich.
The strength with open source is anything can be modified. The consequence of which is that those providing the system can’t assume a consistent state across all deployments of the platform. The more assumptions a open source platform makes the more likely breakage is to occur when updating. Therefore, the safest approach is to rely on users of the platform to update manually. Otherwise any open source system has a potential to break when updating automatically.
Yeah, I would really love to make it so that it can operate in a manner like that.
In these kind of situations, I really want to know how most frameworks do it. How do they allow their users to add new elements without touching the core files. Like SMF, they allow you to make your own text fields of random stuff you can put on profile pages. I know I’m taking the wrong approach and I’m not sure what to expect.
See that’s the thing. I’m not sure if the audience I’m going to be getting is tech savvy or if they’re just beginners. In all honesty, I know that they are going to be beginners, but I would have to assume that they know a little bit about PHP. This way, I know that they will be modifying the core files themselves.
Discussions aside, what I have done is allow my clients to create their own custom codes. They can place these custom codes in a folder named “custom”. The core files are separated from the custom code, but the core files are being called before the custom codes. If a user tries to create a PHP file with a core file name, the custom file will be ignored. However, the main problem from the start of the discussion up until this point where I’m trying to battle for is that my theory is that a few of my audience might go and modify the core files. The whole point I was trying to make with the few couple of posts was that what I truly want is to overwrite the core files so that even if someone is smart enough to bypass and modify some core files, it will revert back to the default core files.
That was the main point of my first couple of posts. The customization of files however will not be affected because the custom folder will not be overwritten with any new updates. Only the core files will. That was what I was trying to argue and point out, but I couldn’t put it in more meaningful words.
Sorry if my topic shifted some how.
Customizations in the files could very well be broken by updates such as API changes. Relying on core as a baseline is practical but not reliant enough to allow automatic updates without accepting some level of risk for the end user when customization is allowed. General rule of thumb is that if someone other than the owners can touch the code the system can’t be automatically updated without medium to high levels of risk in breaking deployments.
Also beginners are the individuals most likely to program in a means that introduces the HIGHEST level of incompatibility with future updates. Well them and those with strict deadlines or contractors who just need to a get a job done. Hopefully not in most cases but sometimes core needs to be hacked or that is simply the “easiest” way to do something with a tough deadline. So are you willing to potentially break those users sites. Users who may have had work contracted, unknowingly push “update” on production and boom goes their entire site. For any open source platform automatic updates is a dangerous path that all to often provides an illusion of false reliability like Wordpress – Sometimes it works and sometimes it don’t – The “cross your fingers and pray to god update method”.
Using Discourse as an example, which is relatively new and still being hammered out so might not be the best comparison, highlights potential problems.
As might be obvious from the list posted earlier, every update includes changes in some templates’ DOM, changes in naming conventions, changes in functionality, sometimes version depency on third party code. etc.
And too often breaking changes.
Check the meta Plugin category and you can see how many older plugins are now broken.
The Core changes so much so that it is essential to run the update on a staging server before updating the live site.
It would not be a good thing if Discourse took it upon itself to update Core files automatically
I agree with oddz. If you do avoid core code changes from your clients, then you end up with some form of API and changes to them are usually part of the upgrade. These API changes can be backwards compatible, but in some cases they aren’t.
The other (less obvious) possibility is a metadata system for add-ons or plug-ins or custom modules or whatever you want to call them, which uses API versioning. This is something I am contemplating about myself and have yet to do any work on. I am also designing this system for a form of PaaS, so probably a whole other ballgame, than what you are doing. I am also not even so sure if PHP, with its share-nothing paradigm, could even support such an API versioning well. All things I am researching.
Scott
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.