阅读视图

发现新文章,点击刷新页面。

尝试升级 WordPress 版本 和 PHP 版本,然后失败了

尝试把 WordPress 从 5.2 版本 升级到 6.6 版本,把 PHP 从 7.4 版本升级到 8.3 版本。

任务艰巨得完成不了。

非常的崩溃。


前提

我现在的线上的博客,以及线下的开发环境,以及(如果还在不为我知的某个角落存在的话)商用用环境,都是 PHP 7.4 的。

最早些时候,应该算是2015年,正式入坑 PHP ,那时候基本是公司用啥,我用啥。PHP 5.2 5.4 5.6 都用过了,尤其是 5.2 大坑一大堆,摔过很多次。然后到 2016 年的时候终于用上了革新的版本 PHP 7.0。真爽。再后来开始自己独立开发环境,直接开了 DAMP 的坑,最初也是用的 7.0 版本,然后就很随意的升到 7.3 版本,主要是当时开发负担少。然后博客站也都升级到了 PHP 7.3。

再后来 2021 年接了一个外包项目。虽然当时 PHP 8.0 已经发布了,但是貌似周边支持都不怎么地。为了保证开发速度,直接用了 PHP 7.4 版本。当时还涉及到前端开发,Node环境也是大更新,很早之前一直用的各种热门前端库基本都死绝了。博客和本地开发环境也都升级到了 PHP 7.4,博客的 WordPress 程序倒是没变,还是 5.2 版本(这里埋了个大坑),只是偶尔会从官网下载代码包然后手动更新对应的文件,以修复些潜在的安全问题。

现在是2024年年末,就连PHP 8.0 都已经停止维护快满一年了,最新版本 PHP 8.3 也已经发布快满一年了。WordPress 都到了 6.6 版本了,一堆 WordPress 插件都已经停止 5.2 版本的支持了。

想趁着有时间有机会,把 PHP 和 WordPress 都升级了。

天真了。


第一天

首先是把线上的代码全备份一遍。这个毫无工作量,我之前写了个备份代码,直接就把自己的整站扒下来。然后把备份的站再部署到本地的开发环境上,再改几个数据库字段,就完事了。打开后台,先禁用所有插件,以便升级之需。

Apache2 和 MySQL 不用动,因为用的一直都是 Docker 的最新版本,这几年也没什么巨大的兼容性变化。

PHP 这块我不知道算不算麻烦。我把 PHP 从 7.4 到 8.3 的所有 不向后兼容变更废弃功能 全都看了一遍。没多少,就几页,几分钟就看完了。个人感觉这么多变更,只有一条能实际影响到我日常开发工作,就是自 8.0 起不再支持 带有默认值的参数后面跟着一个必要的参数

screenshot_on_b85m_by_flameshot_at_2024-10-24_22-51-45.png

其实个人工作中也很少这么用,因为易读性有点烂。论性能来讲的话这么写性能也很差,只不过以前工作过的公司里就有很多人这么写,主要是为了防止其他同事调用函数忘记传参(空参也是参)。

其余的改动基本影响不到我。我使用的基本都是 PHP 的官方建议用法,最多也就是会遇到某些外部库被遗弃然后有个平替的情况,比如数据库接口啥的,即使出错了立刻就能发现。

于是很自信的先把 PHP 环境升级到了 8.3 。因为是基于 Docker 的所以也完全不用担心环境污染的问题。

然后就崩了,WordPress 就打不开了。

这倒是意料之中,毕竟当年 WordPress 4.3 版本当年连 PHP 7.0 都不支持。我现在用的是 5.2 版本,最高能支持的 PHP 版本也才 7.3 ……

Screenshot_2024-10-24_at_23-02-46.png

什么?7.3?但我已经用 PHP 7.4 跑了 WordPress 满 3 年了啊???

什么兼容性测试……

下载了个 wordpress-6.6.2 的包,按官方文档手动安装。 崩得一塌糊涂

