莫名其妙的最近发现手机上的wordpress app无法发布文章了，其他功能都完好：更新、从草稿箱发布等。但是无法保存草稿或者发布新文章。
查了一大圈，有说xml rpc的问题的，有说REST API的问题的，又是改代码又是搞插件都没有解决。
最终参考这个链接，从wordpress.com上删除了application后在手机上重新登录wordpress.com的账号后居然神奇的就解决了，amazing以为记
分类： 开发者
原wp是在主机A上的docker里的容器，后迁移到主机B上。迁移方式为直接 scp 挂在的本地目录。
迁移过去后访问域名显示 “Unable to create a file in the directory! Please check your server settings.“
参考救命稻草 stackoverflow解决问题：WordPress on Docker: Could not create directory on mounted volume – Stack Overflow
经过验证，重点是（在容器内：不一定）执行如下两句：
RUN find /var/www/ -type d -exec chmod 0755 {} \;
RUN find /var/www/ -type f -exec chmod 644 {} \;
注意：我的服务器配置是docker上的nginx 和 docker 上的wordpress，所以其他情况不一定适用。
我的域名是在阿里云注册的，直接使用阿里云提供的免费的ssl证书，按照手册生成证书，上传到服务器，修改nginx的配置文件。注意，nginx如果没有预留443端口，可能需要rm掉重新添加个容器。
重启ngxin后发现只有首页启用了https并且主题都没了，而且不是全站https。网上找了一些教程改来改去，一会儿too many redirects，一会儿502/404/500错误。
经过半天测试发现两个关键的修改点（不要修改.htaccess文件）：
1. nginx的配置文件中的 listen 80那个server 修改为：
server {
listen 80;
server_name domain2.com www.domain2.com;
return 301 https://$server_name$request_uri;
}
2. 在wp-config.php的行首添加如下四行，其他任何多余的都不要改了：
$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_CONTENT', true);
手上有个2011年的MacBook Air，要给妹妹上网课用，想着恢复一下出厂设置。重新安装一下系统再给她。结果没想到试了好久都是提示 “can’t download the additional components needed to install Mac OSX” （“无法下载安装 Mac OS X 所需的其他组件“）。
苹果官网有关于创建U盘启动器的手册：https://support.apple.com/zh-cn/HT201372。 当我按照手册指示试图从另一台安装了macOS Catalina的电脑上下载macOS High Sierra时，却提示“所请求的macOS版本不可用”。看来该方法无法在高版本的macOS上使用。
最终通过v2ex上一位网友的帖子，找到了绕过app store下载macOS的方法。详见：https://www.v2ex.com/t/575410
如果制作好启动U盘后，插入启动却发现看不到电脑硬盘，只能看到启动U盘。这种情况是因为在抹掉磁盘创建分区的时候没有选择GUID分区图，切记切记。而如果较老的Mac发布时预装的是High Sierra之前的系统：如我的11年MBA预装的是OS X Lion。此时如果抹掉磁盘后，按command+r进入恢复系统时，试图加载的是Lion的系统，而磁盘工具也是Lion的。由于Lion已经不再维护，肯定是无法升级的。此时应该使用command+option+r，进入“最新兼容的系统恢复”即 High Sierra，使用其磁盘工具重新抹掉磁盘的时候，可以看到GUID分区的选项。勾选后抹掉磁盘，使用之前做的High Sierra启动优盘即可成功安装系统了。
简言之，旧Mac抹掉重装要注意如下几点：
1. 使用command+option+r的磁盘工具抹掉磁盘，记得勾选GUID分区 //不要用command+r
2. 如果无法网络安装，可以使用脚本绕过app store下载macOS
在使用gRPC在C和Python之间传输二进制数据的时候发现，明明客户端发送的都是等长的二进制bytes，服务端收到的却是长短不一的bytearray。
基于对著名框架的信赖，只考虑可能输入数据的问题。浪费了一天时间后突然意识到也没有可能是本身通讯框架的问题？
用谷歌检索了英文网站发现果然有人提到了类似的情况：https://stackoverflow.com/questions/47373976/why-is-my-protobuf-message-in-python-ignoring-zero-values，即 “0” 被忽略了！
也就是说如果一个10 bytes长的字节流是 0123456789 (此处为简单理解，对二进制数据使用十进制表示法），那么只能收到 123456789。如果0出现在首尾还好说，如果出现在中间那就彻底破坏了二进制流的结构。尽管protobuf解释了自己这样设计的缘由是为了节省通讯资源，但是为了解决这个问题，我不得不使用更多的资源……因为我需要将二进制的bytes转写成string，反而增加了数据量。
由于对gRPC的涉猎较浅，不确定该问题是否有更通用的解决方法，如果对该问题有了解，欢迎指正。