网站建设

解决升级Wordpress 5.1后回复评论框不跟随、页面刷新问题

近期,发现博客存在不少问题,先是发现图片暗箱、JS二维码失效了,接着评论点击回复按钮页面直接刷新,而没有评论框跟随效果,直到今天居然连网站CSS图标也挂了。。。 不能忍,决定花点时间看看到底是啥问题,打开F12并没有发现明显报错,既然是CSS图标挂了,那应该是我外链到fontawesome的css地址有问题。于是过滤了下这个地址,发现居然是301?? 类似情况如下: 原来是 cdn.bootcss.com 的CDN资源全部跳转到了 cdnjs.com 首页(这个做法有点醉),而我的博客好多功能都引用了这个CDN,所以都异常了! 最后找了个替代CDN:https://cdnjs.net/ ,替换之后图片暗箱、二维码、CSS图标、延迟加载等功能都恢复了,但是评论回复按钮还是异常刷新的! 最后和鸟哥交流了下,他说是WordPress升级到5.1.1导致的。网上找了下才发现是自己out了,不少博客已经给出了解决方案,比如懿古今博客:《WordPress 5.1评论回复按钮失效评论框不跟随怎么办?》。 不过,鸟哥给了我一个更简单的解决办法(可以免去刷新CDN缓存、浏览器缓存的麻烦): 如果是begin主题,直接在functions.php里面找到:zmingcx_scripts 函数,在最后一个 } 之前加上: 这段代码其实就是在页面加载一段JS: 所以,非begin主题,只需要在主题的header.php加上如下代码即可: 这样就问题就解决了!
阅读全文
网站建设

博客网页导致电脑CPU飙升的问题解决记录