全部删除了重新来,这回用官方的自动升级功能,直接从 5.2 升级 6.6。真神奇,WordPress 官网被墙了这么久了竟然能秒下 WordPress 的安装包,我也不知道他是走的什么渠道。PHP 就这点恶心,前台所有操作你都看不到任何细节,就像是在用 Windows 一样。

成功安装。然后 崩得一塌糊涂 。这回不仅崩得稀烂,而且由于没手工删除后台的旧文件,新旧文件混在一起,更是手足无措。

就这么搞了超过6个小时,一直干到后半夜三点多,搞不定。

放弃,睡觉。

然后严重失眠,抽搐。

screen_IMG_2148.png


第二天 白天

首先考虑下到底是 PHP 的问题还是 WordPress 的问题。

按理来讲我已经把 PHP 的升级文档都看完了,并没有什么会天塌一般的变更,但是 WordPress 这边的确天塌了。

先在 PHP 8.3 环境下运行一下我的其他项目看看,结果我的个人主页就崩了。

screenshot_on_b85m_by_flameshot_at_2024-10-24_23-33-27.png

我用的是 2023 年 3.1.48 版本 的 Smarty,其基础版本是给 PHP 7.0 做的,可能旧了吧。

下载了最新版本的 smarty-5.4.1 ,然后

screenshot_on_b85m_by_flameshot_at_2024-10-24_15-36-49.png

什么玩意? implode is Deprecated ,我怎么不知道?

又去重新看了一遍 PHP.net 官网的 implode 文档和 PHP 升级文档。根本没有 Deprecated 。

然后在网上搜了一下,发现是 Smarty 的锅。而且 Smarty 还在 join 和 implode 之间反复横跳。更恶心的是,implode 和 join 在 PHP 7.4/8.0 中已经声明并废弃了 先数组后分隔符 的用法,但是在 Smarty 中却是强制要求 先数组后分隔符 ?甚至官方在 issue 里来来了句 Smarty is Smarty and PHP is PHP. 有病吧。而且你就算有病,你特么连个文档都没有,谁知道你有这种抽风的设计啊。

你要知道之所以我还用 Smarty 这种超级古董,就是因为这是一种 靠谱的、前后端分离、完全后端渲染、仅需要 HTTP 和 PHP 环境、不需要臃肿框架和特定语法,的网页渲染模式,是提供给搜索引擎最靠谱的传统模式。没有网页模板系统的话,想写这种纯后端渲染前端显示的页面,就只能 php 和 html 代码混写,非常的恶心。

现在 Smarty 抽风了,真就不知道以后还怎么不依赖框架写这种页面。我搜了下,Laravel 的 Blade ,和 Symfony 框架下的 Twig,貌似也可以独立使用,但是我对 Laravel 和 Symfony 基本一无所知,作为一个 PHP 开发者真是有点丢人。

话题扯远了,回到刚才。

我目前是不太想动我的个人主页的,这 WordPress 是大头,是主要内容。主页只是个入口。虽然主页改动起来并不困难,代码量少,Smarty 抽风的部分比较好找。但主页这一块我其实并不满意,主要是多语言这块用的传参而不是独立页面,很受搜索引擎嫌弃,基本上没收录,收录的也搜不到。但我的确没有精力和欲望去重做。

另一方面,WordPress这边,崩溃得最多的部分其实是插件。WordPress的代码质量本来就很堪忧了,第三方插件更是三脚猫,各种天花乱坠的不规范语法,可以说基本上都不能在 PHP 8.3 上运行。

另外我虽然看了 不向后兼容变更废弃功能 ,但是 PHP 新版新增的语法糖也有点天花乱坠。我用的是最新版的 php-cs-fixer_v3.64.0 ,没配置好的话就会把那些插件的奇葩写法转写成 8.3 的语法糖,有时结果更是瞎眼,基本没有易读性。

