分类 网站后端 下的文章

Discuz! X3.2找回密码提示参数错误的解决办法以及导致的登录缓慢

前言

Discuz!X3.2这个问题不是个案,而是实实在在的bug,网上一搜一大把。但是目前仍然没有官方补丁出来,只有网友力量:

bug描述

在找回页码界面,填写并提交新密码后会出现「参数错误」的提示。

bug原因

discuz在post表单传值的时候没有没有传sign值,但是又校验的了这个sign值。为了安全起见,解决办法不能删除校验这步,必须传送这个sign值。

解决方法

  1. 修改文件:source\module\member\member_getpasswd.php

    $uid = $_GET['uid'];

下方添加

$sign = $_GET['sign'];
  1. 修改文件:template\default\member\getpasswd.htm
    修改

<form method="post" autocomplete="off" action="member.php?mod=getpasswd&uid=$uid&id=$hashid&sign=$sign">

带出的问题

  1. 登录太慢,花时间太久

Discuz!3.2 邮箱32位限制的解除方法

Discuz! 是非常知名的论坛和门户建站平台。但是其对电子邮箱有32位的限制,任何超过32位的邮箱都会被判断为无效邮箱。但是,实际上现在会有一些邮箱会超过这一限制,因此本着对所有用户负责人的态度,解除这一限制就成了当务之急。

经过粗略的研究Discuz!的form有效性验证是form内容提交到网站后,后台(php语言部分)进行验证,再将结果通过Ajax(注册时采用)或者召唤相应页面(注册后手动修改邮箱时采用)的方式返回到网页前端。同时,通过对3.2版本的Discuz!数据库研究发现,其默认的邮箱字段长度位255为可变字符(varchar)。因此,只要我们修改后台相应的php验证模块,我们可以实现最长255位的邮箱支持。不过实际上很难有人注册这种邮箱,我们的目标是为正常人类服务,因此将邮箱长度设置为64位.下面是步骤,就两步:

  1. 修改注册流程的后台php验证代码:
    修改\discuz\source\function\function_core.php第370行函数「isemail」中最大长度32为64
  2. 修改手动修改邮箱流程的后台php验证代码:
    修改\discuz\source\function\function_member.php第285行函数「checkemail($email)」中「strlen($email) > 32」为「strlen($email) > 64」.

php中array_push的用法和注意事项

array_push用法

将一个或多个单元压入数组的末尾(入栈)
array_push() 将 array 当成一个栈,并将传入的变量压入 array 的末尾。array 的长度将根据入栈变量的数目增加。
这里是php.net上的更多内容。

array_push注意事项

  1. 如果用 array_push() 来给数组增加一个单元,还不如用 $arrayXX[] = $dataXX,因为这样没有调用函数的额外负担。
  2. 对于关联数组的push,使用$data[$key] = $value;会更加方便

探索Typecho --2-- Sae memcache

SAE memcache

SAE的memcache基本继承了php本身的memcached,基于memcached有所优化

Typecho Mostcache 插件

Mostcache插件提供了MySQL的cache和SAE的memcache两种方案,因为路上部署在SAE上面,所以直接使用memcache方案。

使用memcache后,chrome浏览器的函数调用从53000+降低到了5300左右,也就是说只有原来的十分之一,而IE11和firefox则更加明显,直接降低到700-800,即只有原来的1.4%左右。换而言之,使用memcache后,性能提升明显。

使用cache后IE/firefox的函数调用图
callgraph1426240020-752.png

究其原因,因为Typecho在设计之初,对数据库进行了充分(过分)的抽象,导致加载页面的时候,会产生过多(复杂)的数据库查询。这就降低了整个网站的效率。

从第一个图片可以看出,在数据库查询是,对mysql_query的查询Inc:104.455ms,Excl:104.455ms,产生了62次调用;对Tyecho_Db_Query::filterColumn的查询Inc:101.316ms,Excl:87.362ms,产生了234次调用,而其对ctype_alnum则有15736次调用。两个大的数据库查询函数调用占到了接近50%(25%+24%)的总执行时间(416.407ms)。从第三个图,也就是采用了cache之后IE访问的函数调用图可以看到:总的执行时间为46.084ms,而且关于数据库查询的时间占用也下降到了<20%。

这再次说明cache是多么的重要!

意外发现

  1. chrome 对后台的调用比IE和firefox多了7倍(5300/750),而且还调用了两次
  2. 采用了gzip压缩网站之后,经常会出现ERR_CONTENT_DECODING_FAILED的错误,导致网站加载失败。。