Thay đổi và tùy biến Magento theo ý mình

Last modified by Mr.Hai on Fri, January 2, 2009 16:55
Source|Old Revisions  |  Back To Group

Nếu bạn đang tìm kiếm mà bạn cần phải thực hiện thay đổi cho Magento của mã để phù hợp với nó vào tổ chức của bạn, bạn có lẽ đang tự hỏi điều gì là cách tốt nhất để thực hiện những thay đổi này để bạn có thể giữ mã số riêng biệt của bạn từ chính mã.

Kỹ năng trình độ: Bắt đầu để nâng cao phát triển. Mục tiêu: Dành cho nhà phát triển website.

Magento thử nghiệm với các phiên bản:

  • 0.6.14100 (BETA)
  • 0.7.14800 (BETA)
  • 1.1.6

Áp dụng cho tất cả các phiên bản (1.1.x và cũ hơn).

Subversion

Cách tốt nhất để theo dõi tất cả các thay đổi của bạn là sử dụng công cụ như Subversion (SVN) hoặc CVS. Giúp bạn theo dõi được quá trình thay đổi và luôn bảo lưu được kết qua thay đổi lần trước

Dưới đây là một layout code mẫu:

my_project/
         trunk/
                   scripts/
                   src/  (magento's code)
                   data/
         branches/
                   vendor/
                             magento/
                                          app/
                                          lib/
                                          index.php

Trong thư mục “magento”, chúng tôi export Magento với SVN ( phiên bản 0.6 beta). Bây giờ, chúng tôi có thể sử dụng SVN để sao chép những thay đổi đó xảy ra đối với một thư mục (branches/vendor/magento) vào thư mục chính của chúng tôi (trunk / src /). Trước tiên, những thay đổi sẽ chỉ được giữa các bản 1 và 2 (nếu không thực hiện bất kỳ sai lầm nào trong quá trình thiết lập).Nhưng, mỗi magento phát hành, bạn sẽ chỉ có 1 phiên bản thay đổi, ví dụ: sau khi thực hiện thay đổi cho 100 cửa hàng của bạn mà bạn đang ở phiên bản 101.

Dealing with vendor branches is very messy in SVN. Đối phó với các nhà cung cấp các chi nhánh là rất messy trong SVN. The way you expect it to work doesn’t, so they provide you with an external Perl script to handle the messy parts of vendor branches. Con đường mà bạn mong muốn nó hoạt động không, do đó, họ cung cấp cho bạn một đoạn mã Perl bên ngoài để xử lý các messy phần của nhà cung cấp các chi nhánh. The program is called “svn_load_dirs.pl”, and, under Fedora, is located at /usr/share/doc/subversion-1.4.3/svn_load_dirs.pl Chương trình này được gọi là “svn_load_dirs.pl”, và, theo Fedora, được đặt tại / usr/share/doc/subversion-1.4.3/svn_load_dirs.pl

Our steps for upgrading the vendor branch go like this: Các bước nâng cấp cho các nhà cung cấp các chi nhánh đi như thế này:

export a new copy of Magento 0.7 xuất khẩu một bản sao mới của Magento 0,7

use svn_load_dirs to properly include the changes into our vendor branch. svn_load_dirs để sử dụng đúng cách bao gồm các thay đổi của chúng tôi vào nhà cung cấp chi nhánh.

In a clean directory:

svn export http://svn.magentocommerce.com/source/branches/beta-0.7-latest

/usr/share/doc/subversion-1.4.3/svn_load_dirs.pl 
   http://127.0.0.1/repos/my_project/branches/vendor
   magento 
   beta-0.7-latest/

You should see some output like:

Checking that the base URL is a Subversion repository.
Running /usr/bin/svn log -r HEAD http://127.0.0.1/repos/my_project/branches/vendor

Finding the root URL of the Subversion repository.
Running /usr/bin/svn log -r HEAD http://127.0.0.1
Running /usr/bin/svn log -r HEAD http://127.0.0.1/repos
Running /usr/bin/svn log -r HEAD http://127.0.0.1/repos/my_project
Determined that the svn root URL is http://127.0.0.1/repos/my_project.

Native EOL on this system is �12.

Finding if any directories need to be created in repository.
....

The following table lists files and directories that
exist in either the Subversion repository or the
directory to be imported but not both.  You now have
the opportunity to match them up as renames instead
of deletes and adds.  This is a Good Thing as it'll
make the repository take less space.

The left column lists files and directories that
exist in the Subversion repository and do not exist
in the directory being imported.  The right column
lists files and directories that exist in the
directory being imported.  Match up a deleted item
from the left column with an added item from the
right column.  Note the line numbers on the left
which you type into this script to have a rename
performed.

You will now see two columns of about 200 changes. On one side are files that are in the repository, but not in the new beta-0.7-latest directory, on the right files that exist in the new directory, but not in the repository. Subversion does not know which of these files have been added, deleted, or renamed. This is why vendor branches are messy. This Perl script wants you to scan through all 200 changes and match up files that actually got renamed or moved by typing in a number of a file in the right column and it’s match in the left, i.e. 214 10 if file 214 in the left column was actually just moved to a new directory and it shows up as row 10 in the right column. This task is summarily daunting and not worth the manual effort since we are only getting access to new Magento code about once every 800 changes.

“What does this mean to me?”, I hear you asking. Well, let’s say you’ve modified a file called “Google_Checkout.php”. In the Magento SVN repository, the Varien developers decide to rename the file, “GoogleCheckout.php”. This seemingly simple change can have dire consequences for you down the road. Since we cannot directly merge from Magento’s SVN repository, but we must use the intermediate files as a driver for “svn_load_dirs.pl”, this renaming action is lost. We simply have a new file “GoogleCheckout.php” and no more “Google_Checkout.php”. svn_load_dirs.pl, unless manually instructed, will delete the old file Google_Checkout and add the new one. When you go to merge the branch into your main development trunk, this add/delete action will be performed again, removing all your changes to the old named file “Google_Checkout”. “WHAT?!”, you ask, “Why do I even bother then with the vendor branches?”. The answer is, because it’s easier than not dealing with them.

Imagine if you simply copied over the new release and the newer “GoogleCheckout.php” file was being used instead of your changes. There would be no error, there would be no message from SVN deleting your code... your changes would silently be dropped simply because the file they were in would not be loaded anymore. At least with this process you will get alerted to your changes being removed, and you can manually pluck them out of an old version and re-instate your changes. Without this method, you will be left scratching your head wondering why so much stuff is behaving strangely after an upgrade.

Merging the vendor

Now you’re ready to see if all this extra work is worth it. It’s time to merge the vendor branch into your working changes. There is no need to have a physical disk checkout of your branch so you can go ahead and delete it.

cd /path/to/my_project/src/
svn merge --dry-run -r 71:72 http://127.0.0.1/repos/my_project/branches/vendor/magento

Assuming the auger goes for you, remove the –dry-run flag. More than likely, the auger will not go all well and you will see some SVN collisions. Even if you haven’t modified any of the code, the changes from one version of Magento to another may be too great for subversion to handle in one diff.

Now you have the option to study any of the collisions and upgrade at your leisure. This is far safer than simply overwriting a package full of files over your hard work.

To view all the collided files:

svn diff | grep ^C

Custom Modules

Most likely you will want to make a module that represent’s your company to hold all your specific changes. Start off by making a new directory like so:

app/
     code/
            core/
            community/
            local/
                    XyzCorp/

Now, if you need to make changes to the Magento file, Mage/Catalog/Block/Breadcrumbs.php, you can add a new directory for the “Catalog” module under your XyzCorp directory, then a blocks directory and copy the file into this new directory. Also you need to create config.xml of your module.

app/
     code/
            core/
            community/
            local/
                    XyzCorp/
                               Catalog/
                                          Block/
                                                 Breadcrumbs.php
                                          etc/
                                                 config.xml

Change the class name inside the file by starting off with “XyzCorp” instead of “Mage”.

Strip out all the code you don’t need, and make it subclass the original class name (”Mage_Catalog_Block_Breadcrumbs”).

Now, you must activate your module so Magento understands that there is new code in the “local” directory.

In app/etc/modules/XyzCorp_Catalog.xml, add the following lines

<?xml version="1.0"?>
<config>
     <modules>
        <XyzCorp_Catalog>
            <active>true</active>
            <codePool>local</codePool>
        </XyzCorp_Catalog>
     </modules>
</config>

It is crucial that the same prefix XyzCorp is used throughout files, class names, directories, and XML tag names.

Now, your own catalog module is activated, but when will it actually be called by the system? Ahh, we need a special rewrite tag to instruct Magento to use this one file (Breadcrumbs.php) instead of its default.

Now we should rewrite block using your module’s config file.

Blocks

Edit app/code/local/XyzCorp/Catalog/etc/config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <XyzCorp_Catalog>
            <version>0.1.0</version>
        </XyzCorp_Catalog>
    </modules>
    <global>
        <blocks>
            <catalog>
                <rewrite>
                        <breadcrumbs>XyzCorp_Catalog_Block_Breadcrumbs</breadcrumbs>
                </rewrite>
            </catalog>
        </blocks>
    </global>
</config>

We need to add a “blocks” tag, or edit inside an existing blocks tag, depending on your XML file. Then we add a rewrite tag after our module name, which is “catalog” in this case. Then, we throw in the word “breadcrumbs”. This “breadcrumbs” name must match a block type in the app/design/frontend/default/default/layout/main.xml file. The data inside the breadcrumbs tag is the name of your classfile, and Magento knows how to find it because the class name is the same as it’s directory path and filename.




 

Magento 2 GitHub Repository

Magento Job Board - Some sort of tag line goes here

Latest Posts| View all Jobs