Dhirajkumar Deore

Yes, I'm from Pune, and I have nearly 10 years of experience in ecommerce development, mainly in Magento. I started out with PHP as a PHP developer in 2014. For a year, I worked on learning the PHP language and different frameworks like Laravel, and then switched to Magento 1, which was the earlier version of Adobe Commerce that is today. I worked on Magento 1 until 2016, completing several projects and gaining a deep understanding of how ecommerce works and all the little intricacies in Magento. So, when we switched to Magento 2 in 2016, it was a very smooth transition. We already knew what Magento is based on, and it's the base structure. So it was a very smooth transition. I switched to Magento 2 and learned it quickly, and then I joined some large projects. One was notably with the Nestle team, which I worked on a Starbucks project, a b to b. And there was a large team involved in that project, and I was part of it. I had a very good exposure to Magento as well as third-party integrations like IBM Commerce, TIBCO, SAP, and Salesforce. So I have worked on all these platforms to integrate the data and have data interchange between Magento and those systems. Recently, I created an extension for a large organization based out of Israel, which is a balanced pay. So it was a b to b checkout extension that they have been working on. And I completely handled that extension from scratch to putting it out on the marketplace. So all the things were related to Fintech. So I gained exposure to payments and all the details about what goes into that. And recently, I worked on migrating an open-source project of Magento to Adobe Commerce Cloud, which is their in-house solution for Adobe. So I was involved from start, analyzing the old system and migrating it, creating a plan, handling a team of developers to work with them to migrate to Adobe Commerce Cloud. So yeah, and that's it.

Yeah. For a debugging process, for a Magento model that causes checkout to fail, First of all, the Magento mode, which is application mode, which is very important. While debugging, we always have developer mode enabled. The command for that is deploy mode set dev space developer. What it will do is it will log all the exceptions and all the errors on your file system. That's 1. The second thing is to understand your environment. You know, what you are using? Apache, NGINX, or whatever web server you are using. So those logs will help us. You know, for Nginx, there will be Nginx logs. For Apache, there will be Apache logs. We should know where they are, and we can check them. First, we can try to reproduce the issue, trigger an issue on the checkout page to fail and see the logs. If we are able to find some exceptions, some information, some notices that we find in logs, which are related to checkout, we can try to resolve them. If we are not finding anything, we can check Alog and see there. If still there is nothing, we can just check the browser console and see if there are any weird things going on in the request that we are sending to the server, like post requests. Are we sending all the data as required in post requests? Like shipping information. There is a shipping information API, payment information API in Magento. There is a check shipping information API. So all these APIs have a standard payload that we send. We need to check that. See if we are sending all the correct payload and if not, let's debug from there. Also, check the response. If you are reading the correct response, there is a standard response that these APIs give us. We can check those and see if there is any disturbance there. Still, if you are not able to find anything, then we can just go ahead and check our custom models that are installed. There are 3rd party models that are installed. Try disabling some modules, removing some modules, and repeating the process of causing checkout to fail, and see if you can find something in those models. There is also custom themes that are involved. Maybe there is a JS which is causing a problem which we have extended from a Luma theme or a base theme Magento has, or we have created a new theme where we have added a new JS file on the checkout which is causing an issue. We can check that as well. There will be a payment method which is customly developed by some developer, and we can disable that and check maybe shipment level. Shipment methods are custom developed, and we can check that. So there are multiple things we can check on code as well, like third party models, custom models, custom fees, custom payment methods, custom shipping methods. So, this is the route that I think we should go to fix the issue on the checkout.

