使用DedeCMS打造的UC头像中心预览

对于UC的用户来说，一定非常熟悉其功能。然而，自从DZ 6.1版本之后，头像系统出现了许多问题。

DZ头像系统在6.1版本后变得不够灵活，例如不能自定义大小等问题。这些问题让许多用户感到困扰，而官方给出的解释仅仅是“没有设置选项”，这显然无法满足用户需求。经过两天的努力，终于找到了解决方案。

——————————————————————————————————

首先，做一个简单说明：

DedeCMS系统与DZ的HOME系统如果能够完美结合，那么这两个系统都将发挥到极致。整合的关键在于获取UC的用户UID值，这样在程序和用户数据调用上会更加方便。

在整合过程中遇到了一些棘手的问题：

1. DedeCMS无法完美体现UC的用户ID，导致无法正常通信。

2. UC的头像和DedeCMS的用户头像无法统一化，这也是第一点所致。

因此，这里着重对UC的UID获得进行解析。以下内容是基于个人的DedeCMS建站模式叙述，主要分享心得，不涉及具体方法。

我使用的是UCHOME注册，同步用户到DedeCMS。通过数据分析可以发现，当用户在HOME注册并登录后，DedeCMS中没有任何相关数据。只有当用户首次登录DedeCMS时，才会在dede_member表中生成一个mid，这个mid是按照用户登录DedeCMS的顺序激活的。

例如，HOME注册到第10个用户，但前9位用户只注册未登录DedeCMS，那么当第10位用户登录DedeCMS时，就会产生uid=10, mid=1的情况。此时，在DedeCMS中无法直接获取UC的UID。

解决方法：

1. 用户在UCHOME注册后，直接跳转到DedeCMS登录界面要求其登录。这种方法比较简单，但如果用户不遵守规则未登录，后续用户的UID可能会混乱。

2. 用户注册后直接POST数据到DedeCMS请求激活，未做测试，可能存在延时等问题导致混乱。

3. 我目前使用的方法是：当用户首次登录DedeCMS生成mid的同时，也会生成一个face字段。重点在于，face字段中包含真正的UID！

查找数据，搜索整个文件夹找到=middle属性，这里是face的上传数据段。删除前后部分，只保留uid。重新登录后，发现数据表中face已经完全等于UC的UID，可能不等于mid。

因此，在系统中涉及到UC UID的地方可以使用以下代码进行调用：

$cfg_ml->fields['face']

$cfg_ml->fields['M_id'] 是系统原有的，表示用户在DedeCMS中的激活顺序/ID。

$cfg_ml->fields['face'] 是修改后添加的，表示整合后在DedeCMS中调用UC的UID。两者可以并存，且可能存在不相等的情况，需根据具体情况选择使用。

解决了UID问题后，可以带来很多好处。例如评论时显示用户头像，点击头像进入UCH的空间等。

接下来是进阶处理。虽然UC看似开源，但在用户头像方面却是一个死胡同。既然我们已经获得了UC的UID，就可以进一步突破UC，让两者更好地融合。

从头像开始，将所有头像保存到DedeCMS目录下，使用QJ裁剪，按照UID排列。这样就把DedeCMS变成了用户的头像中心，而且可以自定义大小和样式。

默认评论包括中评/或者其他，默认POST数据为顶一下。隐藏输入框，只留一个发布按钮，命名为“踩一脚”。推送时，在HOME里显示“XXX对文章XXX踩了一脚”。这样完美地将HOME的踩日志和DedeCMS的评论文章伪装融合。

对于正常的评论，让用户点击进入评论独立页进行评论，推送时根据中评、好评等三个类别进行分类推送。例如，我定义差评为默认“踩一脚”，其他为评论推送。

暂时先分享到这里。总之，完美的融合以达到无缝使用，才是DedeCMS和UC两大主流系统的最终目标。