I did, until one day, I needed to get into the weeds on a project, and I figured I’d try and set up debugging in hopes of making my life easier. I was delighted to find out how easy it was! In this post, I’ll demonstrate how to debug a React project using VS Code and Chrome.

To demonstrate how to set things up, I’m going to use Vite and React to set up a React project. You’ll need to have VS Code and NPM installed.

Set Up a Workspace in VS Code

First, create a directory for our workspace. Then Open the directory in VS Code. Save the workspace.

I used D:devtrainingdebugging-react.

Create a React Starter Project Using Vite

From VS Code, open up this location in the integrated terminal and run the following command to create a starter project: npm create vite@latest

Follow the prompt from Vite. Give the project a name (I used vite-demo ). Select React for the framework and JavaScript for the variant.

Once that’s all set, change directories into the project folder that you assigned, run npm install.

Once the installation is complete, start Vite by running npm run dev.

We can see that our project is running on localhost, port 5173. A browser window will be opened with the project:

Create and Configure a launch.json File in VS Code

Now we need to create a launch.json file. Click the Debug icon (1), then create a launch.json file (2). The launch.json file will be located in your workspace’s .vscode directory.

Select the location:

Select Chrome for the debugging type:

This will open the launch.json file in a tab. (1) Set the port to whatever was specified by Vite earlier (5173 by default), and (2) add the subdirectory your project is into the webRoot option if you have your project in a subdirectory like I do here (/vite-demo).

Add a Breakpoint to the Code

Now open up your project’s src/App.jsxfile (1) and (2) add a breakpoint to line 20. We’re going to debug the count variable.

Start Debugging Your React Project!

OK, we’re getting close! Now click the Start button to start debugging. This will launch our app in a new Chrome window.

The app is paused for debugging.

A debugging session is now active in VS Code. We can use the debugging control bar to step through and inspect the code.

We can interact with the app and see the value of the counter increase after clicking the count button.

Here’s a quick screen capture showing this in action:

One thing to note is that, by default, React.StrictMode is enabled in dev mode, so your app will be run twice. See the docs for details on Strict Mode.

That’s all there is to setting up basic React debugging in VS Code and Chrome. I hope this helps you to more efficiently debug your React projects.

Are you struggling with WordPress security? Our free guide teaches you everything you need to know to protect your site. Download and read our “Guide to WordPress Security” to safeguard your website.

The post Debugging React with VS Code and Chrome appeared first on WebDevStudios.

Getting things set up correctly can be tricky. That’s where this tutorial helps.

Xdebug

Xdebug is a powerful tool for debugging PHP applications. It conveniently comes bundled with Local.

We’re using VS Code for our code editor in this tutorial, as well as some other tools I’ve listed below. Everything included here is the current release and version numbers are noted just in case it might be helpful since things change.

Prerequisites

• Local v6.4.2+6012: A local WordPress development environment, formally known as Local by Flywheel
  • • PHP v7.4.1/v7.3.5/v8.0: Selectable via the Local UI. Choose v7.4.1 or v 7.3.5 for now because PHP 8 has a different Xdebug setup we’ll cover at the end of the article.
• VS Code v1.70.2: Code editor
• PHP Debug by Xdebug for VS code v1.27.0: VS Code extension which allows VS Code to talk to Xdebug
• Xdebug Helper browser extension: Used for explicitly enabling or disabling debugging sessions
  • Chrome
  • Firefox

I use Windows because that’s what makes me happy, but this guide applies to other environments as well. I just wanted to note that, since the paths I’ll be referencing are Windows-y.

Create a Site in Local

Once all of the prerequisites have been installed and activated, you’ll need to create a new WP site in Local if you don’t have one already. When PHP Versions 7.3.x or 7.4.x are selected in Local, Xdebug Version 2 is used.

When PHP Version 8 is selected, Xdebug Version 3 is used. We’re going to use PHP Version 7.4.1 to start off with and will cover PHP Version 8 at the end of the article.

I’ve named my site xdebugvscode.test. Here are its settings:

Set Up php.ini.hbs Directives

Now that the site has been created, let’s double-check the Xdebug configuration directives in the site’s php.ini.hbs file. This file is located under your site’s conf/php directory.

