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-08
14

垃圾评论,滚!

By xrspook @ 10:33:52 归类于: 烂日记

习惯了用python以后要我写php的代码,我各种不习惯。为什么变量前面要加个“$”?为什么要写“{}”这种东西?为什么居然可以乱七八糟不缩进?python估计是不用数组表示东西的,但实际上,在历遍的过程里有数组,而php这东西貌似不像python那样分列表和元组,字符串是肯定有的,字典可能也有,但这个我不确定。在计算某个东西长度的时候还得纠结到底我要分解到什么程度,我不就是要计算一下数组里元素有多少嘛。可能是我使用的方式不对,print_r的确把数组表达出来了,但一坨东西各种嵌套,你给我个缩进好不好,我都分不清谁是谁了。python里计算长度用len(),我已经用得很熟练很爽了,到php里变成了count(),如果数组里还有数组,也要算出长度还得加参数。不得不说,数组这个东西挺让我头痛。记得从前学C语言的时候我就挺烦数组这个东西,我感觉自己一直没学好。当我接触了python,让我明白到其实数组不就是那些东西,为什么就非得用索引号把他们定位表示呢?直接把数据按照数组的排列方式直接表达出来是可以,json就是这么玩的,那是一个混合长度的数组,同样的事情也可以发生在python的列表、字典和元组里。好像在C语言里数组的长度得一开始就设定好,现在看来,我觉得这样不好,因为有些东西的确是很难一开始就想清楚的,搞太小了,放不下,搞太大了浪费空间。学习各种编程语言让我明白到原来某些我觉得参不透的东西其实可能没必要一定用那种思路。

之所以要死磕php,因为我有点讨厌WordPress里的垃圾评论。虽然官方自带的Akismet插件已经免去了我很多烦恼,但还是会有些漏网之鱼,所以我的垃圾评论列表里总有东西,看着心烦。那些垃圾评论虽然不在前台显示,但是在导出数据里会看到,浪费我的空间。对付垃圾评论的方法有很多,插件大法是最适合小白使用的,WordPress自带的规则也能让评论不被摆上台面,但我想做到的是根本不让那些东西写入我的数据库,没有写入就不需要删除,不适合的东西直接滚,减轻数据库的负担。虽然呢,我的小网站向来没什么流量,不会负载超标之类,但每当网站很慢,发布个文章都等半天都开不完的时候我就会暗暗觉得是不是被垃圾评论拖累了。综上所述,所以我选择的垃圾评论对抗大法是“Akismet + 自定义代码”。Akismet这个东西是安装完WordPress以后自带的官方工具,启用、填API就好。自定义代码需要在WordPress模板的functions.php里加入一些东西。网上有很多教程,但哪个才最适合自己得自己试过才知道。评论里可控的参数可以参考comments.php。我的防垃圾评论自定义代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
function refused_spam_comments($incoming_comment) { 	
	preg_match_all('/http/', $incoming_comment['comment_content'], $link); // 有两条或以上超链接的,滚!
	if(count($link[0])>1) {
		wp_die("垃圾评论!!!"); 		 
	}
	$ruattern = '/[А-я]+/u'; // 俄语的,滚!暂时我还没见过大批量日语、泰语、阿拉伯语的
	if(preg_match($ruattern, $incoming_comment['comment_content'])){
		wp_die( "垃圾评论!!!" );
	}
	$name = '/Henrylix/i'; // 中文广告
	if(preg_match($name, $incoming_comment['comment_author'])){
		wp_die( "垃圾评论!!!" );
	}
	$mail  = '/(jjgfqijpo)|(.ru)/i'; // 其它广告
	if(preg_match($mail, $incoming_comment['comment_author_email'])){
		wp_die( "垃圾评论!!!" );
	}
	return($incoming_comment);
} 
add_filter('preprocess_comment', 'refused_spam_comments');

WordPress自带的评论规则里有超链接超两条就自动不显示,自动落入待审核的垃圾评论,但这样我还得去清啊,直接不让进更好,貌似我没有在其它防垃圾评论代码里见过这条。很多教程里“wp_die”那里用的是“err”,我不知道其他人怎样,反正“wp_die”我用得挺好,前台后台都正常,但“err”前台后台都不行。有些人这样,有些人那样,是不是跟不同的WordPress版本有关呢?这个自定义代码只是暂时的,我还得根据垃圾评论继续调整,debug的过程永无止境。

我感觉会了代码,人生才算是有了主动权。

2020-03
23

选择我的语言

By xrspook @ 10:34:20 归类于: 烂日记

现在我到底比10年前进步了多少,我不知道,但显然,10年前我还不认识正则这种东西。后来的很多抓取需要让我不得不学习了这个。一开始,我是在PHP上面用的,而昨天,我要把这个用在Notepad++上面,正则类似,但不同地方的细则又有所不同。正则这个东西让我在Notepad++上完成了我觉得这软件可能完成不了的事情。我太低估Notepad++的实力了!简单的替换或者新增这段,对它来说毫无压力,尤其是纯粹字段的东西。昨天之前我有想过要不要这次之后我也学习一下Python。语言类的东西学习了不少,但是我的电脑里没有配置一个环境可以让某个语言做到输入输出文件。如果把Excel算上,估计那是唯一OK的。我之前用的PHP实际上在编程方面我几乎没接触过。

