Sunaina Sharma

I have completely 9 years of experience in PHP development, including PHP and its various frameworks and changes like WordPress, OpenCart, and others. These types of frameworks I have worked with, and that includes our SEO website and ecommerce website and various others, which involves tasks related to all performance, such as AppSumo, SEO-related performance tasks, pages optimization, payment gateway integration, shipping APIs integration, and subscription modification and integration. This type of work, I have done and worked in, 4 different types of organizations. And, my last organization was founded in November, 2023. And, currently, I'm working as a freelancer developer with Solutions Private Limited.

Consistent UX. That is twice when developing a responsive website theme. Okay. So, in order to maintain the consistency of UI UX on various devices, the respective media CSS are I used to write the respective media for the different devices. Like, if I am using, we can make a preload of first reporting it. And for that, if I'm using a different image for desktop and different for the mobile, then I will make that preload according to the screen dimension. Like, for mobile devices max 767, and for desktop, from 768 to 1,024 pixels. And according to the same way, the media CSS for respective images page and the containers are used to write and design them to behave accordingly.

Do the first step to debug a WordPress plugin that is causing performance issues. Okay, causing the performance issue. So, in order to debug that, if the plugin is causing the performance issue or not, then the first thing we'll check is if the respective CSS and JS files are being called on the specific page. Like, if their functionality is not being recorded through the website, only on the page that is using its functionality, then the plugin's respective JS and CSS file should be called in that particular page only, not the complete website. And, if the JS and CSS files are not being required on the first report, we'll make them defer or we can call them on scroll of the page. We can also minify that CSS and JS files if required. And, we can use different WordPress plugins to optimize our performance, such as Yoast SEO and other similar plugins. And, the first step to debug. Yeah. In the next step, in the network tab, we will also see how much load they are taking and how much time the CSS and CSS and plugin files are taking to load. And, we can accordingly preload, defer, and move them as per the requirement. But we can also call the plugin once according to the specific template conditions or specific page conditions.

A filter for you to optimize a work beside slow time, at the servers and the code level. Okay? At the service, at the server, the optimization is to optimize the load and we can use different types of caches, like CD and cache, mem cache. These types of caches, we can use too, and we can enable the gzip compression to make things load faster, and the compressed objects will take less time, and it will reduce the load time. These are the server levels. And in the code level, we can do that. We can reduce the image sizes, the images which are taking more time. For all of these, we can firstly optimize the images. Like, we can add height to specific images so that the specific container will be fixed, and it will decrease the LCP of the page. And, also, we can compress the images. If images are heavy in size, we can compress them, and we can use lazy load for the images which are not required in the first report and preload for the images which are required in the first report. These were the images perspective, and the rest are part of, like, JS and CSS files. If, for the CSS file, we will find many unused CSS files, and we will remove the unused CSS files, which is we will remove the unused code from the JS and CSS files that are not required in that specific page or that specific template. We will have to filter out that and minify the CSS file. We can also use CSS unification and its calling. And if any particular CSS file is not required in the first group, we can make them load on scroll of the page. If anything is not regarding the header part, we can make them load on scroll also. And third-party JS. We can remove the unwanted JS code from the files. And secondly, we can remove the JS code from the header and move that to the footer if that is not required in the first viewport. And we can minify the JS files. And if jQuery, we can also remove the jQuery dependency and make them load on scroll. If in the first throughput, there is no dependency on jQuery, like we are not using anything which we have to call jQuery. So we can move the jQuery on scroll. And we can also do one thing, like if our page is not requiring jQuery, then we can move the code to JavaScript also. And that's it.

Piece of jQuery paste plugin. jQuery, the factoid piece of jQuery-based plugin code to use for any last JavaScript for performance. Three factory piece of jQuery-based plugin. What to use? Okay. So in that, we can do one thing. If, like, this plugin is using any specific jQuery-based file, then we can do one thing. We can customize that specific file. We will keep the file as its name is, but we can customize the code according to vanilla JavaScript. And so that calling and everything will be the same, classes and calls and events will be the same. Only the core part will be changed. Dependency will be removed, and the JavaScript code will be replaced in place of that, and it will work. I have done one of the implementations in one of the plugins, which was using the K star rating plugin. And check only the dependency we have to remove because it was causing performance issues and making the load time low. So I have converted the check for recording to JavaScript, and all the events and code is converted to JavaScript, and it worked fine. There was no issue. Just we have to keep in mind while we are upgrading the plugin. So we have to modify the code again accordingly.

Version controlling in a new environment using Git while developing a WordPress plugin. Okay, so version controlling in Git and WordPress, we mainly have to drag the wp-content folder with the project we're working on. In the kit, we keep only the WP-content folder, which includes any other folders like WP-admin and WP-includes. While developing a plugin, we can do one thing. We can create a branch. If we create a branch, we can work on that specific branch. And if other developers create a separate branch, we can merge that branch together on the master environment. Or before merging to the master environment, we can merge both branches in our local environment and verify the things. If there's no issue and things are working fine, then we'll merge that branch into the master. Like, if we have a branch 'a' and another branch 'b', and if we've merged our code, like developer 'a' and developer 'b' merge their code in the branch 'a'. And after verification and all the things, then only we'll merge that branch 'a' into the master, and then verify the code in the master branch. The master branch is our dev environment, so we'll merge that to the dev environment and verify the things there.

