2024-04
23

测试用wordpress插件搬家

By xrspook @ 8:46:13 归类于: 烂日记

前段时间就被网友告知我们快要搬家了。搬家其实也没什么,但关键是网友已经忘记了账号密码。发邮件给服务器供应商,根本就没有回应。理论上找账密这种事情是很常见的,但为什么居然会没有回复呢?服务器外国,虽然我们的网站上也没有什么秘密,但如果突然有一天他们宕机了,我们又访问不到,丢失的就会是我们一直以来的心血,准确来说可能是我的心血,因为估计极少有人会像我这么痴迷于每天都写blog。虽然非常惋惜,但实际上我自己的内容倒还有纯文字的备份,只是不太容易查找我想要的内容,也会丢失掉所有的媒体文件以及网友的回复。

在我的印象之中,wordpress的经典搬家是需要在服务器那里把网站的内容拷贝出来,然后再去数据库那里把数据也打包出来,接下来就是到新的服务器那里,把网站内容复制上去,把数据库内容重新导到新的数据库里面。最后的步骤就是在域名那里重新做一个DNS的指向,但是这一个倒不是非常关键,因为用IP地址也能访问得到。对我这个基本上不会有什么浏览量的个人blog来说,外人一两天访问不到无所谓。

我想都没想过,我的合伙人居然把账密忘记了,这实在让人觉得非常的无语,所以如果按照wordpress常规的搬家程序,这个家是无论如何搬不动了,但现在有wordpress插件能实现全站搬家。1月的时候我就试验了一下,把网站的内容打包出来,大小是500多MB。他们的搬家方法你基本上不需要用什么大脑,把东西从原来的地方打包出来,然后新建一个wordpress,再把东西再导进去就可以了,但这个步骤到底行不行,会不会有什么幺蛾子?在没有测试过之前,我是不敢直接在网络上操作的,毕竟文件的大小摆在那里,没必要浪费时间。所以我需要做的就是用XAMPP在本地建立一个wordpress的运行环境,然后在本地建一个新的wordpress,然后尝试一下,把数据导进去。

在本地用XAMPP建wordpress对我来说已经不是第一次,但这一次,在win10之下,我发现了一个非常神奇的问题,理论上本地操作速度应该很快,但实际上打开一个页面居然要转上好几分钟,于是我不得不寻求帮助,结果发现首先第一个拦路虎是Windows Defender,那个东西是一个很大的罪魁祸首,所以首先我得在那里把XAMPP的文件夹设置为例外,第二个拦路虎是Apache的端口默认是80,但是80端口容易跟其他东西形成冲突,所以我把那个端口改成了8080。端口改掉了以后,在浏览器那里,打开本地的网站会出现警告,但是忽略了那些乱七八糟的东西以后就很顺利了,网站是秒开的。在我印象之中,以前我使用XAMPP的时候根本没有设置过MySQL的密码,但这一次我进行了设置,因为实际上在新建一个wordpress的时候需要我填入MySQL的密码,但XAMPP的MySQL默认没有密码。所以以前我之所以没有遇到这个问题,是不是以前的教程默认密码那一栏直接留空?

试验证明,那个搬家插件能非常快速顺利地把整个网站挪到其他地方。基本可以这么说,全部东西都挪过去了,起码我测试的部分都挪过去了。一开始的时候网页会出现404,我觉得可能是某些数据没有完全索引到位,当我在后台检查一番以后,再回到那些之前开不了的页面,发现又全部都可以了。可能在数据库方面,需要一定的时间去建立某些映射关系。除了出现404以外,还有一些warning的地方。搜索之后发现原来那是PHP的一些提示,当某个变量没有声明就开始使用的时候,就会出现那些warning,所以我看到的结果是我要的数据都生成出来了,但是那些数据前面会有一段warning,然后我就在自定义模板的functions.php那里把那些有warning提示的自定义变量全部都先做一个null初始化,这样非常傻瓜的操作以后,那些有warning的地方全部都警报解除了。

试验证明,用这种搬家方式是完全可行的。因为我是在本地测试,所以我把上传文件的大小改为了600MB,但如果我在新的服务器上做这种上传操作,服务器会不会允许我上传那么大的文件呢?万一真不允许我这么干,我还有第二个方案,就是先把导出的文件在本地转化为一个完整的wordpress,再把本地的网站和数据库分两片提取压缩,然后再上传到新的服务器。这是一种曲线救国的方法,应该没有问题。

自己的blog有救了,感觉终于可以松一口气。

2020-06
23

做到了

By xrspook @ 10:27:38 归类于: 烂日记

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的,因为python的转换过程中没有出错,这就证明没有遇到奇怪的事情。用别人脚本的时候,把转换好的文件上传到WordPress,我总会担心不成功,但我自己写的脚本,我知道该注意些什么,哪些参数是现在的WordPress必须要求有的,所以只要python的转换不出错,我的WordPress导入就不会有问题。因为点点的文章有9000多篇,要从后台管理界面导入到WordPress,会非常耗时间。如果一篇文章需要两秒,完全导入就需要5个多小时,所以我没有做这种事。我挑选出22篇,各个类型都有的,试验导入,结果非常成功,网页的效果也很好,完全按照我的意思生成了。我觉得如果要快速解决问题,估计我得在数据库端导入。之前把文章导入到WordPress,因为要尝试不同的版本,我得不断地导入删除,但删除的文章太多的时候,速度很慢。后来我暴力地在数据库那里直接写删除语句,结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉,这也是一个秒杀的过程,而且绝对不会留下任何的手尾,比如文章删除了,但是分类和标签仍然在那里。可能某些东西已经不存在了,但是计数还停留在一个很大数值,之所以这样,肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西,还不如直接把数据库清空。因为我这是单机上的WordPress,我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周,才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签,是因为不能删掉一些不应该删掉的东西,但我没有这个顾虑。既然在数据库层面可以快速的删除,那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法,是因为我发现WordPress的插件有些是针对数据库的,有些是针对WordPress自带函数的,数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法,貌似之前我还没有听说过。在网站迁移的时候,的确是把数据库打包,然后重新放到别的地方的,但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方,原封不动地,但是我却要把大量的数据以快速的方式导入到数据库,并且还得按照WordPress的脾性建立各种关联,显然这貌是非常不简单,但理论上应该可以做到。