Migrating Magento 1 to Magento 2, I did a walk-through on Magento 1 to Magento 2 migration earlier. So, there is a tool that actually facilitates its migration. So, what it does is it creates an XML file where we mention what part of our application we have to migrate, like modules and all the custom models, database tables. We have to mention everything. We can run that script and have a 2-data populate in the table, where all the extension data as well as custom data that we have created will be migrated. And we can just go through the Magento standard installation, Magento 2 standard installation, and see if everything works fine as in Magento 1. And so, this is the data part of it. For the structure part of it, we have to manually create those models, because in Magento 1, there are different types of layering, different types of structure in the database that we use. Like, app design, we have layouts and all, but in Magento 2, you have the layouts in a separate code directly. So, in a particular module, that part will be taken care of by a developer. They will make sure that every layout, every controller, every route, every template file, every block, every model, and every helper are correctly returning Magento 2 format, and they are ready to go. So, data part, I've already told, there is a standard tool available, which can migrate from Magento 1 to Magento 2. For the coding part, we have to do manual model creation.

To improve Magento's API response time for JavaScript front end using GraphQL is something like whatever the standard difference between REST API and GraphQL. GraphQL actually gives you extensibility and simplicity where you can request only those data that is required for your operations. So suppose if you are working with some custom model and there are n number of entities that you have to have in that model custom model. But for your particular operation, you need only 3 entities to perform that operation. So REST API is a standard API where we get all the information from that API, and you don't have control over what response you get. But for GraphQL, you can tweak the inputs. You can tweak the schema that you've sent to GraphQL API and get that particular response in return. So suppose in a custom model, you have n entities, like, say, 20 different fields. You require 3 fields for a particular API to work, but 10 fields for other API to work. And it's all coming from a custom model. So you can use actually one endpoint of GraphQL, which will facilitate both these different functionalities. One is for which requires only 3 entities, which we will pass on through schema only, 3 entities that are required. So in response, you will get only 3 entities. But for the other one, you will pass 10 entities that you require so that in response, you get 10 entities and you can perform your operation correctly. So that's how you can improve the API response time using GraphQL.

Cross-browser JavaScript challenges is something like that there will be problems with cross-browser JavaScript because a JS file will be located on a different server and you are using it on your system. So a standard way is to integrate that JavaScript and use CSP where you apply in CSP whitelist of XML in Magento module that this is the JS that I want to give access to run on a Magento system, so that it doesn't throw an cross-site scripting cross-browser JavaScript errors on the browser. Also, you can enable post-configuration in Magento which supports cross-browser JavaScript. So these are the two approaches that we can use. Most probably CSP's CSP validation in CSP whitelist dot XML will resolve the issues. But if there are any more issues, we can use a custom extension, which actually facilitates some JavaScript linking to Magento.

How would you handle a Magento site upgrade without causing downtime to the live system? I'm thinking about the question right now because the Magento site upgrade is a version upgrade on Magento, or even a small change in code or custom code, so that's fine. Typically, I take the response from about how Adobe Commerce Cloud works. They create a build on a separate instance and then switch to the new build in 5 to 10 seconds on live, so there is only 5 to 10 seconds of downtime. They do all the deployment process, all the standard file creation, compilation, and upgrade on a build hosted on a different instance, and then deploy that build on the live site. That's how Adobe Commerce Cloud works. If you are not on Adobe Commerce Cloud, if you are on open source, then what we can do is have a pre-prod environment on hosting, wherever we are hosted, AWS, Azure, or Google Cloud. We make sure that when we deploy the changes and upgrade the changes on pre-prod, we have the latest database available on pre-prod. We upgrade it, and that may have some downtime, 5 to 10 minutes. We have the live database pulled up in pre-prod, and then do some commands like composer update or composer install, setup upgrade, and DI compile. That may take 5 to 10 minutes, but once pre-prod is ready, we can just switch the pre-prod environment and the prod environment so that the pre-prod environment is our current environment. I do have experience doing this when we had to move from Magento 2.3 open-sourced version to Magento 2.4. So similar upgrades would require a pre-prod environment for one month. We were working on the pre-prod environment, upgrading things, updating custom models. There were a lot of custom models that we upgraded, so we required one month to upgrade that. And once the upgrade was done, for the deployment phase, we pulled up the live database from live, deployed it on the pre-prod environment, did our upgrade pipeline commands, and immediately switched it to the live environment. That's how we can upgrade without causing downtime of the live system.