And, like, what it does, endpoint out any potential security flaws. New is a delight. Given this feature function, identify what it does it matter? Square credential. Username is this and password is this. Okay. Security flaw is there is that we are directly verifying the password in the database. We are directly verifying the password. It shows the password is not encrypted in the form. It is saved directly as text in the database. So before the password should always be in encrypted form, like MD5 or any other encryption method we can use here, so that the password should not be visible to anyone in the database or directly. In this way, all passwords will show as a, b, c, d. It should be always in encrypted form.

warning-message { color: white; background-color: red; font-family: font; font-size: font; }.warning-message { color: white; background-color: red; font-family: font; font-size: font; font-weight: 400; /* assuming 400 is the default weight */ } In the color, we can use font-color instead of color. That would be more specific to specify the font color..warning-message { color: white; background-color: red; font-family: font; font-size: font; font-weight: 400; /* assuming 400 is the default weight */ } The class name which we have used for warning should be without space, like warning_message, or warning_without_space_message. It should not be in this way. It should be in this way: warning_message.

Okay. Implement person control and feature branch for a complex frame with multiple developers. Okay. Fine. If we, when we are implementing person controlling, we have implemented Git in the production environment, then we have a branch like staging. We have a branch like dev environment, which is master, then we have to keep all the environments synced. And in the first step, we'll take the pull of the production branch, that is our production environment, to the staging environment and also to the master environment. And while the team is working, then there are different developers working on different tasks, then there should be different tickets for the different tasks, sorry, different branches for the different tasks. As soon as the developer completes the task, verifies the task, that specific branch should get merged to the master environment. And after that, same as with other developers, as soon as they complete the task, then that will be merged to the master environment. And if we are planning to release, then only those changes should get merged to the dev environment, master environment, which we have to take in the release. And while we are doing this, all the developers have done, they are working on the master environment, and we are planning to release them. We will merge all the code of the master branch to the staging environment because our master is already synced with the staging and production environment. And now our master environment is containing the code which our developers have worked on different tasks. So only that code will be merged to the staging environment. And before merging, we will verify if our branch, that particular code we are going to match to the staging environment, that is containing our changes, our respective task changes only, or it is containing some extra code. We have to verify the format, and then we'll revert to the staging environment. And same will happen while we are doing the release from staging to the production. The staging branch should get merged to that. A PR will be created. A pull request will be created from staging to production. This is related to the normal release. If you are working on a CICD release, then we will create, we will prefer to create a sprint branch. Like, we have created for a specific one. Like, it is a 7 v 1 sprint, then we'll create a 7 one sprint branch, and all, specific task branches will get merged to the master environment. And before, while we are deploying the changes to the staging environment, then we will merge all those branches to the sprint branch, and only the sprint branch will get merged to the staging and production environment. That's all.

Introduce my app to ensure a simple sound from within you. 1 plus 1 does not equal. Introduce my screenshot as sync. Calls, fitting in WordPress plugin, do not affect me. So we define the JavaScript as async to improve our performance. We define the JavaScript as async or the JavaScript in order to improve the page performance and make them load after, like, downloading of all the content or, after the download is complete, to ensure. Okay. So while we are making any JavaScript async, then we have to, firstly, go through their functionality, that if we are making any specific JavaScript async, then it should not impact the page. Like, if that JavaScript is required initially on page load, then it will give an error, and the functionality will stop working. So we have to work in a way that we have to either make the specific part of the JavaScript async. Like, if we can divide the JavaScript code into parts. Like, if half of the code is required on page load and the rest of the code is after the completion of page load, after the download is complete, then we can divide them into parts. Like, we can move the rest of the code to the footer and make it async. And the part which is required initially, we can make that in the header and load it without making it async. And it will not impact our performance and also the functionality will work fine.

Dashboard into a WordPress tool using our SDK and front-end technology. Okay. So in order to develop a dashboard, the dashboard will fetch the data from different in-house systems. You do have. So, if we are planning to implement a dashboard in a WordPress plugin, we can do so by creating a custom plugin. In a custom plugin, we can create a menu item using add_menu and add_action hooks, and create a specific page for that, which will display the data. While we are creating a plugin, we will use activation hooks and deactivation hooks for implementing the feature. On activation, we can define what will happen. And on deactivation, what will happen. We will then call a specific function to call that specific page data, in which we will call the restful APIs for fetching the data as that specific API and front-end technology. We will design the page according to the dashboard design. The dashboard will contain a report from the different in-house systems, including WordPress daily, and from the rest API. It will get updated in sync whenever the data will get updated in the rest API. The page URL will be defined in our WordPress plugin, with the function name, and data will be updated, deleted, and modified accordingly, according to the restful API. But what link we get from there. Like, they will provide us with the rest of the API. They will provide us endpoints for specific data collection, and we'll hit those endpoints either from cURL or any other way in PHP and then fetch the data accordingly. That's all.