Dhirajkumar Deore

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

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

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

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

Cross browser JavaScript challenges is it's something like that is, uh, yeah, that there will be problems with, uh, cross browser JavaScript because 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 know, you you you apply in CSP whitelist of XML in Magento module that this is the JS that I I want to give access, uh, to to run on a Magento system, uh, so that it doesn't throw an, um, cross site scripting cross site cross browser JavaScript errors on on the browser. Uh, also, you can what we can do is, uh, enable enable post, enable, you know, JavaScript configurations in Magento which which support, you know, cross browser JavaScript. So these are the 2 approaches that we can use. Uh, most probably CSP's CSP validation in CSP work list dot XML will will resolve the issues. But if there are any more, I think what we can do is we can use custom extension, which actually facilitates, you know, some, uh, JavaScript JavaScript linking to Magento. Yeah.

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

Based on the JavaScript net, uh, 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. Uh, value. So I think, uh, what should we use here is not null or is null, um, uh, thing on on the form field. If, you know, query selector doesn't return us anything, then form field should have, uh, should have undefined, um, 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, uh, alert that email field cannot be empty.

Examine this PHP function used in the Magento model, explain why it might cause performance change, how could it optimize while maintaining this functionality. So the function is get customer orders, and we are passing customer ID to it. We are in initializing orders array. We are getting collection, which is selecting all the fields. We are adding a customer ID filter. We are looping the collection, uh, and we are we are returning the orders. So if you are getting get customer orders, uh, from get customer orders, you are just getting, you know, uh, order data. So you also has that in collection. Right? So you can just return the collection and don't want to, you know, look through the collection and fetch the order data. So that's unnecessary part of this code. We can just return collection from here and, uh, get on with it in in our next function where we are gonna use this data. So in the next function, what what you are again gonna look through the orders array here. The orders array are here are here are here. So instead of that, we can just return the collection, and we can look through the collection in in our next function, you know, uh, which which returns, uh, this data. So, yeah, uh, that that's how we can optimize it. And that's one thing I can I can remember here is we are selecting all the fields? So if for your function, if there are there is no need for all the fields from the order table, uh, order order object to have to to perform the functionality, then just mention those particular fields. You know, if you just need increment ID, order name, customer name, or, you know, grand total, anything, you can just mention those fields here so that, you know, our query will be very finite. It will be less comp compact, and, uh, will be much more optimized.

Invent a procedure to conditionally load Josh Duplant's Magento to improve page loading times. So, uh, conditionally, there are 2 ways. 1 is we add a condition in layout where we hide a certain block based on the Magento configuration, uh, 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, uh, include the conditions on our block file where we, um, actually define our template and everything. So we can, uh, 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 logging times conditionally.

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

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