For me, the path is D:devlocal-sitesxdebugvscodeconfphpphp.ini.hbs. Scroll to the bottom of the file under the [xdebug] section, and verify that you have the directives below set accordingly. If you need to make any changes, be sure to restart your Local site.

; Enable remote debugging.
xdebug.remote_enable=1

; If enabled, the xdebug.remote_host setting is ignored and
; Xdebug will try to connect to the client that made the HTTP request.
; It checks the $_SERVER['HTTP_X_FORWARDED_FOR'] and $_SERVER['REMOTE_ADDR'] variables to find out remote IP
xdebug.remote_connect_back=Off

; Set the port that Xdebug connects to.
xdebug.remote_port="9000"

; Disable the profiler.
xdebug.profiler_enable=0

; Set the profiler's output directory for when we're profiling.
xdebug.profiler_output_dir = "D:/dev/xdebug-profiler-output"

A Note About the php.ini.hbs File When Switching PHP Versions

If you ever change the PHP version for your Local site, Local will save the settings for the previous install of PHP under the {local-site-dir}/conf/php/php-{version-number}directory.

For example, I started out with PHP Version 7.4.1 installed, then switched to PHP Version 7.3.5. Local made a copy of my PHP Version 7.4.1 settings under D:devlocal-sitesxdebugvscodeconfphp-7.4.1.

If you change PHP versions and made any modifications to Local’s php.ini.hbs file, you’ll need to make the changes again, if this is the first time the PHP version has been activated. After that, if you swap between PHP versions, your setting changes will be preserved.

Ensure Xdebug Is Running

To make sure that Xdebug is running, create a file named pi.php in the root of your site and add the following code to it:

<?php
// Output information about PHP's configuration.
phpinfo();

Activate Xdebug Helper Browser Extension

Once you’ve installed and activated the Xdebug Helper extension for your preferred browser, make sure to enable debugging by clicking on the icon and selecting Debug. The little bug icon will turn green letting you know that the browser extension will set the appropriate flag to turn on debugging.

Open Local Site in VS Code and Save a Workspace

Once the site has been created, go to File > Open Folder in VS Code, then navigate to the site’s directory. Now, save the workspace by going to File > Save Workspace As… and then give the workspace a name.

Install and Activate PHP Debug Extension for VS Code

The PHP Debug extension for VS Code helps to bring everything together. Locate the extension in VS Code’s Extension Browser, and activate it. Make sure to select the one published by the Xdebug team, since there are a few extensions with the same name.

Create a launch.json File for Your Workspace

Next, we will create a launch.json file for our workspace. Click on VS Code’s debugging icon to open the debugging panel, then click on the create a launch.json file link.

Now select the name of your workspace which you created earlier.

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9000,
      "log": false,
      "maxConnections": 1, // @see  https://github.com/xdebug/vscode-php-debug/issues/604
      "xdebugSettings": {
        "resolved_breakpoints": "0", // @see https://github.com/xdebug/vscode-php-debug/issues/629 and https://stackoverflow.com/a/69925257/3059883
        "max_data": 512,
        "show_hidden": 1,
        "max_children": 128
      }
    }
  ]
}

Add a Breakpoint to Your Code

For the purposes of this debugging WordPress demo, I’m going to add a breakpoint to line 48 of  Twenty Twenty-Two’s functions.php file.

To add a breakpoint, hover over the gutter (just to the left of a line number) and a little orange dot will appear. Click it to add a breakpoint.

Click it again to remove it. You can add multiple breakpoints, and the debugger will stop on each one. To keep things simple here, I’ll just add the one.

Once your breakpoint has been added, you will see it listed in the lower left-hand corner of  VS Code’s debugger panel. It’s also possible to set breakpoints on Notices, Warnings, Errors, etc., but we’ll uncheck all of those for this example.

Start Debugging WordPress

We’re finally ready to start debugging WordPress! Open VS Code’s debugger panel and click the green triangle to start listening for Xdebug. Use the F5 shortcut.

Once VS Code is listening for Xdebug, the Debugger Controls window will be displayed. The bottom of the VS Code window will turn orange.

Now Xdebug is waiting to start the session. To kick things off, just load a page that will hit the breakpoint.

I’m just going to load the homepage of the test site I created. Once I hit refresh on the homepage of the test site, VS Code will be highlighted in the taskbar and the debugger will stop executing code on the breakpoint that I had previously set.

