0

CentOS 7迁移Magento 1.9.x到Mangento 2

Posted by Alan on April 20, 2018 in Magento |

Magento 2出来也挺久时间了,市场上的反应有部分人觉得它很慢,这可能与硬件设备的要求有关,也有部分人觉得不好用。不管怎样,事物总是向前发展的,Magento 2必将逐步取代Magento 1.9.x,这只是时间问题,也有消息称从今年11月起官方将可能不再对1.9.x的版本支持。Alan已经很久没有对Magento进行研究了,今天抽空对一个站点作迁移的尝试,在这里记录下来过程和问题和大家分享。

Tags: ,

0

Magento 1.9.x 速度优化基础篇

Posted by Alan on March 24, 2017 in Magento |

网站速度优化和SEO一样属于营销的基本组成部分,常用的速度优化工具有: – Pingdom Website Speed Test – WebPagetest – GTmetrix – think with Google – YSlow – Official Open Source Project Website – Which loads faster? – PageSpeed Insights

Tags: ,

0

Magento 2 命令行

Posted by Alan on August 17, 2016 in Magento |

在Magento 2中可通过命令行来进行相当一部分的操作,如清除缓存、重新索引页面等。进入安装路径的bin目录下,输入php magento –list即可看到相对应的命令: 如查看缓存状态,仅需输入php magento cache:status

Tags:

0

Magento中如何自定义后台登录页面

Posted by Alan on February 1, 2016 in Magento |

很多人在使用Magento开发网站时除了会修改默认的后台登录路径外还会希望对后台登录页面甚至是后台进行修改。Alan使用Inchoo的插件并参照Mastering Magento Theme Design一书拼接了一个简单的代码,实现在后台登录页的自定义修改以及在后台页面中放置自己logo的功能。 这里我使用了Pinterest的logo在进行测试,以下是后台登录页面: 以下是管理员找回密码页面: 以下是后台替换了logo后的效果: 显然在设计上还有很大的提升空间,所以这里贡献出源代码,供大家修改使用: 下载地址:http://pan.baidu.com/s/1eQKksca 使用方法: 1.解压后将app和skin目录拷贝到Magento的安装根目录下,然后登录后台。访问System>Configuration>Design,会看到下面多出一个Admin Theme的版块,在后面填写alanhou保存 2.修改logo文件,我们的logo文件保存在<skin/adminhtml/default/alanhou/images/目录下,后台使用的是Pinterest-logo.png,登录页面使用的是Pinterest-logo-login.png,不想要修改源代码的朋友可以直接进行替换。 此外,也可以修改app/design/adminhtml/default/alanhou/template/下login.phtml和forgotpassword.phtml文件中的如下代码部分修改登录页面logo 修改app/design/adminhtml/default/alanhou/template/page/header.phtml文件中如下代码部分修改后台页面显示logo 所有自定义css代码请在skin/adminhtml/default/alanhou/custom.css文件中进行修改

Tags: ,

Magento 2常见问题

Posted by Alan on December 17, 2015 in FAQ, Magento |

安装过程问题 ../vendor/magento/framework/Code/Generator.php on line 103报错 这一报错通常出现在安装或升级Magento 2的时候,这时请尝试为根目录下的var文件夹设置 可写权限。以下为通过Mac的XAMPP安装时的完整报错信息: missing PHP extensions intl. 很明显是缺失PHP组件,那么如何安装呢,先执行如下指令 安装过程可能会提示安装XCode或M4相关软件,请确认安装即可。下一步就是安装intl组件 安装后还需要在php.ini中加入组件的引用 重启XAMPP中的Apache再次执行检查报错应该就会消失了     登录错误 You did not sign in correctly or your account is temporarily disabled.

开发者模式

 

0

30天备战Magento认证考试二

Posted by Alan on November 24, 2015 in Magento |