我不知道我的python到底学成怎样了,但起码我可以用那个东西实现我自己的愿望。相比于书本的习题,我觉得实现自己的愿望更有成就感,虽然其中有很多问题完全只能靠自己,没有参考答案。虽然总的来说,脚本不是我一个人写的,我是站在巨人的肩膀上修改而成,但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了,接下来我要把脚本优化,一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化,应该泛化到什么程度,这个我还没有想好。昨天之所以可以这么迅速地完成任务,大概是因为在我开始之前先做了个思维导图,明确了我到底要做些什么。基础数据有哪些,应该在哪里取数,需要判断的参数有哪些,各自的参数有什么特性,能不能合并同类项。之前我就写过类似的东西,但是跟思维导图比起来,之前我写的那个真的很水。有思维导图、有专业的思维导图软件,人的思路可以非常快地展开。整体定下来,下面的事情就只剩下一步一步地实现。我做梦也没想到,自己这次居然这么高效。某些我没有把握能快速解决好的问题,昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件,我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快,但怎么才能更快呢?文件里的数据结构是我没有考虑过的,我是不是应该从那里入手?一些相同的判断,大概我应该做一些合并。

追求更好是没有尽头的。

2020-03
12

找到凶手了!!!

By xrspook @ 9:07:38 归类于: 烂日记

最上一次大型自己blog的模板可能已经是10年前的事了,具体什么时候回去我还得查一下自己的日志。因为时间太久远,所以根本不记得。可以确定的是,大概在2010年之前,我还没用WordPress整blog,当时我用的BlogBus,根本没想过几年后我会和BlogBus缘尽。之所以这两天我突然想起要折腾,是我发现原来不只是在后台,在前台评论我自己的文章的时候也会出现网站发生致命错误的提示。我不明白这到底是什么鬼,反正当我把WordPress从4.0升级到5.0的时候,就发生了这种事。因为从4.0升到5.0问题太多,所以我根本没有把这个当做回事,比如说我每天都要碰到的撰写的编辑框,从一开始,那个传说中的区块编辑器就不可用,所以升到5.0以后,我不得不使用插件,继续使用经典的编辑器,但是,经典的编辑器什么时候会不支持,这非常难说。区块链编辑器从他们的介绍看来,相当的牛逼。当然把WordPress 4.0升级到5.0还需要PHP以及数据库等东西协同升级。WordPress进行了大升级,支持WordPress的东西也进行了很多高级别的升级,所以我真不确定之前做的模板以及使用的插件还兼不兼容。发生一系列状况的时候。我就有想过是那些东西不兼容。因为还在用4.0的时候,我从来没遇到过这种状况。那种奇怪的现象是发布文章的时候。会突然间跳出404页面。这种事404不一定会发生,但说不准什么时候会发生,但即便发生了,其实文章也是正常成功发布的。可以肯定一定会发生的是评论的时候,一定会有红色字体弹出,告诉我发生致命错误。

为了搞清到底这是怎么回事,所以我又在电脑上装了个XAMPP,从前我就是用这个软件单机测试WordPress插件以及创作我自己的模板的。对上一次用这个软件已经是在另外一台电脑上。总感觉安装这个东西有点麻烦,虽然用的时候很方便。现在的WordPress和从前的WordPress最大的区别在于在中国如果不爬梯子的话没办法访问到WordPress的官方网站。他们说并不是他们故意把我们墙了,而是因为某些其它的原因,到底是故意还是不是,谁知道呢。从中国这边访问WordPress官网出现429开始,已经过去快半年了,情况依旧。所以对那些把WordPress部署在国内服务器的人来说,升级WordPress和升级WordPress的插件都相当痛苦。几乎可以这么说。如果他们无法访问自己的FTP的话,或者手动安装一些据说很有风险的插件的话,是无法升级的。我在自己的电脑上单机部署WordPress,也会存在升级这个烦恼。大概因为我使用的梯子不是全局起作用的,所以无法访问官网,会出现429的错误,所以升级的时候我就得手动,访问插件的官网地址,然后把那下载回来,用zip的方式安装。

新部署的WordPress后,当我把自己内容都放回去以后,所有插件默认是禁用状态的。我启用第1个插件以后,就找到了问题。因为在启用之前,评论是正常的,启用之后就傻瓜了。我相信凶手就是它!当我把十几个插件都试了一遍以后,最终敲定,的确那就是凶手。抓到凶手以后,我还顺便找出了自己为什么没办法用区块编辑器。结论是,不是因为我的插件有冲突,也不是因为我很多年前写的模板太低端,而是因为我没有启用可视化编辑器。自我开始使用WordPress以来,我就从来没有启动过可视化编辑器,泪奔~~~ 这些年我都是怎么熬过来的啊啊啊啊啊啊啊啊啊啊!

接下来我会花点时间修改一下很多年以前设计的模板,主要做的是简化,会合并一些功能,然后再改一改门面。从前我觉得很有必要堆砌起来的东西,现在看来无所谓了。

不同的时代有不同的特点,我是时候做一些改变了。

© 2004 - 2024 我的天 | Theme by xrspook | Power by WordPress