Accelerated Mobile Pages（简称 AMP）是 Google 带领开发的开源项目，主要为了提升移动设备对网站的访问速度，大概包括 AMP HTML、AMP JS 和 AMP Cache 三部分，非常适合博客及新闻展示类的静态网站。

有关 AMP 的详细介绍可以参考其官方网站：

https://www.ampproject.org/zh_cn/

AMP 网页只能使用 AMP HTML 中允许的有限的标签，不允许使用 AMP Runtime、AMP Components 之外的 JS，而且 AMP Runtime、Components 都必须从 cdn.ampproject.org 加载，因此目前 AMP 网页都必须在翻墙状态下才能正常浏览。

AMP Cache 是负责缓存并传输 AMP 页面的 CDN 服务器，用户在 Google 移动端中点击 AMP 网站时，实际访问的是缓存过的页面。

WordPress 启用 AMP 的问题

WordPress 官方提供了 AMP 插件以支持直接为博客开启 AMP 加速，只是官方插件要求 WordPress 最低为 4.4 版本。

由于我的博客安装了 qTranslate 这款多语言插件，而该插件却只支持到 WordPress 3.8.1 版本，如果升级 WordPress 到最新版本，qTranslate 插件就会自动禁用。然而 qTranslate 插件是对 WordPress 数据库直接进行修改的，禁用之后博客文章就可能会同时显示多种语言的内容，这样显然是不可接受的。

虽然网上已经有人继承 qTranslate 原作发布了例如 qTranslate X 之类的支持新版本 WordPress 的插件，但为了数据安全（其实是懒）考虑我暂时还是不打算直接升级 WordPress 了。

不过还好我在 WordPress 插件库里找到一款看起来支持 WordPress 3.8 的 AMP 插件：AMP for WP，毕竟看此插件的介绍和评分都比官方的 AMP 插件要强哦，而且最低只要求 WordPress 3.0 版本。

AMP for WP 安装起来还是非常顺利的，插件选项里目前基本只提供了 Google Analytics UID 的设置选项，启用之后访问 AMP 版网站的方法是在地址后面加上 ?wpamp 后缀。

不过我刚开始测试访问 AMP 首页和文章就碰到问题了，直接没有任何显示了，看网页源代码输出信息不全，显然是 AMP for WP 插件对老版本 WordPress 兼容性还是有点问题。

修改 AMP for WP

首先修改 AMP for WP 插件的 wp-amp-ninja/admin/common.php 文件，打开 PHP 报错开关：

error_reporting(1);

这下访问博客首页和文章页面就能看到详细报错了：

Fatal error: Call to undefined function get_the_permalink() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-front.php on line 24

Fatal error: Call to undefined function the_posts_pagination() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/template/wpamp-content.php on line 53


Fatal error: Call to undefined function the_archive_title() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-functions.php on line 600

Fatal error: Call to undefined function the_archive_description() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-functions.php on line 601

经过查阅 WordPress 官方文档发现：

1. get_the_permalink 函数在 WordPress 3.9.0 版本开始引入，其实就是 1.0.0 版本就已经有的 get_permalink 函数；
2. the_posts_pagination 函数在 WordPress 4.1.0 版本开始引入，一同引入的还有 the_posts_navigation 函数，与 get_the_permalink 函数一样都位于 WordPress 代码库的 wp-includes/link-template.php 文件；
3. 至于 the_archive_title 和 the_archive_description 函数的功能比较类似，支持显示文章的标题和描述并在前后插入自定义代码，同样也在 WordPress 4.1.0 版本开始引入，位于 WordPress 代码库的 wp-includes/general-template.php 文件。

由此可见，AMP for WP 实际上应该至少要求 WordPress 4.1.0 版本，只是作者并没有测试过是否兼容较低版本的 WordPress。

不过还好我看了下 WordPress 最新 4.8 版本的代码，上面缺少的几个 WordPress 内置函数都是功能比较独立的。

因此我稍微修改了一下博客目录下的 link-template.php 和 general-template.php 文件，将最新版本的 get_the_permalink、the_posts_pagination、the_posts_navigation、the_archive_title、the_archive_description 函数实现分别 Backport 到 WordPress 3.8 版本。Backport 完成之后再访问博客首页和文章，就没有 PHP 报错了。

不过初步试用下来，我还是发现 AMP for WP 插件的一些小问题：

1. 如果通过 qTranslate 插件访问博客的英文版本（通过增加 ?lang=en 地址后缀），对应的 AMP 版页面地址会不正确，AMP for WP 插件在转换地址时并没有考虑地址中会带有其它后缀的情况；
2. AMP for WP 对于带有多种语言标题的文章直接显示数据库中多种语言合并在一起的标题效果，而并不是 qTranslate 插件根据客户端语言自动处理后的效果，这个问题在我使用的几个 WordPress 主题中都不会出现；
3. 文章中插入的多行代码被合并成一行显示了，这是明显不能接受的；
4. 文章的中文发表时间无法正确显示，统一显示为当前日期。

第一个问题需要修改 AMP for WP 插件的 wpamp-front.php、wpamp-functions.php、wpamp-header.php 这几个文件中转换地址的代码，例如 wpamp-front.php 文件的修改：

 		$the_permalink = get_the_permalink( $post->ID );
 	}
 	
