其实是最近有个客户要改自己家网站，用的media temple的wordpress hosting，所以对它家有了个直观的了解，现在讲一下我的感觉。
首先，它家的wp hosting不便宜，我简单看了一眼，20刀一个月，可以host两个wp sites，比大部分的vps都贵了。但是，也有优点：
1. 服务不错，如果出了问题，可以在线提交ticket，虽说24小时之内回复，但我做了几次，都是一两个小时之内就有回音。24小时服务，如果是半夜，回复更快。还可以request support call，也是很快就会回电话。
2. support人员对wordpress非常了解，无论是使用上的问题还是后台还是数据库的问题，都能够很快回答
3. 其它的各种bells and whistles，自动更新wp core啦，每天都自动备份啦，对于不太会维护网站，不太会设置server的用户来说，非常方便。简单来说，就是花钱买服务。它家同时也提供ssh登录，对于想自己上去折腾的同学们也挺方便。
4. 非常好用的功能：一键设置staging site。众所周知，用wp网站的话，除了没publish的内容，其他的设置啊菜单啊等等更改大部分都会直接live，所以如果你是为客户服务，需要客 户sign off，或者有什么东西需要测试，在development的过程中可能会mess up整个站点的话，一般的做法是，建一个跟主站一毛一样的staging site，在staging site上瞎折腾，等完全满意之后，再在主站上改。
如果是自己安装的wp，如果需要一个staging site的话，就得再独立安装另一个wp，把所有文件都复制过去，还得复制数据库，修改数据库里的选项，挺麻烦的。media temple的control panel里有建立staging site的选项，一点之下自动生成一个完全一样的staging site，就可以在staging site上各种折腾，折腾完了以后，它还提供sync回到主站的功能，是个很完整的development cycle。
但是——
就是这个sync back的功能，它的概念非常好，因为如果自己做这事，就要复制各种文件，复制数据库，还有一大堆要修改的地方。media temple自动化解决问题，省了用户很多事。但是！！media temple的script大概写的有点问题，用起来还是有点glitch的，所以造成了这几天的狗血，下面大家可以听听我的搞笑经历了。估计以后也是我 为数众多的黑历史之一。
前几天我做完了客户要求的所有更新，客户sign off了以后，我就要push live了。于是我用了mt的sync选项，此时是晚上10点半。然后，我就去洗澡了。洗完回来一看，咦？还在sync？好吧，我明白有时候这事是要排队的，我就先睡觉了。
第二天早上一看，还是显示在sync。等到中午，PM先不干了，说怎么这么慢啊，我怎么跟客户说？
我就request了一个support call，让pm接（为嘛呢？因为我在上班呢不好意思接私活的电话）。pm接完，转达了mt的意见：哎呀我们这个sync功能又出问题了，要不然你还是手 工把内容传上去吧。pm对我表达了无限信任，觉得手工上传应该是个非常简单的事，于是我只好赶鸭子上架啦。
当天晚上，我备份了staging和prod的所有文件，备份了两个数据库，准备干活了。这次改了的内容包括theme文件，增加了新的page，安装了 新的插件。所以，我先把theme文件传到prod上，其他的内容都是数据库里的。到了数据库这一步，我有点抓瞎了，因为如果是我自己建staging site，我会让数据库的结构一模一样，最后export然后再import就行了，然后改一下主站wp_option里面的url。mt的数据库呢，大 概是为了区分，staging site的table名字都带一个随机字符串的prefix。
我承认，我对数据库没那么熟，我不知道怎么把里面这些字符串的reference都批量改了。所以，我只好回去再让mt给我sync。这一次，倒是显示 sync好了，我可以看到prod上的数据变了。外加theme我已经手工传好，网站已经可以看到是改后的样子了。我就准备关机睡觉了。
但是！事情从来不会这么简单。因为客户还要求在主站上加上google analytics，我就得登录wp admin啊。这一登录，好么，发现mt下面的wp admin功能完全不管用了，自己到后台去登录，登录上去一看，admin菜单里没有一个选项，直接打wp admin的路径，说我没权限。
上网搜一下，这个问题说啥的都有，大部分都是migrate wp网站后出现的，所以我只好按照网上诸位皮匠的建议，到数据库里去看wp_user 和wp_usermeta这些table里的内容，发现usermeta里还有些staging table的reference，我只好手工一个个的改。好吧，实话说，我很少直接去phpmyadmin里改东西的，在我做front end dev的这些年里，每一个后台dev都警告我说这样做是很危险的好不好。
所以，改到最后，突然，在我刷新过页面以后，wp不干了，说我要更新数据库了，不更新哪儿都去不了，我只好让它更新，更新完以后，好么，整个大地白茫茫一片好干净，完全变成一个新安装的wp了。卧槽虽然我知道我都备份了，我还是直接吓尿了好吗？
到了这个份上，我只好submit ticket了。提交之后，我觉得大概今天没回信了，喝了一杯水压压惊，我心想，明天我没办法面对PM和客户啊，我干脆再sync一把得了。
这一次，倒是号称sync成功了，然后发现同时support也回了我的ticket，说是admin用不了是因为这个这个table里的那个那个有问 题，还有那个那个table里有staging site的reference，等等，是上次sync没完成造成的，他给我改了。anyway，不管是谁的作用，现在，前台看起来没有问题，admin也 可以正常登录了。
当然，其实如果看phpmyadmin的话，这一次的sync还是有点问题的，因为出现了有几个table被duplicate了的问题，比如原先是 wp_abcd_options，现在变成了wp_abcd_abcd_options，写正则表达式的那位同学，你是跟体育老师学的吗？好吧，其实我也 不会写，我瞎猜的。理论上这些duplicated table应该可以删掉，但是我现在都吓破胆了，哪里还敢drop table啊。就这样吧。
PM和客户完全不知道出现过这些惊心动魄的事，第二天大家纷纷表示looking good! great job!
结果下午的时候，PM突然说，为啥我登录admin以后，看不到某某内容啊。我当时没转过弯来，心想难道admin又坏了？我上去看看吧。结果在办公室这一看，我又吓尿了，为毛呀？我用办公室电脑打开网站一看，又是昨天白茫茫一片的样子了。
还好这个最后发现是false alarm，是mt的cache问题。清了server上的cache之后，就显示正常了。我登录admin一看，原来pm用自己的账号登录的，他不是administrator，所以看不到某些内容。
所以，以上就是我跟mt的爱恨交织的经历。恨，是这个sync的功能，它能不能表现稳定一点？爱，是它家support太给力了，基本上什么问题都能够解 决，而且一下子就找到点子上，不会东拉西扯地让你做各种无谓的尝试。比起我以前用过的所有hosting来说，简直甩了不止几个火星年的距离。
我觉得这种事大概对于我这种稍懂一点又不精通的dev来说，特别frustrated，但是对于完全不懂的普通客户来说，反而容易一些，因为可以直接跟support说，我不会，你给我解决吧。
要不要用？大家自己判断吧。
