In a desperate measure to create more revenue they have decided to offshore their call centre support to overseas countries. Everything is scripted and everybody is winging it. If your located in Australia you would have memories about how frustrating it is dealing with Telstra support. If Telstra were forced to bring back all their call centres to Australia - imagine how frustrating it is speaking to people overseas about COMPLEX email / server /website issues. Please just google digital pacific reviews to realise how bad it is.

I have recently set up a new company and have had issues emailing potential clients using bigpond. This has been going for near 2 weeks now with the issue not being rectified. I also contacted the postmaster at bigpond in relation to the issue and I can say (much to my surprise) he has been brilliant, responding quickly and outlining what he requires to try and make an assessment. The problem is however every time he responds immediately Digital Pacific let the ticket sit for days until I call and give them a rocket again. It moves forward and then goes back into the same cycle. I have advised them that this could be costing me a lot of money which in the infancy of operation is not what I need, but it doesn't seem to matter to them.!! I will see what the office of fair trading (wishing their was some form of ombudsman) can do, but seriously horrible experience and now looking for my money back and alternative reliable options.

Initially my hosting was decent. I had a few problems (that were poorly addressed by help staff) but I was prepared to accept that these were teething issues. What was happening was a site would crash due to a caching plugin. This crash would take down all of my websites. Pacific Digital's help desk would take hours to respond to my ticket, by which time the server had recovered. I was using very standard caching plugins on Wordpress sites, caching plugins that have not caused any similar problems on any other hosting platform. I was told that it was impossible for one website to crash all these website in the way I described. But crash they did. Time and time again. Techs would log in hours after the server recovered and tell me that they saw no evidence of what I had described to them. No kidding! As tech support goes this was useless and somewhat insulting to my intelligence.

Eventually a tech pointed me toward a Digital Pacific best practice for caching on their servers. This reduced but did not full resolve the issue. It's very stressful crashing all your client's websites in one go.

What has happened subsequently is the hosting platform has become really slow. Really really slow. I know instantly when I'm on a client's website that is hosted on Digital Pacific. Try and log in to the dashboard....waiting...waiting...oh that's right this one is on Digital Pacific!

Right now I'm copying my websites to another server. This is an extremely painful experience because even the process of adding the Updraft plugin and trying to get a backup is an exercise in patience. It's a waste of time and money working with Digital Pacific in this way but unfortunately I have to go through this process so I can stop paying them for hosting every month. (How wonderful it is when I run up a new website on a good server, load the Updraft back-up and start using that same website on a server that is fast an usable).

So I'm rewriting my review.

Since my last review, I've had contact with DP and I've identified some issues with my site loading. One of them was that the PhP was not updated which they did for me and also I had not fully set up Cloudflare on my website, however, when I did my site was still not loading optimally. It's >400kb site with ~16 requests loading at anywhere between quickest of 1.6 to the slowest I had was 2.9 seconds. A majority of this was taken by the response time of the server to respond to the connection request.

https://tools.pingdom.com/#!/dTL5Or/https://www.danieltaylorproducer.com.au/

When I tried to bring this up someone from the team explained to me that they did a speed test and this is what they sent me Verbatim "I have taken a look at both of your sites and can see that danieltaylorproducer.com.au loads within 0.8 seconds and alpha1memorials.com.au loads within 1.28 seconds"

The way I have my site structured is as such, Alpha1memorials was the setup years ago by a webdev who I no longer employ. danieltaylorproducer is a new site and set up as a subdomain, by me. Alpha1memorials is in the current stages of being redesigned because the current landing page is just over 7MB, how they got a 7MB landing page to load in 1.28 seconds I wanna know because that is magic tbh.

When I brought this up and asked them to clarify how and why this discrepancy was present the replies stopped. And I was doing tests off Pingdom on and off through this and somehow magically my site started loading at 1.1 seconds. I didn't touch a single thing backend, no edits to my page, no settings in my Cloudflare changed. No settings in my Autoptimze plugin changed. This never before seen spike in speed just happened after I asked them about the speed discrepancies. The only thing I could credit this spike in speed was Cloudflare, but it's been running all this time without such an increase in speed.

I have no idea what DP is doing in the background, whether they are capping performance on subdomains, whether they are actively shifting resource allocation, whether they are piling on a bunch of sites into a server but I'm not a fan of it. I do appreciate the effort they've made to contact me and get things fixed but I still don't have a resolution or understanding of why the server was taking so long to respond. Or even the initial issues I was having with not being able to access my site(danieltaylorproducer), it would periodically go offline while I was working on it and I would not be able to access it or the other website. I wouldn't even be able to login to the WordPress backend of either site.

Both times on phones I would simply be given the line that "Oh I was working around then and that server didn't have any issues at that time."