-	$the_permalink = rtrim( $the_permalink, '/' ) . '/';
+	$the_permalink = rtrim( $the_permalink, '/' );
 	$perma = strpos( $the_permalink, "?" );
 	if ( $perma === false ) {
+		$the_permalink .= '/';
 		$sConnector = "?";
 	} else {
 		$sConnector = "&";

第二个问题需要修改 wpamp-content.php 文件，文章标题要做 apply_filters 处理：

                 <div id="amp-pagination">
                 	<?php $prev_post = get_previous_post(); if (!empty( $prev_post )): ?>
-                    	<div class="prev"><a href="<?php echo wp_amp_permalink($prev_post->ID, AMP_CONSTANT); ?>"> &laquo; <?php echo $prev_post->post_title ?></a></div>
+                    	<div class="prev"><a href="<?php echo wp_amp_permalink($prev_post->ID, AMP_CONSTANT); ?>"> &laquo; <?php echo apply_filters( 'the_title', $prev_post->post_title, $prev_post->ID ); ?></a></div>
 					<?php endif ?>
 					<?php  $next_post = get_next_post(); if (!empty( $next_post )): ?>
-                        <div class="next"><a href="<?php echo wp_amp_permalink($next_post->ID, AMP_CONSTANT); ?>"><?php echo $next_post->post_title ?> &raquo; </a></div>
+                        <div class="next"><a href="<?php echo wp_amp_permalink($next_post->ID, AMP_CONSTANT); ?>"><?php echo apply_filters( 'the_title', $next_post->post_title, $next_post->ID ); ?> &raquo; </a></div>
 					<?php endif ?>
                     <div class="clearfix"></div>
                 </div>

第三个问题就比较简单了，将 simple_html_dom.php 文件中替换回车和换行符的处理去掉就可以了。

第四个文章发表时间的问题也可以修改 wpamp-content.php 文件简化处理：

                     <?php endif; ?>
                     By <span class="amp-wp-author"><a href="<?php echo wp_amp_permalink( NULL, AMP_CONSTANT, get_author_posts_url( get_the_author_meta( 'ID' ) ) ); ?>"><?php echo esc_html( get_the_author() ); ?></a></span>
-                    <?php $the_time = date_i18n( get_option( 'date_format' ), strtotime( get_the_time('F jS, Y') ) ); ?>
-                    on <time datetime="<?php echo $the_time; ?>"><?php echo $the_time; ?></time>
+                    on <time datetime="<?php echo get_the_date('c'); ?>"><?php echo get_the_date('c'); ?></time>
                 </li>

另外我还对 AMP for WP 插件的页脚处理做了点小修改，将页脚上切换到博客首页桌面版本的链接改为切换到当前文章的桌面版本，方便访问者使用。

总结

对 AMP for WP 插件修改完成之后就可以访问博客的 AMP 版进行验证了，例如我的博客的 AMP 版首页地址就是：

https://zohead.com/?wpamp

普通用户可以通过安装 Google 推出的 AMP Validator 官方 Chrome 扩展检测所访问的 AMP 站点是否配置正确。

网站所有者可以用 Google 搜索的 AMP 在线测试工具进行检测：

https://search.google.com/test/amp

输入要测试的 AMP 版网址就可以开始检测，另外这个测试工具的另一个好处就是检测通过之后可以直接把你的 AMP 站点提交给 Google，让 Google 搜索蜘蛛尽快收录并进行 CDN 缓存。

现在通过 Google 移动端（例如 Android Chrome 浏览器）搜索我的博客，应该就能在搜索结果里看到下面的 AMP 闪电标志了：

点击搜索结果，你会发现访问的其实是 Google 缓存过的 AMP 地址，下面地址只有移动端浏览器才会显示 AMP 网页：

https://www.google.com/amp/s/zohead.com/%3fwpamp

初步启用 AMP 的大体感受就是如果你的梯子还可以，那访问 Google 缓存过的 AMP 网站速度还是非常快的，我这里估计访问 AMP 版网站所需要的流量大概为桌面版本的 1/3。

后面有时间的话还是希望能对 AMP for WP 插件继续改进，例如支持其它的 AMP 后缀或者使用专门的 AMP 子域名方便自己的服务器进行缓存之类的，最后祝大家玩的开心。

最近将 VPS 上的博客程序都迁移到 Bluemix 容器上之后，运行起来倒还算稳定，前两天手贱将 Bluemix 系统上的 LNMP 环境更新到了 1.3 版本，顺带地把 PHP 也更新到 7.0.7 版本了，不过更新完成之后访问博客就碰到了 WordPress 报错：

您的 PHP 似乎没有安装运行 WordPress 所必需的 MySQL 扩展。

这才想起来 PHP 7 已经完全移除了 MySQL 扩展支持，通过 phpinfo 也能看到老的 mysql_ 系列的函数都不能使用了，一般建议使用新的 PHP mysqli 或者 pdo 扩展进行替换。

我的博客程序使用的还是 WordPress 3.6 版本，自然不支持 PHP 7，如果直接升级 WordPress 的话又要考虑一堆 WordPress 插件的兼容性问题，于是像我这么懒的人就考虑如何把 PHP 7 的 MySQL 扩展找回来了。

找回 PHP 7 的 MySQL 扩展

由于 PHP 7 只是在发布前将对 MySQL 扩展的支持移除掉了，这样我们就可以检出遗留版本的支持 MySQL 扩展的 PHP 7 代码自行编译安装了，不过需要注意的就是 MySQL 扩展可是完全没有后续更新的了。

我们可以首先看看 LNMP 环境里 PHP 7 自带的扩展：

root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext# ls
bcmath      date      ext_skel_win32.php  gmp        json      mysqlnd  pcre          pdo_odbc    pspell      simplexml  sqlite3   tokenizer  xsl
bz2         dba       fileinfo            hash       ldap      oci8     pdo           pdo_pgsql   readline    skeleton   standard  wddx       zip
calendar    dom       filter              iconv      libxml    odbc     pdo_dblib     pdo_sqlite  recode      snmp       sysvmsg   xml        zlib
com_dotnet  enchant   ftp                 imap       mbstring  opcache  pdo_firebird  pgsql       reflection  soap       sysvsem   xmlreader
ctype       exif      gd                  interbase  mcrypt    openssl  pdo_mysql     phar        session     sockets    sysvshm   xmlrpc
curl        ext_skel  gettext             intl       mysqli    pcntl    pdo_oci       posix       shmop       spl        tidy      xmlwriter

MySQL 扩展确实已经被移除了，我们可以直接在 ext 目录下检出老的 PHP MySQL 扩展代码：

root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext# git clone https://github.com/php/pecl-database-mysql mysql --recursive
Cloning into 'mysql'...
remote: Counting objects: 145, done.
remote: Total 145 (delta 0), reused 0 (delta 0), pack-reused 145
Receiving objects: 100% (145/145), 88.41 KiB | 0 bytes/s, done.
Resolving deltas: 100% (65/65), done.
Checking connectivity... done.

使用 phpize 准备编译：

root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext# cd mysql
root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext/mysql# ls
config.m4  config.w32  CREDITS  LICENSE  mysql.mak  mysql_mysqlnd.h  package.xml  php_mysql.c  php_mysql.h  php_mysql_structs.h  README.md  tests
root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext/mysql# /usr/local/php/bin/phpize
Configuring for:
PHP Api Version:         20151012
Zend Module Api No:      20151012
Zend Extension Api No:   320151012
root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext/mysql# ./configure --with-php-config=/usr/local/php/bin/php-config

运行 make 编译之后 make install 确认 MySQL 扩展安装是否正确：

root@instance-007a20ff:/home/lnmp1.3/src/php-7.0.7/ext/mysql# make && make install
root@instance-007a20ff:~# ls /usr/local/php/lib/php/extensions/no-debug-non-zts-20151012/
fileinfo.so  mysql.so  opcache.a  opcache.so

最后修改 php.ini 配置文件，增加一行：

extension = "mysql.so"

重新启动 LNMP 程序就能在 phpinfo 里看到 MySQL 扩展了：

此时再访问 WordPress 博客就没有问题了，PHP 7 的问题初步搞定。另外网上也有人是直接把老的 MySQL 扩展静态编译进 PHP 7 程序中，这样用起来也还算比较方便的。当然后面我肯定还是要找机会直接升级 WordPress 了，毕竟 PHP 7 带着有各种漏洞的 WordPress 3.6 实在有点浪费哈，最后祝大家玩的开心。

Pocket 是我平时用的比较多的 稍后阅读 类网络服务，其收集抓取网上文章正文的效果比较好，去除页面广告等无关内容还算给力，支持标记和搜索，同步速度也还可以，免费会员限制也挺少，所以看到一些来不及马上阅读消化的文章我都会先加到 Pocket 队列里，有空时再去查看归档。

只是由于目前抓取网页正文原理的限制，Pocket 对现在越来越多的 AJAX 动态网页基本上都支持的不太好，比较典型的就是知乎专栏文章了。知乎专栏之前曾经是支持 Pocket 直接抓取的，改为 AJAX 加载数据之后，发送文章到 Pocket 之后就是这种效果：

Pocket 正常抓取的文章应该能显示摘要文字或者文章中的图片，知乎专栏文章则是空白的，而且点击文章条目也是直接跳转到知乎专栏链接，并没有显示 Pocket 抓取优化的效果。

问题分析

稍微看看知乎专栏网页代码可以发现，如果在浏览器中访问类似这样的专栏文章链接：

https://zhuanlan.zhihu.com/p/21542817

实际会加载下面的文章内容数据 API 链接，知乎专栏页面加载完数据之后才会显示：

https://zhuanlan.zhihu.com/api/posts/21542817

这种动态加载方式显然 Pocket 是不支持的，不过也好办，我们自己用 PHP 或者 Node.js 等实现一个简单的程序读取专栏文章内容并输出，然后放到 VPS 或者其它虚拟主机上运行，后面访问我自己的网址并发送到 Pocket 应该就可以使 Pocket 正确抓取了。另外这种方式比较好的一面就是输出内容里没有任何其它知乎相关的网页代码，只有专栏文章内容，更易于 Pocket 抓取处理。

PHP 程序 Pocket 抓取效果

这个 PHP 程序实在没有什么技术含量，我就直接写一个简单的 PHP 文件接受传入专栏页面 ID 的 page 参数然后输出文章内容即可：

<?php
if (!isset($_GET["page"])) {
	echo "need page id.";
	exit;
}

$PAGE_ID = $_GET["page"];
$P_HEADERS = getallheaders();

if (array_key_exists("Referer", $P_HEADERS) || (isset($_GET["redirect"]) && $_GET["redirect"] == '1')) {
	header("Location: https://zhuanlan.zhihu.com/p/" . $PAGE_ID);
	exit;
}
?>
<!DOCTYPE html>
<html>
<head>
<meta name="referrer" content="never"/>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<?php
$PAGE_DATA = file_get_contents("https://zhuanlan.zhihu.com/api/posts/" . $PAGE_ID);
$PAGE_OBJ = json_decode($PAGE_DATA);
echo '<title>' . $PAGE_OBJ->{"title"} . '</title>';
?>
<link rel="shortcut icon" href="https://static.zhihu.com/static/favicon.ico" type="image/x-icon">
</head>
<body>
<h1>
<?php
echo $PAGE_OBJ->{"title"};
?>
</h1>
<div>
<?php
echo $PAGE_OBJ->{"content"};
?>
<div>
</body>
</html>

上面的程序只是简单做了下判断，如果请求头中包含 Referer 信息（例如从 Pocket 网站跳转等）或者请求地址中 redirect 参数值为 1 就会直接跳转到知乎专栏页面，默认则输出专栏文章内容。另外程序中使用了 getallheaders 函数得到 HTTP 请求头信息，默认只支持 Apache，如果你要在 nginx 等服务器上使用则稍微修改下即可。

另外程序中还将 referrer 值指定为 never 防止页面引用知乎图片等资源时触发知乎的防盗链机制。

把上面的 PHP 程序放到虚拟主机上，访问类似下面的链接（单纯演示用，需要翻墙哦）：

http://devio.us/~nocwat/zhihu-grub.php?page=21542817

正确显示文章内容后，将上面的链接发送到 Pocket 稍等片刻就能在 Pocket 队列里看到抓取的专栏文章了。

提示

由于知乎专栏中的图片做了防盗链策略，直接访问上面的链接可能会出现文章中的图片不能正确显示的问题，不过没关系，Pocket 会自动为我们抓取保存文章中的图片的。

最后来看看我的 Pocket 队列里的显示效果：

而且点击文章条目进入也能看到 Pocket 优化过的文章内容，在 Pocket 中点击 查看原始文档 也能自动跳转到知乎的专栏文章页面，这样再也不用担心专栏作者删除文章之后就没办法查看咯。

一段时间以来我都算是 Pocket 和 Evernote 的忠实用户，Pocket 用于采集网上看到的想要稍后预读的文章，遇到比较好的内容觉得该记录下来的就记录在 Evernote 里，这样 Evernote 基本被我用来做个人知识库了，平常比较零散的个人信息之类的则记录到 Google Keep 中。

最近在 Android 手机上碰到几次比较奇怪的 Evernote 数据库错误之后还是觉得 Evernote 虽然有相对还算好用的离线、同步、搜索等功能，但也有一些问题：

• 众所周知的编辑功能确实比较烂，不支持 Markdown，对于表格等稍微复杂点的内容那编辑效果简直惨不忍睹；
• 只有笔记本组和笔记本这两层结构对于我来说始终还是觉得不够；
• 客户端里所有笔记数据都放在 SQLite 数据库文件感觉稳定性一般。

再加上最近 Evernote 这头大象给人的前景似乎一直不太好，所以我就想找到一个相对比较简单优雅的个人知识库系统，最好是能直接支持 Markdown 格式，不需要复杂的搭建步骤，能方便的在我的 VPS 和本地跑起来，当然 Evernote 我暂时还是不会弃用的。

MDwiki 和 Wikitten 对比

我找了几个比较流行的 Wiki 系统，开始就跳过了 MediaWiki 这种看起来略复杂的系统，也简单看了看很多网友推荐的 DokuWiki，甚至还有 TiddlyWiki 这种直接单文件的 Wiki 方式，初步考虑后想用 MDwiki 这个基于 Markdown 而且超级简单的纯静态 Wiki 系统。

MDwiki 相对于其它 Wiki 系统的最大好处是其单纯使用浏览器就可以解析 Markdown 文档，部署可算是超级简单了，VPS 上只要有 Web 服务器就可以访问（纯静态不需要 PHP 支持），甚至在 PC 本地也可以直接打开（虽然 IE11 和 Chrome 浏览器上已经不支持请求本地文件了）。

按照 MDwiki 官网的介绍生成一个 Wiki 主页还是非常简单的，网上的说明也比较多这里就不介绍了，如果知识库内容比较少用 MDwiki 还是很方便的，但我想稍微增加一些内容时就发现了 MDwiki 一些明显的不足：

• 导航菜单只支持两层，这个是 MDwiki 使用的 Bootstrap 的限制，而且如果有很多层目录，每个目录下又有不少 Markdown 文档，直接全部放在导航菜单里那体验也是比较糟糕的；
• 由于纯静态的限制，如果在某个目录下增加了 Markdown 文档，那就需要同步修改导航菜单，或者在其它页面里加上指向新文档的链接，这样如果需要动态修改更新实在有点麻烦；
• 同样由于纯静态的限制，基本没有办法实现搜索功能，如果后续知识库文章较多那还需要同步下来对文件夹进行搜索；
• MDwiki 只有一个主 html 文件，切换文章是用 AJAX 异步加载 Markdown 文档然后解析显示的，这样就意味着 MDwiki 对于搜索引擎来说是非常不友好的，基本没有实际可用内容。

因此我还是想实现既能兼顾 MDwiki 直接使用 Markdown 的方便之处又能解决上面列出的问题，最后还是找到了 Wikitten 这个用 PHP 实现的 Wiki 系统。

Wikitten 与 MDwiki 不同之处在于 Markdown 文档是由 PHP 程序解析并直接转换为 HTML 返回给浏览器的，而且配置好知识库目录之后访问就可以显示完整的目录树（有修改更新时也不用手工修改其它 Markdown 文件了），也有比较简单的搜索功能，可以直接把源代码文件以比较漂亮的形式显示出来。

我部署的 Wikitten 系统运行效果图如下：

综合考虑之后我准备对 Wikitten 和 MDwiki 做出少量修改，以实现在我的 VPS 服务器上主要还是用 Wikitten 来动态展示，需要在本地直接查看修改时也可以用上 MDwiki，这样就能兼顾两者的优点了。

MDwiki 的修改

对 MDwiki 的修改主要考虑到要能方便的找到目录树的 Markdown 文档，修改如下：

1. 把 Markdown 文档放到单独的目录中，我是直接改成放到和 mdwiki.html 主文件相同路径的 library 目录，这与 Wikitten 的默认知识库目录是一致的，这样 Wikitten 和 MDwiki 就可以共用 Markdown 文档了；

2. 支持识别 Markdown 文件开头添加的 YAML front matter 数据，front matter 可以用来表示 Markdown 文档的标题、作者、标签等信息；

   提示

   MDwiki 新增加的 font matter 支持需要修改 config.json 配置文件增加 "parseHeader": true 进行开启。

   Wikitten 是直接支持 YAML front matter 的并能动态生成到 HTML 数据中的，常见的 front matter 数据格式是这样的：

   ---
   "title": "Wiki site",
   "tags": ["tag1", "tag2", "tag3"],
   "author": "xxx"
   ---
   

   注意

   上面的格式中开头和结束是 3 个横线，而且开头以及结束的横线和中间的实际 front matter（也就是 meta data）内容之间只有一个回车哦；下面修改后的格式也是类似的。

   不过上面这种格式很多 Markdown 编辑器却是不支持的显示有问题，这里我改成了和 MDwiki 暂未发布的开发版本中一致的形式：

   ```
   "title": "Wiki site",
   "tags": ["tag1", "tag2", "tag3"],
   "author": "xxx"
   ```
   

3. 我写了一个自动生成 Markdown 知识库目录下面所有子目录索引文件 index.md 的 shell 脚本 generate-index.sh 给 MDwiki 使用，使用起来也很简单：

   (trusty)zzm@localhost:~/wiki$ ./generate-index.sh library
   Generate index file: library/生活/index.md
   Generate index file: library/阅读/index.md
   Generate index file: library/技术/网络/index.md
   Generate index file: library/技术/硬件/USB/index.md
   Generate index file: library/技术/硬件/PCI-E/index.md
   Generate index file: library/技术/硬件/index.md
   Generate index file: library/技术/存储/index.md
   Generate index file: library/技术/index.md
   Generate index file: library/技术/音视频/index.md
   Generate index file: library/技术/Linux/内存管理/index.md
   Generate index file: library/技术/Linux/文件系统/index.md
   Generate index file: library/技术/Linux/开发工具/index.md
   Generate index file: library/技术/Linux/index.md
   Generate index file: library/技术/Android/index.md
   Generate index file: library/技术/Docker/index.md
   

   generate-index.sh 脚本会查找输入的 Markdown 知识库目录并判断是否需要生成子目录下的索引文件（如果用户自己单独写了 index.md 文档就不会直接覆盖）；

   编写者在创建新的 Markdown 文档或者删除更新时，只需要再运行 generate-index.sh 脚本就可以自动更新知识库中所有目录的索引。

   我修改的 generate-index.sh 自动生成脚本下载地址在这里（也可以从文章最后的版本库里检出）：
   http://mdwiki.zohead.com/generate-index.sh

这样修改之后 MDwiki 里就可以通过指向目录的索引文件以间接实现目录树功能（只是需要像 Windows 资源管理器那样一层层往下），同时这种方式生成的每个子目录的 index.md 索引文件也可以给 Wikitten 使用（Wikitten 自带目录树功能基本很少会用到索引文件）。

MDwiki 下访问目录的效果（使用脚本自动生成的索引文件）：

Wikitten 的修改

由于 Wikitten 的基本功能都算可以用了，故我对 Wikitten 只有一些小改动：

1. 同时兼容上面说明的 Markdown 文件开头的两种 YAML front matter 形式，可以实现和 MDwiki 下面基本相同的效果；
2. 浏览具体目录页时 Wikitten 原有处理是直接提示用户从左边目录树中选择，这里我稍微修改为自动判断该目录下是否有 index.md 文件，存在则直接解释显示 Markdown 文档；
3. 修正上面的 generate-index.sh 脚本生成的目录索引 Markdown 表格的显示效果。

同时部署 Wikitten 和 MDwiki

部署 Wikitten

Wikitten 部署参照其官网的说明一般没什么问题，只是 Wikitten 需要至少 PHP 5.3 版本，为此我还专门对 VPS 上 LNMP 套件里的 PHP 进行了升级，同时 Wikitten 也需要开启 PHP 的 fileinfo 模块。

Wikitten 需要 Web 服务器支持 rewrite，其版本库中自带了 Apache 适用的 .htaccess 文件，这里贴下适用于 nginx 的我的 Wiki 主域名 wiki.zohead.com 的 vhost 配置给大家一个参考：

server
{
	listen 80;

	server_name wiki.zohead.com;
	index index.html index.htm index.php default.html default.htm default.php;
	root /home/wwwroot/wiki.zohead.com;

	location ~* ^/static/(css|js|img|fonts)/.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt|swf|pdf|txt|bmp|eot|svg|ttf|woff|woff2)$ {
		access_log off;
		expires max;
	}
	location / {
		rewrite ^(.*)$ /index.php last;
	}
	location ~ /index.php$ {
		try_files $uri =404;
		fastcgi_pass  unix:/tmp/php-cgi.sock;
		include fastcgi.conf;
	}
}

