作为一个个人开发者，微博API实在太不友好了。我仅仅是想在自己的博客空间展示一下我的微博主页而已。不断的报错，万恶的10023错误。

实际上当我遇到报错后，我是无法与新浪技术支持在线联系的，只能给他们发邮件。而结果就是并不是所有邮件他们都会回复。

在开发文档中，你会发现API对IP点击次数啊用户点击次数啊频率啊做了限制。好的没有问题，毕竟不是第三方调用限制很正常。还给了专门查询这些数据的接口。然后就见鬼了，10023错误 User requests out of rate limit! 一个根本让开发者找不到数据的错误，我根本不知道实际用户请求数目到底是多少又怎么让我做出调整呢？给技术支持发邮件能否查询也不回，意思就是不给查咯。用一个开发者完全没法得知的变量来限制开发者这不是扯淡吗？行吧，忍了，从跟技术支持交流中仅获得有效信息来看。一天一个UID，100次访问限制。行吧，我调整。然后……又报错了，半天访问不到50个就超限了？！天知道又怎么了。

还有就是审查，非常神奇的审查机制。他会不停告诉我，他找不到微博组件。大哥！就在首页好吗？！你点开主页就能看到啊！你找不到我能怎么样？！

我已经为这个API花费了很长时间，特别是10023报错后很可能会封禁应用，而且一封禁就是3天。实在是没时间跟它耗了，再试一次，如果还是这个结果的话，我应该就放弃了。

这年头你是想浏览器地址栏左边一直显示着“不安全”还是那把锁？对于一个个人博客来说，我又不需要网上支付，而且只是一个边缘小众blog到底怎么看待这事。我想全取决于管理员你到底看着舒服还是不舒服，而我本着学习折腾的精神，觉得不舒服，决定开始折腾。

这玩意简单来说就是找个机构给你发个证书，把你的链接信息进行加密然后告诉浏览器你的网站是安全的。第一反应是找个牛逼的大网站然后看看他家用哪家的证书就一定没错，是的，我第一次找了GlobalSign……见鬼了，他家不是给个人用户用的，一年好几百。找朋友咨询了一下，Let’s Encrypt是个不错的选择，免费，自动续期，尽管针对Unix系统，但win下也是可以的。可前提是你可以完全掌控你的操作系统，这意味着你需要一个云服务器而不仅仅是一个虚拟主机。OK，它的事情到此为止，在我这小站搬家后我会尝试。但现在我只有虚拟主机，所以无奈之下只能选择买证书，网上看到getssl不错，Certum的证书酸能接受，100块两年。开始折腾吧。

申请不是问题，遇到的第一个问题是Certum需要你证明自己是你申请域名的所有者，并提供三种证明的方法。第一种是根据whois信息中的email给你发邮件，但我不确定国内注册域名是什么情况，结论是找不到whois我的email。可能是找不到也可能是那个email就不是我的，无论如何这种情况很操蛋。第二种方法，在你的主机目录下建立一个包含一段代码的TXT文件，并让它能够被访问。这似乎是个可行的方法但我的结果是，这个TXT文件我可以无障碍浏览其他人不行，真TM见鬼了！OK，最后一种方法，在域名注册商那里的DNS解析里增加一个TXT记录。在这之前我都不知道原来DNS里还能添加TXT记录，这次也算是学到了。结果对面还是获取不到那段记录，我当时就觉得自己快疯了。还好在与getssl的人沟通过程中发现，是我当初建站的时候不懂，导致增加了其他解析我域名的DNS。所以certum找不到那个TXT记录。重新设置后，总算是通过了验证。好了，现在我有证书了，接下来开始配置。

不同系统下的证书文件是不一样的，好在getssl提供了所有主流系统的文件格式。另一个好消息是我的虚拟主机商提供添加自己证书的功能。虚拟主机有个好处就是在添加证书很简单，如果是云主机则需要一些配置，中间的配置过程等我搬家后再仔细体会吧。让我们先略过这段，后面还有事情要做。

首先是wordpress，在设置里需要更新你的网站网址，在http后面加s。

然后是在数据库里把所有含有http你网址的地方都改成https

update wp_posts set post_content = replace(post_content,'http://example.com','https://example.com'); 

当然，我看到有在function.php中写函数替换http的，都行吧，道理和目的都是一样的。到目前为止都还不错，SSL正常运行，无论是https还是那把小锁。但还存在最后一个问题，就是当我手动输入网址后进入的还是http，而通过上面的配置，在网站内有任何跳转都会进入https。这不是我想要的，既然都有证书了，就应该不管是手动输入还是跳转都应该进入https，所以后面是最后一步，http转https。

主要方法就是配置 .htaccess 文件，因为我是虚拟主机，直接编辑它即可。如果是云服务器还需要进行其他设置，这里同样等以后我体会了再说。直说编辑 .htaccess 。

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.yourdomainname.com/$1 [R,L] 

