一个DiscuzX的奇怪问题的解答,用户中心出错

 

出错情形如下,dz-unserialize

正常应该是这样的

dz-unserialize2

那么到底是什么出了问题呢,经过一番代码搜索,发现在数据库读取 pre_common_setting 表里面 skey = profilegroup 的svalue 值 无法反串行化 unserialize
从而无法得到数组,导致更新失败,从而无法在这里显示,究其原因,可能是dz之前是gbk版本,后来改为utf8,此字段没有正常修改,从新安装的utf8版本的discuzX 复制进去svalue 后,成功恢复。

 

最土团购的项目编辑多图上传kindedit编辑器

最土团购网站的项目编辑部分,本单详情的内容编辑器采用的kindeditor 比较简陋,可以用最新版本的替换,
下载最新版放入 static/kindeditornew 目录 ,然后修改 include/template/manage/manage_header.html
加入定制内容
注意里面的 textarea[name=”detail”] 是关键

<link rel="stylesheet" href="/static/js/kindeditornew/themes/default/default.css" />
<script type="text/javascript" src="/static/js/kindeditornew/kindeditor-min.js"></script>
<script charset="utf-8" src="/static/js/kindeditornew/lang/zh_CN.js"></script>
<script>
var editor;
KindEditor.ready(function(K) {
editor = K.create('textarea[name="detail"]', {
allowFileManager : true
});

});
</script>

nginx的ecshop伪静态配置