其实也是比较简单的，参考 Wikitten 自带的 .htaccess 就可以修改过来，主要是下面的 rewrite 规则配置正确就可以了。

部署 MDwiki

这里为了和上面的 Wiki 主域名 wiki.zohead.com 区分，我为 MDwiki 站点单独搞了个 Wiki 备用域名 mdwiki.zohead.com，这个的配置就非常简单了，只要最基本的 vhost 配置就可以了：

server
{
	listen 80;

	server_name mdwiki.zohead.com;
	index index.html index.htm default.html default.htm;
	root /home/wwwroot/wiki.zohead.com;
}

可以看到这个 MDwiki 备用域名的主目录和上面的 Wikitten 是一样的，只是刚好把 index.html 给 MDwiki 使用，index.php 给 Wikitten 使用。

综述

说了这么多，下面是我的初步 Wiki 知识库演示效果了。这样修改之后对于我来说最大的好处是当发现哪个用的不爽时可以无缝切换，毕竟现在这两个系统的目录结构和数据是完全共用的，哈哈。

Wikitten 动态主站请访问：

http://wiki.zohead.com/

备用 MDwiki 纯静态站点请访问：

http://mdwiki.zohead.com/

整个 Markdown 知识库目录我是使用 BitTorrent Sync 进行本机和 VPS 之间的同步，另外我把整合和修改过的 Wikitten 和 MDwiki 基础代码放到了一起，并在 GitHub 上建立了一个版本库：