综上考虑,先放弃 PHP 8.3 的升级。先把能通的条通。PHP 的升级难度应该不是最高的,但是底下这些撇不掉的小垃圾目前是必须要保且支持不到 PHP 8.3,没精力做修改。

放弃 PHP 8.3 继续用 PHP 7.4 。


第二天 晚上

看兼容性列表,WordPress 6.6 也是支持 PHP 7.4 的。

但是实际上 API 改动实在太大了,而 PHP 前端应用最恶心的一点,就是 出错了,不报错

即使开启了 define('WP_DEBUG', true); define( 'WP_DEBUG_LOG', true ); define( 'SAVEQUERIES', true ); ,也经常是

  • 功能好像开了但是没开
  • 功能好像崩了但是啥日志都没有
  • 功能正常使用但是页面上打了一堆不知道哪里来的错误日志

面对如此大的一个工程而大部分代码逻辑都是不可靠的。升级到 6.6 实在是消受不起。

放弃 WordPress 6.6 ,只升级到比较近的版本。

要不然试试 5.5 吧,毕竟我在用的一款插件,作者自评最高支持到 5.5。

下了个 WordPress 5.5 的安装包,装完了。崩,但是崩得没有 6.6 多。

主题 graphene

不开插件,只看主题,首先就是文章的评论显示不出来。检查后发现是评论的API变了,而我的主题 graphene 是 1.9.4.3 版本的,不支持 5.5 。

screenshot_on_b85m_by_flameshot_at_2024-10-25_00-48-04.png

有时候看其他人的代码就是折磨,代码里写法五花八门,空格TAB混着,一会拼接字符串,一会替换字符串。单引号双引号混着用,左边括号有空格,右边括号换行了。

说实话我都不知道这算不算改好了,反正现在是能显示出来。我更担心的是其实还有哪个不知道的角落还有错,但是看不到,毕竟 PHP 前端 出错了 不报错

官方倒是有个新版的 graphene,但是我现在用的这个主题就是我大量改动过的,因为 graphene 原版的代码实在是, 太错了 。好多代码完全不符合前端的理念。然后是颜色和界面也是要一点一点从设置里调,那复杂和麻烦程度,说真的我更乐意重写 HTML 和 CSS 。

我真的想过很多次自己做一个 WordPress 主题,这个想法可是足够老了。但是当时 WordPress 3 版本的主题文档就恶心到我了,真的超级麻烦。而到如今就 WordPress 现在的代码质量,我估计开发主题会更困难更恶心。

也是怪不得其他更轻量的博客程序能后追直上。

插件 Disable WordPress Core Updates

接下来是 Disable WordPress Core Updates 这个插件。

这个插件是为了禁用 WordPress 的界面更新的。但是其实只有一行有意义的代码:

add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );

首先 create_function 这个函数在 PHP 7.2 废弃,在 8.0 中删除,所以我改写成了。

add_filter('pre_site_transient_update_core', function ($a) { return null; });

然后就见证奇迹了。能用是能用,但是 pre_site_transient_update_core 这个字段我在整个 WordPress 代码中都没找到。为什么做一个 pre_site_transient_update_core add_filter 就能抑制 WordPress 界面提示升级? 魔法啊?

然后开启这个插件的时候,更新页面是崩的。

screenshot_on_b85m_by_flameshot_at_2024-10-24_21-14-55.png

魔法。

插件 NIX Gravatar Cache

接下来是 NIX Gravatar Cache 插件。

这是个把 Gravatar 头像缓存到本地服务器的插件,只不过早就死透了。我当时随便改了点代码对付着用,大部分时间没出错也就那样了。

首先是这段代码。(红色部分是我添加的改动)

screenshot_on_b85m_by_flameshot_at_2024-10-25_01-04-29.png

不能直接执行 wp_enqueue_scriptwp_enqueue_style ,要先执行个 add_action('wp_enqueue_scripts', 引用能调用那俩玩意的函数); 。外国人看这种超长的单词时不会眼花吗?

然后是这么一段代码。

