Harish Thatikonda

Yes, myself, Harish, and I'm from Warangal. And, in this, I have started working on Magento 2 from the company Kinzum Solutions, where I worked on their own product, which they created by the Kansan people, which is a connector that integrates between Magento and Acumatica ERP systems. This connector provides a bidirectional sync between Magento and the Acumatica ERP system, syncing customers and products and everything. I have worked on many projects. In addition to the connector, I also worked on a product related to mid-Atlantic and American Images in a project. I also started working on d a digital, where I worked on the vision, front-end, and back-end related things. On the back-end, I worked on most of the destination products, including Destination Pet and SHRM. On the front-end, I worked on c p h related things. From scratch, we created the c p s site, which is a previous ID of AEM. These are the things we have done on these projects.

To effectively debug and resolve a complex issue that arises post deployment of a Magento 2 extension, we need to follow these steps: First, we need to check if there are any issues with model naming conventions and model declarations. We also need to verify if the codes we have written or if there are any loggers we have written that are trying to log huge data. If there are test cases, we just need to verify if they are working fine. If there are any issues, we need to check the capability of the code we have written for that extension, which we have deployed for the server level and what the servers, such as PHP version and compatibility, depend on this version 2 extension. We can check this by looking at exception dot log or debug dot logs system dot logs to get some information and figure out if there is any issue and what the issue is facing. We can also create an enable or disable configuration for this model and check if there is an issue from our model itself. Then we need to figure it out by debugging into the code, starting from the registration model at XML, then from the d at XML, and from where it is coming and how it is treating. We need to go step by step, not just enabling this model and going with the functionalities.

To design a fault-tolerant system for image storage, we need to consider testing related things before or after production deployments. This can be achieved by creating Lambda test cases that will be executed after deployment to identify any issues or breakdowns in the site level, which helps us to give reports. Based on the report, if there is a breakage of any feature, we can plug in minimum features to fix those things. For availability, we need to hit an IP allow list. We need to thoroughly check which IPs we need to allow and which we can list. If we are using caching, we can add IP restrictions to prevent certain IPs from accessing our site store. The URL should be secured, and there should be no data leakage. To ensure fault tolerance, we need to take regular backups so that if there are any issues with the current setup after changes, we can revert to the previous backup database and avoid wasting time in debugging and making the production server down.

So, we can upgrade the Magento version from the old to the latest. Basically, if the Magento is completely handled by cloud-related things, like the ecommerce and related cloud things. So, we may raise a ticket to them to check how we can ask them to upgrade the image to the latest version. If not, then we can upgrade using composer from non-local systems directly or from the cloud level. We can just use composer upgrade commands where we need to update the composer JSON file using the composer command. And, after that, we just need to hit the composer update so that the latest updated version, which is added into the composer JSON file, is updated to all the Magento-related things, everything to the latest version mentioned in the composer JSON file. But then we just need to run all the set of commands to check whether everything is up and running.

We can minimize deployment time by merging CSS and less files, as well as matching and combining JS files. We can also implement different deployment strategies, such as enterprise versions that offer support for zero downtime deployment. We can reduce deployment time by optimizing CSS and JS related tasks and checking how to optimize further by removing unnecessary models. Zero downtime deployment strategies will be implemented at the configuration level. By reducing deployment time to around 5 to 10 minutes, it won't affect production or other processes. The effectiveness of zero downtime deployment strategies will depend on the cloud configurations and the optimization of CSS and JS files.

We just need to develop this extension in an exact and particular way, following the Magento coding standards. So we just need to follow all the standards, and there are tools where we can check our coding standards, like how the Magento coding standard follows, which is object-oriented programming language on the Gen framework related things, and how it's going to be used. Based on the Magento coding standards, we just need to create all the necessary files, which are like etc/inmodal.xml.php. And then, if we're adding any web APIs, we can add a web API dot XML file in etc/repositories/api and model files. If there's any grid, the grid level things, we can add it in the layout and a UI admin grid. Basically, there's also the Magento coding standards tool where we can check these coding standards of Magento using this Magento coding standards check tool, which we have on GitHub, and we can use PHP CS PHP CS snippets to check what are the errors and everything. So we just need to do the codings based on the Magento core functionality and principles where we can add all the doc blocks and everything. We can also check our code directly in SonarQube, and these tools give us some errors if there are any issues with our code or if any principles we have violated.