Once a debugging session has started, additional controls will be active on the Debugger Control Panel, and variables will be listed under the VARIABLES section of the Debugging Panel.

We can now use the Debugger Controls to navigate through the codebase:

Debugger Controls

• Pause/Run (F6): Resumes code execution. Debugger will stop on the next breakpoint if set.
• Step Over (F10): Steps over a block of code.
• Step Into (F11): Steps into a block of code.
• Step Out (Shift + F11): Steps out of a block of code that was previously stepped into.
• Restart (Ctrl + Shift + F5): Restarts the debugging session.
• Stop (Shift+F5): Halts execution of the script.

The GIF at the top of this article demonstrates some basic usage of these controls.

Exploring Variables

We can also explore the values of local and global variables using the VS Code’s VARIABLES section within the Debugging Panel.

PHP Version 8 + Xdebug Version 3 Set Up

When a Local site is configured to use PHP Version 8.X, the bundled version of Xdebug will be Version 3, and there are many changes from Versions 2 to 3.

These changes are covered thoroughly in this guide. Notably, Xdebug Version 3 defaults to port 9003 instead of 9000. I’m going to switch my Xdebug Version 3 setup to use port 9000 for consistency, so I don’t have to change anything in my launch.json file.

Here are the Xdebug directives in my PHP Version 8 site’s php.ini.hbs file. Note that I’ve commented out the line xdebug.start_with_request.

xdebug.mode=debug
xdebug.client_port="9000"
; xdebug.start_with_request=yes
xdebug.discover_client_host=yes

<?php
xdebug_info();

Troubleshooting

One common issue that comes up when you’re debugging WordPress is that the debugger does not stop on the breakpoint that you’ve set. This is typically caused by a port conflict—some other process is already using the port that you’ve configured for debugging.

Make sure that no other application is using the port that was configured in the php.ini.hbs and launch.json file. If an application is already using the port you’ve specified, make sure to change your port to something that’s not in use.

To check for a port conflict, end your debugging session in VS Code then run the following command:

Windows CMD: netstat -an | find "9000"

Linux/Mac: sudo netstat -nap | grep ":9000"

You should not see any output after entering these commands. If you do, that means that a process is already using the port you’ve configured for Xdebug (9000) in our example. So you should either configure a different port in your php.ini.hbs and launch.json files, or locate the process that is tying up the port, and stop it/configure it to use a different port.

Bonus: Quick and Dirty Debugging

Sometimes, instead of using Xdebug, I prefer to simply log variables to WP’s error.log file using PHP’s error_log().

I find this handy for real quick stuff, though it’s really not the best way to debug WordPress when things get serious. For this setup, first, add the following statements to your site’s wp-config.php file:

define( 'WP_DEBUG', true ); // Debugging mode activated.
define( 'WP_DEBUG_LOG', true ); // Logs to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Don't add errors to the output.
define( 'SCRIPT_DEBUG', true ); // Load un-minified scripts.

Now, errors will be logged to your site’s wp-content/debug.log file. I typically keep this file open in a side panel of VS Code.

I usually use this one-liner to output values to the debug.log file:  error_log( '$variable_name ' . var_export( $variable_name, true ) );

To make things easier, I trigger this one-liner using a VS Code User Snippet with the trigger logv. Here’s a copy of the debugging-related snippets I use. These are configured in VS Code under File > Preferences >  Configure User Snippets > PHP.