学习编程语言,学习什么样的编程语言,很多时候都不是由我自己说了算。遇到什么问题,看到别人用什么解决,然后我就会觉得那个东西很有用。如果现在要用一种语言去定义我自己的话,我甚至说不出来。我不需要所有语言都懂,我只需要有一个我非常懂的东西就可以了。但显然,现在我还没做到,所以接下来我需要做的是找到这种语言,然后深入的研究。无论哪种语言,深入进去以后都可以无比强大,起码我想实现的那些小愿望全部不成问题了。其实我也不能说我完全不懂PHP,我还是有点懂的,但主要还是用在一些前端方面。因为我会认识这种语言是从网页与CSS配合开始的。一直以来,我都没有深入进去。我没有在电脑上长期安装一个运行环境。每次我要测试开发WordPress模板又或者其它内容的时候,我也是到需要时才安装,不需要的时候又把它卸载掉。需要PHP的运行环境,意味着可以实现很多计算,但我并不需要一定在本地部署。我把脚本放在网上一个免费的地方,我那些小不点功能其实就可以做到。以前,我是这么干的。现在估计我依然可以这么干。我为什么要配置PHP环境而不配置其他东西呢?其他东西可能更方便快捷。我不知道语言与语言之间的差异主要有哪些。从宏观层面上看,判断和循环基本就是它们的全部,但在如何表达参数上面,各家有各家的说法,所以其实一直以来我都很蒙圈。如果你给我一堆代码,要我判断这是哪种语言的。我肯定说不上,除非有一些非常明显的标志。看看他们的声明以及执行部分,很多时候我觉得都一个样。当然这只是我肤浅的觉得,实际上不是这么回事。因为我不熟悉他们,我只是见过他们,有些更加纯粹是一面之缘。

就像我用一个数据透视表能解决几乎Excel的绝大多数问题一样,因为我熟悉它。如果我熟悉公式,我也一样可以单用公式解决Excel的绝大多数问题。我是时候在一种编程语言上下功夫了。

2020-03
17

页码导航,搞定!

By xrspook @ 10:44:11 归类于: 烂日记

昨天突然发现,备份下来的COLOR3模板的截图是2014年的,所以这个模板是不是没有10年历史这么悠久呢?WordPress我用了10年,但这个模板用了多少年?我真的没有仔细翻查过资料。(发布这篇blog之前我又验证了一下,COLOR3的确是2010年的作品)。就怪当年设计好模板之后,我没有在上面标注时间,现在完成改版以后,我会在CSS上标注上版本的更新信息。我会不会把这个模板用一辈子呢?真不知道,又或者不知道多年以后我不用WordPress了呢。

昨天我把之前用插件解决的页码导航也实现了,但实际上不知道从第几个版本的WordPress开始,已经内置了页码导航,但很多个版本的官方标准模板上面的只有上一页和下一页。上一页跟下一页的设置非常原始,对内容有非常多的blog来说,这简直就是把人杀死的节奏,虽然有一点观察力的访客会发现,除了主页是没有页码以外,只要你翻到第2页,从网址上你就已经能看到页码了,所以接下来你只需要天马行空地在那里输入你想要的数字,就能跳转到那个地方,但问题是,对一个路人甲来说。页面只显示了上一页跟下一页,但最后一页是多少呢?难道还要搞一个猜谜游戏?于是,这又让我想起了那个什么逼近法。用靠谱的页码导航就不会有这种烦恼,那些算数问题全部都留给服务器了,因为任何一个导航页面都会有首页和最后一页的锚点(最后一页其实是算出来的),上一页跟下一页的锚点也是有的,当然如果那是最前头和最末末,会缺少了其中一个方向的锚点。中间的页面要展示多少个锚点,系统预留了控制点。我不知道这么好用的功能,为什么WordPress不把它光明正大读放出来,当然,没有很光明正大放出来的还有很多神奇的函数,比如,里面有很好几个预设参数,没有评论的时候可以显示一个信息,一条评论的时候可以显示一个信息,多条评论的时候可以显示一个信息,不允许评论的时候又可以有另外一个信息。对中文用户来说,一条评论和多条评论从语句设定上没有区别,但是,对英文来说,就有一个单数跟复数的区别,WordPress是外国人开发的,当然就会有把这两种分开来预设。昨天我没花什么功夫就找到了WordPress原生自带的那个页码导航,这纯粹是我运气好,万一我搜索了好几个小时才找到呢?找到那个原生的函数以后,我只需要对里面的东西进行格式化。WordPress肯定也知道。他们没有格式过的界面是没办法直接使用的,所以早就放好了各种关键字,只要你对那些东西进行合适的处理,就能做出你想要的效果。