已经有好几个访客朋友匿名反馈只要打开我的博客电脑的CPU就狂转: 因为忙一直也没当一回事,一是我自己的MacbookAir打开并没有异常,二是因为我近期都没进行过折腾改造,不应该有问题才对。 直到今天空下来才想到这个问题还没去验证一番,于是让几个朋友试了下,都反馈确实有问题!Windows下CPU狂转,MAC下风扇呼呼响(奇怪的是我的MAC没问题),看来确实有必要解决下了。 我对于网页导致CPU飙升,也没听过说过有什么解决套路,问了几个前端朋友也说不好定位(有知道的朋友可以留言分享下),只能骑驴找马试试看了。 首先,我看了下是否因为的CSS大括号写成全角带来的问题,结果并未发现异常【相关文章】; 然后,在火狐、谷歌查看了下开发者模式,发现也没有明显报错,又陷入了僵局; 2017-11-12补充:上次排查认为是防镜像代码出现死循环导致CPU爆卡,于是对代码做了下规避,结果还是有朋友在文章下面留言说爆卡!说风扇呼呼响,CPU 100%,有点诡异!主要是我的Mac Book Air并没有出现风扇呼呼响的情况,以为好了。于是开着博客网页看了下top命令,结果发现CPU100%++,看来依然没解决!尼玛。。。 实在没辙,于是打开了使用了相同主题的知更鸟博客试了下, 发现也是100%++,看来是通病。于是顺着看了几个用知更鸟主题的网站,发现有部分又是没问题的。。。 于是从外观上看了下差异,一眼就看到了Logo扫光特效!!!一闪一闪的很有可能是真凶了!于是看了下没问题的博客,发现都没开这个特效,当我把这个特效关了之后,CPU负载瞬间就陡降了! 所以,造成CPU爆卡的原因之一是:知更鸟主题的Logo扫光特效! 拓展:这功能本来也没什么L用,华而不实,一直忙就忘记关掉了,现在发现居然会导致CPU爆卡,试了几个使用了这个特效的网站,也存在同样的问题,大家可以试下。 简单看了下扫光特效的CSS代码,主要使用keyframes来实现的动画,因此也看了些资料。验证这个特效是否会导致CPU上升,可以点击如下网址测试效果: http://www.runoob.com/try/try.php?filename=trycss3_keyframes 反正我点击运行之后,CPU至少升到60%+,如果再加快速度,CPU负载会更高,有兴趣的朋友可以自己测试玩玩。 造成CPU负载较高的原因之二是:底部滚动推荐条! 关掉扫光之后,顺便测试了下我博客底部的滚动条,发现也会带来较高的CPU负载,如果发现风扇依然呼呼的朋友,可以再关掉滚动条试下。。。但是,这个功能我就不去掉了,总要有所取舍。 造成CPU负载较高的原因之三是:防镜像代码中存在死循环。 三个问题全部规避试了下,使用QQ浏览器时,CPU负载依然在50%左右,使用谷歌基本只有20%以下,估计和浏览器内核版本也有所关系,暂时找不出问题了,以后再看看吧! 下面是之前排查过程,无关紧要。 按照我个人经验,这种导致CPU爆卡的肯定是有什么死循环之类的js定时任务导致的。于是按下F12瞄了下有没有异常代码,结果一眼就瞄到了很久之前加入的防止镜像的img+js代码【相关文章】: 几乎本能的确定就是这个代码导致的,这段代码的防镜像原理是指定img为错误的src地址,然后触发onerror错误事件来进行域名判断的,这个过程应该是个死循环,也就是不断的产生onerror事件和域名判断,从而带来了CPU飙升问题。 于是注释了这段代码,让朋友试下,结果一切恢复正常了,果然这就是真凶! 目前没时间研究这段代码的兼容性问题,只好先注释了。理论上应该只需要给这个事件逻辑加上一个延时机制,比如延时个1s以上,应该就可以解决了,也就是和while true不加sleep一样的道理!感兴趣的同学可以去研究研究。 好了,这个问题就记录到这,用到这段代码的朋友也可以看看是否存在相同的问题。 20171021补充:博友【时光在路上】已经留言告知解决onerror事件导致死循环的方法,感谢! 解释如下: 当图片加载失败的时候,我们可以利用onerror事件赋予它默认图片,但是问题来了,假如默认图片又不存在呢,即加载失败,这个时候就会陷入死循环。 为了避免死循环的情况,我们可以在执行完onerror事件后,置于onerror=null 来清除onerror事件,参考代码如下: 原文地址:http://www.cnblogs.com/52php/p/5677847.html 果然,还是和我猜的那样存在死循环问题,本来想着循环判断也挺好的,所以只需要加一个延时,应该就可以解决高负载的问题。不过onerror既然可以清空,那我还是使用清空方案吧! 修改后的防镜像代码如下: 原代码中新增this.onerror=null;来置空onerror事件即可。 看来还是认知不够用,只想到了死循环可以加延时来解决,却忘记了搜索引擎找下【onerror死循环】相关问题解决方法,失策失策。 无聊继续看了下, 发现我前面想的延时方案也已经有前人分享过了,这里继续拓展延伸一下: img加载图片偶尔会出错,利用onerror可以加载一个缺省图片,也可以重载同一张图片。 但是都要考虑,重载的图片仍然错误,就会陷入死循环。 下面给出一个带重试次数,并且延迟加载的实现,超过重试次数仍不能正常显示的,显示缺省图片。 原文地址:http://www.iteye.com/topic/1118362 当然,防镜像那个代码就没必要弄这么复杂了,本文就记录这么多,有兴趣的自己去折腾吧。  
阅读全文
网站建设

博客集成Hitokoto·一言经典语句功能

Hitokoto·一言是一个挺有意思的项目,官方的自我介绍如下: 一言网(Hitokoto.cn)创立于2016年,隶属于萌创Team,目前网站主要提供一句话服务。 动漫也好、小说也好、网络也好,不论在哪里,我们总会看到有那么一两个句子能穿透你的心。我们把这些句子汇聚起来,形成一言网络,以传递更多的感动。如果可以,我们希望我们没有停止服务的那一天。 简单来说,一言指的就是一句话,可以是动漫中的台词,也可以是网络上的各种小段子。 或是感动,或是开心,有或是单纯的回忆。来到这里,留下你所喜欢的那一句句话,与大家分享,这就是一言存在的目的。 自己用了好一段时间了,看到有不少朋友在问文章底部那个一句话是怎么实现的,所以这里来分享下。 一、他山之石 张戈博客之前是调用的自由天空的一言API接口,稳定性和速度还不错,不想折腾的朋友推荐参考他的教程快速部署一个即可。 Ps:喜欢使用官方接口也可以前往官方的API介绍地址参考部署:http://hitokoto.cn/api 如果是像我这种比较喜欢折腾的朋友,可以考虑自己部署一个,主要是方便DIY句子库内容。当然,自己部署的文章其实也已经有博友分享过了==>传送门 。 下面简单的介绍下张戈博客这边的DIY部署过程。 二、部署接口 首先按照我个人编码习惯,把小霖小朋友的代码略微改了下(代码强迫症): 以上代码保存为index.php,然后上传到网站根目录下的hitokoto文件夹(这个自己随机定义)最后,从小霖分享的文章下载hitokoto.txt文本文件 当然这里我也传了一份到微云网盘,方便大家下载: 下载地址:https://share.weiyun.com/cff40cfd057fca81fde3aeb6f00fbfb1 把hitokoto.txt上传到和index.php同级目录,比如hitokoto文件夹内。 现在,浏览器访问 http://你的域名/hitokoto/ 就可以看到输出内容了。 三、博客集成 第一步我们已经完成了这个接口的自建部署,现在可以把这个功能搬到博客上了。 部署方法和其他博客基本一致,非常简单,将下面两行代码添加到博客你想显示一言的位置即可: 不过,这样输出的样式可能会比较丑,如果你懂CSS的话可以自己再美化美化。 当然,Begin主题或者不会css的朋友可以先试下我这边写好的css代码(可以加到style.css): 部署完成之后,前台刷新应该就可以看到效果了,每次刷新都会随机展示一言经典句子。如果你有新的句子,也只要编辑hitokoto.txt文件加入即可。 好了,文章就介绍这么多,喜欢的朋友可以试下了。
阅读全文
网站建设

WordPress发布/更新文章、提交/审核评论自动清理阿里云CDN缓存

使用过CDN的朋友多少都有过文章更新无法自动删除CDN缓存的困惑,针对这个痛点,张戈博客也是多次发布相关教程,为广大草根站长朋友们解惑,比如: WordPress发布/更新文章、提交/审核评论自动清理腾讯云CDN缓存 WordPress发布/更新文章、提交/审核评论自动清理VeryCloud缓存 Nginx-helper纯代码版,文章评论发布自动清理Fastcgi缓存 但是,仍然不能满足博友们的诉求,于是很多朋友留言、邮件给我,要我帮忙写一个XX云CDN的自动清理功能之类的请求,我一般都是给出了敬请期待之类答复。 由于本人日常工作非常繁忙,所以只能一再跳票,今天难得得空,正好研究下阿里云CDN的缓存清理。 实际上,这些XX云CDN基本都有一些SDK接口文档,有点基础的朋友多花点时间撸一撸都能自己写出来,再说张戈博客之前还分享了好几篇类似教程,依葫芦画瓢总会吧?总不能因为有个XX云就要写一个XX云CDN清理教程吧?写完了XX云可能很快又会有一个OO云了。。。所以,掌握套路才是解决问题的关键! 好了,废话不多说,直接上教程。 一、准备工作 ①、开启CDN缓存 这里应该无需多言,如果存在CDN缓存不刷新困惑,肯定已经在CDN配置了文章、首页或目录缓存机制,否则也就不需要清理页面缓存了。 ②、申请认证密钥 阿里云密钥管理地址:https://ak-console.aliyun.com/#/accesskey 申请成功后,得到如图的AccessKey和AccessSecret,保存备用。 二、使用方法 ①、下载代码 为方便维护,代码已提交到github,请前往github下载或使用git clone命令克隆服务器本地: 然后,将refresh-aliyun-cdn-for-wordpress文件夹,上传到WordPress主题目录: ②、部署代码 编辑refresh-aliyun-cdn-for-wordpress文件夹下的api.php文件,按照实际情况修改如下代码:   保存后,修改WordPress主题函数模板文件functions.php,在<?php 之后加入如下代码并保存: 最后,如果PHP开启了opcache功能,还需要重启下php确保代码正常生效。 Ps:本文代码基于阿里云官方PHP-SDK代码修改,官方SDK包含了阿里云所有接口功能代码,单由于我们只用到CDN清理功能,所以其他功能代码已被我精简删除。 三、验证效果 完成上述部署操作后,我们可以进行效果验证了。验证方法很直观,我们先确保api.php文件中已将日志打开: 然后,我们在服务器上使用tail -f查看日志: 最后,我们试着更新文章、发表评论或审核评论,就会看到如下效果了: 当然这只是日志,你还可以实际修改下文章内容,然后在浏览器对比下修改前后的内容是否发生改变。 好了,关于阿里云CDN缓存的刷新就介绍这么多,后面有空再补充下百度云CDN的刷新教程,敬请期待!
阅读全文
网站建设