{
// Place your snippets for php here. Each snippet is defined under a snippet name and has a prefix, body and
// description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
// $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
// same ids are connected.
// Example:
// "Print to console": {
// "prefix": "log",
// "body": [
// "console.log('$1');",
// "$2"
// ],
// "description": "Log output to console"
// }
"Log var_export()": {
"prefix": "logv",
"body": ["error_log( '$1 ' . var_export( $2, true ) );"],
"description": "Do a var_export( $variable ) to PHP error log."
},
"Log print_r()": {
"prefix": "logp",
"body": ["error_log( print_r( $0, true ) );"],
"description": "Do a print_r( $variable ) to PHP error log."
},
"Exit with var_dump()": {
"prefix": "xvd",
"body": ["exit( var_dump( $0 ) );"],
"description": "Exit with var_dump()"
},
"Exit with print_r()": {
"prefix": "xpr",
"body": ["exit( print_r( $0 ) );"],
"description": "Exit with print_r()"
},
"Detailed Error Log": {
"prefix": "logd",
"body": [
"error_log( print_r( (object)",
"t[",
"tt'line' => __LINE__,",
"tt'file' => __FILE__,",
"tt'dump' => [",
"ttt$0,",
"tt],",
"t], true ) );"
],
"description": "Detailed error logging"
},
"Log gettype()": {
"prefix": "logt",
"body": ["error_log( gettype( $0 ) );"],
"description": "Do a gettype( $variable ) to PHP error log."
},
"Debug Filters": {
"prefix": "logf",
"body": ["add_action( 'all', function() { error_log( var_export( current_filter(), true ) ); } );"],
"description": "Logs current filter."
}
}

Conclusion

That’s about it for this post on debugging WordPress using Xdebug, Local, and VS Code. Using Xdebug, you’ll be able to more efficiently and effectively debug code. If you’ve never used it before, I’m sure you will find that Xdebug is a helpful tool in your development arsenal.

The post Debugging WordPress Using Xdebug, Local, and VS Code appeared first on WebDevStudios.

Job Title: Backend Engineer

Years at WebDevStudios: 2.25

I’ve always been a big fan of WebDevStudios (WDS). I can’t remember precisely what drew me in, but WDS always seemed to make good choices about WordPress development practices.

When trying to stay on top of WordPress happenings, something related to WDS would always be part of the conversation, whether it was wd_s, CMB2, the podcasts, or informative blog posts. I adopted a “what would WDS do?” approach to problem solving, which yielded great results. Oh yeah, WDS’ 100% remote thing greatly appealed to me too.

Years later, after long commutes to do agency work, then dabbling in freelance, an opportunity to work for WDS presented itself. I applied, and went through a paid engineering trial, which re-enforced my opinion that that these folks were _doing_it_right().

I passed the trial, which was a great and challenging experience in and of itself, and officially became a Backend Engineer (BEE) at WebDevStudios.

A Typical Day

A typical day involves thinking about solutions and creating tickets, writing/testing/reviewing/discussing/documenting/and deploying code, as well as some other odds and ends sprinkled in. That’s probably not much of a surprise to anyone. I’ll go over things in a little more detail below.

First Things First: Getting Ramped Up for the Day

Each day, I go through a little routine to get myself set up for the day’s tasks. The process looks something like this:

• Check email and Jira tickets for updates and send responses to keep conversations flowing.
• Review Google calendar to see what meetings are scheduled for the day.
• Check Harvest Forecast to see what projects I’m assigned to. (We track time using Harvest. It integrates well with Jira and web browsers via an extension, which makes tracking time a cinch.)
• Slack conversations
• Give birthday/anniversary tacos: We use HeyTaco, a great extension for Slack that allows us to give virtual tacos to coworkers for achievements or for other recognition. Everyone has five tacos a day to give out. We typically give out tacos for birthdays and anniversaries, which we are reminded about via a Slack bot.
• Team standup: We typically have a quick team standup to discuss what we’ll be working on for the day and discuss any blockers.

The Bulk of the Day

It’s no surprise that most of my day as a backend engineer is spent writing code. Everything we work on is tied to a specific ticket in Jira, which is great.

Work on Tickets

• Jira/Slack: We use Jira to track ticket progress and communicate with clients and a dedicated Slack channels for project-specific discussions.
• Github/Bitbucket: All of our code is maintained under version control and each ticket has its own branch. We use a naming convention that makes it easy to associate branches with tickets and also allows for better integration with Slack.
• Write code: Personally, I use VS Code (tricked out with a bunch of extensions). VS Code is a well supported, cross-platform editor. At WDS, developers are free to use whatever tool they want to get the job done. VS Code, PHP Storm, Sublime—use whatever makes you happy. That goes for operating systems too. By the way, we have a Slack channel called #cool-tools where we share links to utilities that help us to be better engineers.
• Implementing features/enhancements/bug fixes: Most of my time is spent writing code to fulfill the requirements outlined in the associated Jira ticket. All of the code we write must pass WordPress Coding Standards and linting.
• Deployments: For the most part, sites have development, staging, and production environments. For local development, we use Local or Docker, depending on the project. Each environment has its own deployment pipeline using Buddy. PRs to staging and production require peer review.