Based on the JavaScript net, used for form validation, identify what operator is wrong with the use of double applicable to operator and suggest more reliable way to check the form field. value. So I think, what should we use here is not null or is null, thing on the form field. If, you know, query selector doesn't return us anything, then form field should have, should have undefined, value as well. So we have to check undefined as well if the form field is undefined. Or if it is null, then we can, you know, alert that email field cannot be empty.

function getCustomerOrders($customerId) { $orders = array(); $collection = Mage::getModel('sales/order')->getCollection() ->addAttributeToSelect('*') ->addFilter('customer_id', $customerId); return $collection; } This function can be optimized by removing the unnecessary loop and selecting only the required fields. Here's the optimized version: function getCustomerOrders($customerId) { $collection = Mage::getModel('sales/order')->getCollection() ->addAttributeToSelect('*') ->addFilter('customer_id', $customerId); return $collection; } However, this will return the entire order collection, which might be unnecessary if the next function only needs a specific set of data. To optimize this further, we can select only the required fields in the collection: function getCustomerOrders($customerId) { $collection = Mage::getModel('sales/order')->getCollection() ->addAttributeToSelect(array('increment_id', 'order_name', 'customer_name', 'grand_total')) ->addFilter('customer_id', $customerId); return $collection; } This way, the query will be more finite and less computationally expensive. The next function can then loop through the collection and fetch the required data. The original function's intention of returning only the order data can be achieved by modifying the next function to fetch the required data from the collection. However, this would require significant changes to the code and might not be the most efficient solution.

In order to conditionally load Josh Duplant's Magento to improve page loading times, so there are two ways. One is we add a condition in layout where we hide a certain block based on the Magento configuration back end configurations. And if we hide the block, then JavaScript won't be loaded, that template won't be loaded, and the JavaScript file won't be loaded through that template. One is that way. One is a custom way where we can just include the conditions on our block file where we actually define our template and everything. So we can create a function where we add our conditions and use that function on a template file to include or exclude the JavaScript file. So that's how we can improve the page loading times conditionally.

Yeah. Describe how we'll do and announce existing Magento ecommerce site to support subscription based model. So, subscription based, I have worked on in Magento 1. So, what we did there is we created some custom models to support the subscription based model. What we did is, we used Magento's default products and our custom extension to facilitate this. The subscription model is something you create a new type of product, and you use that product as a subscription based product. You have different types of attributes assigned to it based on your subscription model, like subscription timeline, 3 months, 6 months, 12 months. There will be different pricing along with it that we can use. This is the first approach where you create a new product type and do it, but there is another approach where we use a virtual product type in Magento to facilitate the subscription based model. We can use some custom actions, third-party custom extensions that are available, which are for subscription based models. You can use those as well, but I prefer custom developed models, which will be specifically enhancing our functionality that we require from a business point of view. Because extensions will have all kinds of different functionalities involved, but maybe we don't need those. Maybe we need something more. Maybe we need something customized. So, I would prefer a customized model to enable the subscription based plans or model. So, there will be different types of payment methods as well, which will support the subscription based model. There is a PayPal method, Braintree, different kinds of credit cards, authorized.net, and Stripe. Every large payment gateway provides subscription based APIs and different kinds of interfaces that we can use in our custom model. So, using these, we can actually enhance our subscription based model.

Elaborate on your favorite tools and practices for Debankham Magento performance decisions on your side. To be honest, I prefer Magento Profiling, which is a default tool in Magento installation. Also, I prefer New Relic. I have a vast amount of experience in New Relic, you know, going through all the New Relic logs and checking where, which database query, which functionality is actually breaking and taking a hit in the performance. We can run some custom queries in New Relic, which will send us on a path to find the deadlocks in tables, the under-optimized database tables that we can find out through New Relic. There are requests that we can find out through New Relic, which can be improved. So, I have already had a lot of exposure to New Relic. I have very high tickets for New Relic to fix the performance issues on our live site.