阅读视图

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

尝试升级 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 石樱灯笼博客.

感谢星巴克

多年来我一直说,作为从业者,对星巴克的态度多半是感谢。2009 年我的咖啡馆开张之后的许多年里,顾客都寥寥无几,把泡咖啡馆描绘得多么贴近生活,都没什么收效。倒不是说独立小店长着一张不可信的脸,而是声量太小,认同这个观点的人未必听得到,听到的人里又有不少人不认同——咖啡馆是相亲的地方;咖啡馆应该有单间;咖啡馆可以抽烟打牌……许多人始终这么认为。

星巴克开到我们这个小城市的时候,有朋友替我担心竞争压力,我反过来安慰——在我没为此事感觉疲倦之前——独立咖啡馆和星巴克不在同一片海域,它像是一艘大游轮,会让人们知道可以出海,但是喜欢坐游轮和喜欢摩托艇、潜水艇、小舢板、古董船……并不冲突。果不其然,也正是从那时候开始,咖啡馆在我们这个城市渐渐多起来,我的店,因为「历史悠久」,经营状况如我所料是有好转的。而且客人们已经大致上了解,咖啡馆里可以只是坐着喝杯咖啡聊聊天,消磨一段时间,放松一下身心。

在我的观念里,事物的发展会衍生出许多相应的习俗和趣味,我不喜欢所谓弯道超车的原因之一就是它会丢掉这些习俗和趣味。妳要问我细致的因果链条,我没法说出。但是要说「因为一切发展太快了,所以才会有,带着A家的东西去B家吃,惹得B家不高兴的事出现」,我猜还是会有很多人同意吧?毕竟,就算不知道事情到底是怎么运作的,如果慢下来,一定会出现让各方都相对满意的方案出现,大家都慢慢接受,这就是约定俗成。

这世界没有如果,现在的情况就是,一切都那么快。上一秒,咖啡馆还是所谓小资场所;下一秒咖啡馆随处可见。一方面,人们还抱有一种预期,自己进了门就该被当作上帝或者潜在的上帝,不容置疑;另一方面,现实是咖啡馆已经和早点摊理发店没什么区别。不会有人觉得早点摊主或者理发店主要求已经落座的客人赶快做决定有什么不对,但是咖啡馆似乎就不行。如果问我的处理方式,坦白说,我把自认为理应如此的规矩——归根到底就是不要影响到其他客人——写在了大门上、菜单上、小票上,但是具体到某个客人时,我基本什么都不说。原因还是那样,作为独立小店——即便是全市最古老的咖啡馆,影响力是很小的,客人们听到的是「这家店的要求」而不是理应如此。这个时候,星巴克作为在中国有几千家门店的连锁品牌,它的做法不见得最妥当,但是无疑是成功地提醒到了我们,因为跑得太快而忽略了一些必要的思考。

fin.

我们在反对微博「访客记录」时到底在反对什么?

近日,微博在会员功能板块中新增「访客记录」功能,一下子桶了马蜂窝,炸出很多妖魔鬼怪。

反对者大多以侵犯用户隐私权为由,对微博一顿炮轰。

在持此观点的人看来,访客记录功能侵犯的「隐私权」是用户自由浏览的权利,我可以自由翻看某一个微博账号的所有发布内容和评论区,但你平台不可以告诉博主我进行了浏览。

事实上,访客记录是微博原本就有功能,只不过最近才开放给普通用户[1]

其实,想知道谁访问了我的空间,不一定需要访客记录,现实世界里其实有很多可以借鉴的方法。

人就是这样狭隘的动物,只关心自己看到的,那些潜藏在事物本质里的东西,即使危害更大,也漠不关心。

或者说,人只能看到自己认知以内的东西,对认知以外的事物熟视无睹。

「访客记录」这种功能并不是什么新鲜事物,早在QQ盛行时代已经存在,谁访问过我的QQ空间,通过访客记录一目了然,时至今日,用户也只能开通黄钻才能查看。这也没听说过有大规模的反对声音。

访客记录更早来源于网站的流量统计系统,比如友盟+、CNZZ、百度统计等平台,每个宽度账号都有一个IP地址、每个用户终端设备也都有MAC地址、设备编码,站长在网站页面里嵌入统计代码,就可以精确查看每个访客的设备配置、地理位置、访问的时间、访问的内容……根据这些统计内容,优化网站的内容运营。这些信息的收集,网站访客是毫无感知的。