Odds and Ends

• Slack chats: We have numerous channels to discuss various topics. Each project has its own channel. We also have a general channel to let everybody know when you’ve arrived and when you’re leaving, and for general announcements. There are also plenty of channels for discussing hobbies and non-work related topics.
• Zoom meetings to discuss tasks: Sometimes, particularly with more complex tasks, it’s beneficial to get together with another developer to plan out solutions. Even though WDS is 100% remote, I don’t ever feel isolated.

Regularly Scheduled Meetings and Scrums

There are a variety of regularly scheduled scrums that we attend over Zoom. Here’s a breakdown:

• Client calls: With some clients, particularly on larger projects, we will meet regularly to discuss tasks and priorities. I keep it professional, while also letting a bit of my free-spirited personality shine through.
• Weekly BEE scrum: This scrum is for BEEs only (frontend engineers [FEEs] also have their own dedicated scrum). We discuss everything backend here, with some banter sprinkled in for good measure. During our BEE scrum, we’ll cover topics and links that were mentioned in Slack throughout the week. One of the most exciting reoccurring segments is our “Let’s get pedantic” discussion where we talk about exhilarating topics such as whitespace, project file structures, and so forth. There also might be a shoutout or two for TablePlus, and I might sneak in a review of Taco Bell’s current Limited Time Offer (LTO).
• Weekly FEEBEE scrum: Here, the FEEs and BEEs get together to discuss React and Gutenberg related things. There’s almost always a demo of some kind.
• Monthly engineering scrum: Here, we discuss any changes or updates to the engineering process. There may be a demo of new tech.
• Weekly company scrum: Each week the whole company gets together each Friday over Zoom to discuss company achievements and announcements, new work prospects, and social media happenings. We also have an opportunity to give out “real world tacos”, which are basically shout-outs to individuals who went above and beyond during the week. We typically end the company scrum with a Team building exercise.

Maintaining a Balance

Another thing I like about working at WDS is the balance of time spent on meetings vs coding. I rarely ever feel like I’m stuck in meetings all day or that I’ve been staring at code all day and haven’t talked to anyone. I don’t take this for granted.

Wrapping the Day Up

EOD updates: Each day, engineers will post an end-of-day update to the project channels that they are assigned to, outlining what they did that day for each ticket. This gives everybody a birds eye view of what’s going on, and helps to prime the pumps for the following day’s standup.

Before signing out of Slack, I try to send out any remaining tacos I have for the day.

Me Time

Work/life balance is great at WDS. Once I get my time in for the day, I know that I can switch over to my personal life. This helps me to be the best backend engineer I can be.

I’m always up to something, though it changes frequently. Here are some activities and hobbies that are currently or routinely part of my day:

• Bike rides: I live very close to a bike trail and I thoroughly enjoy going on bike rides. It’s super refreshing to my mind and body. During the colder months, which are plentiful here, I put my bike on a stationary trainer. This isn’t nearly as fun or mentally stimulating as riding outside, so I listen to music (like my awesome 80’s playlist on Spotify) and play Tetris while riding the stationary bike.
• Exercise: Sitting all day does take its toll, so I try and get some light exercise in. Also, I go hard in the paint when it comes to fast food on the weekends, so I try and work some of that off.
• Bug photography: I enjoy taking macro photographs of tiny creatures.
• Carbonating water: I gave up pop years ago but I do love the zing of a carbonated beverage. I’ve mastered the art of making the moist painful bubble water possible.
• LEDs: I love good lighting! Incandescent bulbs on dimmers are my go-tos for general lighting, but I do enjoy some RGB for accents. I’ve recently started using WLED on a QuinLED-Dig-Uno (ESP 32). Now I want to put LEDs on everything!

That’s about it. Thank you for reading about how I spend my day at WebDevStudios! We’re hiring backend engineers right now. Take a look at the job description and apply today.

The post WebDevStudios Day in the Life of a Backend Engineer appeared first on WebDevStudios.

Here’s my setup. These issues could appear on any platform, though.

• OS: Windows 10 Pro
• Local web stack: Local Lightning v5.90
• Database client: MySQL Workbench v8.0.22

