Ghost is based on node.js. They already said here: http://feedback.cloudways.com/forums/203824-service-improvement/suggestions/5832660-install-nodejs-in-click-go that they won't be supporting node.js. I would like to see this too. But it doesn't sound like it's a very easy thing.
Also, Ghost has been great for WP. It's brought about a lot of changes that make it simpler/quicker to write in, like Ghost.
Partner with Hover.com, if you do this CW. They have the same simple, straightforward mindset that CW does. Plus they offer paid email accounts. So domains and email: the 2 things that CW doesn't do that traditional hosts do.
I'd still love to see this: file manager and file editor (text editor only for PHP, CSS, .htaccess, etc files).
A simple file manager would be really helpful/nice.
iThemes Security plugin has an option to blacklist IP's. Plus lots of great tools/settings to automatically blacklist them. It's worked great for us. Reach out to me, if you want help configuring it.
Could you explain how this makes sense for CloudWays? Apps is it's own deal, and entirely separate. You connect it to your domain by adding DNS entries. Since CW doesn't handle DNS, it makes no sense (at least that I can see) to get them in the middle of setting up Google Apps. Just set it up, point the web traffic to CW and the MX records (and such) to Google Apps.
New Relic and CloudFlare are both finished....
33 votes6 comments · Service Improvement » Server Configuration Improvements · Flag idea as inappropriate… · Admin →
I think we need a CloudWays users (or clients) group on Facebook, or something. Some way we can talk about things like this, and give it exposure for more people to vote it up. I REALLY want PHP 7. But I REALLY don't want to go through the hassle it's going to be right now, moving over 60 sites on 6 servers to new servers just to get there.
OR... even a "Upgrade to Debian 8" option would be good enough. It wouldn't help with the other cases like DO server downgrades, but would get us to Debian 8 so we can have PHP7. I wouldn't mind if there were half an hour or hour of downtime while everything is rebuilt, as long as I could schedule it and don't have to go through the cumbersome process Andrew describes.
PLEASE give us an upgrade path without all that pain. I assume it's better for us to be on Debian 8 for other reasons as well. So don't make us go through a alot of hassle and work, just because we became customers before Debian 8/PHP 7 was an option.
11 votesAdminCloudways (Admin, Cloudways) responded
The logic behind keeping same creds is that many people use this feature to create test/dev environments, so it is convenient for them to have it like this.
In any case, for the flow you mention, you could clone a template from server A to server B. Then on server B, keep the first copy of the app as a template and clone it (on the same server) as many times as needed. Cloning on the same server changes all credentials, so this should work for you?.
It doesn't work for us, because then when we want to adjust our template site, we have to adjust it multiple times across multiple servers. We want 1 source app (2 actually 1-WP and 1-WC) that we can clone anywhere, but have it be able to be cloned to another server multiple times.
I understand the logic, and we use it that way. But perhaps there could be 2 options: direct clone (current functionality) and "mimic" or something... I don't know the best word(s). Just an alternative that works the same way a clone does within the same server, but to another server. You don't have to change the functionality you have now, just add a checkbox or something to handle it differently for those of us that want to clone the same app multiple times from one server to another.
That's a good idea. And we've thought of that. But it doesn't really work. The reason is that from time to time, we make changes and updates to the template, based on changes in plugins, themes, and settings as things evolve over time.
If we did what you said, we'd have to either login to each of the template sites and make the same changes on all the templates (like 5-6 servers currently), which is a hassle. Or we'd have to delete them from all the servers, then re-clone from the "main" templates. Either is a hassle and not ideal.
We understand the reason for keeping the credentials the same. And that's why we suggest just having a checkbox or something when doing the clone to allow them to be changed, or not, during that process. That way the clone can be done multiple times from server A to server B, if we, your clients/users want to, or not, if we want an exact duplicate for dev/test environments.
I disagree with this one. Why not just install ManageWP or InfiniteWP? Or better yet MainWP, which is my favorite, since it runs in WP, is GNU, and is a much more comfortable interface than InfiniteWP, since it's a WP plugin.
84 votesAdminCloudways (Admin, Cloudways) responded
After analysing feasibility we have decided to drop this option by now. We are not experts in node.js, there are far too many full-stacks to be able to focus on one and the changes/efforts that we would need to do to adapt our platform are too big compared to the limited market we currently have for node.js.
That said, surely it is something that we may reconsider in the future.
Thanks to all for your feedback.
After some difficulties with Cloudflare, we have spoken now with Sucuri (https://sucuri.net/). They offer malware removal, website firewall (providing DDoS protection among other things, requires DNS redirection to point to their firewalls) and site scanning (via local agent). All features independent (we can offer all or some).
We are thinking that a better approach to solving our customers problems when it comes to security and performance will be to offer (as add-ons) Sucuri (security centric and very focused on our most common apps) and MaxCDN (pure CDN focused on performance).
Any one has had experience with Sucuri? We have already tested (and in talks with them) and looks very promising.
Let us know thoughts on this (Sucuri + MaxCDN) approach (vs Cloudfront). We know this is well overdue and want to get it rolling.