So basically, we can check this JavaScript files or JavaScript related code, everything. If you see any errors in the checkout code page, we can check in the console or add any loggers in the JavaScript file which we have added. And we need to figure out what is going wrong. And we can also check if the updated JS file is present in the store level or this old one. You can directly check that JS file's code in the browser using debugger tools. And we can figure out how we can fix those things. Basically, we can check in the console related things, the errors we can get, or we can add some type of loggers, and we can figure out how we can fix those things.

Magento Extension Class ========================= ```php // Rename class to follow Magento's naming convention class CustomProductTypePlugin { // Renamed method to remove depth and follow naming convention public function getProductName(\Magento\Catalog\Model\Product $product) { // Renamed method to follow naming convention public function getProductName(\Magento\Catalog\Model\Product $product) { // Renamed variable to follow naming convention $productName = $product->getName(); // Rest of the method remains the same return $productName; } // Renamed method to follow naming convention public function getPluginName() { // Renamed variable to follow naming convention $pluginName = 'Custom Product Type Plugin'; // Rest of the method remains the same return $pluginName; } // Other related plugin methods can be written below } ``` Note: The above code sample is based on the provided text and assumes the code is written in PHP. The actual code may vary based on the Magento version and the specific requirements of the extension.

To approach the optimization of a heavily overloaded Magento 2 database critical for business operation, we need to check if there is any previous data storing in our database that is not required. If there are products that have been deleted or deleted related reviews or any related data for those products, we can remove them. We also need to check if there are any query logs happening. Additionally, we need to check if there are any cron jobs that are creating a significant impact on the database and figure out how they are affecting it. To do this, we can check a better way to optimize queries, such as enabling cache-related things. We just need to remove unused or unwanted data that is not required for our store level. If there is any previous data that we deleted but is still present in the information, we can delete it directly to free up space and decrease the load on the database.

What approach would you take to customize your image into to store Timer. Team for optimal rendering on mobile services. So, optimal rendering on mobile devices. So, actually, we can write these themes related to CSS and everything using this depending upon the mobile devices. So we need to add these CSS related things in the app design theme level theme folder. Suppose if we want to add any CSS to extend the theme, we can write then we can directly in the app design level, we'll just create this theme folder, and add the CSS files, which we want to add to mobile devices. Suppose if any mobile device is selected, then the CSS will be used from this list files. We can just optimize these screen widths and stylings and everything so that it will be updated. It will be updated based upon the device, the CSS, the screen width and everything will be updated accordingly. User can have a good experience on the device level. So we have this type of feature. Like, we can write CSS for different devices using min width like that.

We need to check which tables the data is getting into. So we will be having this rollback feature when generally if any table has been dropped or if any data has been deleted using this MySQL rollback feature, we can just get the data directly if that rollback feature is enabled. But if it's enabled, then it may create some type of load. So, basically, we just need to be fully prepared. If any things may happen in different scenarios, so every time we just need to take a backup of the databases when we are trying to do any deployments or anything so that if anything goes wrong, then the old database can be reverted back into the same place instead of breaking down the production services. We also need to check that MySQL is running in a correct, good, healthy state if it is not creating any load impacts so that the imported data can be added directly into these tables. If the load is heavy on the database level, then the input will be failed because of this heavy load. So we just need to check everything that the things are in place before importing these things. I also checked the groundwork related things which are working parallelly for importing things. The consumer if there is any consumer hitting this SQL database for inserting this import data will be impacted.