nginx 配置 ecshop 伪静态
if (!-e $request_filename)
{
rewrite "^/index\.html" /index.php last;
rewrite "^/category$" /index.php last;
rewrite "^/feed-c([0-9]+)\.xml$" /feed.php?cat=$1 last;
rewrite "^/feed-b([0-9]+)\.xml$" /feed.php?brand=$1 last;
rewrite "^/feed\.xml$" /feed.php last;
rewrite "^/category-([0-9]+)-b([0-9]+)-min([0-9]+)-max([0-9]+)-attr([^-]*)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$" /category.php?id=$1&brand=$2&price_min=$3&price_max=$4&filter_attr=$5&page=$6&sort=$7&order=$8 last;
rewrite "^/category-([0-9]+)-b([0-9]+)-min([0-9]+)-max([0-9]+)-attr([^-]*)(.*)\.html$" /category.php?id=$1&brand=$2&price_min=$3&price_max=$4&filter_attr=$5 last;
rewrite "^/category-([0-9]+)-b([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$" /category.php?id=$1&brand=$2&page=$3&sort=$4&order=$5 last;
rewrite "^/category-([0-9]+)-b([0-9]+)-([0-9]+)(.*)\.html$" /category.php?id=$1&brand=$2&page=$3 last;
rewrite "^/category-([0-9]+)-b([0-9]+)(.*)\.html$" /category.php?id=$1&brand=$2 last;
rewrite "^/category-([0-9]+)(.*)\.html$" /category.php?id=$1 last;
rewrite "^/goods-([0-9]+)(.*)\.html" /goods.php?id=$1 last;
rewrite "^/article_cat-([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$" /article_cat.php?id=$1&page=$2&sort=$3&order=$4 last;
rewrite "^/article_cat-([0-9]+)-([0-9]+)(.*)\.html$" /article_cat.php?id=$1&page=$2 last;
rewrite "^/article_cat-([0-9]+)(.*)\.html$" /article_cat.php?id=$1 last;
rewrite "^/article-([0-9]+)(.*)\.html$" /article.php?id=$1 last;
rewrite "^/brand-([0-9]+)-c([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)\.html" /brand.php?id=$1&cat=$2&page=$3&sort=$4&order=$5 last;
rewrite "^/brand-([0-9]+)-c([0-9]+)-([0-9]+)(.*)\.html" /brand.php?id=$1&cat=$2&page=$3 last;
rewrite "^/brand-([0-9]+)-c([0-9]+)(.*)\.html" /brand.php?id=$1&cat=$2 last;
rewrite "^/brand-([0-9]+)(.*)\.html" /brand.php?id=$1 last;
rewrite "^/tag-(.*)\.html" /search.php?keywords=$1 last;
rewrite "^/snatch-([0-9]+)\.html$" /snatch.php?id=$1 last;
rewrite "^/group_buy-([0-9]+)\.html$" /group_buy.php?act=view&id=$1 last;
rewrite "^/auction-([0-9]+)\.html$" /auction.php?act=view&id=$1 last;
rewrite "^/exchange-id([0-9]+)(.*)\.html$" /exchange.php?id=$1&act=view last;
rewrite "^/exchange-([0-9]+)-min([0-9]+)-max([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$" /exchange.php?cat_id=$1&integral_min=$2&integral_max=$3&page=$4&sort=$5&order=$6 last;
rewrite ^/exchange-([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$" /exchange.php?cat_id=$1&page=$2&sort=$3&order=$4 last;
rewrite "^/exchange-([0-9]+)-([0-9]+)(.*)\.html$" /exchange.php?cat_id=$1&page=$2 last;
rewrite "^/exchange-([0-9]+)(.*)\.html$" /exchange.php?cat_id=$1 last;
}

phpdisk 支付宝支付的一个可能缺陷

在phpdisk z-Core 3.5 版本 的
plugin/payment/alipay/class/alipay_function.php 的 para_filter 函数 没有去除干净符合支付宝的参数,在alipay_config.php 里面定义的返回地址包含了额外的参数 action=alipay,

return_url = $settings[‘phpdisk_url’].’payment.php?action=alipay’;
所以必须把这个也去除,方式是如下图,
否则的话,计算md5 值可能出错!从而导致支付失败

phpdisk_alipay

 

 

两个ecshop的同步,相同goods_sn的价格保持一致

假设 A库 同步到 B 库,就是说A库发生变化了,B库就要和A保持一致,相同goods_sn的商品价格也变化到和A相同,那么A 为sorce_table,B 为 target_table  ,相应的SQL为 :

update b.ecs_goods target_table  ,a.ecs_goods source_table set target_table.shop_price = source_table.shop_price where source_table.goods_sn = target_table.goods_sn;

几乎所有支付通道的通知系统设计

简单一句话:

支付通道一般都有两种通知应用程序支付结果,一个叫PDT,一个叫IPN,

有些名称不一定叫这个,但是一般来说,原理是一致的,我们这里采用的是Paypal 的叫法

PDT 就是所谓的客户端通过网页返回付款数据

IPN 就是服务器之间的数据通知,一般来说IPN 有重复通知的,如果没有通知到,可能回发出多次通知

而且一般来说 IPN 速度要快过 PDT,这就是为什么有些支付后,显示订单已经被处理过的情况,其实我们认为,好的程序设计只要采用IPN通知来处理付款后的逻辑,这样比较安全,而网页返回部分逻辑可以用,仅仅查看本系统内的订单支付状态,根据订单支付状态来告知客户是否已经支付成功,就不必去处理更改订单状态的逻辑部分。当然,万一IPN通知出现了延迟,那么可以告知客户过一会再看,不必多次支付,免得对一个订单多次支付。

ecshop 注册送红包

在user.php 的注册成功信息显示前面,大概是  show_message(sprintf($_LANG['register_success'].............前面加入
注意下下面的 $bonus_type_id = 1; 需要先在后台加入对应的红包的id

//phpsir 1111
$bonus_type_id=1;
$bonus = $db->getRow('SELECT * FROM ' . $ecs->table("bonus_type") . " WHERE send_type = 0 And type_id =  $bonus_type_id", true); 
if($bonus){ if(time()<($bonus['send_end_date']+28800)){
 $sql = "INSERT INTO " . $ecs->table('user_bonus') . "(bonus_type_id, bonus_sn, user_id, used_time, order_id, emailed) " . "VALUES ('$bonus[type_id]', 0, '$_SESSION[user_id]', 0, 0, 0)";
 $db->query($sql); } } 
//phpsir 1111_end

phpcms 的 sso 通信失败的解决和思路

朋友的phpcms 在sso 登陆设置中,出现通信失败,最终调试发现,服务器本机linux,无法访问本身域名的ip,这个vps是虚拟的ip,内部ip,蛋疼的是,他无法访问外部隐射ip,从而导致,file_get_contents(“http://域名/api.php………”);无法得到结果

解决方法是手动在本地 hosts 里面加入一行
10.0.8.99  www.domainname.com
也就是虚拟ip和域名的对应关系
程序无需修改,自动就通信成功了。

发现此类问题的服务器是 息壤VPS,不知道其他的VPS商是否也有此类问题,并且,是否如DiscuZ Ucenter 也会出现此类问题,不得而知,在此记录一下心得

mysql 重置密码的正确方法

net stop mysql 先停下当前mysql服务 
c:\mysql-init.txt 内容如下
UPDATE mysql.user SET Password=PASSWORD('phpsir') WHERE User='root';
FLUSH PRIVILEGES;

然后 启动 mysql

C:\> "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld.exe"  --defaults-file="C:\\Program Files\\MySQL\\MySQL Server 5.5\\my.ini" --init-file=C:\\mysql-init.txt  --console

参考 : http://dev.mysql.com/doc/refman/5.5/en/resetting-permissions.html

ecshop的paypal sandbox 测试支付,需要修改的部分

QQ截图20130503164129

QQ截图20130503163955

下面是代码,方便复制

get_code函数里面
 $def_url  = '<br /><form style="text-align:center;" action="https://www.sandbox.paypal.com/cgi-bin/webscr" method="post" target="_blank">' .   // 不能省略
respond 函数里面
// post back to PayPal system to validate
$header = "POST /cgi-bin/webscr HTTP/1.0\r\n";
$header .= "HOST: www.sandbox.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) ."\r\n\r\n";
$fp = fsockopen ('ssl://www.sandbox.paypal.com', 443, $errno, $errstr, 30);

shopex 在nginx 环境开启伪静态

core/admin/controller/sale/ctl.tools.php
搜索 test_fake_html 后面加两行如下

 $svinfo->test_fake_html(false,$msg);
 $this->system->setConf('system.seo.emuStatic','true');
 return true;

nginx 的配置文件里面

location / { 
if (!-e $request_filename) { 
rewrite ^/(.+\.(html|xml|json|htm|php|jsp|asp|shtml))$ /index.php?$1 last; 
# 下面这行也可以
#rewrite ^(.*)/(.+\.(html|xml|json|htm|php|jsp|asp|shtml))$ $1/index.php?$2 last;
         } 
} 
  

linux系统负载检查的思路

有时候客户会说服务器慢,综合来看就是负载变高了,一般情况下有几种可能

  1. 用户访问量确实增大
  2. 被攻击了
  3. 代码或者数据库更改造成索引丢失,或者代码未用到索引
  4. 硬件发热

首先通过 top 命令查看服务器中占用cpu比较重的进程,

如果发现是 mysql ,可以先在mysql > 命令行里面show full processlist; 查看是否有语句被lock,然后考虑
1)是否可以优化数据库索引
2) 是否可以找到相关php代码,
3)查找web服务器的日志,分析当前发生了什么,是否有恶意蜘蛛,或者采集,或者某些特征的访问,可以从web 配置里面屏蔽相应特征的访问,比如基于特定referer的访问,特定user-agent的访问