解决网站静态缓存后WP-PostViews插件不计数的问题

突然发现文章浏览计数功能失效了,文章发了几个月才几十上百的浏览数,本以为是因为最近发的文章都比较冷门,不受欢迎。但是发布了几个月,才不到2百的访问量,这就不合理了。 一、发现问题 于是花时间分析了下,结果一查网站日志,发现浏览计数的请求居然一个都没有。。。 由于网站开启了纯静态缓存(nginx_fastcgi_cache),所以wp-postviews的计数方式会自动改为ajax提交方式,正常情况下,Nginx日志里面会出现如下请求记录: 而我翻看了最近半个月的Nginx日志,只有寥寥数条,看来确实有情况。 二、解决问题 首先,我打开了一篇文章,按下F12,再刷新该页面,在NetWork内容中搜索我熟悉的admin-ajax,发现没有记录,甚至搜索php关键词都没有任何请求记录,直接在页面源码中搜索关键词也是一无所获,看来确实没有浏览计数代码了。 我以为是更新了WP导致PostViews插件不工作了,于是打开WP-PostViews源码看了下,发现有如下逻辑代码: 发现了开启ajax计数的必要条件:开启WP_CACHE缓存!!!!! 鉴于对WP的熟悉程度,我直接打开了wp-config.php文件,发现果然是我自己注释了如下代码: 估计是之前调试网站的时候注释掉了。 于是取消注释,重载php-fpm,并清理Nginx静态缓存后,前台熟悉的ajax代码就回来了: 再看了下Nginx日志,admin-ajax.php?xxx的请求也回来了,看来浏览计数功能已恢复正常。 三、结论分析 ①、为什么并非完全不计数或只计数一次? 回溯了下过程,很明显的发现,文章发布后还是有计数的,只是计数非常少,这是为什么?实际上,原因非常简单,文章在首次缓存的时候,WP-PostViews其实是会工作一次的,使用的是非缓存环境下的php计数。计数之后,文章就缓存下来了,再次访问就不会再更新计数了,直到有人发表了评论或者缓存到期,导致缓存被刷新,才会再一次发起浏览计数!这就是为啥并非不计数或只计数一次的原因了。 ②、WP-PostViews缓存环境下计数的条件 这个问题很常见,刚我还搜了下,发现也有不少和我这个类似的情况。也就说,PostViews插件会去判断WP是否开启了缓存(WP_CACHE),若开启了则使用ajax的计数方式,否则使用php计数方式。 因此,如果你使用的是非PHP的缓存机制,比如Nginx的fastcgi_cache或者proxy_cahe,那么必须在wp-config.php里面开启WP_CACHE: 让插件知道你的网站是有缓存机制的。要不然,你就得修改插件,去掉这个判断,让插件强行在页面中插入ajax计数代码了。
阅读全文
网站建设

利用HSTS安全协议柔性解决全站HTTPS的兼容性问题