再比如,很多APP都会收集用户的信息,包括用户的个人信息、位置信息、通讯录、输入设备……通过分析这些数据,可以精准地为用户画像,可以更加精准地进行营销和广告推送,实现更大价值的流量变现,甚至有些企业会直接通过售卖用户隐私信息来赚钱。你不同意收集,那就不能使用APP。这也没有出现大规模的反对声音。

而微博说要开通访客记录功能,就有一大批人跳出来反对了。

既然访客记录是一个有着悠久历史的功能,在技术上也并非是一家垄断,那为什么微博推出访客记录就遭到了用户大规模的抵制?我们在反对微博「访客记录」功能的时候,到底在反对什么?

国民软件抖音也有访客记录功能,为什么没有遭到用户的反对?让我们研究一下抖音的访客记录开放机制。

抖音的访客功能需要用户自己打开,一旦打开系统会提示:

·访客记录中仅展示同样已授权的用户
·开启后,你访问他人主页也将留下记录
·你可以随时在访客设置中关闭授权

——你想查看谁访问了你的主页,你必须也让对方知道你访问了TA的主页这项记录。再反观微博的访客记录政策:

·面向SVIP和VVIP用户开放
·内容仅对博主本人可见,且不论访客是否关注,博主都能看到这些访客,并且还能按照全部、关注、粉丝、非粉丝和认证用户分类查看
·SVIP用户还可以管理自己的访问记录

——谁买了会员就能查看自己主页的访客记录,而且还可以删除自己访问其他用户的记录。

对比之下,不难发现,在微博上谁交了钱谁就可以查看其他人的脚印,而且交了钱还可以擦除自己的脚印;抖音是你想查看其他人的行踪,你必须公开自己的行踪,不用掏钱,免费!

用户反对微博访客记录,其实反对的是权限不对等、政策不公平。

在当下信息社会,这样的不对等、不公平现象还很多。

此前有新闻报道,湖南岳阳三荷机场的公共停车场禁止特斯拉进入,机场方面给出的解释是特斯拉哨兵模式会24小时远程监控周围环境,存在泄密风险。消息一出,即刻引起舆论的热议,讨论更多的就是公平问题,既然特斯拉已经在中国正常渠道销售,为什么仅仅三荷机场一处要禁止入内?

其实,早在2021年7月国家安全部门就下发过,各市局单位要限制特斯拉驶入跟停放于办公场所,且要求工作人员禁止在车内及车周围讨论与工作相关事宜,已购买的特斯拉需要登记备案。[2]

无独有偶,在体制内,公务员、事业单位的人员也被告知禁止使用苹果手机。

很多人不解,明明特斯拉、苹果手机可以合法合规在中国销售,却为何要禁止使用?这也反映了权限不对等、政策不公平。

表面上看,这些都是「个人隐私」,个人的自由,事实上,这里面涉及的「个人隐私」已经包含了国家层面的公共安全。众所周知,特斯拉的数据储存在美国,车辆进入涉密单位后周围环境监控瞬间传输给美国情报机构,存在严重泄密风险。苹果手机更是以安全性著称,某些官员被调查后,公安机关从国内调集多款破解软件都无法解开官员的苹果手机,只要官员不打开手机,在证据链上就欠缺,从某种程度上就能逃避一些调查,给反贪腐工作的进展带来障碍。

在一定程度上,可以这么认为,舆论反对侵犯隐私本质上也是反对不公平。

媒体经常拿用户隐私大作文章,用户真的对个人隐私特别看重吗?在互联网时代,以免费使用产品换取用户隐私,是世界通行的方案。这是一个权宜之计,因为互联网公司需要盈利。假设我付费使用互联网产品,你互联网公司要100%保护我的个人隐私,可以吗?基本上不可能,因为一个普通用户根本无力承担互联网产品空间租用、宽度管道的占用成本。

而互联网公司通过跟品牌商合作,就能平衡互联网产品运营成本、甚至盈利。可以说,互联网广告都是靠出卖用户隐私赚钱,互联网公司靠各种形式包装用户隐私卖给品牌方带来巨大的溢价,同时也带来了互联网商业的繁荣。

当下的互联网企业,只要存在广告分发业务,无一不在兜售用户隐私,禁止出售用户隐私绝大部分互联网公司就会倒闭。

于是,才有了禁止过度采集用户个人信息的相关法律条款。我只是使用了一下你的产品,而你把我的个人信息打包出售,这个价格远远超过了普通人能想到的数目。

这不是很神奇吗?


  1. 这里的普通用户指除微博运营人员之外的人。
  2. 该传闻并未得到相关当事部门的正式确认。
❌