screenshot_on_b85m_by_flameshot_at_2024-10-25_01-00-47.png

WordPress 的 register_啥啥啥_hook(__FILE__, array($this, '函数名')); 写法全都作废了,要改成 register_啥啥啥_hook(__FILE__, array($this, '函数名'));

接下来底下那一节:

  • 假如 路径不可写 且 路径为目录,报错

否则

  • 假如 创建目录(权限777)失败 且 路径不为目录,报错

就这烂判断条件看得我脑子都快炸了也没弄明白为什么这破玩意能在我线上服务器上跑几年没报错,而我本地开发环境却根本跑不通。

screenshot_on_b85m_by_flameshot_at_2024-10-25_01-19-42.png

而且这玩意讨厌就讨厌在于,确在我的测试环境下报错了,但是 WordPress 只是多了个 .php-error 的样式并且高出来 2em 的一节,但是一点错误日志都没有!!! 出错了 不报错

最后还是靠自己写 debug 代码定位的问题。

这 TM 都是些不该是问题的问题,竟然多得到处都是。

2天,一点有效进展都没有。唯一有效收获就是这些屎山不碰就没事,一碰能崩得全身是屎。

反而自己写的没有引用那些垃圾玩意的插件和程序,没发现啥大毛病。


第三天

2天没啥进展,给我干懵了。

俗话说没事别升级,升级必出事。

原本的想法是先试着升级,如果不能平滑升级的话,大不了全摧毁了,然后把整个博客文章用导入的方法塞回去重建。如果插件出问题了,大不了找找看是否有新的替代品。结果搜了一下,靠谱的插件基本没有,一大堆商业推广的插件,和一大堆复合性插件,而且这些插件无论对 5.x 版本 还是 6.x 版本的兼容性都乱七八糟,问题解决不了,还有可能引入更多的问题。主题这边则是更不想换,一方面本身现在用的主题就是我大量修改过的,因为网上的各种主题,仅安全性就一塌糊涂,更别说 HTML 标准了。我这主题还是专门针对 1366×768 分辨率优化过的,能在 小屏幕 150% 比例正常显示。让我再去改个新的,工作量也是太大。

现在基本上没辙了。

PHP 这边其实还行,而且版本活跃度比较稳定。

screenshot_on_b85m_by_flameshot_at_2024-10-25_22-09-00.png

https://packagist.org/php-statistics 能看出各版本使用占比都跟维护相关。但 7.4 版本 比 8.0 版本还受欢迎 属实乐了。

但是周边应用真的是质量山体滑坡。WordPress自 3.0 版本就开始崩,后面很多发展都很魔幻,就连编辑器都是靠社区兜底,到现在已经想不清楚这玩意的产品路线是啥了。

其他生态我也不清楚,毕竟作为一个 PHP 开发,我连 Laravel 和 Symfony 都没用过,商用产品都是用 ThinkPHP 应付的,当然最爽不过不依赖框架没有条条框框自己从头写。

但是像 Smarty 这种原行业标志都走奇葩路线了。可以说整个IT行业,基本上,正常的元老人物都退出舞台了,剩下的这些,刨去臭鱼烂虾,就只有偏执而扭曲了,假若走向歪路,那就没得旧,而这一点在开源社区上也极为明显(因为闭源商业的死不死没人关心),Godot 基金会开搞政治正确炮轰特朗普和动画头像用户,Linux 基金会直接开踢俄罗斯的代码贡献者。IT 行业现在就像是一个患了早期癌症的癌细胞轻微扩散病人,看似有救但却是谁都不想救。


结论

给我干哑火了,懵逼了,现在不知道咋整了。

The post 尝试升级 WordPress 版本 和 PHP 版本,然后失败了 first appeared on 石樱灯笼博客.

您的邮箱被管理员屏蔽无法评论

这几天突然被垃圾评论包围,于是寻找一个可以屏蔽垃圾评论的插件,通过一番搜索,终于找到了一款名为 SmartSpam 的插件,最新版本 2.7.0,声称“智能评论过滤器,让机器人彻底远离你!”,最后更新时间为 2021-03-08,装上去之后,果然没有了垃圾评论,感觉非常良好。

