要实现“上传图片名不变”,主要有两种方法:

- 核心函数修改(推荐,一劳永逸):直接修改 DedeCMS 的核心上传类文件,让所有上传功能都默认使用原始文件名。
- 修改配置文件(适用于特定场景):通过修改
config_upload.php文件来控制上传行为。
修改核心上传类(最推荐,最彻底)
这是最常用也是最有效的方法,DedeCMS 的文件上传逻辑主要封装在 /include/dedeclass.php 文件中的 UploadFile 类里。
操作步骤:
-
找到并打开文件 使用 FTP 或文件管理器,登录你的网站服务器,找到并编辑以下文件:
/include/dedeclass.php -
定位关键代码 在
dedeclass.php文件中,搜索GetRndKeys函数,这个函数就是用来生成随机文件名的,我们需要找到调用这个函数的地方。在
UploadFile类的Save()方法附近,你会找到类似这样的代码:// ... 其他代码 ... $filename = $this->GetRndKeys(8) . '.' . $filetype; // ... 其他代码 ...
-
修改代码 将生成随机文件名的代码,修改为直接使用原始文件名。
修改前:
// 假设在 Save() 方法中 $filename = $this->GetRndKeys(8) . '.' . $filetype; // 生成随机文件名
修改后:
// 修改为直接使用上传时的原始文件名 $filename = $this->uploadname; // $this->uploadname 存储了原始文件名,如 "我的图片.jpg"
重要提示:
$this->uploadname包含了原始文件名和扩展名,photo.jpg。- 为了安全起见,最好对文件名进行一些过滤,比如去除特殊字符,防止上传恶意脚本,你可以稍微修改一下:
// 更安全的写法:使用原始文件名,但进行过滤 $ori_name = $this->uploadname; // 去除路径,只保留文件名 $ori_name = basename($ori_name); // 去除可能存在的特殊字符,只保留字母、数字、中文、下划线和点 $ori_name = preg_replace('/[^\w\x{4e00}-\x{9fa5}\.]/u', '', $ori_name); $filename = $ori_name; -
保存并测试 保存
dedeclass.php文件,然后登录 DedeCMS 后台,尝试上传一张图片,你会发现图片的名称就是你上传时的原始名称了。
优点:
- 一劳永逸:修改一次,所有使用
UploadFile类的地方(包括内容、图集、软件等)都会生效。 - 效果彻底:完全实现了你想要的功能。
修改配置文件(适用于特定场景)
DedeCMS 有一个专门的配置文件来控制上传行为,通过修改它可以在不改变核心代码的情况下,实现特定场景下的文件名不变。
操作步骤:
-
找到并打开文件 找到并编辑以下文件:
/data/config.upload.php -
修改配置项 在这个文件中,找到
$cfg_upname这个变量,它控制着文件名的生成方式。修改前:
// config.upload.php $cfg_upname = 'rnd'; // rnd:随机命名, datetime:日期时间命名, custom:自定义
修改后:
// config.upload.php $cfg_upname = 'custom'; // 修改为 'custom'
-
定义自定义命名规则 仅仅设置为
custom还不够,你还需要定义具体的命名规则,在config.upload.php文件中,找到$cfg_customname这个变量。修改前:
// config.upload.php $cfg_customname = ''; // 自定义命名规则,留空则使用原始文件名
修改后:
// config.upload.php $cfg_customname = '{origname}'; // 使用原始文件名config.upload.php中还支持一些占位符,{origname}: 原始文件名{rnd}: 随机字符串{time}: 时间戳{datetime}: 日期时间
-
保存并测试 保存
config.upload.php文件,然后去测试上传功能。
注意:
- 这种方法是否生效,取决于具体的调用代码是否遵循了
config.upload.php的配置,在较新或某些特定模块的 DedeCMS 版本中,这个配置可能已经被弃用或不起作用。 - 如果修改后无效,说明该功能已经不再读取这个配置文件,此时你必须使用方法一。
总结与建议
| 方法 | 优点 | 缺点 | 推荐度 |
|---|---|---|---|
| 修改核心类 | 一劳永逸,效果最彻底,通用性强 | 需要修改核心文件,升级时可能被覆盖(需注意备份) | ⭐⭐⭐⭐⭐ (强烈推荐) |
| 修改配置文件 | 不修改核心代码,理论上更安全 | 可能在某些版本中失效,通用性差 | ⭐⭐ |
最终建议:
直接使用 方法一,这是最稳定、最可靠的解决方案,虽然升级时可能会被覆盖,但这是一个可以预见且容易解决的问题(升级前备份一下修改过的文件即可),对于绝大多数用户来说,方法一带来的便利性远大于升级时的小麻烦。