Day 2 Continued Explain how Magento loads and manipulates configuration information Magento的配置基本上散布在很多个.xml文件中,那么很自然地就有一个疑问,Magento是如何操作这些文件又从而为每个插件找到相应的配置文件的呢?下面我们先来梳理一下Magento结构的核心要点: • Magento是一个模块化系统,功能分布在各个模块中; • 有三个代码池,分别是local, community和core; • 每个模块中包含app/code/[codePool]/Namespace/Modulename/config.xml (该文件 中存放基本模块配置)和app/etc/modules/Namespace_Modulename.xml (该文件存放代码池信息以及插件激活标记); • Magento安装时的全局配置(包括数据库连接系统和后台地址)存放在app/etc/config.xml和app/etc/local.xml文件中; 如是我们从index.php开始追踪代码的话,会看到如下内容(在1.9.*的index.php中未找到这部分内容,使用的是Mage::run($mageRunCode, $mageRunType)): 或者 之后在两个版本中都有相似的类方法加载顺序。在Mage::run()中所有处理配置加载的内容都在Mage_Core_Model_App中并引用Mage_Core_Model_Config方法。调用Mage::app()会立即调用Mage_Core_Model_Config::init(),其中包含配置加载的进程。 最后会到达Mage_Core_Model_Config, 继承自Mage_Core_Model_Config_Base和Varien_Simplexml_Config。在这个层面调用方法无关紧要,让我们一起来看看Mage_Core_Model_Config:: init()方法(app/code/core/Mage/Core/Model/Config.php): 让我们来逐行分析一下这个方法吧 $this->loadBase(); 在最前面定义了一具app/etc目录的绝对路径,然后获取了此目录下的.xml文件列表,读取其中的内容并并入一个simpleXmlElement对象中。如果local.xml文件被载入了的话(也就意味着Magento已经完成了安装),则设置$this->_isLocalConfigLoaded = true;这会在后面用于实例化店铺并加载模块设置脚本。 只要这个方法不限制名称和载入文件数量,我们就可以在需要时载入app/etc中的自定义.xml文件。在开发服务器上不通过local.xml文件来指定数据库连接信息会比较有帮助,只使用该文件包含生产服务器的信息 这部分代码不言自明,如果配置中激活了缓存并包含所要求的内容,就加载整个配置。我们还会用这一配置替换app/etc中已载入的配置,从缓存中载入(Mage_Core_Model_Config:: loadCache())并返回到Mage_Core_Model_App。 您可能会问如果所有的配置都能从缓存中载入,为什么不在扫描app/etc目录前就进和这一验证呢?因为Magento的缓存不仅可作为文件存放在var/cache中,也可以存放在apc, memcached和xcache中。从app/etc中载入的步骤允许设定用于存储缓存的类型和配置。 接下来是加载最为广泛的配置部分-模块配置。 $this->loadModules(); Day 3 $this->_loadDeclaredModules(); _getDeclaredModuleFiles(): 首先扫描app/etc/modules目录获取指向系统所有模块的.xml文件路径列表。建立一个以base, mage和custom为键名的关联数组,仅有Mage_All.xml路径指向base版块,而Magento的基础包(core代码池app/code/core/Mage下)指向mage版块,custom版块涵盖其它的模块。最终会将所有内容并入一个数组,由于前面按键名拆分,最终数据的存储顺序是: Mage_All.xml, Mage命名空间里的模块,其它所有模块。 如果还没有明白Mage_All.xml的重要性的话,现在应该查看其中的内部结构了。Mage_All.xml包含了所有保证系统正常运行需要加载的模块。 然后collected.xml文件会加载到Mage_Core_Model_Config_Base $unsortedConfig。就会获得一个$moduleDepends数组,它是基于<depends>, <active>标记和模块名称。 […]

Tags: ,

0

30天备战Magento认证考试一

Posted by Alan on November 22, 2015 in Magento |

Day 1 使用Magento有挺长一段时间,但一直都限于泛泛的一些见招拆招的小功能,之前也参照Alan Storm的博客写过有关Magento开发的系列教程,不过在开发上实在没有什么更进一步的发展。于是决定通过备考Magento认证考试来进一步了解Magento的结构,从业余向专业过渡。 Magento开发系列之一 基础知识 Magento开发系列之二 配置文件 Magento开发系列之三 控制器 Magento开发系列之四 布局、块和模板 Magento开发系列之五 模型和ORM基础 Magento开发系列之六 安装、升级脚本 Magento开发系列之七 EAV-更高级的ORM Magento开发系列之八 后台配置开发 Magento开发系列之九 后台开发进阶 Magento开发系列之十 Varien数据集合 Magento开发系列之十一 数据重载和升级 Magento开发系列之十二 默认系统配置 这次的计划是在年底前参加考试,大约一个月的准备时间,于是有了30天备战Magento认证考试的标题,难度还是挺大的,不管成功或者失败,都希望在本文中进行真实的记录为更多参加Magento认证考试的人们所参考。 由于一直没有机会接触Magento的Enterprise版,所以本次计划参加的考试为Magento Certified Developer Exam而不是Plus,官方的大纲如下: 链接: http://pan.baidu.com/s/1jGCnR8a 密码: sw6u Basics Describe Magento codepools 代码池在Magento根目录的app/code目录下,通常有系统自带的core代码池(可以拷贝到local文件夹中再进行相应的更改),通常不建议直接修改core代码池中的代码;第三方开发、共享插件(如Magento Connect)等使用的community代码池以及本地开发的local代码池。 那么系统是如何与各代码池进行交互的呢? 可以查看一下app/Mage.php文件中如下代码: 从这段代码中我们可以看出Magento中的加载顺序,即先是local代码池,然后community代码池,最后才是core代码池,也正是因为如此,我们可以在开发时通过重载来修改core中的类。 Describe typical Magento module structure 在Magento中通常一个模块会包含 Controller, Model, Helper, […]

