Magento(CE1.X)自带模块解析四

摘要: shuishui8310 的好文章，学习学习

31、GoogleAnalytics

谷歌分析模块，在后台打开开关并配置谷歌的账号就可以使用，使用起来非常便捷。



谷歌分析（Google Analytics）非常好用，几乎是网站的标配。不过很可惜，因为一些众所周知的原因，它没法在国内环境正常使用，只能找一些替代方案。这里推荐可以用下“百度统计”，虽然百度最近丑闻不断，但还是有一些不错的产品的。

做境外英文站的话，这个模块当然很好用，不过我这个系列的主题是Magento在国内的应用，既然谷歌分析在国内就是没法正常使用，那么也只能建议把这个模块关了。

32、GoogleBase

这个模块就比较特别了，因为Magento系统本身就没开启这个模块，模块内的配置文件（比如config.xml）内容也是大段大段的注释掉了。GoogleBase曾经是个什么业务，有兴趣的可以去搜索下，反正对现在的谷歌来说，这只是一个已经被砍掉的试水项目之一。至于为什么最新版的Magneto依然保留了这个模块的代码，大概是留个纪念吧。

33、GoogleCheckout

Google的第三方支付平台，类似于国内的支付宝，老外的Paypal。跟GoogleBase相似的一点是，GoogleCheckout这个项目也已经被谷歌砍掉了，不同的一点是，在Magento里GoogleCheckout模块默认是开启的。其实不管GoogleCheckout是不是还活着，它在国内网站都是用不到的，所以，果断关闭掉这个模块。

34、ImportExport

另一个导入导出模块，相比Dataflow来说导入导出的功能更简单，导入速度快于Dataflow。



关于导入导出这类需求，实际工作中，Magento自带的功能很多时候是无法满足各种实际需求的（主要是批量导入的复杂需求）。应对方案分两种，一，基于自带的模块做二次开发，二，购买第三方插件（官网的插件市场专门分出了一种类型 叫Import/Export）。批量导入是很常见的需求，也是一些qq群的热门话题，不过回到本系列的主题来说，一般是做外贸站的有比较多这方面的需求，而做国内B2C大部分的商品上架是采用后台手工操作的方式。

这个模块就是典型的按需使用了，确定用不到的话就把模块关了。

35、Index

索引模块，Magento的索引与数据库的索引不是一回事（虽然原理上有部分想通之处），Magento的索引本质上是按照更适合前台数据调用的情况，在源数据基础上生成一份冗余数据，这些冗余数据存在与一批数据库的物理表中，这样前台做页面展示时可以使用这些结构上更简单的数据而不是去读取相对数据结构比较复杂的源数据（比如EAV类数据）。





索引数据的更新类型分钟两种：保存时更新（实时）和手工更新（一般会做计划任务定时），采用哪种方式没有标准答案，看实际的使用场景。理论上保存时更新这种方式可以保证索引数据始终是跟源数据一致（实时性），不过当数据量比较大时（以大量商品数据为例），后台每一次的商品编辑保存都会触发对应索引数据的更新，除了对服务器资源的消耗之外，后台操作的体验也会受到明显的影响（点击完保存按钮后的等待时间变长）。手工更新模式（配合计划任务）虽然没办法保证数据的实时性，但是相比较保存时更新，更新索引数据的操作相对于后台操作是异步进行的，理论上性能更好。

Index模块本身只是提供了一套索引的机制，具体的索引项（上图中的这几种）都是各自相对应模块中的代码来实现的，比如Product Prices的实现就是写在Catalog模块里的。

Index模块属于核心模块之一，必须保持开启。

36、Install

Magento安装模块，我们在初始安装时的几个步骤页面就是由这个模块所支持的，安装完成之后，这个模块就没用了。

已经安装完成的Magento，只需要删掉根目录的app/etc/local.xml文件，刷新页面就会跳转到安装页面。

Install模块属于一次性模块，用完就可以甩了。

37、Log

Log模块通过监听各种事件（events）记录了网站访问的一些日志数据，记录的数据详见数据库里以“log_”为前缀的一系列表。

