Supraja Ganji

So, coming to the first question, could you help me understand more about your background by giving a brief introduction of yourself, Bhakti? So, yeah, hello, everyone. So my name is Gunji. I have around 9 years and 8 months of experience in this as a front-end developer, UI and front-end developer. So I started my career in June 2015 with the GGK Tech Organization. In my initial days, I started as a UI developer, wherein we used to build the pages on websites and web pages of an application using plain HTML, CSS, and JS with some mock data, and we used to provide those to the front-end developers, who would integrate it with the APIs and all. But later, after four years of my career, I learned Vue JS and JS thoroughly, and now I'm working as a front-end Vue JS developer for one of the projects. I'm responsible for all this API integration as well. I also have experience working with AngularJS for one year, ReactJS for one year, and four years of experience working with VueJS, and around six months to one year of experience working with WordPress. I have extensive knowledge of HTML, CSS, plain vanilla JavaScript, and all the front-end frameworks like Bootstrap. I have experience with SASS, CSS preprocessors, cross-browser compatibility issues, building mobile-responsive applications, and all. After looking at this job description, I feel I'll be a good fit for it, but I do have a few doubts about how the part-time work operates. Maybe when you connect with me, I'll get those clarified. That's it. Thank you.

We are coming to the next question. Design a complex UI component that requires dynamic content updates from ACF feeds in WordPress while ensuring it is mobile responsive. Okay. To be frank, what exactly ACF fields are, I'm not sure because I have only six months of experience with WordPress, but I do have knowledge on HTML, CSS, JavaScript, and all. However, talking in general, building a UI component that requires dynamic content updates will be like using reactive properties in our view or Angular or React JS. We use reactive properties which have two-way data binding. So, whenever that prop gets updated, it will automatically update in the UI. That's how we do dynamic content updates. Building a UI component means I have experience building a table component. In our application, we have used Kendo UI for the table component, but we've customized it a lot to fit our application requirements. So, I do have experience building complex UI components, and I've even built new directives in Angular. We are coming to these exact ACF fields. I'm not sure, but I can quickly learn it. It's like, whatever the language or technology, only the syntax will vary. But the main logic and how we think and write should be within us. So, whatever technology we use, it doesn't matter; we can learn it with Google's help. Sorry if I'm wrong, but we have Google for everything, and in this IT field, if we learn new things, we'll survive. So, we shouldn't stick to one thing; we should learn new things and upgrade ourselves. Yeah. That's all I have. Thank you.

So the next question is describe a way to automate the compilation of SASS to CSS on a live production web WordPress website without downtime. Automate the compilation of SASS to CSS on a live production web WordPress website without downtime. Ultimately, browsers will understand only CSS. We generally write in SASS because it has many advantages compared to CSS. We have the ability to reuse code and it will be clear. We can also minimize the code and whatever styles we have written in SASS code, we can then compile it to CSS for the browser to understand. So how do we compile SASS to CSS? This depends on the application. In a WordPress site, I think we might have automatic plugins that will automatically compile SASS to CSS. Generally, in our view applications and also in the webpack config file, we automatically configure it to compile SASS to CSS. We generally give that in our package.json and webpack settings file. Unless we have comments to compile SASS to CSS, but in a WordPress site, I believe there will be some plugin that will automatically compile SASS to CSS.

What steps would you take to remedy common cross browser compatibility issues with JavaScript functionality? Common cross-browser compatibility issues, I would say. So in IE, there used to have a lot of issues because Chrome, Safari, Firefox – all these browsers are one type. Generally, they support all the CSS properties and all, whereas IE and the older versions of IE generally won't support a lot of things. So, new whenever a new CSS property is introduced, generally that will work in Chrome always, Google Chrome. But in IE, it won't. So to address these kinds of issues, we use the vendor prefixes like -webkit for WebKit, -moz for Mozilla Firefox, -o for Opera Mini, -ms for IE, and -webkit for Chrome and Safari. We use the vendor prefixes to make our new CSS properties work in all the browsers. And coming to compatibility issues with JavaScript functionality, ES6. Sorry. Sorry, ma'am. But ES6, those features might not be supported in the older versions and in the IE. But recently, Microsoft has introduced Edge. So that is similar to Chrome or working similar to Chrome and Safari now. It supports almost all the things. So, if the end user is not using IE, it's not a big deal. Mostly it will support. But to fix the cross-browser compatibility issues, we do have to thoroughly test it in all the browsers and make sure it's working fine. If not, we have to fix that.

Debugging a complex JavaScript problem that only occurs in a specific web browser. So, generally, any debugging, we do it through dev tools. We put a breakpoint in our JavaScript file. And, in the console, we face the error. Right? So based on that, we'll get to know the file name and the line number and, which function is causing that. So we, put the breakpoint there in that particular function at that particular line, and then we refresh the page. And whenever the program, I mean, the execution reaches there, we can debug through that. So, that is how we generally do the debugging in any of the browsers. So, if it is occurring only in a specific browser, we, of course, have to put the breakpoint and access the application in that particular browser and try to debug from there. If sometimes it won't hit the breakpoint, then we can put the debugger in our code itself and then check. And, we might have something in JavaScript to identify the browser in which we are checking. Like, in the code itself, we can put, if the browser is, for example, Internet Explorer, we can get the browser the user is using. So we can put a condition, if the browser is IE, then do so and so to fix that problem, particularly in that particular browser. Yeah. That is how we