晚上继续调整博客细节,增加一点点没有什么卵用的小玩意。

  1. 图片exif添加一个判断,如果不存在,则显示该图无exif信息,感谢作者 @Lopwon 和 @1900 的帮助。(为了这个,去掉了图片懒加载,去掉了 Pjax,损失打开速度。)
  2. 在评论区加一个点赞按钮,搞一点互动,觉得挺新鲜的。
  3. 调整博客配色,绿配橙,很扎眼。
  4. 升级 php8 后,此主题 ShortCode 功能报错,从各个文件里面删除。

以上都是在登录的情况下进行的,很正常。尝试退出登录测试评论功能,却被提示您的邮箱被管理员屏蔽无法评论,小脑瓜子嗡嗡的,完蛋啦,赶紧禁用 SmartSpam 才正常。

所以,这两天光临敝博客的朋友,如果评论失败,并不是我屏蔽您的邮箱,是插件导致的,在此向各位道歉!

最后祝大家国庆快乐!

4F2C5C77441FD0F099C4E838D39B028E.png

Obsidian 和 WordPress 我都用什么插件

Obsidian 插件

1. Hover Editor
快速悬浮模式编辑。

2. Outliner
整理大纲。

3. Clearing Unused Images
用于清理图片,该插件默认不开启,需要清理时才启用。但现在基本不插入图片到笔记,纯文本记录。

以上就是我当前使用的所有第三方插件。之前也试过安装 Calendar、Kanban、Thino 等等插件,但感觉都没太大必要,软件自带功能和核心插件完全可以应付常规笔记需求。插件多了反而影响软件秒开。

我使用 Obsidian 插件的使用原则是,脱离 Obsidian 后,所有内容可以在其他编辑软件中继续正常使用。这意味着类似 Dataview 需要语法来判断、筛选内容的插件不符合我的要求。没有 Dataview 的便捷性,反而让我对于索引卡制作和双链的使用更加严格,对内容有更多的思考。提升效率的插件可以考虑安装一两个,或者多记几个快捷键。


WordPress 插件

1. Akismet
默认插件,能应付部分垃圾评论。

2. Autoptimize
优化 HTML、CSS、JS。

3. Object Cache
优化缓存。

4. WP Permalinks Migration
去年简化固定链接后作重定向安装的,计划明年删除。

以上就是我当前使用的所有插件,其他就是依赖部署服务器的时候一些优化,买的最低配轻量应用服务器。目前感觉网站整体速度还可以。我的开源主题,我会在functions.php 中禁用一些不需要的功能。我自己用的主题,我会禁用更多,比如禁止WordPress自动生成缩略图、禁止响应式图片。我不考虑使用第三方服务,比如图床,以避免以后服务终止或迁移带来的困扰。

-

个人觉得,做笔记也好,写博客也好,软件/程序功能上的需求没有那么多,就是图片和文本信息。基于极简原则,其他都是画蛇添足或锦上添花。花样多,需要投入的非必要时间就多,让你分心的东西越多。够用就好。

WP搬家策略

当年今日

