Support Forum

Ah, thanks for pointing me to that. However, I'm finding that:

• Featured Topics and Posts is listed as v1.0.2 and I already have 1.0.3 installed
• Polls is listed as 1.3.7 and I already have 1.3.8 installed

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.

Mr Papa said
the allow_url_fopen is not a good example... just a temp fix for you until we issue an update... would you rather have it not working?

as mentioned, we are discussing ways to better present versions to prevent them from getting out of date...  but that doesnt happen over night...

[sigh] Please don't be patronizing. I was trying to make a valid point. Sorry if I used an example that just came to mind and didn't fit your criteria.

If you'd like to discuss things, I'm all eyes.

Fair enough. "would you rather have it not working?" seemed unnecessary. And I know you can't turn on a dime and give 9 cents change. Not asking you to do that at all. I fully realize that making adjustments to a system as complex as this one can sometimes be extensive. I'm originally a Fortran guy, working on IBM Big Iron System 360's, so not a n00b. Just sharing a situation that may not have been considered; from a viewpoint that may not have been voiced prior.