Tags: ,

0

Magento Facebook, Twitter登录插件

Posted by Alan on August 21, 2015 in Coding, Magento |

社交网站已成功占据网民们越来越多的时间,不论是一个内容站还是电商站,社交分享按钮都早已成为标配。社交分享按钮在很多模板中都已添加,甚至在Magento自带的rwd包默认模板中也已加入了Facebook和Twitter的分享按钮,此外还可以采用AddThis这样的免费代码来集成分享功能。 分享以外为了降低获取用户的成本、改善用户体验各大网站也开始纷纷添加了Facebook等账号登录的功能,这样做的目的是一个避免了客户看到冗长的注册表格后产生的较高的跳出率,更深层的目的也是为了能够打入客户的关系链。 关于Magento社交登录有不少付费插件,这里不再赘述。今天介绍的这款免费插件是由做Magento开发比较资深的Inchoo网站发布的,最近一次的更新时间是2014年9月5号: 下载地址: http://pan.baidu.com/s/1e7A3c 密码: ttk2 更新地址:https://github.com/Marko-M/Inchoo_SocialConnect 下载后进行压缩将app和skin两个文件夹中的内容复制到Magento的安装根目录下,登录后台System > Configuration > Customers > Customer Configuration下会出现Social Connect Facebook Options等配置组 以Facebook登录为例,若要开启此功能,打开Facebook开发者页面https://developers.facebook.com/,点击导航栏My Apps下的Add a New App,在弹出窗口中选择Website 在新出现的窗口中输入一个标识名称如localtest,点击下面的Create New Facebook App ID按钮 然后在弹出窗口中选择一个分类如Business点击Create App ID 在新的页面中输入网址,这里在本地测试使用http://localhost/magento,点击Next 此时再点击上面导航中的My Apps就会出现我们所创建的App(这里的名称为localtest),点击进入,就可以获取得App ID和App Secret(点击右边的Show按钮并输入密码验证),将这个两个值分别填入后台中的Facebook App ID和Facebook App Secret然后保存。 接下来需要激活这个App,在同一个页面左侧导航中点击Settings然后在Contact Email下输入一个有交的email地址,保存然后点击左侧导航上的Status & Review按钮,此时将Do you want to make this app and all its live […]

Tags: , , , ,

0

Magento开发系列之十二 默认系统配置

Posted by Alan on August 16, 2015 in Coding, Magento |

