微信有 3 亿用户, 几乎成为每个人手机上必装的应用, 而微信公众帐号则为个人开发者和商家提供了一个绝佳的 SNS 营销平台, 拥有博客的朋友们肯定也不会失掉这样的机会. 本文我会介绍一个叫微信机器人的插件, 可以将 WordPress 的文章搬到微信上.

插件介绍

微信机器人可以将你的微信公众账号和你的 WordPress 博客联系起来, 订阅者可以在微信中搜索文章. 高级版可以使用快捷回复返回热门文章, 最新文章等文章列表, 还可以设定过滤器自动回复用户信息, 还有一些不同于普通版的强大功能.

微信机器人 | 微信机器人高级版

这是 Denis 今年耗费很多心机来开发的一款插件, 基础版是免费的, 有搜索功能, 输入关键字返回文章列表; 而高级版现在更新比较快, 据说完善的差不多就要提价了, 有需要的朋友可以考虑买一个, 免费升级.

Token 设置

无论基础版还是高级版, 插件有必须设定一个 token, 用于向微信提供数据接口. 默认是 weixin 在基本设置中可以修改.

在微信公众平台的接口配置信息里面填入对应的 Token 信息, 如果使用默认配置, 应该填入如下:

快捷回复和自定义菜单

在插件的高级设置中, 可以为对应的常用功能指定快捷回复的输入. 比如: 输入 n 返回最新文章, 输入 r 返回随机文章等等, 并且这些关键字都可以自定义.

如果你已经申请了微信自定义菜单功能, 这些关键字也可以用于自定义菜单, 已经完全支持.

自定义回复

可以在自定义回复中添加过滤器, 为特定的关键字设定自动回复.

题外话

用了微信机器人插件能将 WordPress 与微信打通, 但从微信点进去的网页却还是移动浏览器看到的页面, 所以建议大家为自己的网站做个 Mobile 主题, 可以用我开发的手机主题调度插件 WordPress Mobile Themes 来进行管理.

NeoEase 的微信公众帐号是: neoease, 欢迎关注.

少于 10 个经常改动的页面应该可以算是小型网站, 当然, 博客也算是, 这个博客现在就是使用这个工具来辅助开发的. 本文作为延伸, 说说平时我是怎样利用这个工具来完成网页开发的.

拆分 JS 模块

JavaScript 模块化和细分成文件是为了减少代码的复杂度和便于代码复用, 我将网站用到的 JavaScript 代码分类以下几类:

• 第三方的框架和工具类, 沿用 YUI3 的命名定义, 我称之 Gallery 库, 比如: jQuery, Backbone
• WordPress 插件中用到的 JS 文件, 有时我们想合并掉这些文件以减少页面请求数量.
• 可以供第三方使用的组件和工具, 比如: go-top.js, sidebar-follow.js 和 view-history.js.
• 自己网站上用到的一些共用代码, 比如: NeoEase 所有页面用到的二级菜单 categories.js.
• 业务 / 页面初始化文件, 这里往往会调用其他一些组件, 还会有一些页面特有的代码. 我觉得 WordPress 这中小网站都不需要区分页面了, 作为一个入口即可.

准备配置文件

模块拆分完成后, 我们可以按照 YCombo 配置文件的方式创建一个后缀名为 .js.seed 的配置文件将 JS 文件组织起来. 我用相对路径的方式, 配置如下:

/* 第三方库 */
// #require "gallery/jquery/jquery.js"
// #require "gallery/jquery/jquery.scrollto.js"
// #require "gallery/jquery/jquery.lazyhover.js"
// #require "gallery/json/json2.js"
 
/* 组件 */
// #require "moudle/scroll-trigger.js"
// #require "moudle/view-history.js"
// #require "moudle/article-history.js"
// #require "moudle/sidebar-follow-jquery.js"
// #require "moudle/go-top.js"
 
/* 插件 */
// #require "plugin/wp-recentcomments/wp-recentcomments-jquery.dev.js"
 
/* 共用代码 */
// #require "common/social.js"
// #require "common/comments.js"
// #require "common/categories.js"
 
/* 页面初始化 */
// #require "biz/domready.js"
 
/* Rating 初始化 */
// #require "common/ratings.js"

合并和调试代码

将配置文件 xxx.js.seed 拖放到 YComboGUI 或者 JCombo 工具内, 即可得到合并后文件 xxx.js. 调试代码的时候, 为了能定位代码出错位置我们只合并不压缩, 所以我会选中 nocompress.

每次修改代码后, 点击 Combo! 重新合并代码和进行调试, 直到开发完成.

压缩和混淆代码

一旦开发完成, 取消选中 nocompress 并再次进行压缩, YCombo 通过 YUI Compressor 对代码进行合并和压缩, 可以减去注释, 额外空格, 一些细微的优化和进行标识符替换.

如果还需要进一步压缩或者混淆代码, 可以使用 Pack 等一些工具再对代码进行处理, 而我会到在线 JavaScript 压缩和混淆工具上进行一次混淆.

后话

使用 YCombo 做 JS 开发, 可以做到将细分在多个文件中的 JavaScript 合并在一起, 从而减少页面请求数量. 开发者每次修改后需要多点一次合并按钮, 但是还算是方便的, 对小型网站来说应该足够了.

哦, 对. YCombo 还可以用来处理 CSS 文件.

选择主机并不是一件很难的事情, 事先多分析一下自己的需求, 了解一些主机常识, 做点功课, 找一个适合的 WordPress 主机空间并不麻烦. 本文我会通过对用户的背景和网站的需要, 说说 WordPress 用户该如何选购博客主机, 主要是虚拟主机.

了解 WordPress 环境需要

如果要搭建一个 WordPress 网站, 搭建某个网站首先要知道需要哪些服务支持. WordPress 很简单, 它需要 PHP, MySQL 和一个 Web 服务器 (可以是IIS、 Apache 或者 Nginx) 的环境支持.

现在国内的 IDC (申请域名, 租用虚拟主机空间, 主机托管等业务的服务) 绝大部分都支持这样的环境, 毕竟 WordPress 的买家应该最多. 购买空间的时候留意一下是否支持这些即可.

比较主机的系统参数

可能看到的 10 个在售的虚拟主机中 9 个都支持 PHP + MysQL, 但其参数不尽相同, 有些事项是必须了解清楚的, 下面我列举了几个:

数据库大小限制

国内的很多主机商都是将数据库的大小和网页空间分开来算的, 他们给你一个很大的磁盘空间, 却只给你一个很小的数据库. 前段时间我看到一个 680 块钱每年的主机, MySQL数据库大小才 20M, 一般开始都要几兆了, 文章一多这么点数据库空间是明显不够用的 (NeoEase 现在的数据库都一百多兆了).

搬个主机很麻烦, 为个数据库空间换地真没必要, 所以建议选择稍微大一点的数据库空间, 起码得能支撑个三两年 (小博客的数据库算一年 5M 吧). 当然, 最好能找个不限数据库大小的主机.

域名绑定个数和搭建网站数量

大部分主机都会限制域名绑定个数的, 如果可绑定的域名个数很少的话, 当你想用一个主机搭建多个不同域名的网站时就无解了. 当然, 对于 WordPress 的 freshman 而言, 选一个可以搭建一两个网站的主机就可以了, 刚开始你也不会一口气搭建那么多网站. 在需要的时候再去找 IDC 加几个网站也可以的, 也不会太贵.

速度和稳定性

主机速度的考虑是必不可少的, 因为成本和备案的影响, 国内的绝大多数 IDC 只提供海外的主机服务, 而服务器所在地往往会影响到用户访问速度. 如果你的用户群在中国大陆, 那么香港, 韩国和日本的主机会比较快, 美国的速度也不错.