现在WordPress服务器供应商的服务期限大概到今年10月就满了,所以在那之前,团长是应该带着我搬家的,今年早些时候我们已经讨论过这个问题,因为他已经忘记了账号密码,所以常规的搬家步骤不没办法实现,因为根本进不了后台,导出不了数据库,同时也不能把我挂在上面的网站拷贝出来。今年4月的时候,我已经折腾了一番,用的是一个WP的插件(All-in-One WP Migration),那个东西可以在WP后台的界面把网站所有数据全部导出。导出的那些数据被压缩成一个文件。那个文件通过他们网站上面的某些工具,可以在线浏览里面的内容,也可以下载工具安装之后把它解压出来。但即便都解压了出来,那个东西的结构跟WP网站本身还是有一定区别,所以我猜他们没想过用户会把数据导出来以后,通过手工搬家的方式,把数据库挪到其他地方。比如在新的服务器那里,首先进行一个数据库的导入,然后把网站解压的内容复制到新的服务器。为什么这么说呢?因为上面说过,文件加压后的结构跟WP网站本身是有点区别的,但我并没有研究过差异在哪里。有区别就意味着直接搬过去肯定会遭殃。所有人都知道服务器上传文件的大小是有限制的,有可能服务商对你进行了限制,也有可能是软件进行了限制。所以这个插件还卖了一个功能,他们可以把超大的压缩文件上传到你的网站上。你完全不需要考虑文件超限,做不了任何事情。这么高端的操作是付费服务。如果人人都可以轻易地自己挪动,这个付费也就毫无意义,他们也就无法靠这个东西生存下去了。如果网站的数据超限了,但又不想给钱,他们还是给出了一些调整的方案,但这些步骤对小白来说有点复杂,但是对我这种不怕折腾,只要能免费的人来说,完全是可行的。主要步骤分为两个,第一个是在我WP的文件里插入某些语句,但即便这样插入了,也不能保证上传一定不超限。因为还有服务商那边的门槛,所以必要的时候还是要跟服务商沟通一下。在测试搬家这个问题上,我用过两个方式,一个是纯粹的导出导入,第二个是在导入形成网站之后,再导出那个网站的数据库文件,接着把那个网站的网页文件复制到一个新的地方,然后把数据库文件另存为一个新的数据库文件并修改网址,最后把新的网页文件指向新的数据库。之所以做这么无聊的测试,是因为万一服务器那边无论我怎么修改,就是不让我直接导入大文件,我还可以通过这种方式搬家。我20年数据的整个文件不到600MB,而数据库文件只有70多MB。不让600多MB的文件上传,我觉得这是有点可以理解的,但是70多MB的数据库文件,我感觉还是可以成功导入的。如果能实现,我很折腾的第二个方案就意味着我可以把网站从线上搬到线下,然后进行一个普通搬家的流程。之前说过,之所以得这么折腾,是我没办法直接访问现在那个网站的后台,折腾一番以后,实际上我就是把网站线上的后台搬到了线下。

这两年来写了很多的VBA+ADO+SQL,所以我在 phpmyadmin里看到数据库和SQL的时候,我感到了默默的亲切。当我在那里测试SQL语句的时候,发现那个速度实在太感人了。70多MB的SQL文件用Notepad++打开,大概13万行。我要更新里面的某些东西,那是眨眼就能完成的事,跟用Excel处理的速度相比,专业的数据库真的太伟大了。

星期三就已经找过团长,但到星期四下班的时候,他还没回复我。通常情况下不会这么长时间都没反应的,大概他出差了吧…

4个步骤让 MacOS 13 以下版本支持 AVIF 格式预览

如果你使用的是 macOS Ventura(MacOS 13),系统已默认支持 AVIF 格式打开和预览。对于更旧的系统版本,需要通过安装第三方图片浏览软件或拖到浏览器中查看。

AVIF QuickLook 插件可以通过4个简单的步骤,实现在系统直接预览 AVIF 格式,该插件由国内一个作者 DreamPiggy 开发。

要求:

1、macOS 10.11+ (Big Sur+) 以上版本
2、M1/Intel Mac 都支持

步骤:

1、在 Github Release Page 下载最新的 AVIFQuickLook.qlgenerator
2、打开 访达.app (Finder);
3、通过快捷键 Shift + Command + G 打开“前往文件夹”窗口,输入 ~/Library/QuickLook/ 然后回车。 macOS Catalina 以上版本, 使用 /Library/QuickLook/
4、把下载的 AVIFQuickLook.qlgenerator 复制到该文件夹内,可能需要输入电脑密码确认。

如果你已经安装了 Homebrew,只需要一行命令即可。

brew install avifquicklook