https://github.com/zohead/wikitten-and-mdwiki

大家有兴趣的话可以检出这个版本库自行修改部署哦，项目主页上也有一些介绍说明，如果你不需要同时支持 Wikitten 和 MDwiki 的话也可以自己取舍的，毕竟这个版本库里 MDwiki 的代码只有根目录下的 index.html 这一个文件。

Wikitten 的配置文件为根目录下的 config.php，MDwiki 的配置文件为根目录下的 config.json，还是比较一致的哈。

如果你只想要 Wikitten 系统的话那删除 index.html、config.json 文件即可，如果你只需要 MDwiki 那也只用保留 index.html、config.json 和 generate-index.sh 这几个文件。

最后本文及对应版本库中有任何问题欢迎提出指正哦，祝大家玩的开心 ^_^。

之前我是使用 fulltextrssfeed.com 这个网站来辅助生成全文 RSS 输出的，但现在发现 fulltextrssfeed.com 对于我实际要用的几个 RSS 源没有什么作用了，经常不能输出有效的信息。

最后在网上找到 fivefilters.org 也提供了类似的服务，在其网站上输入原始的 RSS 源地址就可以输出全文 RSS 内容，看起来确实是比较好用，但这个网站默认只输出 3 条最近的文章的限制确实还是有点坑。不过好在 fivefilters.org 把他们的全文 RSS 程序开源了，用户可以使用这个程序自己搭建一个全文 RSS 输出系统，虽然他们最新版本的全文 RSS 程序是需要购买的，但是老版本的程序是可以免费下载使用的（只是不对老版本提供技术支持）。