上面的意思是，如果访问的 （ RewriteCond ）端口是80，也就是http端口，就执行 RewriteRule，进入https。所以端口那里我们也可以这么写

RewriteCond %{SERVER_PORT} !^443$ 

只要访问的 （ RewriteCond ）端口不是443，也就是https端口。

这里需要说明的是，如果没有 .htaccess 则需要新建一个。而如果是win系统，无法新增 .htaccess 这种命名的文件。方法：

我们先新建一个“新建文本文档.txt”文档，记事本打开，选择另存为，保存类型选择“所有文件(*.*)”，文件名输入“.htaccess”，保存。这样便生成了一个.htaccess文件。

相信这个功能是很多主题的一道坎，我看到很多大型门户网站都没有支持这个功能。为什么呢？因为麻烦。最传统的做法是把主题中的各个div的宽度用百分比规定，然后他会自动填满整个屏幕。但这样做你会遇到很多麻烦，比如需要自动设置宽度的元素过多，多到我们甚至无法对每一个自动宽度的元素进行设计。此外动态变化的宽度对主题美化是个灾难，毕竟现在的网页美化还是靠图片和html5实现。图片是无法自适应动态宽度的。最后，为什么大型门户网站不支持这种功能呢？据我观察，大型门户网站网页格局大都采用区块化设计。一个页面中有N个区块，每个区块中显示不同的内容。这一点和本主题的设计方式很像。如果要自适应浏览器宽度，那么是改变每个区块的宽度呢？还是改变一行中显示区块的数量呢？出于美学的考量，通常会选择后者，因为区块尺寸的变化会造成整个网页变的很难看。但实现每一行的区块数量随着浏览器尺寸变化，就会涉及到网页结构的动态调整，这很麻烦。

为什么说麻烦呢。就拿本主题为例，wordpress主题采用php编写。php作为服务器端的语言是无法获取本地浏览器宽度的。所以在获取本地浏览器宽度这种活通常都用JS完成，因为JS实在本地运行的语言。好了，按照这个逻辑的发展就是，我们能否在本地通过JS获取浏览器尺寸然后发送给服务器让服务器通过PHP做出调整呢？也许能，也许不能，我不知道，因为我不会。

在网上我们能找到php获取JS变量的最简单的方式通常如下

<script type=text/javascript>document.write(XXX)</script> 

这样做看似能行，但结果通常不是我想要的。这里我假设XXX的值是1。

<?php 
$a = " <script type=text/javascript>document.write(XXX)</script> " 
?> 

这样得到的$a会是什么？echo出来的话会显示1，但用var_dump你会发现是一个长字节数的string格式的1。为什么？因为$a本质上是被赋值了上面代买中双引号中的字符串。所以$a的字节长度是上面js代码的长度，格式是string。只不过在输出的时候js运行了，给了结果1。这意味着$a无法作为php变量参与计算，因为参与运算时$a会被当成一段文本，是string而且不能被转化为int或者bool。哪怕在使用php格式转换时，$a也是作为储存着js代码的文本，而那一串代码是无法转换成任何int或者bool的。所以这么做的结果是只我想要的1只能通过$a显示出来，不能干其他事情。

那该怎么办？实际上上述这种最简单的方法是没辙的。要想真正做到变量的传递只能增加过程。GET方法、session方法、ajax方法、cookie方法选择适合的就行。我没有一一尝试，这次主题更新采用的是cookie方法。

逻辑很简单，网页加载的时候获取浏览器宽度等控制参数，然后查找本地储存的cookie。如果没有，把控制参数储存进cookie然后自动刷新网页，此时cookie中已经了刷新前存储的控制参数，通过php直接调取改变网页结构。如果本地已经存储了cookie，则与获取的控制参数进行对比，不同的话就存储新的参数并自动刷新。如果相同就什么都不做。

这样做的结果是我想要的，本主题在窄屏的情况下，会显示两列日志。而在浏览器宽度尺寸超过某个值后，会显示三列日志。

主题上线以后我还在不断的完善它，毕竟在制作的时候不能跟原设计图100%一致。这次的更新主要就是针对和设计稿差别较大的侧边栏。因为sidebar内容本身是wordpress自动生成的，所以很难编辑html内容，以前最多是靠CSS来修改样式。这次要是尝试用JS来创建canvas并移动到sidebar里的固定位置，同时对sidebar的CSS做了大量修改。

最终虽然算是比较完美的实现了设计要求，但因为CSS订制的地方比较多，也导致这个主题和侧边栏插件的绑定非常紧密。以后如果需要修改侧边栏的插件的话，估计需要修改CSS的地方也不少。