安装完,系统就支持直接预览 AVIF 格式了。

wxsync:采集微信公众号图文插件

标准云微信公众号文章采集与自动同步插件wxsync,手动采集永久免费,自动同步采集可按月收费。下载和付费地址:http://std.cloud。

插件支持wordpress和zblog平台,支持公众号历史文章链接付费导出。

搞一个垃圾站,偶尔需要采集微信公众号文章,由于使用频率不高,所有没有选择使用付费的WPJAM GrabMP。实际使用下来,wxsync已经完全够用,能够去除微信公众号文章里的大量无用代码,还可以自动保存图片到本地。我找过很久,免费且实用的插件并不多,且用且珍惜。插件相关功能如图所示,不一一介绍,基本都很直观。

text-autospace

强迫症们,你们终于可以关掉在博客后台安装的text-autospace.js或者Space Lover“空格爱好者”插件了,原因是在CSS Text Modul...

WP Post Heatmap 给 WordPress 博客添加热力图

简介

逛推的时候偶然看到椒盐豆豉的《如何给 Hugo 博客添加热力图》,正好有人需要 WordPress 版本,又正好我还从来没有做过一个 WordPress 插件,又恰好想「多多创造一些自己感兴趣的东西」,就想着试试手。没想到 WordPress 插件做起来出乎意料地简单,整个开发和适配过程大概花了 2 小时 30 分钟(来自 WakaTime 的统计数据)。技术上的细节,在椒盐豆豉的文章里已经非常详细了,想了解的朋友们可以直接去她的文章中看,或者直接查看源代码

在 Hugo 版本的基础上,WP Post Heatmap 使用 PHP 函数读取文章的日期,字数,标题,和链接;然后将其传给 JavaScript 文件渲染 echarts. 整个开发过程没有遇到太多困难,但的确遇到了字数统计不准确的问题:WordPress 默认的字数统计无法统计中文字符,所以我用了个迂回的方式来解决:

$word_count = mb_strlen(strip_tags(strip_shortcodes($post->post_content)), 'UTF8');

在 JavaScript 里,文章的字数单位是千字,保留两位小数:

const wordCount = (post.word_count / 1000).toFixed(2);// Word count of the post

安装和使用

当前版本:v0.01

项目地址:https://github.com/ann61c/wp-post-heatmap

下载地址:https://github.com/ann61c/wp-post-heatmap/releases/download/v0.01/wp-post-heatmap.zip

安装方式:下载后在 WordPress 后台上传插件并启用

使用方法:在文章或者页面中,输入[_heatmap_]即可(请自行去掉下划线)。

在线演示:

如果你想要添加新功能可以在 GitHub repo 里添加 issue 或者在该文章下评论。

特别感谢 椒盐豆豉 分享的源代码。

The post WP Post Heatmap 给 WordPress 博客添加热力图 first appeared on 雪糕.

2款简单的 WordPress 全站限制访问插件

今天要介绍的这两款插件都可以实现让你的博客完全私有化,也就是说没有账户的访客只能看到登录页面。为什么有人想把博客完全私密划呢?1、只想记录给自己看的博客;2、某些内部使用的网站;3、特殊资源的网站。

Registered Users Only

Registered Users Only 安装完成启用后会在设置里面生成菜单进行管理,可以选择的功能只有三个,在没有注册登录的情况下,都会重定向到登录界面。

2款简单的 WordPress 全站限制访问插件

1、This is a default WordPress option placed here for easy changing.
1、任何人都可以注册

2、Allow access to your post and comment feeds (Warning: this will reveal all post contents to guests!)
2、允许访问您的帖子和评论源(警告:这将显示所有的帖子内容给客人!)

3、Allow access to your REST APIs (Warning: this will reveal all post contents to guests!)
3、允许访问您的REST API(警告:这将显示所有的帖子内容给客人!)

Force Login

Force Login 安装完成后甚至连个管理界面都没有,只要开启插件即可实现全站需要登录查看功能。如果是单纯想把博客私有化,Force Login 插件就够了。