Issue 1: MySQL database export error due to client/server version mismatch

The first error I ran into when trying to export a DB was:

Unknown table 'column_statistics' in information_schema (1109)

TL;DR: Make sure that the version of mysqldump that your MySQL client (MySQL Workbench in my case) points to is the same as the DB version as what is used by the server. (You know, like the warning message suggests when you try and do otherwise.) Use MySQL v5.7 or v8 when setting up a site in Local by Flywheel rather than using Maria DB.

My Local setup was configured to use MariaDB v10.4.10. When setting the site up in MySQL Workbench (my preferred MySQL client), I was presented with the following warning when testing the connection:

I made a mental note of the warning, but decided to proceed anyway. I didn’t have any problems running queries, so I didn’t think about it again.

To export a DB using MySQL Workbench, connect to a DB server, then navigate to Server > Data Export.

When attempting the export, a dialogue showing the following warning indicating a version mismatch was displayed:

The export was not successful. Here’s the full log of the error:

11:52:38 Dumping local (all tables)
Running: mysqldump.exe --defaults-file="c:usersuser1appdatalocaltemptmpnkltww.cnf" --user=root --host=127.0.0.1 --protocol=tcp --port=10142 --default-character-set=utf8 --skip-triggers "local"
mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'local' AND TABLE_NAME = 'wp_commentmeta';': Unknown table 'column_statistics' in information_schema (1109)
Operation failed with exitcode 2
11:52:38 Export of D:devlocal-sitesmysqlexporttestmariadbmysqlexporttestmariadb-2020-11-16.sql has finished with 1 errors

Issue 1, Solution 1

I did some Googling, and found this helpful post on ServerFault that explained a workaround for Windows/Mac/Linux.

The solution is to create a script that runs mysqldump with the flag --column-statistics=0, then configure Workbench to point to the script:

Windows

mysqldump_nostatistics.cmd

@ECHO OFF
"C:Program FilesMySQLMySQL Workbench 8.0 CEmysqldump.exe" %* --column-statistics=0

Mac/Linux

mysqldump_nostatistics.sh

#!/bin/sh
_mysqldump $@ --column-statistics=0

This allowed me to successfully create a an export of the DB, but the dialogue indicating a MySQL version mismatch was still displayed:

Issue 1, Solution 2

I followed the dialogue’s guidance and configured MySQL Workbench’s settings to point to the version of mysqldump provided with the MariaDB version used by Local.

Edit > Preferences > Administration > Path to mysqldump Tool:

C:Program Files (x86)LocalresourcesextraResourceslightning-servicesmariadb-10.4.10+4binwin32binmysqldump.exe

I then tried to export the DB again, and finally it worked without any errors and without needing to pass additional parameters to the client:

11:59:54 Dumping local (all tables)
Running: "C:Program Files (x86)LocalresourcesextraResourceslightning-servicesmariadb-10.4.10+4binwin32binmysqldump.exe" --defaults-file="c:usersuser1appdatalocaltemptmp_mjmqv.cnf" --user=root --host=127.0.0.1 --protocol=tcp --port=10142 --default-character-set=utf8 --skip-triggers "local"
11:59:55 Export of D:devlocal-sitesmysqlexporttestmariadbmysqlexporttestmariadb-2020-11-16.sql has finished

Issue 2: MySQL export fails due to user not having PROCESS privileges

The second error I encountered was when I tried to make a backup of a remote database. In this case, I was not using the root user. The error was:

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

The error would also happen when connecting via the WP CLI:

$ wp db export
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

When searching for a solution for this error, I found this comprehensive answer on the DBA StackExchange site, which explains that the issue crops up due to a security-related breaking change added to MySQL minor updates in v5.7.31 and v8.2.21.

This issue does not affect the root user because it has inherently has all privileges. To resolve the problem, log into the the MySQL server and grant the PROCESS privilege to the affected user:

GRANT PROCESS ON *.* TO someuser@localhost;
FLUSH PRIVILEGES;

After the above commands were run on the server, I could once again make backups, and I was out of this rabbit hole.

Don’t get stuck in your own rabbit hole. Use my recommended solutions, or contact our team to help dig you out of any holes or trenches where you’re currently trapped.

The post MySQL Database Export Errors and Solutions appeared first on WebDevStudios.