关键字描述：心得 整合 完美 &mdash 用户 DEDE UC 登陆 头像
使用DDEDE打造的UC头像中心预览
对于UC的用户 一定都知道
DZ自从6.1以后 头像系统整个就傻了B了
不能自定义大小
不能的太多了。。官方一句 没有设置选项就忽悠过去了
用了2天终于突破了。。
——————————————————————————————————
首先，做下简单说明：
DEDECMS系统，以及DZ的HOME系统如果能够完美结合，那么这两个系统都将把自身发挥到极致
而整合的最大关键就是获取UC的用户uid值 这样在程序和用户数据的调用上都很方便了
在整合中出现了一些2B的问题比较棘手
1，DEDE不能完美的体现UC的用户ID 造成无法正常的通信
2，UC的头像和DEDE的用户头像无法统一化 一定程度上也是第一点所致
所以这里着重对UC的UID获得做一个解析
因为是按照个人的建站模式叙述，所以，只谈心得，不谈具体方法
我使用的是UCHOME注册，同步用户到DEDE
通过数据可以看出，home注册 并且登陆后，DEDE中无任何数据
当用户首次登陆DEDE后，就会在dede_member下生成一个mid 这个是按照用户登陆DEDE的顺序激活的
也就是说 例如 home 注册到第10个用户，但是前9位都是只注册，没有经过dede登陆，那么当第10位登陆dede
就产生了uid =10 mid=1的情况，而在dede中没有 直接的途径获得uc的uid
解决方法1：用户在uchome注册后，直接跳转到dede登陆界面 要求其登陆。这个比较简单，但是一旦有人不守规矩，不登陆，那么后面的人就完全错乱了。。
解决方法2：用户注册后直接post数据到dede 请求激活，未做测试，估计也存在延时，等等问题造成混乱
解决方法3：也是我目前使用的方法，当用户第一次登陆dede 产生mid的同时（参上上面mid的地方），也会产生一个face
重点就在这里了，face里面包含了一个真正的UID!
查找数据 搜索整个文件夹 找到 =middle 属性，这里就是face的上传数据段
删除前后，只保留uid
这样重新登陆，发现数据表中 face 已经完全等于uc的uid了，而可能不等于mid
所以在系统中涉及到uc uid的地方可以使用 $cfg_ml->fields['face'] 进行调用
$cfg_ml->fields['M_id'] 系统原有，表示用户在DEDE的激活顺序/id
$cfg_ml->fields['face'] 修改后添加，表示整合后，在DEDE中调用UC的UID
两者可以并存，切存在不相等的可能性 而且极大，所以根据情况使用即可
解决了UID问题
这样就可以带来很多好处
例如：
评论时显示用户头像。点击头像进入UCH的空间
等等 这里好处肯定是很多
接下来进阶处理
UC看似开源 但是在用户头像这里却是一个死胡同
既然我们获得了UC的UID
那么我们就可以进一步突破UC
来让两者更好的融合
从头像开始，把所有头像保存到DEDE目录下，使用QJ裁剪，按照UID排列
这样就把DEDE变成了用户的头像中心
而且可以自定义大小和样式
说明 在下是DEDE和DZ的老用户 所以很多棘手的问题都拿来谈谈
可能DZ的问题 DEDE的用户不是很关系 我不过是谈谈而已
接下来，在事件推送中
把评论系统加以改造
默认评论 中评/或者其他
默认POST数据 顶一下
隐藏输入框 只留一个 发布按钮 命名为 踩一脚
呵呵，这样
推送时 在HOME里显示
XXX对文章XXX踩了一脚
这样完美的把HOME的踩日志 和 DEDE的评论文章伪装融合
那正常的评论，让用户点击进入评论独立页
进行评论，而推送时 根据 中评 好评等3个类别进行分类推送
例如我定义的是差评 默认踩一脚
其他的为 评论推送
暂时先这么多吧
总之，完美的融合
以达到无缝使用
才是DEDECMS和UC两大主流系统的宿命啊
使用DDEDE打造的UC头像中心预览
对于UC的用户 一定都知道
DZ自从6.1以后 头像系统整个就傻了B了
不能自定义大小
不能的太多了。。官方一句 没有设置选项就忽悠过去了
用了2天终于突破了。。
——————————————————————————————————
首先，做下简单说明：
DEDECMS系统，以及DZ的HOME系统如果能够完美结合，那么这两个系统都将把自身发挥到极致
而整合的最大关键就是获取UC的用户uid值 这样在程序和用户数据的调用上都很方便了
在整合中出现了一些2B的问题比较棘手
1，DEDE不能完美的体现UC的用户ID 造成无法正常的通信
2，UC的头像和DEDE的用户头像无法统一化 一定程度上也是第一点所致
所以这里着重对UC的UID获得做一个解析
因为是按照个人的建站模式叙述，所以，只谈心得，不谈具体方法
我使用的是UCHOME注册，同步用户到DEDE
通过数据可以看出，home注册 并且登陆后，DEDE中无任何数据
当用户首次登陆DEDE后，就会在dede_member下生成一个mid 这个是按照用户登陆DEDE的顺序激活的
也就是说 例如 home 注册到第10个用户，但是前9位都是只注册，没有经过dede登陆，那么当第10位登陆dede
就产生了uid =10 mid=1的情况，而在dede中没有 直接的途径获得uc的uid
解决方法1：用户在uchome注册后，直接跳转到dede登陆界面 要求其登陆。这个比较简单，但是一旦有人不守规矩，不登陆，那么后面的人就完全错乱了。。
解决方法2：用户注册后直接post数据到dede 请求激活，未做测试，估计也存在延时，等等问题造成混乱
解决方法3：也是我目前使用的方法，当用户第一次登陆dede 产生mid的同时（参上上面mid的地方），也会产生一个face
重点就在这里了，face里面包含了一个真正的UID!
查找数据 搜索整个文件夹 找到 =middle 属性，这里就是face的上传数据段
删除前后，只保留uid
这样重新登陆，发现数据表中 face 已经完全等于uc的uid了，而可能不等于mid
所以在系统中涉及到uc uid的地方可以使用 $cfg_ml->fields['face'] 进行调用
$cfg_ml->fields['M_id'] 系统原有，表示用户在DEDE的激活顺序/id
$cfg_ml->fields['face'] 修改后添加，表示整合后，在DEDE中调用UC的UID
两者可以并存，切存在不相等的可能性 而且极大，所以根据情况使用即可
解决了UID问题
这样就可以带来很多好处
例如：
评论时显示用户头像。点击头像进入UCH的空间
等等 这里好处肯定是很多
接下来进阶处理
UC看似开源 但是在用户头像这里却是一个死胡同
既然我们获得了UC的UID
那么我们就可以进一步突破UC
来让两者更好的融合
从头像开始，把所有头像保存到DEDE目录下，使用QJ裁剪，按照UID排列
这样就把DEDE变成了用户的头像中心
而且可以自定义大小和样式
说明 在下是DEDE和DZ的老用户 所以很多棘手的问题都拿来谈谈
可能DZ的问题 DEDE的用户不是很关系 我不过是谈谈而已
接下来，在事件推送中
把评论系统加以改造
默认评论 中评/或者其他
默认POST数据 顶一下
隐藏输入框 只留一个 发布按钮 命名为 踩一脚
呵呵，这样
推送时 在HOME里显示
XXX对文章XXX踩了一脚
这样完美的把HOME的踩日志 和 DEDE的评论文章伪装融合
那正常的评论，让用户点击进入评论独立页
进行评论，而推送时 根据 中评 好评等3个类别进行分类推送
例如我定义的是差评 默认踩一脚
其他的为 评论推送
暂时先这么多吧
总之，完美的融合
以达到无缝使用
才是DEDECMS和UC两大主流系统的宿命啊
关键字词:
