有些常用的magento相關指令比較長，即使有官方縮寫也經常容易打錯。使用bash function可以自定義這些常用指令的縮寫，以進行簡化或是自行使用容易記得的縮寫。
先前有介紹過一篇 POSTMAN HEADER直接文字加密的方法，打過去的API傳回來的資料可能是加密的資料(如下圖)，每打一次API都要再將回傳的資料再找其他方式解密才能閱讀資料是非常麻煩的事情。所以今天要來介紹POSTMAN Response直接解密的方法。
現今在專案中，透過composer安裝第三方套件來使用是極為普遍的方式，使用composer安裝的程式碼是來自網路的公版軟件，也就意味著不可任意修改。而實務上，難免會遇到第三方套件存在bug，且尚未釋出修正。我們無法直接去修改vendor中的程式，因為每次composer更新安裝時，程式就會再次被公版覆蓋掉。針對這樣的修正需求，Magento Cloud在部署過程設計了一個Patch機制，可以在composer install完畢，去執行修改vendor裡特定的程式檔案。
作為開發者，對於使用外部軟體套件一定不陌生，有在持續維護的套件，每隔一段時間，就會因功能上的追加或問題修復，釋放出新版程式。在未探究前，我們可能只知道版本基本上是遞增的，似乎又有分大小號。但何時加小號，何時加大號，該如何判斷呢？總會有那麼一天，我們需要自行定義產品發布的版號，今天就一起來認識關於版號使用上常見的慣例與規則吧！
在Magento2的結帳頁面是使用knockoutjs渲染製作的功能和特效，而它的購物車、客戶、商品等資料都是藉由\Magento\Checkout\Block\Onepage::getSerializedCheckoutConfig的函數提供，再將它宣告至windows.checkoutConfig裡，讓knockoutjs的model能去取得一些基本必要設定值，但當我們客製化一些新的功能在結帳頁面，想要去新增或定義新的windows.checkoutConfig值該如何做呢?
做API需求舉例，Stamp會需要拿RequestBody去做加密，但如果每一次都要將如果要修改RequestBody那麼同時也會需要以下面的加密方式再將SHA128(Base64Encode(RequestBody))寫回去Header裡的Stamp，而時間戳也要馬上產生，這樣每打一次API都要再重新加密是非常麻煩的事情。那要如何改善呢？
使用Git來管理程式版本，身為開發者一定不陌生。在Magento專案裡，如果遇上原生不支援的功能，我們會自己開發模組，如果這個模組被設計可通用於不同專案，那麼集中一個地方去開發，肯定是較好的維護方式。今天要跟大家分享git本身即有功能可達到此目的，透過submodule的建立，一個模組專案，可以被安裝在不同Magento專案之下，一旦模組有更新異動，各專案可自行同步到最新程式，一起來看看吧！
Magento 1 Vue Storefront環境建置系列已經來到下篇啦！在前兩章節我們講述如何建立Vue Storefront環境的環境，但是我們沒有提到我們的資料從何而來，大致可以分為以下兩種。如何在Magento專案下操作呢？就讓我們一起來看看吧！
好久不見的Magento2開發-使用Plugin改變原生行為系列又來啦！這次Plugin的使用來到尾聲囉！最後一個，也就是置入點放在最末的 after Plugin，其使用也是最簡單的，我們繼續以先前的範例往下看吧！
Magento 1 Vue Storefront環境建置系列又來啦！還記得我們在上一篇文章中提到什麼嗎？ 在上一篇magento 1 Vue Storefront 環境建置（上），我們建置了基礎的環境，這次我們要來建置Vue Storefront與Vue Storefront Api。那就跟著以下步驟，一起來試試吧！
Vue Storefront發送請求Vue Storefront Api決定連結之後端，並處理資料來源，有可能來自magento端或cache或elasticsearch或是其他平台。Vue Storefront的環境建置有兩種：你可以選擇使用docker與cli與是手動灌所有的程式。今天我們先以手動安裝的方式來進行，有助於了解整個架構呦！跟著以下步驟試試吧！
上回帶大家實作before的Plugin，用來改寫傳入的參數值。今天要探究的是最常被使用到的around Plugin，因為它可以直接覆蓋掉目標方法裡的邏輯行為，是普遍的客製需求所在，所以實做變化較多，話不多說，直接進入主題！沿用上回範例，我們以虛構類別 Magento\Example\Model\SummaryAmount.php來覆寫，不過這回稍微為目標方法增加了額外行為