稳定性比速度更重要, 决定网站的是否可以正常运行, 还影响搜索引擎收录. 通常来讲, 主机正常运行时间在 99% 以上的主机才值得选择.

控制面板和管理方式

可能有人建站工具的技能掌握较多, 甚至直接通过命令行来操作; 但大部分人更希望通过图形化的界面来进行操作, 无论是绑定域名, 新建服务和备份网站.

操作的便易和功能的强大同样重要, 好的主机商通常能提供好的控制面板, 一般都会集成网站和域名管理, 文件管理, 文件编辑, FTP管理, 甚至压缩解压等等功能, cPanel, WebSitePanel 和 Plesk 都是非常出色的.

另外, IDC 如果能提供完备的教程那就更好了. 而对 WordPress 用户来说当然最好还能提供一键安装等功能, 一键安装可以为新手省去很多麻烦的事情, 而且不用担心兼容性的问题.

购买相关

购买的时候也有一些可以关注的点, 比如主机的类型, 操作系统, 售后服务等等.

海外主机

如果选择国外主机的有两个优势: 一是价免备案, 二是格较低.

走过备案流程的人都有过类似的痛苦, 审核慢和难以通过. 提交一次等一天, 但提交又经常被卡, 我注册过 "XXX 动物园" 因为动物园涉及到机构不给通过, 全英文不给通过, 涵盖面太广不给通过, 什么鸟理由都有, 最后还建议我将名字改成 "我的小站 XXX", 只能呵呵了.

价格低是理应的, 因为服务器运营成本低, 而且不用备案. 比如我买了某公司的云主机, 超强大一个服务器, 4000 每年却只能注册 3 个域名 (可以绑定无数个域名, 但只能备案 3 个), 对于一个小站, 来说买个国外一两百的虚拟主机真的就足够了, 主机 91 最便宜的wordpress虚拟主机做到了25每个月, 质量也是很好的.

退款服务

在使用主机空间之前谁也不好判断主机空间的质量, 好在现在许多主机都提供 7 天退款, 甚至有些主机提供 30 天退款. , 大家也可以去主机点评网站上去看一下这些主机的点评, 第三方的主机点评网站上的评论和点评通常是比较客观的, 口碑不错的主机质量一般不会太差.

后话

结合上述, 不要期望用价格直接换到好东西. 买之前了解花 20 分钟了解一下, 根据自己的情况选择一个适合自己的才是明智之举. 拿不定的时候买个支持退货的.

NeoEase 上挂的主机小广告覆盖了 30 到 500 不等的选择, 大部分都提供退款服务. 如果你是WordPress新手, 对选择主机还是没概念, 那买个像主机 91 这样便宜些的香港主机先跑起来, 再作判断. 如果你考虑小换大, 可以参考我以前写的《选择博客主机》.

但无论在 Android, iOS 还是其他移动设备上, 机器的 hosts 一般不给修改, 要通过越狱和 root 等手段来获取 hosts 的修改权限. 尽管还有 Opera Mobile Emulator 和 Weinre 等一些虚拟机和调试工具, 但真机测试是比不可少的.

所以, 我们还是希望可以通过修改 hosts 或其他方式访问到开发环境, 于是有以下一些方法:

修改设备的 hosts

一根筋地继续找方法修改移动设备上的 hosts, iOS 越狱, Android 获得 root.

这是一个土得掉渣的方法, 需要改动到移动设备, 并且修改 hosts 的成本高. 事实上我以前都是这么搞的, 我已经懒得 root 和越狱了, 才开始去寻找其他方法.

修改 DNS 解析

搭建一台 DNS 服务器, 将这个网站解析到开发机器上, 并修改手机和平板上的 DNS.

看起来很完美, 因为只需要修改一下移动设备上的网络配, 以后只需要修改服务器配置文件. 但实际上搭建 DNS 服务器是很麻烦的, 而且很浪费服务器资源.

通过代理网络

搭建一台 HTTP 代理, 移动设备通过这台机器登录网络, 即可借用代理机器的 hosts 设定.

可能有人上学时做过这样的事情: 一台电脑作为服务器共享网络给全宿舍用. 这种事我们尽干这事, 其实这里原理是一样的, 就是让手机设备通过 PC 或 Mac 使用网络.

这是我目前知道最合理的方案, 搭建代理服务器方法简单, 而且只要修改一下移动设备的代理服务即可. 与搭建 DNS 服务器不同的是: 大量的现成软件让它的实现变得简单, 并且有些工具可以在一台机器上搭建多个代理服务.

昨天我在找相关资料的时候, 发现一篇叫《利用代理实现无线 WEB 测试中的修改 hosts》的文章, 想联系作者问问, 没想到文章作者是同事王一. 他文中推荐使用遥志代理 CCProxy, 这款软件简单方便, 但经过一轮折腾, 我还是选择了 Squid. 后面我会分开讲讲如何使用这两款软件来做 Mobile Web 的测试.

本文会介绍一个 CSS 和 JS 的合并工具, 对模块化的文件进行管理.

CSS 和 JS 合并工具的发展

对于 CSS/JS 合并和压缩的问题, 有很多解决方案, 我所在的团队也经历了几个阶段.

1. 网站刚刚搭建的时候, 纯属的手动合并 CSS 和 JS 文件.
2. 因为手动易出错, 繁琐, 改为使用配置文件来管理. 当时我们用 JS Builder 和我自己写的一个叫 CSS Builder 的程序来管理, 后来同事楠乔做了一个叫 YCombo 的工具, 合并这两个工具的功能.
3. 网站扩大, 文件多起来配置文件的管理也成为负担, 所以由 URL 作为配置, 比如: http://a|b|c.css 则合并 a.css, b.css 和 c.css 三个文件; 还通过专门的服务来寻找页面中使用的 JavaScript 并自动合并.

无疑第三种的处理方式最完美, 开发者省心省力, 但因为需要专门的服务管理和部署策略. 对小型网站和个人网站来说, 前面提到的第二种方案更为实用. 本文会介绍一下这款叫 YCombo 的工具和对应的两个 GUI 工具.

YCombo 介绍

顾名思义, 它主要为了解决合并 CSS 和 JS 文件的工作, 需要依赖一个命名为 .css.seed 或者 .js.seed 的配置文件. 比如: 现在有配置文件 xxoo.js.seed, 通过 YCombo 处理后在同目录可以得到合并后的 JS 文件 xxoo.js.

YCombo 已经发布在 Github, 需要 JRE 1.6 或以上版本支持, 执行操作如下:

java -jar ycombo.jar [参数列表] [配置文件地址]

对应的参数列表和相关说明请查阅 YCombo 文档.

配置文件

.css.seed 和 .js.seed 支持两种特殊语法:

• // #require "PATH" 和 /* #require "PATH" */, 引用绝对路径的文件或者相对于本配置路径的文件.
• // #require <PATH> 和 /* #require <PATH> */, 引用基于 root 目录的文件.

YCombo 会按后续遍历顺序加载配置文件, 解决依赖问题和进行去重处理. 这里是个遍历顺序的例子:

         SEED
          /\
         A  B
        /   /\
       C   C  D
      /   /   /\
     E   E   F  G

文件引入和合并的顺序如下:

E > C > A > F > G > D > B > SEED

用户界面工具

如果前面的使用方法你看不出头绪, 没有关系. 为了方便用户使用, 我们做了两个 GUI 版本: YComboGUI 和 JCombo.

• YComboGUI: 是 YCombo 作者做的一个依赖 .NET framework 的版本, 可以在 Windows 系统使用. [下载]
• JCombo: 因为有些开发没有 Windows 开发环境, 我做的一个基于 Java 的版本, 可以在所有操作系统使用. [下载]