因为Log模块记录了网站的每一次请求的数据，在网站有一定的访问量的情况下，log表（比如log_url）的体积会迅速膨胀，基于这一点，Magento提供了计划任务来定期清理过期的日志数据，可以设置需要保留最近多久的日志数据（比如一个月）。

同样因为Log模块记录了网站的每一次请求的数据，在网站并发量比较大的时候，记录日志会对数据库进行大量的并发写操作，这个时候光写日志就会耗去数据库大量的资源。比较粗暴的避免方式就是把log模块的事件监听配置都拿掉，不再往log_系列表里写数据，系统的功能上会有轻微的损失，但不影响所有主干流程。

之所以说不需要记录日志时是把日志记录代码屏蔽而不是关掉Log模块，是因为其它模块的一些代码对Log模块有依赖，除非自己找到所有这些依赖并处理掉，不然直接关掉Log模块是会对主干流程造成影响的。

需要注意的是，通过Mage::log函数记录日志到var/log目录，这个功能跟Log模块是没有关系的，虽然大家都叫log

38、Media

Media模块从命名来看应该是根目录的media目录（后台上传的商品图都在这里）有关系，不过实际查看代码后发现这个模块跟前台商品图的展示没有啥关系。模块结构特别简单，有实际作用的类只有两个，而且通过全局搜索发现好像别的模块都没有调用到这两个类里的方法。实际测试关掉Media模块之后，网站前后台看不出有哪里受到影响（在干净的新装Magenot上测试的，可能有遗漏）。从具体代码来看，Media模块可能是一个帮助类，里面的一些方法可以用作对media目录下的图片文件的管理和操作。

鉴于Media模块很小巧（config.xml的内容总共也没几行），而且不敢保证模块关闭之后百分百没影响，建议把这个模块保持开启。

39、Newsletter

邮件订阅（参考京东商城的叫法）模块，邮件订阅的意思是指网站访客留下邮箱地址并同意接收网站推送的促销邮件或者其它邮件。这里有两点容易混淆，首先订阅者不一定是注册用户，也可以是未注册的访客，其次订阅者同意接收的邮件一般是指定期批量推送的促销类邮件，而不包括注册邮件、订单邮件等内容针对具体个人的触发类邮件。

Magento的Newsletter模块提供的功能相当标准，可以在后台制作要推送的邮件模板，然后设定发送时间，模块的计划任务会会到点自动执行发送邮件的动作。同时模块也提供了标准的退订功能，订阅者可以通过点击邮件底部的退订链接进行退订（订阅类邮件必须在邮件内容里提供给用户退订的链接，这个国内也是有法规明文规定的）。

从模块的实际使用来看，功能上原生Newsletter模块没有分类型订阅（比如订阅者可以勾选只接收男装类推送，不接受女装推送等等），需要自己二次开发或者寻找合适的第三方插件，性能上，当订阅者数量到达一定量级时，通过网站系统本身发邮件不仅效率有问题，也会同时对系统的正常流程造成干扰。所以建议是网站发展初期可以用自带Newsletter模块发发推送邮件，到一定量之后可以选择通过一些专业的邮件服务供应商来做更专业的邮件推送（和管理、分析等等）。

如果确实不用这个模块的话，可以选择关闭，不过我觉得大部分Magento用户应该都是会把Newsletter模块用起来的。

40、Oauth

系列文章的第一篇有提到，Oauth模块是配合Api2模块使用的，为Magento的Rest Api提供oAuth授权协议。所以如果不需要使用Api2模块，那么Oauth模块也可以关闭，如果需要使用Api2模块，那么Oauth模块也要同步开启。

以上是本系列的第三篇内容，简单总结下上面10个模块，

其中Index，Log，Media，Newsletter四个模块是必须开启的（网站正常运行的基础），

ImportExport，Oauth是可以根据需求自选要不要开启的，

GoogleAnalytics，GoogleBase，GoogleCheckout，Install我的建议是关闭（针对做国内中文站），