将博客减法进行到底之如何精减WordPress插件

对于WordPess的话题,老张好长时间都没有谈了。看了下文章归档,还是在2010年左右老张写的WordPress类的文章多一些,像折腾技巧、插件之类的。《WordPress更换域名后所要注意的十件事》还被admin5收录过。虽然有收获,但是那段时间真的是花了大量的时间和精力在上面。

前段时间把老张博客服务器从4C4G高配降到了2C2G低配版。这个时候遇到了服务器长期满负载而导致博客访问速度变慢的情况,不得不对网站的配置环境和WordPress优化再进行折腾了。

博客的主流程序为WordPress和Typecho了吧,在大家的心目中,WordPress是臃肿的而Typecho精简的,但是大家却没有深入想WordPress为什么会臃肿。WordPress的之所以功能强大,就是借助种类繁多、功能各异的插件实现的。当WordPress插件安装多的情况下,肯定会影响网站的整体速度。记得当初玩WordPress的时候,插件安装了五六十个。其实在月初《将博客减法进行到底!》这篇文章里,还应该提到WordPress的插件也应该做减法,那今天就单独说一说。

对博客做减法其实也应该有一个度的问题,那是什么度,就是“用户体验”。什么是用户体验,老张个人理解认为博客的基本功能要有的同时,还需要让大家看着舒服。所以,过度的对博客做减法,势必会影响到用户体验。所以在做减法的同时,必须要做到与用户体验的平衡。

大家有没有注意到标题里的两个字“精减”,就是体现出如何来对WordPress插件做减法。对于WordPress插件,我们可以分为必装插件和选装插件,而选装插件也可以叫做功能性插件。老张认为必装插件即为缓存类插件,而缓存类的插件还应再细为HTML缓存(前端类缓存)和对象缓存(后端类缓存)。一个网站的打开速度不仅仅是要有一个良好的服务器线路,同时还需要对WordPress优化而安装缓存插件。

目前老张博客安装WordPress插件一共就四个,其中两个为必装插件,另外为功能性插件。

HTML缓存(前端类缓存)-WP Rocket

百度下,WordPress缓存插件不下于十种,每种插件都有各自的特色。常用的前端类缓存插件有WP Super Cache、WP-Optimize、W3 Total Cache、WP Rocket等等。印象当中WP Super Cache插件最为大家熟知。而这次优化WordPress时小胡给我推荐安装的是W3 Total Cache,但是后来与代码高插件冲突,就改为WP Rocket了。

对象缓存(后端类缓存)- Object Cache

对象缓存,后端类缓存只是我个人理解的叫法。主要是用来缓存数据库。WordPress 使用此对象缓存通过将数据库查询结果存储在内存中来节省时间。对象缓存是一种服务器端缓存。这意味着缓存是在服务器级别管理的,不受最终用户或他们用于缓存的系统的控制。对象缓存存储已加载的数据库查询结果。然后它会在下次请求它们时更快地为它们提供服务,这样就不必再次查询数据库。

Redis Object Cache是迄今为止领先的持久对象缓存 WordPress 插件之一, 具有许多强大的功能,包括内置复制、脚本和磁盘持久性。在使用 Object Cache插件时必须要安装PHP扩展redis。具体教程不展开说,网上一大堆。

功能性插件-WP-Douban

我的博客导航“阅读”和“观影”就是这个插件来实现的,直接调用豆瓣里的已阅图书和已观影视来实现。其实这个插件也就是用来装装X吧,某天可能会删掉。

功能性插件-Highlighting Code Block

老张是个爱折腾的人,只有折腾才能出一行教程,而教程里会有大量的代码。为了增加用户体验,还是很有必要安装代码高亮插件的。Highlighting Code Block就是一款比较优秀代码高亮插件。

老张博客的WordPress插件就安装了这四个,也是做到了把WordPress插件的减法做到极致了。

❌