Why are they asking for these details without giving us the instruction to fix the issue?  There is a license issue after moving host.  When I asked phpfox to solve it, they asked for the details.  Since I didn't give them (nothing there to hide.  I gave those details to them and they had access to my site before.  Now I like to know why do they need them since many members complained here about this behaviour),  they refused to solve it.  

I have many sites running scripts developed by others and if there is any issue, they ask questions then direct us to solve it.  They don't ask for access to our site.  What do you think about this?

Be the first person to like this.
awg

I AGREE...I refuse to let them in as much as possible. I got it down to 100% as of now. It is the most dangerous thing you can do, especially when we really absolutely dont know any of these people. SAD THING, if you have a problem, and dont let them in, it will drag on for days, or simply go without reply.

This has been a problem for over a decade (10 Years) and I look at many of these issues as a way for the developer to obtain access to your site. Disregarding the app, the developer becomes a constant bug within your system from an unknown jurisdiction.

Your exactly right, I as well use other scripts that has never asked for FTP access, and thing are fixed as a whole, meaning every customer that has access to the perticular app, has the same consistent fix.

Here, with phpfox devs,  its an repeated customer issue with a very HIGH VALUME of FTP requests, which most come in record speeding times, compared to regular support. So the urge is that great, that, as soon as an app is purchased, the developer knows he has to be contacted for the little simple planted bug fixes.

You have to keep an close eye on your share features as well. Have to edit files to change all that, or you can easily be tracked daily....

You Dont Have To Imagine This, If You Have Experienced It Time And Time Again!!!

Be the first person to like this.
Paul Kellow

I totally understand your concerns when providing any secret access to your site. If your issues are known, we can make a guess and provide recommended solutions for you to try. We have also created many articles on phpFox Docs for known issues. Otherwise, in case the issue can't be reproduced at our end, our team will need to experience and troubleshoot on your site in order to figure out the root causes. Your issue may be caused by core, wrong info in a database, missing source files, conflicts among 3rd-party apps, incompatible server software, missing server configures, etc. It is very difficult for us to guide you to troubleshoot by yourself in this case.

Thus, if you have the development site and the issue also happens on this development site, we can assist you on checking and then provide you the exact instructions to fix the issue on your Production site.

Last update on June 14, 2019 by Paul Kellow.
websistema2013

I totally understand your concerns when providing any secret access to your site. If your issues are known, we can make a guess and provide recommended solutions for you to try. We also create many articles on phpFox Docs for known issues. Otherwise, in case the issue can't be reproduced at our end, our team will need to experience and troubleshoot on your site in order to figure out the root causes. Your issue may be caused by core, wrong info in a database, missing source files, conflicts among 3rd-party apps, incompatible server software, missing server configures, etc. It is very difficulties for us to guide you to troubleshooting by yourself in this case.

Thus, if you have the development site and the issue also happens on this development site, we can assist you on checking and then provide you the exact instructions to fix the issue on your Production site.

I completely agree. Errors can be hidden in server settings and this happens quite often - a developer can never create a universal kernel that would suit every client-administrator, there can always be nuances and settings that may affect the performance of the site and its work.

Although I have an unpleasant experience, when a programmer from Vietnam secretly installed a mining script on the server for me - fortunately it is no longer on phpfox.

Kibcode

agree with paul! but i have to say that most of the time clients send me their login data even if i dont have asked. they seem to think that it is much faster this way and they are right. it is much faster than guessing the problem. i totaly understand the concerns about that and always try to solve the issues by communicating with clients but that does not solve the problem in some cases. at this point the client needs to trust the developer. it is sad that there are developers abusing the trust clients gave them but imho they can or hopefully will not survive very long in the business. it is not good to state this on all developers in the store globaly because that way you get an atmosphere of mistrust in this forum and store that is not rightful and helpful.

the best thing or compromise is to make backups of files and db before someone works on your site and change passwords when the work is done.

Last update on June 15, 2019 by Kibcode.
Paul Kellow

the best thing or compromise is to make backups of files and db before someone works on your site and change passwords when the work is done.

Thank Scheinwelt-Media. Your recommendation is a quite practical and good way for developers and clients to work together.

Be the first person to like this.
awg

it is not good to state this on all developers in the store globaly because that way you get an atmosphere of mistrust in this forum and store that is not rightful and helpful.

the best thing or compromise is to make backups of files and db before someone works on your site and change passwords when the work is done.

In most my experience, its a file that needs to be fixed across the entire board. If they fix it properly from the beginning, or after the bug has been reported, it most likely wouldnt require as many FTP access. if we dont give FTP access, the dev will certainly say, wait until the next upgarde. Forcing the FTP access to prevent downtime.

The back-up, site change password, is really old now! Its funny to see the cheerleading to support the ftp access to continue as TRUSTED! But bottom line, we really dont know you guys at all, and people are all over the world here.

This subject is really fine lined as I first stated. Devs just sit up and wait after purchase to go fix that little needle in the haystack. And sad to say, but true. Its going to require FTP access, which if they are smart enough, changing your password does not stop them from chaeck your data settings file!!!

Be the first person to like this.
awg

We would end up running out of passwords, and bothered with long back-ups over a easy file fix, in most cases...PHPFOX Core, needs little support at all, if any...To me, personally, the core is running very good.

Be the first person to like this.
Kibcode

restrict ftp users to specific directories to prevent devs checking your settings files or other important locations. please learn how to enable debug after that ;)

Be the first person to like this.
Paris

Here's what I went through.

I gave developers my logins and server access.

Site would have odd issues later on. Even some heated complaint could piss off a dev and it's goodbye stable server.

Since I have 100% ended access with new install. Sites been flawless since. This proves a lot that some devs are causing issues out of pure hunger to get hired to fix issues.

I now suggest ALL clients to have two servers.

1 a dev server. After fixed you simply TECHIE export the addon to your main server or FTP over write yourself.

I no longer trust devs on my main server since my last huge server crash and compromise.

Also another issue.

I had the dev steal my customization and resell on Crea8social which now up to date they refuse to admit. My gift code.

That one still burns deeply with hatred towards the crea8social team.

Paul Kellow

Hi Paris,

I can understand that it is really annoying when having more issues after fixing an issue. Having an additional site for development is always a practical and good solution. All fixes should be verified carefully before distributed to the Production site. Your site becomes much more stable to end users.

Be the first person to like this.

Few years ago, I hired a freelancer to customize one of my sites.  We were't happy at the end.  Even I changed all the passwords, the contents are get deleted every few months.  I changed server and username of the site.  It didn't help.   Year later, I found out that they added code to remove the db content when they access a file.  How do you tell justify it?  How backup, changing passwords, development site are enough to prevent these kind of issues?

However, as I mentions above, I gave access to phpfox and younetco (have their many addons) to fix the issues.  But I just asked now to clarify after many expressed concern about giving those accesses.  I like them to find some other ways to fix problems on clients sites. 

Be the first person to like this.
websistema2013

2 servers, 2 backups - this all applies to English-speaking clients. Then it turns out, after buying the app, I can not fully test it if I do not fully translate the language packs. If I do this on the backup site, I will not be able to transfer the translation of the language to the working site, since it is impossible to do this for one app. It’s too bad that they removed this feature when upgrading to version 4. Previously (for example, version 3.4) I could easily translate phrases and transfer the already translated app to the working site. Now the language pack consists of 2 files - the installation file and the translation. In this case, all the phrases are mixed from different apps. It is not possible to clean the database (language packs) of garbage from remote applications. phpfox developers do not care, since I have already raised this issue. Well, I, like many others, suffer with language packs ....

Last update on June 17, 2019 by websistema2013.