本节并没有太多新内容,更多的是对前面有关系统后台配置的补充。在我们创建新的系统配置路径时,Magento并没有存储默认值,甚至对于一些系统默认配置也是如此,这点可以通过查看core_config_data表来进行验证。 这张表仅存储在后台或基它程序中明确设置的值,而如果请求一个没有进行这个设置的系统配置值的话,Magento会到全局配置文件中去查看默认值。虽然不要求这么做,但为自添加配置变量设置一个默认值是一个不错的习惯。这样做很简单,也防止在获取到空值时产生一些意想不到的效果。 上面提到默认值存放在全局配置文件中,这可能与很多的想法大相径庭,因为大家可能会认为这默认值会存储在用于配置后台的system.xml文件中。为什么要这么做其实大可不必深究,我们可以理解为配置文件中存储常用的值,而stystem.xml中存储着用于修改这些值的界面的配置。 在模块配置文件config.xml里添加一个<default />代码块(如app/code/local/Packagename/Modulename/etc/config.xml) 这就是我们用于存储默认值的最上级节点,接下来将配置路径转化成XML格式的树形节点,比如我们为以下配置路径设置默认值: 那么在config.xml的代码就会是这样: 应用了这个配置后,请求design/header/welcome时,如果没有设定值,就会返回”Default welcome msg!”。这个例子是基本系统默认的配置,我们业看看design/header/welcome的真实配置(文件地址:app/code/core/Mage/Page/etc/config.xml): 这是所有design/*的默认配置,和我们例子中不同的时这里有一个translate属性: translate和module属性告诉系统哪些节点需要被translate,以及使用哪个模块的Data Helper来进行这一操作。在上例中,welcome节点将被转化为: 前面我们也提到过,如果调用helper类时URI没有传入第二部分,会默认使用data,也就是说下面两句代码是一样的: 如果想要转化多个子节点,可以在名称之间用逗号进行分隔,如: 写在后面 本系列更新到此结束,一共十二篇,大多数代码并非出自笔者之手,而是来自Magento资深大师Alan Storm,笔者只是用自己的理解丰富了一下内容,以有助于国内Magento学习者更为有效地掌握Magento开发相关知识。本系列的终结只是一个阶段性的符号,Magento作为一套强大的电商系统还有很值得探讨和学习的地方,需要大家共同努力去研究和分享,让我们一起努力吧!

Tags: , , ,

0

Magento开发系列之十一 数据重载和升级

Posted by Alan on August 16, 2015 in Coding, Magento |

在Magento经常被鼓吹也常被滥用的功能就是重载core中的系统代码,而另一个开发者经常讨论的话题就是升级以及重载对升级的阻碍作用。本节我们就来一起看看重载给版本切换所带来的不便。 需要强调下我们这里的是修改Maento中core的业务逻辑,对于phtml模板文件的修改是非常普遍的。 不论是在Magento中还是其它系统中对升级最不友好的肯定是直接修改源代码,比如想要修改产品模型时,就直接编辑了如下文件: 一旦这么做,就直接修改Magento中的基础代码,因而在进行升级时就需要进行逐个文件的合并,这通常都会出问题。此外这种修改还可能返回系统无法识别的数据或者是得到计划外的数据。虽然我们不建议去修改源代码,但还是有很多开发者在刚开始时会去这么做。在开发新项目时可以从官网下载一份全新的系统文件,然后比对下lib和app/code/core文件夹内的代码,看看核心代码有没有被修改。 Magento或者说PHP会在下面的目录中搜索类文件 由于这个原因以及PHP构造时包含的顺序,在core/code/local中复制一个core文件系统就会先包含这个文件,所以如果想要修改产品模型的功能,就可以进行如下复制: 如果这里定义的是类而不是core文件,就无需包含核心文件,这也就避免了合并文件的麻烦,并且所有修改文件都会放在同一个目录结构中。这样虽然比直接修改核心源代码要好些,但还是有可能会修改掉一些重要方法,比如前面说到的产品模型中的getName方法 在对这个方法进行重载时,我们有可能不小心添加了代码导致重载后返回空 系统的其它部分可能会使用到这个方法并等待该方法返回一个字串,而我们的修改则会导致接下来的执行被中断。这里如果返回对象情况还会更糟,因为调用一个空方法会导致一个致命错误(Fatal)。 下面我们来看看同一模型中的validate方法 在修改时我们有可能不小心删除了dispatch事件 这时系统中其它依靠这一事件的部分都会停止运转。此外,在升级时同样存在着危险,如果升级中更新了类,而我们仍将使用旧的过时了的方法。也就是说我们还是需要在升级时进行手动的代码合并。 Magento中的类重载和系统重写依赖于创建模型、Helper和Block时使用的工厂模式,比如在执行如下代码时: 实际是在告诉Magento去查找catalog/product用到的类并进行实例化。接下来,Magento会付出查看系统配置文件,并在config.xml中查看针对catalog/product应该使用哪个类,然后Magento就会对类进行实例化并返回一个模型。 而当我们在Magento中重载一个类时,实际上修改了配置文件,在进行上述操作时,就会告诉系统:如果要实例化catalog/product模型的话,请不要使用core中的类,而使用我们定义的类Myp_Mym_Model_Product 同时,在定义我们自己的类时,需要继承原来的类 这样,我们的新类就会包含系统类中的功能,同时也就避免了在升级时还需要合并文件的功能,也不会在升级时包含过时的方法。但是在修改方法时还是存在问题,我们还是以getName和validate方法为例,我们还是会忘记返回值或返回错误的值,甚至是忘记添加方法中重要功能的代码块: 重载重写系统无法在这个层面上形成保护,但也提供了一些避免的方式。同于我们是继承了原来的类,因而可以在构造时使用parent::来调用原类中的方法: 通过调用原来的方法,就可以确保该进行的操作都会完成,并且也减少了返回非系统要求值的可能性。当然只能是减少,而非彻底消除,开发者还是需要负责在自建代码中返回和原方法相同的对象或其它值。也就是,即使应用了重载系统,系统还是可能会由于误操作导致崩溃。 鉴于此,我们在进行开时,应使重载最小化,重载时可以在最后添加如下代码: 如果重载时要求先运行原方法,可以使用如下方法: mymodule/immutable指向如下类 这样并不能保证$original_return不会被我们自己或其它人重写,但确实会在修改后更容易发现。如果在重载类的方法最后没有使用$original_return->getValue或parent::method,那么在debug时就很容易发现问题。 还有的时候我们会希望修改core方法中的返回值,在有这种需求时,定义一个新方法来调用原方法并在主题中调用新方法往往更为安全: 这样可以保证原方法的一些功能依然有用,原来的返回类型保持不变,而我们也可以在系统中的某些地方添加自己的逻辑。

Tags: , , , ,

Copyright © 2012-2018 记录点滴生活 | Alan Hou的个人博客 All rights reserved.