 Well, good morning everybody on day two of domains 201. Hey, Amanda. Hey, Meredith All right, so I hope yesterday was such a great day of conversation. So we want to keep that going on that side so this morning we're going to talk about advanced site troubleshooting and tips and tricks for advanced errors within your WordPress or omica sites even general sites on your domain of one's own account as well and and through that tips and tricks on site organization as well through a couple of different topics like error logging in WordPress and turning on errors in omica. Also, we're going to look at translating the messages themselves when we get the error messages. Sometimes it can be really daunting to see this long string of text within an error message and you don't know where to go from there. So we'll help you look through the errors and understand where the errors pointing to and what's next steps we need to take from there. The next steps can be turning off plugins, even switching themes in WordPress or even updating themes and plugins in a site like omica or anything like that from there. We'll also take a look at file permissions that a lot of times can cause the site to go offline for as simple as one file within your account being the wrong permissions. We'll talk through the WordPress config permission changes that we've made to help make sure that the WordPress sites are a little bit more secure. Also changing default file permissions within your FTP client. A lot of times the file FTP client that you're working with like FileZilla or Cyberduck sets a default file permission that's different than what C-Panel needs to be able to read the file or folder to load the site. So we want to make sure that we'll set those correctly as well as an admin file permission script that we have set up at the root of the server that lets you set up the fix the permissions right off the bat to help make sure everything's on a clean slate for there. And then we'll also look at account organization to help prevent any errors in the future through subdomains and subdirectories on that side. So looking at the error logs themselves, we can look at WordPress in particular first. WordPress typically records errors within the error log file within the site directories themselves. This happens automatically, whether it be a PHP warning or a failed plugin update, anything like that. If the site does go offline because of an error like this, WordPress also sends an email to the site administrator. So a lot of times it's pretty vague. So I'm sure all of us have seen, I got this email from WordPress. What does it mean? Sort of support ticket. So that means that there's an error reported in WordPress that causes the site to go offline temporarily and it's recorded in the error log file within the site directory itself. You can also choose to display the error on the site itself as a message and you can change that within the WordPress config file directly. And I'll put in a resource here for changing that as well in Discord. So definitely keep the conversation there, ask us questions as we're going. We'll be happy to take a look from there. On the flip side, another common application that we work with is Ameca Classic and Ameca S. And these applications don't typically report error logs automatically. So you need to enable these within the htaccess file. It's really handy to have if you're working on the site like in a development mode, you can change that to report any errors if you're like making updates to plugins or anything like that. Otherwise Ameca will just throw an error saying it encountered an error. Please enable here's instructions on how to do so. And you can see on the right side, the bottom screenshot shows how you can change Ameca Classic to record errors themselves. So this is also once you're done troubleshooting the error or developing the site, you want to make sure you can disable the error logging itself. That way the site will continue to load properly. So it's helpful when it's turned on, but it won't let you load the site. It'll just keep displaying the errors completely on a page. I have a question about that, Meredith. If you have resolved the errors, would you continue to see the debug pop up on the page? Is that something that would just continue to open with like past errors or would it load the site normally? Yeah. Are you talking about WordPress or Ameca? Ameca. Okay. Yeah. In Ameca, the error log is only displayed once the page loads. It doesn't show like the full log and it doesn't log to the error log like WordPress would. So it only displays it on the page once you load. Like if you go to like a particular item or particular collection, it won't show the content. It'll just display the error message until you disable that in the hdaccess file. Even if the error has been resolved? If the error has been resolved, then it won't actually show the error only when the error occurs. So if you've like updated the plugin or anything that it's referencing, then it should be fine. Still best practice to disable that when you're done. Yeah, absolutely for sure. For sure. Okay. So now we'll take a look at interpreting the error itself. So I've got a error message from November from a site that I've been working on and it was a fatal error for PHP, which means that something broke the site and it's not loading anymore. This could happen. You may see this may see a spike of these sort of errors when big updates happen. So if there's like a larger update to WordPress that your plugins are out of date and they don't work with the latest version or even like a PHP jump. So like we saw this when we updated our default server version of PHP from 7.4 to 8.0 after 7.4 reached its end of life support. So we saw a lot of this with like older plugins. So it's important to make sure that your plugins are up to date on that side. So you'll see a whole string of text typically like a fatal error, uncaught error for an undefined function here. And then it shows a file path of where the error specifically was reported. It looks very confusing and a lot of times like a different language, but the important part is to understand that the first portion of the error log in that bolded text means that's where the error lives. So looking at this it's showing home folder Meredith, which is my cPanel username, and then the website name. And then within WordPress, there's the plugins are held in the WP content folder under plugins. And then this one in particular was the fusion builder plugin, which is a page builder. And there was one line within their class fusion builder library that threw an error. This was during an update. And luckily, I knew how to disable plugins within WordPress to be able to roll back the version. And then the site came back online from there. So once you know where the error lives, it's helpful at that point, then you can move into your troubleshooting steps to bring the site back online. Right. So like you might be asking, well, yeah, I know how to turn off plugins and themes. I just do that from the WordPress dashboard. But the error message that Meredith showed you on the last slide is something that's actually in the error log. But you may, and I'm sure that most, if not all of us have seen this, when you try to load a WordPress site and you get that error message splashed right across the page, that's when debugging is on, so that you can kind of see that as you're trying to load the WordPress page, or you would see some sort of critical error notification. And that's when you'd be able to go back and check the error log itself for more details. And so in that case, you really can't access the dashboard. And so that's when you have to go to the file manager and work on things from there. So the first thing that we always like to do, especially if you follow Meredith's example of noticing that it's specifically telling you, hey, this is a plugin based on the path. You'll want to try turning off those plugins from the file manager. And that is as easy as going into the file manager, following that path that the error message is showing you to the affected plugin if you know what that plugin is, and simply renaming it. So just like double clicking or right clicking. And I like to do just like an underscore off so that I know which one I'm working with. But it doesn't really matter what you name it as long as it's not the name of the plugin. And then you can also disable a plugin through the WordPress command line interface. And we have a command for that in a support doc that we can also link as well if you're more comfortable working in that platform. And then once that is disabled, you can go back and see like if things are starting to load again. And if they are, then you know that that particular plugin is the issue and audit your plugins from there. It's a great opportunity to take a solid assessment of your plugins because sometimes you can forget about them if it's been a while and not realize that they're no longer being maintained. Yeah, absolutely. So within that PHP upgrade to a.0, we got a lot of tickets about like my sites offline plugins are out of date. And it turned out that a lot of them have actually been removed from the repository itself. So they were no longer maintained. So I was seeing plugins like go back from 2013 even and even one from like 2010 which is like crazy that they were that out of date. So it's always definitely important to make sure you have like automatic updates on for sites. It's always helpful to keep those up to date. But also now we know how to turn off plugins if something does go wrong with those updates. Absolutely. So then if you say needed to switch a theme in the database, if the error message is coming back and it's not necessarily pointing to a plugin, but it's pointing rather to a theme, then you'll want to address that not from inside the platform because you can't access it, but rather from the C panel. And so from there you'd want to be able to work in a database. So in the database, you know, you'd want to be able to know which database is specific to this particular site that you're using, which is something that you can find in installatron. And our support files take you through all of this. So this is just a light overview. And once you have that database title name, then you'll go to the to its options table. And then you'd be able to look for the specific fields of style sheet and template. And from there actually rename things to default. So like if you've got a funky theme that is throwing an issue, you can always go like to 2020. You know that that's a WordPress theme that or 2022, I guess that should be pretty solid and should set some defaults. And if you can can make that work, then you're in a better in a better spot, or at least you can start from there and continue working. Yeah, any of the default WordPress themes so 2020 through 2023 right now, they can, they'll automatically bring the site back online and let you troubleshoot the theme on that side. You may see your your CSS or any theme specific settings go away because obviously you're switching the themes. But the other theme settings will remain in the database on that side. And if needed, you can restore from a from a backup prior to the theme update if needed to to make sure it comes back online for sure. Yeah, absolutely. Back up to your friend. And they're there for you when you need to make these types of changes and experiment. So don't let that stop you. So the final thing here is updating plugins and themes, not just in the WordPress repository, but also in Omega. So there's a big difference between the way that you do these update updates in WordPress versus in Omega WordPress has a very nice lovely little updating feature platform interface that makes that kind of updating quite simple. Omega on the other hand is a little bit more manual. And so this is where being familiar and comfortable in the file manager is really going to benefit you and being comfortable in your FTP client if that's how you choose to work things. But essentially what you would be doing is actually going to the Omega site or where the where the plugin or theme lives that you want on your site and actually physically downloading it and then uploading that via FTP or just via the file manager to your site and then just configuring things from there. So it's more manual, it's not super complicated. And again, we do have support docs on this so that can walk you through it. I think that the toughest part sometimes is just wrapping your head around that process of like, well, what am I actually doing? It's not just a click of the button, you have to understand the structure a little bit in order to get that to work. Absolutely. And I think that's also really helpful when you're kind of approaching troubleshooting itself is like even just updating plugins and themes within Omega really helped me understand how to even troubleshoot to begin with. Understanding the file structure between WordPress too as well helped gain the practice to like start interpreting those error messages and knowing, okay, this is a particular plugin. And then you can also see like recurring themes happen within the errors too. Like maybe the Kale theme in WordPress was not up to date fully and not compatible with the latest version of PHP. So a lot of times you'll see those errors for sure from there. All right. So now we're going to take a look at file permissions themselves within CPanel. This is important when working on sites because you want to make sure that you have secure enough permissions set up for your account so that your account's secure. Not everybody can execute a command on this particular file or even in the folder, but also enough that the site isn't only viewable to the owner of the account, which is yourself. So typically within CPanel itself, files should be at a 0644 permission. There's two groups within file permissions themselves. There's the owner and then others, which are visitors to the site and that sort of thing. So within the 0644 permissions, the owner can read, write and execute the file itself and others can read and write, which means that they can visit the site and they can either post comments or anything like that on the site itself, but they can't execute any commands or create additional files within the folder. And folders themselves should be 0755, which means that the owner themselves can read, write and execute as well, and the others can read and execute. So that means loading images, themes, and that sort of thing. Recently, we did change the WPconfig file for a more strict permissions on the site itself under 0400, which means that the owner is the only one that can execute the permissions itself. So similar to 644, it just has a little bit more a little bit stricter permissions on the file itself. This way, like the limit login attempt, we can limit brute force attacks and that sort of thing. So if you are working with a caching plugin in particular, a lot of times this plugin like that will need to write to the WPconfig file. So you can temporarily change the permissions to 0644 if needed. That's definitely recommended. And then make sure to switch it back to 0400 to make sure that everything's secure. We do have a script on the server that does automatically check for this permission across the board. So if it's not changed, not a big deal, it will get changed back to 0400, but make sure to switch it on your end as well. And then you want to switch it to 0644, do the installation of the caching plugin, and then change it back just that way like nothing is overwritten on that side. We'll see that a lot with Supercache or WP Rocket as well on that side, for sure. A lot of times we've seen FTP clients running into issues with file permissions themselves. They like to have their own specific default setups. So the screenshot on the right is FileZilla and how to change the particular permissions within the FTP client itself. So you want to make sure to set those 0644 and 0755 permissions unless specifically told otherwise for like a particular application. And those are typically documented within their setup pages and all of that good stuff. If the site isn't loading, you want to make sure to check those permissions as well. Also the errors section in cPanel will let you know if there's a file permission error. It will say something like client denied by server configuration on index.php or something like that. It'll definitely let you know like a particularly client denied by server configuration side leads to a file permissions. And it can be kind of daunting to have to go through and individually change file permissions on that side for each folder and then subsequently each file within your account. So as administrators, we set up a file permissions script. I did not include the command itself, but I'll walk through the process and put the command in Discord as well. You want to log into your root server through SSH and then it's sh.fixperms.sh-a and then the cPanel username. So you want to copy and paste that into it. Dash a signifies that you want to make changes to a particular account. And then once you run the commands, it'll go through each folder of the account and then change permissions accordingly as needed. And you can make these changes because the account is the owner of the files, so you won't run into any issues on that side. But if you do, let us know and we can always troubleshoot on that side for sure. So file permissions are always a good thing to look at when you're initially troubleshooting as well. I go through the error logs and then into file permissions if needed. So those two in tandem are typically the most common issues when loading sites. So it's always helpful to know those for sure. Yeah. And I mean, just from my experience as well, the issue has been file permissions even when I have looked at the file permissions and not seen anything out of the ordinary. And then I just think, you know what, I'm just going to run the script. It doesn't hurt. And then boop, everything's back. So it's like permissions, it's always permissions. Yeah, it's not always permissions, but it's not a bad thing to try if that's all else is failing. Yeah, for sure. I always joke, it's either permissions or permalinks and Christian or infrastructure team will always say it's always permalinks on that side. So all right. Yeah. And the last thing we wanted to kind of touch on today is this idea of subdomains versus subdirectories or subfolders. These can be kind of confusing for people. So we wanted to kind of break it down a little bit and also help you understand what issues can pop up when you are working with one of these versus the other and in what scenarios you would want to rely on a subdomain versus a subfolder. So for subdirectories or subfolders, these are essentially multiple sites that are under one parent directory. So that's where you're seeing the domain name slash blog. And some of you may have noticed that when you go to install a WordPress application, installatron likes to just add blog to that optional directory field. And so you have to remember to take that out if you just want something that is installed right on the parent directory. But that is a perfect example of that's, you know, how you would create a sub directory is through an on that field in installatron. You can do it in installatron, but you can also do it from the file manager by just creating a folder within the public HTML folder. So the, you know, we caution people when it comes to working with subdirectories because there can be permalink errors that occur because of this. Anywhere that you're using a different application that is built off of your parent, your primary domain, you're going to probably want to lean towards subdomains rather than subdirectories. Anything that relies on HT access rules should certainly be in a subdomain. And I feel that subdomains kind of result in better organization than subdirectories. Sometimes you can run into some, you can really confuse your site by having a sub directory, depending on what it's named. And then while you're, you know, working in the main site, those subdirectories can be created off of the main site and then conflict with maybe a sub directory that you're creating manually, it can get very confusing. And so you just want to consider that when working there. But something that is, you know, a great scenario for this could be working with WordPress multisite. That might be somewhere where you want to work with subdirectories rather than subdomains so that everything is, you know, clearly branching off of that main WordPress multisite landing homepage. And it could work very well for that. And another great benefit to subdirectories is how easy they are to set up. So, like I was saying, in Installatron in particular, you can just install an application without having to do anything ahead of time. You would just install the application and set up the sub directory while you're installing it. Subdomains, on the other hand, are take a little bit more planning. So you would have to actually set up the subdomain either in the file manager or from Cpanel in the subdomain section ahead of time before installing an application to it. It really makes sites organized because these folders exist outside of that public HTML folder, which prevents these permalink errors from happening that we were discussing. And it really helps you isolate any additional errors to a specific site rather than getting things mixed up with that parent site because it really does live separately. Absolutely. And it's important to note that the hdxs file is hierarchical. I can't ever say that word, but it's hierarchical in the sense that the parent directory takes over if there's something wrong. So a lot of times if you're working with, like, say WordPress and you have a page like a portfolio page, but then you have a static HTML site under the portfolio folder, the WordPress hdxs is going to take over and try to load that page in particular. So then when you go to the portfolio folder on the static site, you may run into some of those permalink errors and permissions on that side, for sure. So we're going to wrap up here. I've got a couple of resources, troubleshooting WordPress errors. Common, we have a guide that compiles a lot of the common WordPress errors that we see, particularly file permissions and changing the default file permissions through your FTP client. And then subdomains versus subdirectories, which kind of dives in into more detail on the difference between the two. And then some final thoughts on that side. Once you understand where the errors are reported within error logging, you can start to easily disable plugins and themes and really kind of understand, like, how the inner workings of the application starts to work. 0644 and 0755 are your friends within file permissions, except when you're working in the WP config file, which are going to be 0400. So definitely make sure of those and that fixed permission script and subdomains over subdirectories typically with applications that rely on an hdxs file helps you organize the account and isolates any other potential issues to the particular site itself, rather than through the directories themselves. So, all right. Well, thank you so much for joining the session on advanced site troubleshooting. And let us know any questions and discord and we'll keep chatting throughout the day. See you everyone.