后话

我自己的网站一直使用 YCombo 来合并 JavaScript, 再通过 JavaScript 压缩和混淆. 我将 JS 拆分成 20 来个小粒度的文件 (包括 jQuery), 总文件大小 280KB, 合并后 170KB, 压缩和混淆后只剩 90KB.

这个工具适合个人网站和小团队开发使用, 欢迎完善, 建议和反馈.

实现原理

这个功能实现非常简单, 平白一点来说就是找个地方将页面一些信息保存起来, 如果页面两次被访问, 新的内容覆盖掉旧的内容; 在页面加载的时候, 将保存的信息取出显示.

实现方法也很多, 最土的是将内容保存在 cookie 中, 但用 cookie 储存数据存在一些问题. 比如: cookie 是随 HTTP 响应一起被发送的, 会对服务器端响应时间产生一定程度的影响, 尤其是在使用 XMLHttpRequest 对象向服务器端发送或请求数据的时候.

利用 cookie 虽然比较土, 但最实用, 因为几乎可以兼容所有浏览器. 我这里使用的 localStorage, 数据完全保存在浏览器中, 不会有影响服务器响应, 但 IE6/7 中不能使用.

这里要完成以下几个功能点:

• 将存储内容转成数组对象, 因为 localStorage 只能保存字符串.
• 去重, 如果保存的内容已经存在, 则删除旧数据, 以最新的为准.
• 限制保存数量, 没有必要无限保存历史导致列表超长.

实现步骤

我已经写好了一个名为 View History 的脚本, 不到 50 行代码, 就是为了实现上述的三个功能. 可以在 Github 中下载.

1. 引用脚本并初始化对象

<script src="view-history.js"></script>
<script>
/* <![CDATA[ */
if(typeof localStorage !== 'undefined' && typeof JSON !== 'undefined') {
    var viewHistory = new ViewHistory();
    viewHistory.init({
        limit: 5,
        storageKey: 'viewHistory',
        primaryKey: 'url'
    });
}
/* ]]> */
</script>

2. 在文章页面保存浏览信息

<script>
/* <![CDATA[ */
// 如果 ViewHistory 的实例存在，则可以将页面信息写入。
if(viewHistory) {
    var page = {
        "title": document.getElementsByTagName('title')[0].innerHTML,
        "url": location.href // 这是 primaryKey
        // "time": new Date()
        // "author": ...
        // 这里可以写入更多相关内容作为浏览记录中的信息
    };
    viewHistory.addHistory(page);
}
/* ]]> */
</script>

3. 显示历史浏览记录

<script>
/* <![CDATA[ */
var wrap = document.getElementById('view-history');
 
// 如果 ViewHistory 的实例存在，并且外层节点存在，则可显示历史浏览记录
if(viewHistory && wrap) {
    // 获取浏览记录
    var histories = viewHistory.getHistories();
 
    // 组装列表
    var list = document.createElement('ul');
    if(histories && histories.length > 0) {
        for(var i=histories.length-1; i>=0; i--) {
            var history = histories[i];
 
            var item = document.createElement('li');
            var link = document.createElement('a');
            link.href = history.url;
            link.innerHTML = history.title;
 
            item.appendChild(link);
            list.appendChild(item);
        }
 
        // 插入页面特定位置
        wrap.appendChild(list);
    }
}
/* ]]> */
</script>

后话

只用 localStorage 做历史浏览记录不能解决时效性问题, 也就是不能获得最新的文章信息. 如果我将文章评论数加到浏览记录中, 那么用户看到的仅是他访问当时的评论数量. 解决办法是有的, 有些网站只保存文章的 ID, 在页面加载时再动态加载文章信息, 比如: 评论数和平均评价.

在我看来, 作为博客保存到 localStorage 已经足够了, 至于你要怎么用我就管不着了.

左侧边栏宽度只有右侧边栏的一半, 只在宽屏的 IE8 或更新的浏览器展示, 我打算用来放一些辅助信息. 在首页会显示一些跟导航相关的内容, 有分类和标签云; 在文章详细页面, 显示文章目录作为内导航.

为什么新增左侧边栏?

对于左侧边栏的内容, 其实我没有完全准备好. 我原本希望在分类和日期存档页面中可以显示 Refined Filter, 一些相关的过滤规律. 比如: 在 #A 分类的页面, 可以过滤作者, 选择作者 #1 则将显示内容变为 #1 的所有 #A 的文章列表. 因为 WordPress 虚弱的搜索功能, 这样的功能并没有原生支持, 也找不到较好的插件.

不过对于宽屏的读者来说, 固定宽度的两边的留白实在太浪费了, 而过去的一段时间我已经将博客的分类整理好了, 很想加强类目导航, 所以最后还是增加了这一栏, 以后慢慢完善.

浏览器兼容性考虑

主题更新完没多久, 就有人问我为什么不用响应式布局. 响应式布局想在吹得很大, 看起来很完美, 而工作量大, 兼容性差也是不争的事实. 在现阶段, 我宁可通过 WordPress Mobile Themes 插件搭配一个手机主题, 兼容平板事件和折中处理窄屏来解决掉问题, 这样性能和体验都可以更好.

起码目前我没有办法丢弃那响应式布局不能兼容的 IE8, 不妨看看数据. 下图是 2011 年 6 月和 2012 年 12 月的 IE 占有率对比.

下图是 IE6-9 的占有率对比.

可以看出, 过去一年半中, IE 整体占有率大幅下降, 尤其是 IE6 和 IE7, 统计可得相对全部浏览器占有率.

不管是因为 Windows 7 的普及, 还是因为 360 的假补丁, IE6 和 IE7 的占有率已经很小, 并且占有率下降速度也比较快; 但 IE8 占有率不低, 而且 Windows XP 不能安装更新版本的 IE, Windows 8 的不给力也可能导致 IE8 长期存在.

最终, 忽略 IE6 和 IE7, 给它个 960 宽度了事; 兼容 IE8, 但阴影等一些效果 IE8 不做支持, 算是渐进增强吧.

类目栏的显示方式

加入左侧边栏的一个最重要的新增功能无疑是类目栏, 它占据了页面中最能吸引眼球的左上角. 我想加强类目导航, 但类目栏只会在首页和搜索页面默认展开, 其它页面仅当鼠标悬停在该区域时才显示. 这有两个原因:

1. 在业务角度

一般进入类目列表或者文章详情页面的读者是通过网站导航或者搜索引擎进来的, 他们有明确的目的, 不应该被其他类目抢走读者的太多目光, 更希望他们多关注本页内容. 所以在文章详细页面, 我将文章目录放在最显眼的位置, 便于读者更快地定位内容.

2. 在 SEO 角度

如果每个页面都载入所有类目, 可能网页信息不够内聚, 更可能分散爬虫的关注度. 所以在这类页面没有必要加载所有类目, 仅在读者想看的时候通过异步的方式加载进来.

后话

没有看到侧边栏的读者, 要么还在用 IE6 或者 IE7, 这真的该换了; 要么显示屏达不到 1200 宽, 宽度不够真没办法. 而平板读者将会以 990 宽度展示, 其中包括两边 15px 的留白, 所以也不会展示左侧边栏.

好不好用? 觉得好, 不好, 或者有什么建议请留言给我吧.

a 标签在网页中无所不在, 而且样式复用性很高. 一般来说, 一个网站上的链接形式是比较统一的, 所以作为 reset 或者基本的 a 标签 CSS 定义十分重要.

a 标签伪类的 lvha 顺序

为了解决伪类状态覆盖的问题, 网上建议开发者书写 a 标签样式如下:

a:link {color:#FF0000;} /* 没访问过的链接样式 */
a:visited {color:#00FF00;} /* 访问过的链接样式 */
a:hover {color:#FF00FF;} /* 鼠标进入链接区域的链接样式 */
a:active {color:#0000FF;} /* 点击链接时的链接样式 */

相信很多开发者都看了这段称为 lvha (love & hate) 的书写顺序建议, 我看了很多网站在全站通用的 CSS 里已经也是这么写的. 除了样式上有特殊需要, 我不建议这样来定义 a 链接的样式, 尤其是在通用样式中.

a 标签 lvha 存在的问题

lvha 的写法从逻辑上没有问题, 而事实上这种写法是过度设计, 为代码维护带来很多额外的维护成本.

假设全局通用 CSS 中已经按 lvha 定义样式, 而页面中一些链接即便被访问过, 要求跟没访问过的样式一致, 开发便需要重写 visited 样式; 如果某些链接颜色跟通用样式不一样, 基本上要重写所有链接伪类的样式, 代码量大, 也相当麻烦.

下面是一段过度设计的示例代码摘要.

a:link{color:#06C;text-decoration:none;}
a:visited{color:#969;text-decotation:none;}
a:hover{color:#F90;text-decoration:underline;}
 
.normal a:link,
.normal a:visited{color:#666;}
.normal a:hover{color:#000;}

有什么问题相信大家看看就知道了, 几乎所有对链接的重新定义, 都需要将 a 链接对应的个伪类的样式重写一遍.

a 标签样式规划建议

为什么会出现上述的写法? 我猜这是因为设计库中存在一套对文本和链接的完整的设计规范, 编写代码的人认为可以通过通用的样式一劳永逸, 而这可能弄巧反拙. 下面是 Alibaba DPL 的一个片段, 一看便知.

link 和 hover 状态的链接样式通用性很高, 但 visited 样式仅在搜索页面的商品标题, 帮助中心的问题链接等少部分列表的主要链接上才会使用. 所以完全有理由将它们分开处理.

在通用 CSS 中只定义 a 和 a:hover 样式, 需要使用 a:visited 样式时再做定义. 则前面那段 CSS 可以定义如下:

a{color:#06C;text-decoration:none;}
a:hover{color:#F90;text-decoration:underline;}
 
.normal a{color:#666;}
.normal a:hover{color:#000;}
 
.list a:visied{color:#969;}

从代码可以看到, 一般的链接样式修改, 只需要顾及到 a 和 a:hover, 而其他状态仅在使用的时候进行定义. 因为前者常有, 后者少用, 所以维护量是非常小的.

后话

过度设计无所不在, 三年前我刚入职写过一段商品价格的 CSS 定义, 对货币, 价钱, 单位以及各种场景都做了看起来完美的定义, 但现在看来这是我做的最错误的一件事情, 因为强定义导致样式覆盖的代码量大. 而随着网站的发展, 这些修改和重写必将越来越多.

当我们希望有一套 CSS 架构解决掉所有页面外观需求, 甚至出现如: size-35, margin-left-10 这样的 class, 过度设计就开始了...

大概两年前吧, 我开始使用 Yet Another Related Posts Plugin (YARPP) 这款相关文章插件, 与其他类似插件比较, 它有很多优点, 也有一些问题, 本文我会介绍一下这些优缺点和提供一些使用建议.

为什么选择 YARPP 相关文章插件?

WordPress 的相关文章插件选择很多, 但做得好的没几个. 我原本用的是另一款插件: WordPress Related Posts.

WordPress Related Posts 的原作者是国内知名博客我爱水煮鱼 (现在已经卖给了一老外开发), 我也贡献过一些代码, 用了好几个年头了, 而且我发布的所有主题都默认支持这款插件. 当时这款插件的问题是相关文章不精准, 自定义程度低, 所以我换了...

YARPP 的卖点正是 WordPress Related Posts 的不足, 页面结构和相关特征高度的自定义. 界面上, 你可以使用默认的模板和简单的调整, 或者选择自己编写写的模板, 在 $post 对象可用的数据项中, 基本你想将界面做成什么样子都可以.

而在筛选相关文章的功能上更是强大, 用户可以对相关因子 (如: 标题, 内容, 标签和分类等) 进行给予不同的权值.

相比于其他欧美开发者制作的相关组件, 因为 YARPP 的作者是个日本人, 基本上对汉字的支持也非常好, 适合国人使用.

YARPP 相关文章插件的缺点

YARPP 功能是强大了, 但操作也更加复杂, 很难实现安装完即可使用, 必须做一些设定, 尽管这不难. 借 Denis (我爱水煮鱼的作者) 的话: 多数用户看到整个面板的选项就可能将插件卸载掉了. 另外, 因为相关因子较多, 如果网站的文章少, 会匹配不到或者是能匹配到少量的文章.

是不是文章多了就比较好? 也不一定, 插件需要为相关文章生成缓存数据, 如果设置不当加之文章太多就会宕机. 当然, 万篇以内应该是没问题的. 而现在 WordPress Related Posts 为了解决相关文章不精准的问题, 也开始使用类似的缓存方式, 同样不能避免这个问题.

使用 YARPP

下载和安装

1. 在插件页面下载.
2. 解压上传到 {WordPress 目录}/wp-content/plugin/ 目录.
3. 将 yarpp-templates 目录内的 PHP 文件拷贝到正在使用的主题根目录.
4. 在 http://{你的网址}/wp-admin/plugins.php 激活插件.

配置插件

进入 Settings > Related Posts (YARPP) 进行插件配置, 我相信一般人都可以看懂. "Display options for your website" 中有几点需要注意的:

1. Automatically display 这里是选择自动加载的选项, 如果勾选, 则自动在文章后面追加相关文章列表.
2. 最新的一些版本, 插件已经支持带缩略图的相关文章, 但需要你的主题本身支持 Featured Images 功能.
3. 如果选择自定义模板, 请确定在主题根目录存在以 yarpp-template- 作为前缀命名的 PHP 文件. 你可以在插件的 yarpp-templates 目录找到这些文件.

后话

我这里建议刚入门的 WordPress 用户还是使用 WordPress Related Posts 比较好, 容易上手, 也避免找不到相关文章; 而追求更精准更可控的那些整天折腾的用户, YARPP 更加适合.

如果主题支持 Featured Images, 最新版本的 YARPP 的已经支持带缩略图的展现模式了. 如果你的主题不支持 Featured Images 功能, 也可以结合《WordPress 缩略图的方法》提及的方法制作带缩略图的插件模板.

虽然这个网站上的广告更换频率很低 (我的客户基本都是按年买的), 但偶尔换个活动链接, 更新一下图片还是要修改 PHP 或者 JavaScript 代码. 所以我想如果能有这么一个工具, 为我提供一些展示橱窗, 当我要修改时在后台修改橱窗内容就可以了.

一些 WordPress 插件, Google 广告管理系统 (Google DFP) 和百度广告管家都可以提供这样的服务, 为了跟网站剥离和避免广告因为我国特殊的网络环境不能显示, 最后我选择了百度的广告管理平台.

各种物件及其之间的关系

在百度广告管家系统里, 你会发现很多不同的物件: 广告, 广告位, 物料, ... 这系统的用户体验真不好, 作为同行我还折腾了一会才搞清楚这些概念及其关系, 这里我逐一解释一下这些概念.

广告位

这是一些可以设定宽高的橱窗, 我们要将这些广告位放到网页上, 这也是广告平台与网站唯一的关联.

物料

可带有链接的文字, 图片, Flash 或 HTML 片段等广告中需要用到的元素.

广告

由广告位和物料, 我们可以组装成一些广告, 这些广告可以针对特定地区, 特定时段来进行投放. 如果广告位已经嵌入网页, 一旦广告投放即可在页面上将对应的物料展示出来.

频道

我们可以为广告位定义一些频道, 以便于查看和管理, 可以认为这是广告位的分类. 建议按站点来区分频道.

客户

我们可以定义一些广告客户, 并将对应的广告数据查看权限分享给他们. 客户的姓名和邮箱是必填的, 而邮箱需要验证, 但是我测试过, 验证邮件根本没有发出去 (不知道是不是 bug).

订单

我们可以为指定的客户创建订单, 订单创建完成后可投放对应的广告. 所以订单是客户和广告之间的联系, 但广告可以独立存在.

排期表

排期表功能需要写邮件给管理员进行开通, 将邮件发往 adm_service@baidu.com 说明需要开通百度广告管家排期表功能即可. 开通排期表后, 我们可以直观地看到广告投放情况, 如下图.

这里的排期表是按月份来翻页的, 我觉得体验还是不好, 因为在今天之前的排期其实是没有意义的, 而作为广告主我更希望看到下个月初广告是否已经有着落, 如果这里不以本月一号作为开始页, 而是以当天作为始点会更好一些.

创建和使用广告

前面已经介绍过一些相关的物件, 这里我将一步一步讲解创建和使用广告的流程.

1. 准备物料

在 "广告 > 广告物料库" 页面中添加物料, 以图片广告为例, 在广告物料库新建物料, 上传图片和设定 URL.

2. 创建广告位

在 "广告位 > 广告位" 页面中添加广告位, 这里广告位名称和尺寸是必填的.

因为广告位与页面显示位置相关, 所以我建议以页面位置, 如 "首页侧边栏顶部" 作为广告位名称; 广告尺寸可以自定义设定, 这里应该选择与准备使用物料尺寸相同的宽高.

另外, 网盟推广合作选项可以绑定百度推广帐号, 如果启用空闲时使用百度推广, 那么在广告过期或不存在的时候会显示百度广告.

3. 创建广告

在 "广告 > 广告" 页面中添加广告, 选择目标广告位和物料, 再修改投放时间即可.

如果这是一个带订单的广告, 在广告类型选项中将 "未关联订单广告" 修改为 "订单广告" 和选择一个订单即可.

如果你已经开通排期表功能, 广告创建后可以在 "订单 > 排期表" 中看到广告排期.

4. 向网站添加广告位

在 "广告位 > 获取代码" 页面选中需要添加的广告位, 并生成代码.

这里有两种广告投放方式: (Google 广告管理系统提供的也是这两种方式.)

1. 两段式 JS: 在 <head> 部分添加一段 JavaScript 代码 (其实在调用代码前插入这段 JS 即可), 然后在页面中各个区域加载不同的广告位. 这种方式的优点是灵活, 比如本博客侧边栏的广告随机显示得以实现, 但因为需要预先加载 JavaScript 影响页面加载速度.
2. 一段式 JS: 和百度推广的广告处理方式一样, 在需要加载的时候去加载广告和相关文件, 但处理不够灵活.

存在的一些问题

百度广告管家是个很好的工具, 但跟 Google 广告管理系统比起来体验实在太差了, 而且有一些小 bug, 比如: 填写广告高度时, 作为 placeholder 的 "高" 字会一直存在. 恐怕这个工具正在测试阶段, 投入资源很少, 甚至是三两个人的作品, 重构一下对百度来说这不是问题.

广告平台提供的 JS 文件在中国大陆的访问速度很快, 但海外和港澳地区的 DNS 解析时间超长, 严重影响页面性能. 所以我被迫撤掉海外的广告位, 换成了 Adsense.

后话

百度广告管家还有很多问题, 还带着抄袭 Google 产品的名声, 但它确实能够帮我将网站广告和网站系统剥离开, 管理广告更加方便, 在国内的网络环境中可以一用. 我也建议大家尝试一下 Google 广告管理系统, 尤其是做英文网站的各位.

好话说完了, 是时候 "但是" 了. 但是... WordPress 秉承一贯的作风, 也偷偷改了一些内部方法, 现在 wpdb::prepare() 必须填入第二个参数, 否则报错如下.

Warning: Missing argument 2 for wpdb::prepare(), called in xxx.php on line 75 and defined in /www/wp-includes/wp-db.php on line 990

wpdb::prepare() 的第二个参数

从技术上 WordPress 这样修改 prepare 并没有错, 因为这是用来组装 SQL 语句的方法, 按常理来说必须有带变量的字符串作为第一个参数和第二个作为变量的参数, 这是为了避免 SQL 注入所引起的安全问题. 但是 WordPress 从 2.2 或者更早版本允许了忽略第二个参数的写法, 现在突然令第二个参数成为必填, 必然导致很多主题和插件不能正常使用.

我发布的所有 WordPress 主题和最新评论插件 WP-RecentComments 都中枪了. 感谢 neoner 提醒, 半个月前我更新 WP-RecentComments 解决了这个问题, 但还没有时间改主题, 因为主题审核太麻烦了.

解决办法

在更新主题之前, 我先在这里说说解决办法, 让用户们自己可以先解决一下, 相信还有其他主题或者插件可能也会有类似问题, 希望对大家有帮助.

1. 我们需要先定位出现问题的文件和代码. PHP 的代码报错很精准的, 打开报错提醒中的文件 (前一个文件, 不是 wp-db.php), 找到代码 $wpdb->prepare.
2. 为该方法添加一个空串作为第二个参数, 比如: $wpdb->prepare('xxx'); 改为 $wpdb->prepare('xxx', ''); 即可.

总结

WordPress 也不是第一次偷偷修改方法调用方式了, WordPress 2.7 的时候也要求 comments_template 必须输入第二个方法, 但是当时是为了扩展功能, 这次我真的不解. 除了安全考虑, WordPress 也可能有意淘汰一些不积极更新的主题, 我的主题明明向后兼容做得很好的, 实在太没节操了.

这是一篇译文, 本文将会介绍 Opera Mobile 模拟器的作用, 来历, 特性及其使用方法, 还会提到一些有价值的用法和需要注意的地方.

Opera Mobile 模拟器概要

早在 2009 年, 我参与 Opera Mobile 10 开发的时候, Opera 的同事决定调整 Opera Mobile 编译机, 以便生成的程序不仅可以运行在普通的移动设备, 还可以运行在 Windows 和 Linux 上. 最初是为了保证质量和提供测试环境, 而且这些桌面程序也被证实对 Web 开发有用; 令桌面运行的 Opera Mobile 取代一个手机上的所有测试成为可能, 仅需 Alt+Tab 或者 Command + Tab 即可呼出 Opera Mobile 的调试窗口, 这是多么地令人激动!

所以, 我们决定打通所有平台, 添加了对 Mac 的支持, 并且将它公开成为开发者工具, 称为 Opera Mobile 模拟器. 做成相当小的尺寸, Opera Mobile 模拟器可以在 Opera 开发者网站或者Mac 应用市场免费下载, 而且安装起来相当简单. 模拟器的处理引擎和 UI 与手机上的 Opera Mobile 是一模一样的, 与此同时可以配合桌面上如配置面板, 键盘快捷键和命令行等操作进行额外的调试.

本文中, 我们来看看如何使用 Opera Mobile 模拟器来创建响应式设计, 另外我们还会讨论一些相关的奇特配置.

基本使用

打开模拟器, 你首先看到的是配置面板. 使用左侧的配置, 你可以开启不止一个具有某些设备特征的的 Opera Mobile 浏览器. 比如, 选择 "HTC Desire" 配置可以打开一个分辨率为 WVGA (480x800), 纵向放置和放大到 150% 的 Opera Mobile 浏览器, 跟 HTC Desire 真机上的显示无异. 如果你再选择一个配置, 将会产生另一个相匹配的独立存在的 Opera Mobile 模拟浏览器.

可以在地址栏输入 URL 来加载网页 (这他妈不是废话吗!), 也可以通过拖拽文件或者 URL 至浏览器窗口来实现. 内页导航也同样的简单: 点击事件匹配成轻巧, 你可以在触控板上使用两指手势触来放大和缩小页面 (译者没有 Mac, 求网友测试). 如果你的设备不支持多点触控板, 可以通过使用 Ctrl 配合鼠标滚轮, 或者点击浏览器中滚动页面时出现的悬浮按钮 + 和 - 来缩放页面. (译者补充: 很多移动版网页已经禁止用户放大缩小页面, 这种场合无论是触控板还是缩放按钮都不可用.)

你可能留意到 Opera Mobile 模拟浏览器是可以调整窗口尺寸的, 随之加载的网页布局也会相应改变. 这是理所当然的, 浏览器是一个全屏应用, 不同设备上的体验也不相同, 当你需要在各种分辨率中测试的控制视窗的 meta 标签或各种情况下加载的 CSS 时, 该功能非常方便. 事实上, 通过调整 Opera Mobile 模拟浏览器的尺寸来测试不同的布局, 比在桌面浏览器中做同样的事情感觉更加真实, 因为后者不会触发针对视窗的设置, 因为可能忽略掉一些与视窗相关的 bug.

这里值得一提的, 在 Opera Mobile 模拟器中的设备宽度不是电脑屏幕的宽度, 那是正在运行的 Opera Mobile 模拟浏览器宽度. 另外, 如果你只关心设备横放和纵放时的效果. 你可以通过 Alt+R 或者 Option+R 快捷操作, 或者点击状态栏右下方的 Rotate screen 按钮切换方向.

当然, 每一个人的工作方式都不一样, 我在这里是为了协助你提高工作效率, 而不是命令你. 显然的, 没有什么能比真机上的测试更加靠谱, 但因为在移动设备中你可以确切地感受到网站的表现, 如设备上性能有限的 CPU 等. 然而, 真机测试太繁琐了, 所以在我的项目进入内测版本之前不会使用真机测试, 当项目刚启动时, 我更倾向于快速的 (1) 开发, (2) Opera Mobile 模拟器测试, (3) 调试迭代.

高级启动选项

在配置面板的右侧, 你会看到很多配置选项.

在 "分辨率" 下拉列表中有一些常见的屏幕尺寸和方向拱你选择, 你也可以添加自定义的选项. "像数密度" 下拉列表是一些 PPI 值的列表: 在 HTC Desire 上, PPI 是 252, 那么开启的模拟浏览器是默认 150% 的窗口比例和 1.5 倍的设备像素比. 假设选择了另一个 PPI 值的, 285, 那么是 200% 的窗口比例和相当于 2 倍的设备像素比. (这段太专业了, 译者表示压力很大, 可能翻译的不准确, 希望指点和更正, 原文如下:)

for the HTC Desire, this is 252, which will result in a 150% default zoom and a devicePixelRatio of 1.5 when launched. Selecting a PPI of, for example, 285, on the other hand, will result in a zoom level of 200% and a corresponding devicePixelRatio of 2.

简而言之, "分辨率" 和 "像数密度" 可以组合出不一样的配置和模拟浏览器视窗的展示效果, 以及确定哪些 CSS 会被应用.

最后, "User Agent 字符串" 下拉列表中允许你选择在几种访问模式中选择模拟浏览器对应的外观和 UA:

Touch
选择该项将以针对触屏手机优化过的 UI 来加载 Opera Mobile, 并且浏览器 UA 是 Opera Mobi.

Keypad
选择该项将以针对非触屏手机优化过的 UI 来加载 Opera Mobile, 为方便开发者, 鼠标点击, 平移和缩放手势仍可以在这里使用. UA 也是 Opera Mobi.

Tablet
选择该项将以平板化的 UI 来加载 Opera Mobile. 对应的 UA 是 Opera Tablet.

MeeGo (因为新版本支持 MeeGo, 这是译者加上的.)
选择该项将以 MeeGo (诺基亚 N9 用的是这个) 的方式来加载 Opera Mobile, 而 UA 是 Opera Mobi.

带参数启动

在配置面板的最后一个选项是 "参数" 输入框, 这应该是这批配置选项中最强大的. 你可以在这里填入大量参数或者标记, 这些参数或标记将用于加载一个新的 Opera Mobile 模拟浏览器. 比如: 使用 -displaysize 320x480 -url www.opera.com 会加载一个窗口大小为 320x480 像素的 Opera Mobile, 并且打开页面 www.opera.com.

这些标记也可以在命令行中使用. 默认的情况下, Opera Mobile 模拟器可在下列目录中执行:

Mac
/Applications/Opera Mobile Emulator.app/Contents/Resources/Opera Mobile.app/Contents/MacOS/

Windows
C:\Program Files\Opera Mobile Emulator\

Linux
/usr/bin/

重复通过命令行做一遍我们刚才的例子操作如下:

Mac

./Opera\ Mobile -displaysize 320x480 -url www.opera.com

Windows

OperaMobileEmu.exe -displaysize 320x480 -url www.opera.com

Linux

operamobile -displaysize 320x480 -url www.opera.com

这里有 -displayzoom 和 -monitorppi 两个参数用来调试页面非常便利:

-displayzoom

你可以用这个参数来缩小 Opera Mobile 模拟浏览器在桌面上的尺寸, 在此同时可以保留其宽度值, 高度值和设备像素比等. 换句话说, 如果你试用一下三星 Galaxy Note 的配置, 会获得一个 800x1280 的浏览器, 那你可以通过 -displayzoom 50 将它等比缩放成 400x640 大小, 对一个 900 像素高的显示屏来说这样的效果更好, 例如一台 MacBook Air.

-monitorppi

(丫的, 又是 PPI, 译者不懂, 不翻译了, 读者自己看看下面的原文吧, 知道 PPI 能看懂的请帮忙翻译一下.)

This, on the other hand, allows you to set the PPI of your computer monitor (for example, -monitorppi 128 for a 13-inch MacBook Air) and launch an Opera Mobile instance with a zoom factor adjusted to match the physical dimensions of the profiled phone’s screen. This will give you a better idea of how big, say, the clickable areas really will be when the page loads on an actual device, but remember that the PPI you get on the screen won’t be representative of what you’ll see on the device.

注意 -displayzoom 和 -monitorppi 是互相排斥的，因此不能被一起使用.

如果要查看所有可用参数, 请点击配置面板的 "帮助" 按钮, 或者在命令行中执行 --help 查看.

浏览器中设置

记住一件事情, 在 Opera Mobile 模拟浏览器中就算都是使用 Android 配置, UA 也可以有所不同. 你可以在打开 Opera Mobile 模拟浏览器后再去修改 UA, 点击红色的大 "O" 并打开 "设置 > 高级 > 浏览器", 你可以在 5 个选项中选择一个, 包括 "Android". 如果你需要设置完整的 UA, 从地址栏打开 opera:config 并搜索 "Custom User-Agent", 你可以将自定义的 UA 在此输入, 这里的配置将覆盖掉其他任何地方设置的 UA.

值得强调的其他设置选项有清除 cookie, 缓存和本地分享相关功能, 可以在 "设置 > 隐私" 镇南关找到. 另一个值得推荐的是禁止浏览器键盘的切换按钮, 可以在 "设置 > 高级 > Opera 键盘" 中找到.

连接到 Opera Dragonfly 进行深度调试

在任何 Web 项目中, 有一个原则是你绝对要看看浏览器内部究竟做了什么事情. 这就是为什么 Opera Mobile 模拟器要与 Opera 的内建 Web 调试工具, Opera Dragonfly 通信.

你可以容易地将这套调试环境搭建起来:

1. 下载 Opera, 并在桌面环境安装好.
2. 在桌面版 Opera 上打开一个页面, 右击页面的任何地方, 点击 "Inspect Element" 打开 Opera Dragonfly. (译者提醒: Ctrl+Shift+I 可快捷打开.)
3. 在 Opera Dragonfly 中, 点击右上方的 "Remote debug configuration" 按钮, 保持默认配置点击 "Apply".
4. 然后, 打开 Opera Mobile 模拟器并加载一个模拟浏览器.
5. 在 Opera Mobile 模拟浏览器中打开 opera:debug, 保持默认配置点击 "连接".
6. 现在已经连接成功, 你可以在 Opera Mobile 中加载任何想研究的页面. 在切换浏览器标签时请确保调试环境选择正确. (可在 Opera Dragonfly 右上方第四个按钮中选择.)

在 Opera Dragonfly 下的 "Network > Network log", 你可以检查请求的资源文件是否正常被加载, 以及样式中是否引用了不必要的图片文件. 如果没有异常, 在 Opera Mobile 浏览器窗口打开页面的同时, 你应该可以在调试窗口看到朝下生成的瀑布图.

另外值得一提的功能是 "Network > Network" 的选项. 那里有一个选择框可以令所有缓存失效 (这是你在测试的时候想要的). 那里还有一个选项可以设置和重写掉全部的文件头信息, 当你依赖浏览器嗅探时使用这个选项非常方便 (小心!), 或者通过特定的头信息来优化网站内容时, 你不必打开多个浏览器就能测试各种变量的效果.

对于其他 Opera Dragonfly 的功能, 包括哪些关于 DOM, CSS 和 JavaScript 检测, 获取颜色和使用命令行的使用, 建议到 Opera Dragonfly 文档去查阅.

这是一篇总结! 我希望你会喜欢这篇介绍如何通过 Opera Mobile 模拟器优化网站设计的文章. 自己去试试吧, 让我们知道你的想法和你想看到的改进.

译者的话

前两天我写了一篇文章《如何让开发者兼容你的浏览器》是为了回应浏览器厂商呼吁开发者们支持他们各自的浏览器, 但没有考虑到开发者的难处. 我本来是站在开发者角度说句话, 但带来了很多不一样的声音, 甚至有人认为我这是跟浏览器标准对着干. 我恰恰是希望厂商们不要只挂嘴边, 也为开发这做些事情. 罢了, 谁干谁知道...

文章中我提到 Opera Mobile Emulator, 因为没深入了解, 刚开始的时候我不知道可以用来调试. 将 Debug 环境搭起来后感觉十分好用, 性能比 Android 虚拟机要好很多, 也不比 XCode 调试 iPhone 效果差. 于是我想在团队内分享一下这个工具, 也花了点时间翻译了这个文章.

文章翻译自 《Developing Responsive Designs With Opera Mobile Emulator》, 原文出自 Opera 的测试工程师 Andreas.

由于文章写于两个月前, 最新版 Opera Mobile 模拟器的少部分功能在文中没有提及, 但不影响使用. 另外, 因为我不了解 PPI, 文中相关的两段文字我肯定没翻译好, 希望大家帮忙完善一下.

或许因为很多网页在 IE10 上表现不理想, 微软呼吁 Web 开发者要做好各种浏览器的兼容, 防止 Webkie 成为移动网页的 IE6. 很讽刺, 当年以浏览器优势来阻击竞争对手的微软会向开发者发出这样的请求.

Webkit 垄断移动设备带来的问题

因为移动领域中 Webkit 的垄断地位, 开发者对其他内核的浏览器兼容不积极, 其他浏览器厂商为此着急可以想象.

假设一大批网站只支持 Webkit 浏览器, 由于 Windows Phone 8 使用 IE10, 这些网站体验会较差, 甚至不可用. 那么用户有可能会认为 Windows Phone 不好用而放弃这款产品.

面对这样的形势, 有些浏览器厂商开始支持 -webkit- 前缀, 也在埋怨开发者不够给力.

为什么开发者不做其他浏览器兼容?

作为一个 Web 开发者, 我很看重开发标准和好的网页兼容性, 但这只能是个人追求, 不是工作. 工作中各个角色对于网页的要求更可能是这样的:

• 用户: 我的浏览器要能正常使用.
• 老板: 项目很多, 要用最少的时间满足最多的用户.
• 测试: 测试资源有限, 我们只能测 4 款浏览器.
• 开发: 按时完成需求, 在指定浏览器中没有 bug.

以上的角色的要求都是合理的, 这样做出来的产品可以花 1X 的时间满足 95% 以上的用户, 永远不可能有 100% 兼容的网站存在, 除非余下用户价值也很高, 否则没有人愿意花 2X 的时间来满足 98% 的用户.

为什么开发们哭着喊着干掉 IE6, 推新款浏览器, 却不能对 Webkit 下手? 这不能比, IE6 的存在已经影响网站业务发展了, 很多功能在 IE6 上根本无法实现, 或者实现起来非常费劲, 但目前 Webkit 不存在这样的问题.

浏览器厂商的那些忽悠

看了 Opera 张金龙的《如何让 WebKit 优化的网站更兼容》, 我觉得作者想法太简单了. 腾讯百度作为知名互联网企业, 如果有意兼容 Opera 会不知道这些兼容策略吗? 更可能是他们检测到 Opera 用户数量很少, KPI 中没有要求兼容, 测试也不会出资源去测, 所以就不兼容这款浏览器了.

浏览器厂商总在宣扬做好兼容是前端开发工程师的天职, 以此来向这群苦逼的开发洗脑. 而事实是他们只考虑自己的浏览器使用率, 你见过微软在 IE6 称霸的时候让你去兼容 Firefox 吗? 另一个事实, 前端开发的职责不是兼容浏览器, 而是通过前端技术推动网站的业绩.

浏览器厂商们, 少来忽悠, 多推标准. 开发们要的是一句代码兼容所有浏览器, 而不是增加一句代码多兼容一个浏览器.

解决问题才是最好的推广

没有无缘无故的爱, 也没有无缘无故的恨. Firefox 因为安全, 强大的扩展和 Firebug 成功了, Chrome 因为高端用户群和速度成功了. 参考各种后来居上的故事, 要吸引用户和开发者就要有做好市场和解决开发者的困难.

市场我不懂, 但我相信那款浏览器能搞定 12306.cn, 在中国绝对可以占有一席之地.

那 Web 开发者有啥困难? 移动设备差异大, 调试困难. 现在只有各类虚拟机和真机测试是靠谱的. Opera Mobile Emulator 是个很好的工具, 直观方便. 如果它还有调试功能, 我想会有很多开发者愿意用来做开发调试的, 就像当年的 Firebug 一样, 那还用担心别人不支持你的浏览器吗? 当然, 如果浏览器用户群庞大, 比 IE6 再烂的浏览器也会被兼容得很好. 我之前没有调查清楚, Opera Mobile Emulator 支持远程调试的, 也很好用, 这里有具体的介绍和使用说明: 《Developing Responsive Designs With Opera Mobile Emulator》

能解决掉用户的需求就能赢得用户, 能赢得用户或能有效辅助开发就能得到网站支持.

这里要介绍一下 Google 重定向的作用, 带来的问题, 以及消除的方法.

搜索结果链接重定向

几乎所有的搜索引擎, 包括百度都对搜索结果中的链接进行了重定向. 比如 WordPress 的网站链接是 http://wordpress.org, 但在 Google 页面搜索点进网站时其实进入的链接如下:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDQQFjAA&url=http%3A%2F%2Fwordpress.com%2F&ei=H0ayUOTEOIyXiAfOrYG4Aw&usg=AFQjCNF9LajB5652xWLlsPJGhDjlnNybaA&sig2=oVfZxCndwa1AroHLTR_ujQ

搜索结果的链接会变成 Google 重定向链接, 这个链接最后也会转跳到原网站链接 http://wordpress.org, 如下图.

重定向带来的问题

但因为网络问题和其他一些原因, Google 的服务器在国内访问其实会遇到很多麻烦, 搜索结果经常打不开. 就算你用了某些代理来解决这些问题, 也避免不了网速变慢带来的不愉悦感.

依我的观察, Google 重定向经历了几个阶段, 最开始的时候是将重定向链接输出到页面上的 (百度和 360 现在就这么干), 如果这样的话我们没有任何办法. 幸好 Google 现在选择用 JavaScript 脚本来处理, 点用户按下鼠标时才跟换 URL 地址, 所以只要我们禁止这个 JavaScript 操作, 就可以避免出现错误页面, 也减免了代理出国再过来的网络开销, 就会变成下图所示.

我猜测 Google 通过重定向统计搜索结果的点击次数和记录用户的搜索历史, 取消掉重定向将导致用户看不到搜索历史记录.

浏览器扩展和插件

看了前两段, 也许你觉得这里会有一大段代码, 然后告诉你按某些步骤添加到哪里哪里... 其实没那么复杂, 我也懒得弄. 很多浏览器有类似插件:

• Firefox: Remove google search redirects
• Chrome: Remove Google Redirects
• Opera: Remove Google Redirects

这几个插件都是都是老外开发的, 我一直纳闷为什么他们也有这样的需求? 不管了, 能用就好. Google 用户们如果不介意没有搜索历史可见, 推荐一用.

我在《Apache 虚拟主机 VirtualHost 配置》介绍了在不同操作系统上使用 Apahce 虚拟主机的方法, 还有那么些朋友想知道 Nginx 虚拟主机配置方法, 本文作为补充也介绍如何 Nginx 上添加虚拟主机.

绝大多数的 Nginx 运行在 Linux 机器上, 虽然有 Windows 移植版, 但我也没搭建过. 所以本文将以 Linux 为例讲解, 而 Mac OS 或其他 Unix like 机器上的操作应该是一样的.

增加 Nginx 虚拟主机

这里假设大家的 Nginx 服务器已经安装好, 不懂的请阅读各 Linux 发行版的官方文档或者 LNMP 的安装说明. 配置 Virtual host 步骤如下:

1. 进入 /usr/local/nginx/conf/vhost 目录, 创建虚拟主机配置文件 demo.neoease.com.conf ({域名}.conf).

2. 打开配置文件, 添加服务如下:

server {
	listen       80;
	server_name demo.neoease.com;
	index index.html index.htm index.php;
	root  /var/www/demo_neoease_com;
 
	log_format demo.neoease.com '$remote_addr - $remote_user [$time_local] $request'
	'$status $body_bytes_sent $http_referer '
	'$http_user_agent $http_x_forwarded_for';
	access_log  /var/log/demo.neoease.com.log demo.neoease.com;
}

3. 打开 Nginx 配置文件 /usr/local/nginx/conf/nginx.conf, 在 http 范围引入虚拟主机配置文件如下:

include vhost/*.conf;

4. 重启 Nginx 服务, 执行以下语句.

service nginx restart

让 Nginx 虚拟主机支持 PHP

在前面第 2 步的虚拟主机服务对应的目录加入对 PHP 的支持, 这里使用的是 FastCGI, 修改如下.

server {
	listen       80;
	server_name demo.neoease.com;
	index index.html index.htm index.php;
	root  /var/www/demo_neoease_com;
 
	location ~ .*\.(php|php5)?$ {
		fastcgi_pass unix:/tmp/php-cgi.sock;
		fastcgi_index index.php;
		include fcgi.conf;
	}
 
	log_format demo.neoease.com '$remote_addr - $remote_user [$time_local] $request'
	'$status $body_bytes_sent $http_referer '
	'$http_user_agent $http_x_forwarded_for';
	access_log  /var/log/demo.neoease.com.log demo.neoease.com;
}

图片防盗链

图片作为重要的耗流量大的静态资源, 可能网站主并不希望其他网站直接引用, Nginx 可以通过 referer 来防止外站盗链图片.

server {
	listen       80;
	server_name demo.neoease.com;
	index index.html index.htm index.php;
	root  /var/www/demo_neoease_com;
 
	# 这里为图片添加为期 1 年的过期时间, 并且禁止 Google, 百度和本站之外的网站引用图片
	location ~ .*\.(ico|jpg|jpeg|png|gif)$ {
		expires 1y;
		valid_referers none blocked demo.neoease.com *.google.com *.baidu.com;
		if ($invalid_referer) {
			return 404;
		}
	}
 
	log_format demo.neoease.com '$remote_addr - $remote_user [$time_local] $request'
	'$status $body_bytes_sent $http_referer '
	'$http_user_agent $http_x_forwarded_for';
	access_log  /var/log/demo.neoease.com.log demo.neoease.com;
}

WordPress 伪静态配置

如果将 WordPress 的链接结构设定为 /%postname%/, /%postname%.html 等格式时, 需要 rewrite URL, WordPress 提供 Apache 的 .htaccess 修改建议, 但没告知 Nginx 该如何修改. 我们可以将 WordPress 的虚拟主机配置修改如下:

server {
	listen       80;
	server_name demo.neoease.com;
	index index.html index.htm index.php;
	root  /var/www/demo_neoease_com;
 
	location / {
		if (-f $request_filename/index.html){
			rewrite (.*) $1/index.html break;
		}
		if (-f $request_filename/index.php){
			rewrite (.*) $1/index.php;
		}
		if (!-f $request_filename){
			rewrite (.*) /index.php;
		}
	}
	rewrite /wp-admin$ $scheme://$host$uri/ permanent;
 
	location ~ .*\.(php|php5)?$ {
		fastcgi_pass unix:/tmp/php-cgi.sock;
		fastcgi_index index.php;
		include fcgi.conf;
	}
 
	log_format demo.neoease.com '$remote_addr - $remote_user [$time_local] $request'
	'$status $body_bytes_sent $http_referer '
	'$http_user_agent $http_x_forwarded_for';
	access_log  /var/log/demo.neoease.com.log demo.neoease.com;
}

LNMP 套件在提供了 WordPress 为静态配置文件 /usr/local/nginx/conf/wordpress.conf, 在虚拟主机配置的 server 范围引用如下即可.

include wordpress.conf;

如果你使用 LNMP 套件, 进入 WordPress 后台发现会出现 404 页面, wp-admin 后面缺少了斜杆 /, 请在 wordpress.conf 最后添加以下语句:

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

后话

一直以来, 我主要在用 Apache, 自从去年从 MT 搬家到 Linode VPS 之后, 发现服务器压力很大, 每隔几天就要宕机一次, 在胡戈戈的协助下转成了 Nginx, 大半年了一直很稳定.

相对 Apache, Nignx 有更加强大的并发能力, 而因为他对进程管理耗用资源也比较少. 而 Apache 比 Nginx 有更多更成熟的可用模块, bug 也比较少. 卖主机的 IDC 选择 Nignx, 因为高并发允许他们创建更多虚拟主机空间更来钱; 淘宝也因此改造 Nignx (Tengine) 作为 CDN 服务器, 可承受更大压力.