在使用原生页码导航之前我查看了WordPress最新官方模板2020的代码,那个模板用的就是原生的页码导航,但经过高度的格式化处理。不知道现在的开发理念是不是区块管理,所以在2020模板里一个php又引用了另外无数的php。一个模板里有好几个文件夹,一个文件夹里有好几个php。当你打开一个以后,你不得不又继续跳到另外一个,继续有可能还要到其它地方。我是个很懒惰的人,基本上我把我需要引用的函数都丢到我的functions.php里。之前的COLOR3有好几个sidebar相关的php,但现在通过用函数判断,我直接把它们都缩到一个里。十年之前的COLOR3,基本上我都只是对CSS动刀,但现在,我会自己研究php里面的判断。其实无论是哪个编程语言,我觉得最终都可以变成简单的几条。第1条是分配,第2条是判断,第3条是循环,第4条是输出。基本上可以这么说,所有编程语言都在玩这几条,尤其是判断跟循环,不断地组合搭配,就能得出你想要的东西。现在回想起来,当年学习C语言的时候,冒泡法基本上可以被称作是终极大boss。当时老师觉得那是教学大纲里最高端的了,搞懂了那个,其它基本上不成问题,而冒泡法这种东西,连老师自己上课的时候也说得小心翼翼,因为她自己也没达到可以随便就脱口而出谈冒泡法的境界。估计现在再让我去冒泡法,我会得心应手很多。

大概当我彻底完成COLOR3模板升级以后,我会重新开始学习Java。几年前那本深入浅出学习Java的书看得我直接投降,因为后面的习题我就没做对几个,如果现在再去看的话,估计会有一些长进了。

2020-03
15

搞清楚comments.php

By xrspook @ 11:28:25 归类于: 烂日记

时间用在查找代码上去得特别快。感觉问题还没解决,时间就已经溜了。大体上看,就只有几个大问题需要解决,但实际上那些东西是完全没有头绪应该怎么去做的。昨天我花了一个下午的时间去处理comments.php。那个模板用来设定在哪里显示评论,哪里显示评论框,这其中还不包括评论框里的具体格式。看上去这是非常简单的事情,实际上,还是要考虑好几个问题,但显然,10年前,做那个模板的时候,我没有在comments.php这个问题上纠结,我顶多是往里面放了一些我设定好的CSS,所以那个部分的逻辑到底是怎样的,我没去修改,沿用的是某个模板。实际上我用的那个模板是不是标准的,我也说不准,因为我实在不记得当年我用作改造的模板是哪一个。因为通常WordPress的官方模板都非常简单,甚至可以说简单过头,于是你不知道该如何在那个的基础之上改造。大概之前,我的那个comments.php测试的时候,我只是考虑了一般情况。但除了正常情况,WordPress里还是会有一些极端情况,比如说某篇日志被设计为密码可见。无论是日志还是评论,在输入密码之前都应该是一片空白。那个模板就很神奇,日志部分已经是提示输入密码才可见,评论部分直接不显示就行了,但实际上,那里居然在会提示一次输入密码才可见,显然这就是画蛇添足了。让我纠结的时间最长的是嵌套格式的代码。因为正文部分我分为左边和右边,左边是文章的主体以及评论框,右边是边栏。这两个板块,一个是float向左,一个向右,一旦代码嵌套不合理,右边的边栏就会进入左边,又或者直接消失,也有可能是因为缺少结束嵌入代码,所以网页底部的东西飞上去了。要解决这些结构格式上的问题,就首先要搞清楚,那些php代码的开始结束位置。比如说某篇文章设定了不允许评论,但是对于已经有的评论,你还是要把它们显示出来,然后在最后一条的那里显示不许再评论。之前我根本没有测试过不许评论这个功能,显然当我在撰写日志的时候设定了不允许评论以后,之前的模板相应网页会出状况。而之所以这样,是因为默认的模板里面我只在if下面添加了足够多的格式结束标签,在else里面没写。不许评论就是else的部分,判定函数应该是评论是否开放,但实际上,不允许评论这句话从结构看来,应该是放在评论列表的最后。这样的风格才会统一,因为有些时候,不许评论之前可能文章已经有评论了,如果硬生生地把那放在允许评论就有评论框,不允许评论评论框消失并写着不允许评论,那样就太生硬了。

我花了几乎一个下午的时间去处comments.php,最后终于搞清了里面的逻辑关系。为了让那些if跟else,以及endif能更好地维护,我在上面做了很多注解,基本上每个的那里我都会写清楚了对应的是哪个,同时我也进行了缩进。那么以后找的时候就不会那么头痛。如果写代码的人用的是大括号,显然就不需要纠结endif对应谁。我也不知道为什么那个人不用大括号,在没有标注也没有缩进的情况下搞清那些东西真的好费神。

纠结不是毫无用处的,这会让我变得更强大。

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