按照 fivefilters.org 网站的说明，找一个支持 PHP 的普通主机就可以使用了，首先访问其项目主页并检出最新的 full-text-rss 的源代码：

https://bitbucket.org/fivefilters/full-text-rss

解压缩放到 PHP 空间目录里，把目录中的 config.php 拷贝为 custom_config.php，然后就可以修改 custom_config.php 配置文件：

$options->max_entries = 10;
$options->caching = true;
$options->key_required = true;
$options->api_keys[1] = 'secret-key-1';

上面列出了几个常用的配置项，max_entries 表示最多输出多少篇文章，caching 最好改为 true 这样可以启用缓存防止每次请求时都需要重新产生 RSS 输出，另外 key_required 和 api_keys 也可以启用，这样就可以为 RSS 全文输出系统增加密码验证功能，防止被其它用户使用（如果你是壕而且主机毫无压力的话大可以不设置密码并共享给其他人使用哦 ^_^）。

修改完成之后通过浏览器访问 full-text-rss 目录就会出现全文 RSS 的界面了：

全文RSS输出配置

输入原始 RSS 源的地址（这里以虎嗅为例），输入密码（就是 Access Key 了）并选择最大输出文章数，点击 Create Feed 按钮之后一切正常的话就会出现全文 RSS 输出了，此时显示的地址就可以给 feedly 等各种 RSS 阅读器使用咯。