To the next question, what's your plan to retrofit an older nonresponsive WordPress site with your mobile first design approach? So, yes, I actually do have a lot of experience making applications mobile responsive. So I work on some existing applications to make them mobile responsive. And I did work on completely building an application from scratch. So, you're telling there is an older application, and we should make it a mobile first I mean, responsive WordPress site and with a mobile first design approach. So, a mobile first design approach is nothing but, first, we have to build it for the mobile and build or, I mean, as it is an existing application, we have to fix it for the mobile screen first. From there, we have to go to the higher screens. So, as that is an existing application, so we have to change all the HTML structure if needed to make it responsive. And we have to write new CSS media queries, new CSS to make it work. So, we have to first fix it for the mobile screen and then increase the screen width and see if it's working fine for the tab or not. If any area, if that is not UA appropriate in the tab, then, we have to fix it in that particular area for the tab resolution. Suppose if we take 554 pixels and below for the mobile resolution. Generally, it's 768 and below for the mobile resolutions, but these days, like, even Bootstrap 5 has introduced a new breakpoint, extra small at around 554. So, suppose below 554 will come under the mobile screen. So, first, you build everything for below 554 resolution and then make it increase the screen with, suppose, 768, and see if everything is working fine for the 768 resolution or not. If anything is breaking, then we write a query between 554 and 768 and fix it for that. Maybe above 554, breakpoint, fix it. So, that will now work for the tab. Now, again, increase it. Make it as a laptop or desktop resolution, that is at 1200, and see if whatever the thing which we have fixed for the tab, if it's working for the 1200 resolution, that is well and good. If not, again, we might have to go back and fix whatever is breaking. So, like, that is nothing but a mobile first design approach. So, fix it for the lower resolutions first, and from there, increase the resolution, go to the higher resolution, and fix it. So, that is how generally we do. Thank you.

And then the next question is, given this implementation of a WordPress shortcode, identify why it might not be showing any content, and provide a solution. So I could see here there is a function called custom underscore shortcode. In that, they are internally calling one more function, obi underscore start. Get another function, get template part, passing content and custom parameters, and then they're returning OB get click. There is another option called add shortcode, not function, maybe. Whatever the shortcode they have created ago, they're adding that custom content. Custom shortcode. Okay. So what exactly is the question is. The question is, why the custom shortcode is not showing any content and provide a solution. I think it's because the add_shortcode function is not being used correctly. They are adding the custom shortcode, but it's not being registered. So the issue might be that the add_shortcode function is not being called with the correct parameters. It should be called like this: add_shortcode('custom_shortcode', 'custom_shortcode_callback'); where 'custom_shortcode' is the name of the shortcode and 'custom_shortcode_callback' is the function that will be called when the shortcode is used. But right now, this one, what is this custom content? Might be. Yeah. Sorry. Not that. Not sure.

So the next question is, can you explain what might go wrong with the following CSS code related to responsive design and how would you correct it? So there is a container class with a width of 900 pixels, and there is a media query with a max width of 900 pixels. The container width is 100%. So generally, for all the resolutions, the container class has a width of 900 pixels. And there is a media query with a max width of 900 pixels. This media query will work for screen resolutions below 900 pixels. So below 900 pixels, they are making the container width 100%. This means that for all resolutions below 900 pixels, the container will take up 100% of the parent width. I'm guessing that exactly at the cut point at 900 pixels, we might face an issue with this code. Yes, we might get an unnecessary horizontal scrollbar. So what we can do is change the max width in the media query to 991 pixels. This would solve the issue because until 900 pixels, the width would be 900 pixels, and from 991 pixels and above, the width would be 100% of the parent width. I also think that we should keep the order of the media query at the top, so that it checks for the screen resolution first and if it is below 900 pixels, then the width would be 100% of the parent width. So finally, what I feel is that around the 900 pixel point, there will be an issue. We might get an unnecessary horizontal scrollbar. So making the media query max width as 991 would solve the issue.

So, coming to the next question, how do you ensure the JavaScript code you write takes advantage of modern ES 6 features while still being compatible with older browsers. You generally want to ensure that your code takes advantage of modern ES 6 features while still being compatible with older browsers. Most older browsers like IE won't support the new JS ES 6 plus concept. So, until ES 5, they'll be supportive. If you write any new ES 6 feature, then that might not work in older browsers. We still need to be compatible. Ultimately, we have to test everything in all our supported browsers in older versions as well and see. If we use new ES 6 concepts, it won't work in older browsers. So, we have to use that approach. Maybe we can base our code on browser compatibility. We can know what browser the user is trying to access the application from. And if it's IE, we can use that code. If it supports ES 6 concepts, then we can use this particular code, like that, we can do it.

So good to have questions. So next question is illustrative workflow where you integrate Adobe Creative Suite Graphics into WordPress theme while maintaining responsive integration. Illustrative workflow where you integrate Adobe Creative Suite graphics into WordPress theme while maintaining responsive integration. Fine. To be frank, I have very little experience with WordPress around six months, but not in-depth about using, you know, integrating, using the ins and outs. But I don't think that will be difficult. Like, I can learn it easily, but I do have very good experience with making applications mobile responsive. I did see the job description. Coming to theme, I have experience with this work. In the six months I worked on a WordPress website, we used the Divi theme there, and that website is my current organization's website, Innovative Solutions website, which you can see. I worked on a few pages. We used the Divi theme there. To integrate anything here with the Divi team, they're asking how to integrate. I don't create graphics, sir. That's exactly what I'm saying, but I think I can learn it. Yeah.

An efficient and maintainable way to handle theme and plugin updates on your WordPress site without breaking the custom SaaS implementation is to test updates in a staging environment. This allows you to verify that updates do not affect the current implementation. We should see the update release notes and check if it affects any of our custom code, and then we can decide whether to update or not.