本章开始逐个解析Magento1自带的模块,根据模块复杂度和重要性的不同,描述的方式也会有所区别,有些仅使用文字,有些会配上截图。
1、Admin
如字面意思,Admin模块是跟后台管理员相关的,具体来说,主要就是后台用户(admin_user表)和后台用户的权限管理(admin_role和admin_rule表)。到1.9.2.3版本,
出于安全考虑新增了permission_variable和permission_block功能,这个就不细讲了,详见1.9.2.3的release-notes。
这里扯远一下,Magento的权限功能是基于ACL模型的,市面上还有另外一个应用广泛的访问控制模型叫RBAC。虽然ACL一般情况下也可以满足Magento后台管理的需要,但结合以往实际工作中碰到的情况来说,RBAC模型可能更符合一个电商网站后台管理的需求,比如出现“客服主管”和“普通客服”这种层级结构的权限分布要求时。
毫无疑问,这个模块是必须开启的,后台的基石。
2、AdminNotification
字面意思是后台的通知,这个模块的实际作用差不多也就是这个意思。通知的展示形式分钟两种,一种是通栏方式显示在后台主菜单栏下面,另一种方式是登录后台时以弹窗方式出现。
通知的内容大概有以下几种:网站运行状况(比如缓存过期,索引未更新等等),Magento官方推送的通知(比如有新版本,官方要举办什么活动等等),安装的第三方插件所属公司推送的信息(比如安装的插件有新版本,或者如上图这类推销打折信息)。
AdminNotification模块理论上可以关闭,不会影响网站前后台的正常运行。关闭之后上面提到的这些通知你将不会再收到,避免了骚扰同时也失去了得到有价值通知的功能,当然失去通知也不会有多大影响,比如关注Magento的人自己本身就会时不时关注官方是否有新版本发布了。
所以,这个模块关闭与否,可选。
3、Adminhtml
Adminhtml是一个庞大无比的模块,整个目录下有超过500个文件夹和超过1000个文件。虽然如此庞大,这个模块的作用却很好解释,那就是几乎整个后台所展示的内容(不算第三方插件)都由Adminhtml来控制。
这里有一个代码结构上的疑问,Magento把功能按模块划分的做法是受大部分人认同的,对降低整个系统的耦合度相当有益。唯独Adminhtml模块把所有功能的后台管理部分集合在了一起,把这个模块变成了一个庞然大物。理论上Magento可以把不同功能块的后台管理的代码写到各自的模块目录下面,比如商品后台管理的代码可以写到Catalog模块里去,这样子看上去系统的模块化就更彻底了(比如第三方插件如果有后台管理的部分,后台的代码自然是写在自己模块的目录下的)。
Magento官方这么做也许有自己的考量,至少对于后台的修改和二次开发来说,可以在一个模块里找到所有后台源码也是一种便利。
Adminhtml模块当然是必须开启的,不开就没后台了。
4、Api
Magento的第一种类型的接口模块(早期的版本只有这一种类型),提供XML-RPC和SOAP两种接口协议,这两种协议一脉相承,对于已经封装过的Magento来说,新增一个接口只需要开发一套代码,就可以同时支持XML-RPC和SOAP两种协议。
SOAP是一套虽然已经不年轻,但依然被广泛使用的接口协议,基本上所有流行的编程语言都有现成的支持SOAP的类库。
除了对协议的封装,Api这个模块提供了基于ACL模型的接口资源权限分配,可以通过后台来按需指定不同接口用户拥有不同的访问权限(比如A用户只允许访问1、2、3接口函数,B用户只允许访问4、5、6接口函数),这个对网站的信息数据安全相当有好处。
Api模块不是必须开启的,如果没有对外开放接口的需求的话。当然,实际运作中的Magento网站,应该很大比例都会有跟其他系统对接的需求,这个时候,经过系统底层的封装之后,在Magento上开发新接口还是很方便的。
5、Api2
Magento的第二种类型的接口模块(后期版本新增的),提供REST风格的Api接口支持。
与Api模块类似,Api2模块同样对接口进行了封装,以及同样提供了通过后台进行接口资源权限分配。
针对REST风格的Api的授权,Magento采用流行的oAuth协议来实现,这一点在系统里是通过另一个模块来配合的,这个模块的名字就叫做Oauth。
同样道理,Api2模块开启与否是可选的,取决于你是否会需要用到系统对接。Api2模块与Api模块之间没有相互依赖关系,可以自由选择单独用、一起用或者两个模块都不用。
6、Authorizenet
authorizenet模块非常好理解,就是一个美国本土的支付网关(类似paypal,详见http://www.authorize.net/)。不太清楚authorizenet在美国的流行度如何,肯定没有paypal流行。如果是做国内中文站的话,就肯定用不到这个模块,果断关闭吧。
7、Backup
Backup模块在后台提供了可视化界面用于给网站做备份,可以选择备份(及还原)网站文件或者备份数据库等等。备份生成的文件会放置在var/backups目录下。
常见的网站备份操作,一般是由运维人员通过在服务器上通过计划脚本来操作的。虽然Magento的Backup模块也提供了通过系统的cron机制来定时备份数据的功能,但能直接通过后台操作就能备份(特别是还原)网站,感觉上会不太安全(虽然也可以通过后台权限来控制一般后台用户无权操作),我个人是不太推荐这种方式的。
如果你不需要备份网站,或者如上所言把备份网站交由运维来操作了,那就把这个Backup模块关了吧。
8、Bundle
Magento原生提供了6种商品类型,捆绑商品(Bundle Product)是其中一种。6种类型里,Bundle Product和Downloadable
Product是各自独立一个模块控制的,其他4个类型都在Catalog模块里面。
Bundle Product与另一种类型Grouped
Products类似都提供了组合打包购买商品的功能,不同之处在于Bundle Product提供了更复杂的组合方式,以及自由设置组合后商品价格(比如上衣加裤子组合买比单买优惠20等等)。详见:Magento
grouped vs bundle products
捆绑商品的功能在蛮多场景还是用得到的,当然这个也看网站具体卖的商品类型(衣服还是食品)以及销售方式。这里有一个问题是,捆绑商品功能所能捆绑的对象只能是简单商品(Simple
Product),而实际应用中好像有许多把几个Configurable Product捆绑卖的需求。PS:好像有第三方插件可以满足这个需求
如果确实不需要或者暂时用不到这个功能,可以把Bundle模块关闭(这个时候就体现出把捆绑商品单独拎出来做成一个模块的好处了)。
9、Captcha
验证码模块,可以用于后台的登录和找回密码。
原生情况下只能用于后台(不排除二次开发之后用于前台)。关于这个模块开启与否的建议,我不太清楚老外的审美是咋样的,至少在国内来说,跟国内网站上常见的验证码相比,Magento的这套验证码生成的图真的是有点丑。所以如果不用这个功能的话,就把Captcha模块关了。如果确实需要用到验证码(我指的是国内),建议找一个更符合中国人审美的验证码类库,自己基于类库在Magento上做验证码的功能。
10、Catalog
电商几大基本组成元素之一的“商品”(还有用户和订单),主要就由Catalog模块来控制。稍微具体来说,这个模块管理着包括分类,商品,商品属性等内容以及前台大部分跟商品展示相关的控制代码。对于Magento系统来说,这是一个核心模块,也是所有Magento用户最熟悉的几个模块之一。我这里只是对模块的概述,所以针对Catalog模块反而好像没有什么需要特别拎出来讲一下的东西了。
Catalog模块当然是必须开启的。
以上是本系列的第一篇内容,简单总结下上面10个模块,
其中Admin,Adminhtml,Catalog三个模块是必须开启的(网站正常运行的基础),
AdminNotification,Api,Api2,Bundle是可以根据需求自选要不要开启的,
Authorizenet,Backup和Captcha我的建议是关闭(针对做国内中文站)。
之前有提过本系列是一个概述,所以对大部分模块的描述都是走马观花式的,因为每个模块要讲清楚的话都可以单独写成一篇文章(甚至多篇文章)。上面十个模块的描述都是基于我的个人理解,如果有描述不正确的地方,欢迎指正。