DISCUZ论坛的UBB编辑器（增加灵活调用，支持ASP)

复制代码 代码如下: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">  <html>  <head>  <meta http-equiv="Content-Type" content="text/html; charset=gbk">  <title>Discuz编辑器</title>  <m

演示地址:http://52515.net/lib/upfile/ubb/下载地址:http://52515.net/lib/upfile/ubb.rar本地下载:http://www.jb51.net/downtools/discuzubb.rar

在destoon开发中有时候我们需要调用论坛的帖子,但是带有图片的帖子该怎么调用出来呢,本文就来实例展示一个可以调用discuz论坛带图片的帖子的方法: 标签代码如下: <!--{php $tags=tag("table=pre_forum_thread i,pre_forum_threadimage t&prefix=&condition=i.tid=t.tid&length=36&order=i.tid desc&pagesize=9&t

发现此主机运行了几个 Discuz 的论坛程序, Discuz论坛的好几个表也存在着这个问题.于是顺手一并解决,cpu占用再次降下来了. 前几天,一位朋友通过这篇文章找到了我,说他就是运行最新的 discuz 版本,MySQL 占用 CPU 100%,导致系统假死,每天都要重启好几次,花了一个多月的时间一直没有解决,希望我帮忙一下.经过检查,他的这个论坛最重要的几个表中,目前 cdb_members 表,有记录 6.2 万:cdb_threads 表,有记录 11万:cdb_posts表,有记录

书写错误,导致恶意用户构造语句可以写入webshell,进而控制整个服务器. 前几个晚上,把前台文件,只要是数据库调用中的变量都看了一遍.看看是不是有过滤不严的地方,看完后觉得,过滤不严的地方的确不少,但是都已经被单引号保护起来了.在php中,如果magic_qoute_gpc=on(默认的)编译器会自动把单引号等特殊字符转义,而这个时候我们想改变程序的执行流程是非常困难的.这样大大的增加了入侵的难度,在某种程度上,也的确保证了其安全.这也是为什么朋友提出一定要在magic_qoute_gpc为

在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分.对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化,二是MySQL自身(my.cnf)的优化. 一.服务

Discuz密码加密规则: md5(md5('字符串').'固定字串'): 固定字符串是在注册用户的时候随机生成的,且保存在数据表pre_ucenter_members的salt字段中. 举例:假如密码为 123456789 ,固定字符串为jb51,  那么加密规则为:md5(md5('123456789').'jb51'); 得出的结果就是:96122ff0dd306c912aab15adccf21df1 Discuz密保加密规则: 加密过程是value的值先加密一次,比如我的提问是"驾驶执照

libcurl同时也支持HTTPS认证.HTTP POST.HTTP PUT. FTP 上传(这个也能通过PHP的FTP扩展完成).HTTP 基于表单的上传.代理.cookies和用户名+密码的认证. php的curl真的是相当好用,网上一搜索相关文章都是关于curl模拟登陆的,很少人提供模拟discuz发贴的源码. 复制代码 代码如下: <?php $discuz_url = 'http://127.0.0.1/discuz/';//论坛地址 $login_url = $discuz_url

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "' target=_blank rel=nofollow>http://www.w3.org/TR/html4/loose.dtd"><html><head><title>UBB编辑器</title><meta http-equiv="Content-Type

过了这么久,discuz论坛的问题还是困扰着很多网友,其实从各论坛里看到的问题总结出来,很关键的一点都是因为没有将数据表引擎转成InnoDB导致的,discuz在并发稍微高一点的环境下就表现的非常糟糕,产生大量的锁等待,这时候如果把数据表引擎改成InnoDB的话,我相信会好很多.这次就写个扫盲贴吧. 1. 启用innodb引擎,并配置相关参数 #skip-innodb innodb_additional_mem_pool_size = 16M #一般16M也够了,可以适当调整下 innodb_b