上次博客空间提供商突然被 GFW 封了一天，想着用这临时的免费主机不太保险，准备随便买个国外空间试试的，发现了这个 GigaWebHost，结果各种经历不吐不快，这空间主页：

http://gigawebhost.com/

看空间主页介绍的似乎很不错的，Features 里写的 30G 空间，似乎无流量限制，3万个子域名，PHP/MySQL/Zend 等都支持，最主要还支持我比较看重的 SSH Shell 功能，而且只要 1欧元 1个月，算起来一年也就 100 RMB，相当划算，就在主页上点了个申请试用，结果这坑爹的所谓两小时试用还必须付款才可以，崩溃ing。后来看这空间似乎是个德国主机，德国主机一向质量还不错，就准备顺便买一个月（这个主机是月付）看看，结果在选域名那发现悲催了，只能选免费的二级域名，使用已有的域名要 30~50欧，还是每年，而主机本身一年才 12欧，FAKE，这简直是。。。 -_-#

好吧，都到这份上，先搞个免费的二级域名看看速度再说吧，然后试试在 CPanel 里 park domain 看看吧，用信用卡付款开通之后进 CPanel，悲剧了，默认的 CPanel 英语管理界面被 “智能” 滴翻译成了阿拉伯语，再汗。切成英语之后，死活找不到 park domain 的地方，oops，我认了，先看看 SSH 咋登录，准备把博客程序通过 SFTP 压缩上传上去再解压，这样备份和恢复网站内容是必须方便的哇。

结果在 SSH Shell 面板，再次吐血，默认 SSH Shell 不开通（FAKE，你 Features list 里写它干啥。。。），提示必须联系客户开通。好吧，我还是有耐性的，大不了联系客户呗，找到 submit ticket，用英文写了一段需求说我为什么要开通 SSH，顺便小问了下能不能帮开通下 park domain（因为这个对 CPanel 来说是非常简单的），提交 ticket。

然后开始等的过程，然后，然后，然后，就等了一个星期，德国人终于回 ticket 了，说开通 SSH 必须提交护照副本（我去，还护照副本，也不看我从哪来的。。。），而关于 park domain 则只字未提，我当即在 ticket 里回复：没有护照副本，park domain 能否开通？然后又是等待，5 天都没回，好吧，折腾不起了，果断取消空间和后续付费，还好也就花了首期的 1欧元，取消原因填上：never wanna use it again, never ~~~~

结束语：烂空间伤不起，各种选择主机请务必谨慎，作为前车之鉴咯~~~

前两天写了一个友言近期评论的 WordPress Widget，初步测试还能用，但多次进行刷新，会出现不能正常登录之类的问题（Failed to authentication with uyan.cc、Invalid comments data from uyan.cc 之类的报错），而且原来每次都需要登录友言的后台管理严重影响速度，我也比较怕怕这样不断发请求会导致友言把我的脚本和博客给封掉，嘿嘿。

由于友言没有公开 API 给我等码农来调用，因此今天又花了点时间做了一些改进，弄了个 1.1 版本，原介绍文章在这：

https://zohead.com/archives/wordpress-uyan-recent-comment-widget/

1.1版本更新说明：

1、登录友言后台管理，得到近期评论等地方增加错误处理，如果服务端返回的 JSON 数据不对则报错
2、减少 PHP 本身的 error message 输出
3、将得到近期评论的功能分离为一个函数单独调用
4、登录成功之后保存得到的 cookies 到同目录下的 uyan_cookie.php 文件中方便下次直接使用，而无需再重复登录，如果 cookie 过期下次获取评论时失败则再重新登录
5、发查询近期评论请求时增加友言本身的管理地址作为 referer

此次增加了一个 uyan_cookie.php 文件用于保存 cookie，从下面的链接下载解压缩之后，请将此文件也上传到同一目录中（不上传的话 PHP 可能会报 require_once 出错），此文件默认为空，详细代码就不贴了，直接在下面下载查看吧。友言 的登录邮箱、密码、域名之类的修改请参考原始的介绍文章了。

这个是 1.1 版本的下载地址：

http://miseal.googlecode.com/files/uyan_comments_v1.1.zip

当前的通过临时文件保存 cookie 方式应该还有改进空间，有任何问题欢迎指正咯 ^_^

现在有很多人都使用 WordPress 来搭建自己的博客系统，其中有一些是像我这样使用 友言 这个社交评论插件来替代系统原始的评论框的，友言 评论框插件对一些主流的社交网站支持比较好，很是推荐，友言官网：

http://uyan.cc/

之前我写过一个修改 友言 插件实现完美与 WordPress Mobile Pack 插件配合实现移动版博客的文章，在这里仅供参考：

https://zohead.com/archives/modify-plugin-wordpress-mobile-pack/

但现在发现还是有一点不足，由于使用了友言评论框替代 WordPress 本身的，导致 WordPress 的 ”近期评论“ Widget（小工具）显示不了，因此小折腾一个晚上，靠着还依稀记得的 PHP 编程经历，写了一个简单的显示 友言 近期评论的 WordPress Widget，先看效果图（本博客右侧就有 ^_^）：

原理及代码：

实现原理比较简单，先用工具分析 友言 评论的后台登录和评论显示之类的 HTTP 包信息，然后用 PHP 的 fsockopen 来自己发送 GET、POST 请求实现在 WordPress 上列举显示已经存在的友言评论（备注：默认只显示已经经过审核的评论）。

由于中间有几步 GET 和 POST 请求，就找了个现成的 post-to-host 这个很小的 PHP 脚本来发 GET 和 POST 请求，下载地址：

http://code.google.com/p/post-to-host/

下面是主程序 uyan_comments.php 的代码：

<?php
// global site information
$email = "xxxx login email xxxx";
$password = "xxxx encrypted password xxxx";
$domain = "xxxx domain name xxxx";
$maxcomments = 10;

require_once("post_to_host.php");

header("Content-Type:text/html; charset=utf-8");

// Login to uyan.cc
$url = "http://uyan.cc/index.php/youyan_login/userAutoLoginCrossDomain?email=" . $email . "&loginPassword=" . $password . "&rem=1&domain=" . $domain;

$ret_str = post_to_host($url, array(), array(), "", $ret_head, 0);
$ret_str = trim($ret_str, "()");

if ($ret_str == null || $ret_str == 'noData' || $ret_str == '"noData"') {
	echo("Failed to authentication with uyan.cc");
	return;
}

$ret_json = json_decode($ret_str, true);

// check response JSON data
if (!array_key_exists('uid', $ret_json) || !array_key_exists('uname', $ret_json)) {
	echo("Invalid data from uyan.cc");
	return;
}

// delete unneeded 'auth' cookie key
$arr_cookie = get_cookies_from_heads($ret_head);
unset($arr_cookie['auth']);

