I’m aware of that. Something needs to be figured out for situations like this for users who are at least a couple of levels up on the clue scale as to how to install stuff on their server. Yes, I could jump through the hoops to change server configs but that does not address the issue of doing updates by other than automatic methods; where the user has no control.
Nothing is perfect. Software has bugs. Installs and updates get Borked. It’s a fact of life. If I’m just pushing a button and watching the blinking lights, not knowing what is really taking place until after it happens, and I know not where, I’m in for a bad day if something goes wrong. Further, many times customizations are made to files prior to uploading. If an automatic update takes place, the forum reverts until the edits are located and restored. This needs to be done before the update. I do this all the time with WP plugins by checking the file date and running a compare routine, then moving over the changed portions to the new version.
Yes, I know, just like in WP you don’t edit the core files. However, there are times where it is necessary, either to remove a feature, correct a typo or refine something. There have been many instructions in these support forums outlining just that operation to be performed on plugin files. The allow_url_fopen fix is an example.
A theme is another story, where a child theme can be created so an update doesn’t step on it.
I get that your business model is centered around the assumption that users just do the auto-update thing, so you don’t have to provide access to the server to get updates if they don’t pay the rent. They’re still getting the updates, though, just not new plugins. One of my LightWave plugins does this same thing. Pay for access to the server for a year. When he decides to make an update, sometimes more than one year down the road—sometimes less than a year for a particular user, he invalidates all of the logins and pushes the new version; instead of having versions in separate locations and allowing access to the version that they registered for, for as long as they need, which would be good customer service. Meanwhile, you’re paying for access to the server just to see if any updates had come along. If they didn’t, it’s not good value for the customer. In this case it was three years between updates. I considered for a long time whether I wanted to support this business model before deciding to purchase the new version, because keeping one’s customers shackled isn’t the best way.
SP updates do come at a more frequent pace than this but, quite naturally, not all of them are updated at the same frequency. Still, having a way to obtain access for the SP plugin version set purchased might be something to consider for a better customer experience.
we do really like getting feedback… and we listen – it drives what we work next…