该插件由微软开放技术（中国）研发并开源，官方博文：http://cn.msopentech.com/?p=874781
准备工作
您需要预先安装 Drupal 7, 并启用 CKEditor 。（你可以通过如下界面安装启用 CKEditor）
下载地址: https://www.drupal.org/project/ckeditor
适用于 Drupal 7.x 版本的 CKEditor 构建模块，解压缩后将 ckeditor 文件夹复制到 Drupal 模块安装目录/sites/all/modules/
例子1
[one.php]
经常在论坛和QQ群上听人说Drupal很慢，初始状态下承载不了多少数据量及并发，性能很差。但是我们可以发现很多大站也是用Drupal开发的，因为大站做了性能优化，包括硬件及软件优化，这里我们来讨论一下Drupal缓存技术。
自动登录的原理很简单就是用户初次登录时把用户名与密码保存在cookies中，这样下次登录时加以判断cookies值中的用户名与密码是不是与数据库一样，如果是的就自动登录并设置session 即可，具体如下。
我们知道在PHP中没有函数重载这个概念，让很多时候我们无法进行一些处理，甚至有时候不得不在函数后面定义好N个参数只有使用func_get_arg,func_get_args,func_num_args实现伪重载了，下面一起来看看吧。
Drupal 配置迁移是什么？很多 Drupaller 对这个话题感到无所适从，新人工作之初并不会意识到这个问题的存在，而意识到这个问题的朋友也不确定怎样正确地进行配置迁移。本文就围绕 Drupal 配置迁移的原因、方式/方法及相关模块较为系统地聊聊这个话题。
以下对 Drupal 的一些缺陷和不足进行罗列和说明，并且也提供一些弥补、改善或者避开的方法，这样以后在遇到这些问题的时候能够更从容一些。
易学性与易用性
Drupal 在用户友好的层面上存在两大“不足”，分别是易学性和易用性。
Drupal 易学性上的不足是先天基因决定，它是面向“开发人员”的工具，而非面向普通用户的产品。要基于 Drupal 搭建一个网站或者是系统，普通用户入手之初最多只能安装和配置一些简单的模块，要想做到像熟手们说的那样“找到模块安装一下就好了”，那是不可能的。
如果想要对系统进行修改或者说是扩展，前期没有投入一定的时间去学习和了解 Drupal 的基本知识，除了面对一大片后台管理链接无所适从之外，新手们还能干什么呢？
Drupal 非常不容易学习，因为扩展的灵活性使其拥有了相对其它系统更为复杂的结构，添加新页面应该使用菜单系统、访问数据库应该使用数据库抽象层、添加修改模版要先学习模版机制，原本在其它系统下的经验到 Drupal 上来统统都不能用了 —— 使用 Drupal 的人少，与它的学习曲线、学习周期严重相关。这是 Drupal 的一个先天不足，但这些“化简为繁”的机制和抽象层最终给 Drupal 提供了无比强大、无可比拟的扩展性和灵活性 —— 所以对于慕名而来的 Drupal 的仰慕者们，Drupal 很强大，但必须要在熟练的人的手上，可以花重金请专业的团队打造世界一流的站点和系统，但切不可抓几个 PHPer 就妄想短时间内驾驭这匹野马。
PS: Drupal 功能性和扩展性的强大，以及学习曲线和周期决定了其自身的价值，一分努力一分收获，请走在 Drupal 之路上的各位谨记！！！
与易学性相同，Drupal 的易用性也是先天不足，一方面是因为它不是面向普通用户“开箱即用”的产品，另一方面是因为在用户体验“能用、易用、好用”的三级标准上，Drupal 的功能在很大一部分程度上都只是“能用”的级别。只实现基本的体验和交互，优点在于能够方便地在其之上添加需要的行为，缺点在于没有一个默认易用的行为，每个站点都需要付出一定的工作量。
易用性是 Drupal 的一项不足，但并非硬伤，相对其它一些不易扩展的CMS或者框架，Drupal 至少能够让我们更快的优先获得功能，至于用户体验和交互，对于熟手来讲也是手到擒来的事。
因为今天时间有限，后面的一些缺陷与不足先简单介绍一下，后续有需要了解的地方大伙再给我发邮件或者是留言咨询吧，先谢过。
兼容性
Drupal 大版本之间不提供向后兼容，即 D7 不向后兼容 D6，D8 不向后兼容 D7。根据 Dries 若干年前的博客（大概是2005年，记不太清楚了），说明了 Drupal 的新版本会选择同时期最新的技术，以保证 Drupal 走在技术的前沿，同时因为不提供向后的兼容，能够更好的保持核心的精简。
对于需要做大版本升级的个人或公司，在此的第一个建议是不要做大版本升级，因为确实必要性不大，但工作量可能惊人的可怕。如果实在要升级，同样从工作量出发，可以先行评估，然后从升级和重建中做出合适的选择。
性能
Drupal 在扩展性和灵活性之间需要做出平衡，模块化的架构和 hook回调系统则是站在扩展性这一边。强大的扩展性会带来性能上的损耗，但 Drupal 通过内置的缓存系统以及整合各种外部缓存、代理、加速来大幅提升性能。
有关扩展与性能的话题，我们在之前的视频里面有提到过，可以找找看。
模版抽象层
Drupal 的页面布局更多是通过区域分配的方式来执行，内容与内容框架（确定内容组织方式的HTML代码结构）混合存在一起，传统前端生成 HTML的方式在 Drupal 中难以得以应用。而内容与内容框架混合的形式也使得 Drupal 主题很难像 WordPress 那样做到主题的复用。
团队协作
Drupal 的团队协作应该算是 Drupal 各种抽象层的副作用，因为整个项目流程与传统网站项目不同，所以协作上也会出现一些难点。不过通过对 Drupal 流程有清晰的了解之后，能够找出不同职能的分界线，通过 Drupal 的方式来进行团队协作，问题就能够得以解决了。
在工作项目中有一个需求，要把数一些数据转成数组，然后再存到数库库一个字段中，个人目前知道两种方法，一种是用序列化函数serialize($arr);，还有一种是用php的json扩展自带的函数json_encode($arr);。
主要参考的PHP框架包括：CodeIgniter、CakePHP、ZendFramework、Symfony。我对很多框架也没有认真使用，只是简单试用了一下，可能很多看法不成熟或者是错误的，请大家指正，一起成长。
1、CodeIgniter
优点：
1. 配置简单，全部的配置使用PHP脚本来配置，执行效率高；具有基本的路由功能，能够进行一定程度的路由；具有初步的Layout功能，能够制作一定程度的界面外观；数据库层封装的不错，具有基本的MVC功能
2. 快速简洁，代码不多，执行性能高，PHP框架简单，容易上手，学习成本低，文档详细；自带了很多简单好用的library，框架适合小型应用
缺点：
1. 把Model层简单的理解为数据库操作
2. PHP框架略显简单，只能够满足小型应用，略微不太能够满足中型应用需要
评价：
总体来说，拿CodeIgniter来完成简单快速的应用还是值得，同时能够构造一定程度的layout，便于模板的复用，数据操作层来说封装的不错，并且CodeIgniter没有使用很多太复杂的设计模式，执行性能和代码可读性上都不错。至于附加的 library 也还不错，简洁高效。
2、CakePHP
优点：
1. CakePHP是最类似于RoR的PHP框架，包括设计方式，数据库操作的Active Record方式；设计层面很优雅，没有自带多余的 library，所有的功能都是纯粹的框架，执行效率还不错；数据库层的 hasOne, hasMany 功能很强大，对于复杂业务处理比较合适；路由功能，配置功能还不错；自动构建脚手架（scaffold）很强大；适合中型应用；基本实现过了MVC每一层；具有自动操作命令行脚本功能；
2. 文档比较全，在国内推广的比较成功，大部分都知道CakePHP，学习成本中等
SQL注入攻击的概念及危害我相信大家都有所了解，如果不了解的请自己度娘，下面我们来学习一下在php中如何有效的防止
问题描述：
在用wordpress进行二次开发的时候，会在它的模板里面看到一些奇怪的php语法，这些语法在php里面不常用。对于一部分PHPer没见过的代码？难道是那些博客的开发者自己搞的仿PHP的模板语言？其实这些都是PHP的语法，只不过不常用而已，这些都是PHP流程控制的替代语法。