导读:目前,很多站都开始实现HTTPS了,而且其中的大部分强迫症站长还会开启强制HTTPS机制,对于网站的HTTP请求全部301跳转到HTTPS,从而实现全站HTTPS。这明显是一个粗暴的做法,下面张戈博客就分享一下目前正在使用的柔性做法,告别粗暴。 一、HSTS协议 这里我们要借助一个新的安全协议:HSTS HSTS(HTTP Strict Transport Security)国际互联网工程组织IETE正在推行一种新的Web安全协议,作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。 主要目的是为了解决HTTPS网站首次请求时使用的是未加密的HTTP协议,也就说用户一般访问我们的网站都是直接在浏览器输入域名,比如 zhang.ge,然后我们的服务器检测到是HTTP请求,就301跳转到HTTPS页面。那么前半程采用的就是未加密的HTTP请求,同样存在被劫持的可能,那么HTTPS说好的安全性也就大打折扣了! 在我看来,HSTS还有另外一层好处:增强网站的兼容性。 以往分享的全站HTTPS都是采用301强制性跳转,而且还会区分下低版本IE、不支持HTTPS的搜索引擎来忽略301跳转,很明显这样做无法照顾到所有情况。那么如果是用HSTS呢? 采用HSTS后,支持这个协议的浏览器会自动跳转到HTTPS页面,返回码为307: 而不支持HSTS的浏览器访问我们的网站,则不会产生跳转,从而提高了兼容性。这个机制对于不支持HTTPS的搜索引擎来说是非常友好的做法了! 二、开启HSTS 开启HSTS很简单,只要在我们网站的响应头里面新增HSTS即可,下面简单说下 ①、Nginx服务器 只需要在站点server模块内插入如下配置并重启: ②、Apache服务器 Apache如下配置并重启: ③、LigHttpd 将下述配置增加到你的 Lighttpd 配置文件(一般是 /etc/lighttpd/lighttpd.conf)并重启: ④、通用方法 如果你用的虚拟主机,或者不会折腾WEB软件,那么可以采用更简单的通用方法。原理很简单,通过代码来新增响应头即可,这里只分享一下php的做法,其他语言自行参考: 将如下代码插入到网站根目录的index.php即可: 三、相对链接 当然,为了兼容不支持HTTPS的客户端,我们还需要将网站的所有超链接都改成相对模式: 比如,正常的页面链接如下所示: 改成相对模式: 好处就是,不管是HTTP还是HTTPS请求,页面中的地址都是和请求协议保持一致,避免出现页面是HTTP,而页面中的链接却是HTTPS的情况,那么前面的做法也就没了意义。 如何修改为相对模式,估计有同学又玩不转了。万变不离其宗,和以前纯代码启用七牛CDN一样! 直接粗暴替换前台输出的代码即可: 将以上代码新增到 WordPress 主题的functions.php中即可。以上代码只会替换和网站主域名有关系的超链接,八竿子打不着的外部超链接就不管了,有需求自行参考解决。 四、提交HSTS 上文已介绍了HSTS,主要是为了解决HTTP请求301跳转到HTTPS这个过程被劫持问题,而实际上就算加上HSTS响应头,用户请求的前半程依然是HTTP,并没有什么L用。 提出这个协议的砖家们就想出了一个解决办法:将支持HSTS的网站全部加入一个Preload的清单,支持HSTS协议的浏览器请求网站前会查询当前网站是否在清单中,如果是那么直接转换为HTTPS请求!从而解决前半程为HTTP的问题(不专业,但说人话。。。)。 那么,如果我们的网站启用了HSTS,还得将网站提交到这个Preload清单才行了 提交地址:https://hstspreload.appspot.com/  (需要扶墙访问) 提交直到批准,我们的网站必须强制301跳转到HTTPS,否则无法通过,完成审核后再取消301即可。 当然,提交后会显示正在提交到preload list,快的话两三天,慢的话一两个月都是有可能的: 好了,罗里吧嗦分享了一大堆,自行参考吧! 20170205最新补充:经过漫长的等待,偶然查询发现已经是preload状态了,可真不容易:
阅读全文