// need this to set uid and uname
$url = "http://uyan.cc/setting?uid=" . $ret_json['uid'] . "&domain=" . $domain . "&uname=" . $ret_json['uname'];
$ret_str = post_to_host($url, array(), $arr_cookie, "", $ret_head, 0);

// get comment
$url = "http://uyan.cc/youyan_admin/getMoreCommentsByDomain/0";
$get_comment_params = array('currentMore' => '0', 'normalCommentToogle' => '1', 'readyCommentToogle' => '0', 'trashCommentToogle' => '0', 'delCommentToogle' => '0');

$ret_str = post_to_host($url, $get_comment_params, $arr_cookie, "", $ret_head);

$comment_json = json_decode($ret_str, true);
$nr_comments = 0;

echo("<ul>");

foreach ($comment_json as $comment) {
	$display_name = "";
	$display_title = "";

	if ($maxcomments >= 0 && $nr_comments >= $maxcomments) break;

	// must with valid URL and page title
	if (!array_key_exists('page_url', $comment) || !array_key_exists('page_title', $comment) || strlen($comment['page_url']) <= 0 || strlen($comment['page_title']) <= 0)
		continue;

	// must with a valid display name
	if (array_key_exists('comment_author', $comment) && strlen($comment['comment_author']) > 0)
		$display_name = $comment['comment_author'];
	else if (array_key_exists('show_name', $comment) && strlen($comment['show_name']) > 0)
		$display_name = $comment['show_name'];
	else
		continue;

	$display_title = $comment['page_title'];
	$pos = strpos($display_title, ' | ');
	if ($pos >= 0) $display_title = substr($display_title, 0, $pos);

	echo('<li>' . $display_name . '&nbsp;<strong><font color="#0000FF">&gt;&gt;</font></strong>&nbsp;<a href="' . $comment['page_url'] . '">' . $display_title . '</a></li>');

	$nr_comments++;
}

echo("</ul>");
?>

代码本身比较简单，有些 PHP 基础就可以看懂了，把 uyan_comments.php 文件最上面的 $email、$password、$domain、$maxcomments 改为实际的 友言 后台管理的登录邮箱、密码、你的域名、显示的最多评论数（备注：默认为10条，如果改为小于0的值则不限制显示的评论条数），就可以使用了。你应该已经发现这个 uyan_comments.php 其实和 WordPress 没太大关系，完全也可以直接单独使用。

需要注意的是为了避免使用明文密码而可能导致的问题（安全第一 ^_^），上面的 $password 是 友言 后台管理时实际用到的加密过的密码。这个加密过的密码可以通过 Firefox 的 Live HTTP headers 插件之类的抓取 HTTP 协议头的插件或工具来得到。

得到友言的加密登录密码：

下面以 Firefox 的 Live HTTP headers 插件为例说明如何得到 友言 的实际加密的密码，打开 Live HTTP headers，该插件会自动开始抓取，然后用正确的邮箱和密码登录 友言 的后台管理，停止 Live HTTP headers 的抓取，在输出里就能找到地址为如下格式的 GET 请求，请求参数中就有加密的密码：

http://uyan.cc/index.php/youyan_login/userAutoLoginCrossDomain?callback=jsonpxxxxxxx&email=xxxxx@xxxxx.com&loginPassword=xxxxxxxxxxxxxxxxx&rem=1&domain=xxx.com

其中的 email 段就是登录邮箱，loginPassword 段即为加密的密码，保存下该密码，修改 uyan_comments.php 文件中的 $email 和 $password 值。

Live HTTP headers 的抓取截图如下所示（后面的未显示完整）：

如何加入 WordPress Widget 列表中：

你如果有真正实现一个 WordPress Widget 的心思，可以用本代码加上 WordPress 的 register_widget 之类的接口来实现。无奈我是一个超级懒人，懒人就有懒人的办法，下面介绍的就是懒人的办法，哈哈。

首先下载本文最下面下载链接中的 post_to_host.php 和 uyan_comments.php，将 uyan_comments.php 中对应的 登录邮箱、密码、域名 改掉（参考上面），将这两个文件上传到 WordPress 根目录中（位置也可以自己修改），然后给 WordPress 安装 PHP Code Widget 插件，这是一个通用 Widget，添加之后，可以自行添加 文本、HTML、PHP 代码等，比较方便，插件地址：

http://wordpress.org/extend/plugins/php-code-widget/

安装之后，在 WordPress 管理后台的 外观 - 小工具 里就能看到名为 “PHP Code”  的小工具，将其托至右侧的 “第一小工具区域”，输入自定义的标题，然后加入以下代码保存即可（如果上传的位置不在 WordPress 根目录那请自行修改）：

<?php
include_once("uyan_comments.php");
?>

重新访问 WordPress，如果上面的 登录邮箱、密码、域名 设定都正确的话，应该就可以出现类似上面效果图的评论列表。

不足和改进：

1、uyan_comments.php 每次访问时都需要登录 友言 管理后台，请求评论列表，因此速度会有些影响，这个有空再改进了。

2、由于需要在 Web服务器中使用 PHP 的 fsockopen 来发 GET、POST 请求得到评论列表，因此可能对 WordPress 博客的访问速度造成一些影响，如果 PHP 空间在国内还可以，像我这样空间在国外的就稍微悲剧点了，所以建议安装 WP Super Cache WordPress 之类的插件来实现更好的缓存加速，将影响尽量降低。

下载地址（115网盘）：

http://115.com/file/beezjk3b

写博客好累，准备休息，HOHO，本文件为个人作品，有任何问题欢迎指正。 ^_^