后面这里我想着重说明一下本主题所用的canvas情况。在发布的时候就说明了，本主题是基于HTML5制作的，这里尤其体现在内容大量canvas的使用。出于降低网站加载速度的需求，凡是能用canvas自己绘制的地方都没有采用图片作为背景。而出于让canvas能够准确的进行绘制，所有canvas函数均采用window.onload调用。即整个页面加载完毕后，才会开始执行。而针对本主题，最大的加载内容无非就是page的背景图，那个确实没辙，又大又不能自己画。所以本主题在载入的时候，会被发现，很多地方先出现空白区域，等到背景大图加载完毕后，空白区域再出现绘制内容。这是JS函数逻辑导致的。

除此以外，对于很小的图片加载和canvas的绘制速度对比上，其实没有多大差别。那为什么一定要用canvas呢？其实主要还是考虑到如果用图片的话，一是图片数量比较多，二是JS的加载对网络的要求比图片还是小很多的。简单来说就是现在JS绘制文件总共也就30KB，只要这30KB的JS被加载主题的绝大部分背景就有了，而如果要让这30KB的代码换成对应的图片的话，体积可能远大于30KB。

最后要说的是，目前的主流浏览器均已经支持HTML5，所以本主题并没有制作兼容html4的内容。也没针对除chrome以外的浏览器进行兼容性调整，这些都是以后的工作了。

稍微花了点时间做了个简单设计，自己进行PSD TO DIV，目前算是2.0版本了。

2.0版本开启了html5+css3，摒弃了PSD中大量的图片素材，自己用canvas画。得益于在设计时就采用了大量线段的风格，使得能用canvas的地方很多。整个主题最大的部分应该就是背景了。同时，所有canvas在主题加载完毕后才会加载，所以要等背景加载完毕后才会显示全部图画。

目前还是有一些小BUG，还在修缮中。

原版wordpress在进入后台或者直接进入编辑页面时会载入非常缓慢，用chrome的开发者工具看network很容易发现是googleapis的jQuery-ui.css加载超时导致问题。国内对google的支持并不好，这点大家都知道。所以解决方案也很明确，就是替代出问题的

ajax.googleapis.com/ajax/libs/jqueryui/1.11.4
/themes/smoothness/jquery-ui.css

其中的1.11.4是版本号，以后可能会变。然后问题来了，翻遍wordpress都找不到上面那个地址。推测那个地址并不是直接饮用而是通过变量组成的，所以无法直接找到。不过在网上有另一个方案，修改wp-includes/functions.php。详细方法： https://www.cnblogs.com/ningmeng666/p/7324924.html

但我用起来存在问题，我先引用方法中的代码

function hc_cdn_callback($buffer) {returnstr_replace('ajax.googleapis.com/ajax/libs/jqueryui
/1.8.21/themes/smoothness/jquery-ui.css','cdn.bootcss.com/jqueryui/1.12.1/jquery-ui.min.css', $buffer); } 
function hc_buffer_start() { ob_start("hc_cdn_callback"); } 
function izt_buffer_end() { ob_end_flush(); } 
add_action('init', 'hc_buffer_start'); 
add_action('shutdown', 'hc_buffer_end'); 

用起来直接报错，找不到 hc_buffer_end 函数。多明显啊，上面定义的叫 izt_buffer_end 。我不知道作者是故意的还是怎么，这么明显的问题就直接放出来了。不过作者接介绍方法结尾的地方说上面代码可能需要修改，后面我发现需要修改的不止一个函数名。izt_buffer_end 和 hc_buffer_end 修改哪个都行，函数名要一致。然后会继续报notice。

PHP Notice:  ob_end_flush(): failed to delete and flush buffer. No buffer to delete or flush in 

如果你能够修改php.ini，我建议你直接关了notice提示。如果不能，目前来说我能做到的唯一方式是，把 add_action(‘shutdown’, ‘hc_buffer_end’); 删了或者注释掉。

最后谈一下遗留问题。首先上述方法的大概逻辑是，既然找不到那个要修改的直接网址，就等php运行后在网址生成时，在php缓存中拦截并修改它，然后输出。ob_start是开启缓存进行修改，ob_end_flush冲出修改的缓存内容并关闭。我奇怪的是，就算我把ob_end_flush删了，上述方法也是有效的（不知道是不是大家都是这样的）。也就是说，其实并不需要ob_end_flush来冲出缓存。所以上面的方法其实可以缩减一下。

 function hc_cdn_callback($buffer) {
     return str_replace('ajax.googleapis.com/ajax/libs/jqueryui/1.8.21/themes/smoothness/jquery-ui.css', 'cdn.bootcss.com/jqueryui/1.12.1/jquery-ui.min.css', $buffer);//主要是修改这行 
} 
function hc_buffer_start() { ob_start("hc_cdn_callback"); } 
add_action('init', 'hc_buffer_start');