This two-part series will look at the development of Magento checkout to meet the requirements of a client using Enterprise 1.13. We won’t deal with the basics of setting up modules or extending classes. I’ve an earlier series on that. Here, I want to focus on checkout’s end-to-end inner workings — a post I’ve wanted to do for some time.
In this post we’ll add an attribute with a select input field. First, we’ll store the select options in the EAV database, then we’ll see how we can allow the client to update the options in Admin.
In this post, we’ll add the ‘website’ attribute to checkout. Entities for ‘order’ exist outside the EAV model, so we’ll need to add a column for ‘website’ to the tables sales_flat_order_address and sales_flat_quote_address.
It’s time for some real action. In this post we’re going to see how to add attributes in our EAV database model. We’ll build install and upgrade files which do the heavy lifting including giving Admin and Frontend access to our new fields throughout our site for create and update.
In this series of posts we’re going to considerably extend customer registration for our site. Along the way we’re going to see how easy it is to add fields to the various input forms of our site using the power of Magento’s EAV database. If that sounds like fun, read on.
In this post, we take a different approach. Part 2 provided a solution based on a rewrite. Here, our approach is light touch. We track down a suitable event and build an observer to provide the solution. Again, as we did in part 2, we’ll focus on how we got there, as well as on the end goal itself…
Now we want to take a look at rewriting some of Magento’s core code in a module of our own. Our aim is to set the quantity of a related product (a product warranty) added to the cart to the same quantity as the main product that we select. There are bigger lessons here too, and we want to learn those along the way. Here goes…
In this and subsequent posts we’re going to look at how to change the quantity of a product added to the cart. Our first solution will be a rewrite of a model class. Second – lighter touch – we’ll look at using an observer to do the same. Along the way, we’ll discuss ways to approach a problem such as this. Ready?
This is a follow-on post to a recent series where I provided administrators with an option to add a despatch date in Admin, present this in the order grid and include it in an order update email. In this post, we want to ‘ajaxify’ the user experience. We’ll update the database with the new date without having to refresh the order view page.
In this post, we are going to add our newly created despatch date field to the customer’s ‘My Account’ area for any orders they have made. For this, we’ll take a similar approach to the one taken in part 2 of this series, when we set up the layout for the field within Magento Admin.