I put in a workaround where I run this inbetween site up/down for the one I wanted to test:
rm /tmp/mysql.sock
ln ~/Library/Application\ Support/Local/run/SITEIDHERE/mysql/mysqld.sock /tmp/mysql.sock
I do the remove part because after restarting a site or Local, the sock has to be reset again.
I’ve published 1.0.1 after testing the reset site option so it now reinstalls WP properly so the DB is fresh and clean.
Is there anything left to do to be listed officially on https://localwp.com/add-ons/ and in the App?
Hey @sc0ttkclark – Thanks for submitting the addon! I still need to take this for a spin, but I should be able to take a look and get back to you tomorrow!
Hey @sc0ttkclark – Thanks for your patience with this!
A couple of things I noticed when trying to QA this:
Local needs a tgz file in order to be installed from disk, but the releases page only has a zip. I think you should be able to build one with npm pack.
For reference, this is applicable for when a user tries clicking the “Install from Disk” button:
I was never able to get the actual reset screen (“More > Reset”) screen to show. More specifically, the “More” menu item is missing within Local for me. This was in Local 5.7.4, under macOS Catalina, and I deactivated all other addons. What version are you developing in?
I might be doing something wrong, so I’d love it if others can confirm that they are getting it working!
Can you try building a tgz file so that I can try manually installing the build?
Updated the release with tgz file: https://github.com/moderntribe/local-reset-site-addon/releases/download/1.0.3/local-reset-site-addon-1.0.3.tgz
You’re right, when I load up and use the tgz, it doesn’t show the more menu. Do you know what would cause that? I’m in Local 5.7.4+4876 + Catalina
I’m not sure what’s up there, it runs fine from the add-on directory I run the build process from.
I tried installing from that tgz file and that appears to load within the UI correctly (ie on the addon’s page) but the menu is still missing.
Taking a look at my Local log, I see this mentioned:
"thread": "renderer",
"class": "RendererAddonLoader",
"stack": "Error: Cannot find module 'lodash'\nRequire stack:\n- %%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js\n- %%userDataPath%%/addons/local-reset-site-addon/lib/Boilerplate.js\n- %%userDataPath%%/addons/local-reset-site-addon/lib/renderer.js\n- %%appPath%%/renderer/_browserWindows/app/app.html\n at Module._resolveFilename (internal/modules/cjs/loader.js:717:15)\n at Function../lib/common/reset-search-paths.ts.Module._resolveFilename (electron/js2c/renderer_init.js:930:16)\n at Function.n._resolveFilename (file://%%appPath%%/renderer/_browserWindows/app/app.js:2:316268)\n at Module._load (internal/modules/cjs/loader.js:622:27)\n at Module._load (electron/js2c/asar.js:717:26)\n at Function.Module._load (electron/js2c/asar.js:717:26)\n at Module.require (internal/modules/cjs/loader.js:775:19)\n at require (internal/modules/cjs/helpers.js:68:18)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:117372)\n at r (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:279)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:117190)\n at r (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:279)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:114301)\n at r (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:279)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:32431)\n at r (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:279)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:26862)\n at r (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:279)\n at %%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:1078\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:1:1088)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/node_modules/@getflywheel/local-components/dist/index.js:3:3)\n at Module._compile (internal/modules/cjs/loader.js:880:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:892:10)\n at Module.load (internal/modules/cjs/loader.js:735:32)\n at Module._load (internal/modules/cjs/loader.js:648:12)\n at Module._load (electron/js2c/asar.js:717:26)\n at Function.Module._load (electron/js2c/asar.js:717:26)\n at Module.require (internal/modules/cjs/loader.js:775:19)\n at require (internal/modules/cjs/helpers.js:68:18)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/lib/Boilerplate.js:14:28)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/lib/Boilerplate.js:137:3)\n at Module._compile (internal/modules/cjs/loader.js:880:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:892:10)\n at Module.load (internal/modules/cjs/loader.js:735:32)\n at Module._load (internal/modules/cjs/loader.js:648:12)\n at Module._load (electron/js2c/asar.js:717:26)\n at Function.Module._load (electron/js2c/asar.js:717:26)\n at Module.require (internal/modules/cjs/loader.js:775:19)\n at require (internal/modules/cjs/helpers.js:68:18)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/lib/renderer.js:6:39)\n at Object.<anonymous> (%%userDataPath%%/addons/local-reset-site-addon/lib/renderer.js:28:3)\n at Module._compile (internal/modules/cjs/loader.js:880:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:892:10)\n at Module.load (internal/modules/cjs/loader.js:735:32)\n at Module._load (internal/modules/cjs/loader.js:648:12)\n at Module._load (electron/js2c/asar.js:717:26)\n at Function.Module._load (electron/js2c/asar.js:717:26)\n at Module.require (internal/modules/cjs/loader.js:775:19)\n at require (internal/modules/cjs/helpers.js:68:18)\n at t.default.loadAddon (file://%%appPath%%/renderer/_browserWindows/app/app.js:13:73909)",
"level": "error",
"message": "Error Loading Add-on: %%userDataPath%%/addons/local-reset-site-addon/lib/renderer.js",
"timestamp": "2020-09-18T21:05:39.873Z"
}
Do you have lodash installed globally on your system? Maybe it needs to be declared in the package.json?
I added it to package.json and I still get that same error, so I’m not sure what’s up in the packed version of the add-on. I’ll continue messing with this over the weekend to see what might be causing that.
FYI I literally used the Local Addon Boilerplate for this addon, I don’t believe I’ve added anything unique to the package itself so that’s why I wasn’t expecting to see that problem.
I just set up the boilerplate addon itself and packaged that the same way. Same problem, it’s hitting the same issues as mine (since mine is based on that).
Are there issues with the Boilerplate add-on that have not been fixed yet?
To move forward, I followed some of what the Local TablePlus Addon developer had to do in order to get their packaging to work properly since the boilerplate has issues.
There’s now a 1.0.4 package that I verified works as expected.
Latest package: https://github.com/moderntribe/local-reset-site-addon/releases/download/1.0.4/local-reset-site-addon-1.0.4.tgz
Thanks for digging into this!
I was able to install that package as well as get things installed and working from the latest version.
What I think happened is that there was a bug introduced into the local-components repo after you first created the “Reset Site” addon and when I went to do some QA. The Local team has since pushed a fix to local-components which is why you were able build it again.
The “Empty Site” button works great, but I keep running into issues with the “Reset Site” button. It seems like the wp db reset command isn’t working for me – is everything working on your end?
Just to clarify, I’m not 100% sure this is a bug with this addon’s code. It feels like there might be something with Local’s connection to the DB, or possibly something within wp-cli. I just wanted to make sure things were working for you so that I could zero in on anything specific to my computer.
This is definitely that Local issue with WP-CLI and the socket connection. If I run this locally (change the path to the path of the site ID), it resolves the problem with Local at least on that site and until the site is stopped.
rm /tmp/mysql.sock; ln /Users/sc0ttkclark/Library/Application\ Support/Local/run/ROSiprrEq/mysql/mysqld.sock /tmp/mysql.sock
Works great otherwise, I wish there was a better solution for the socket issue in Local right now, but it does look entirely unrelated to the addon itself as it’s doing what it should be doing.
There’s definitely something funky with the /tmp/mysql.sock issue.
Some commands do work, which makes me think that there’s a bug in wpcli. For example, I can’t use the wp db reset command that this addon uses, but I can use wpcli’s query command to drop that database:
wp db reset # doesn't work without the above symlink to the MySQL socket
wp db query 'DROP DATABASE IF EXISTS `local`;' # works, is same SQL command that `wp db reset` _should_ be running.
I know that we had to submit some upstream fixes for some of the db commands to work, but maybe we’re running into additional wpcli commands that aren’t respecting the MySQL config that Local is injecting?
That sounds correct to assume here, I myself thought there were still WP-CLI DB issues with Local’s socket setup that should be looked at on the Local side. I had seen this same kind of error message on other DB commands before. I do agree that it seems to be fixed a bit further, this is one of the ones that doesn’t look to be working without further intervention on Local’s side.
As that’s the case, it sounds like we need to hold on pushing this add-on to the directory until that’s solved to prevent confusion about that Local / WP-CLI bug. I’d rather not introduce a series of CLI commands that replicate wp db reset as the solution here.
That sounds like a plan!
I did some more digging on this with the intent to push the convo to a solution in upstream wpcli. Basically it looks like the wp db subcommands need to implement the --defaults global flag for them to work.
The wpcli config.yml file that Local uses, introduces those flags for the subcommands that are supported, but something like wp db reset doesn’t allow that global flag. Here’s a screenshot that I hope helps illustrate the issue:
I’m not as familiar with the wpcli codebase, but if you’d like to ping anyone you know to join this convo and help get the ball rolling with submitting an issue/pull request to upstream wpcli, I can definitely help get things wired up on the Local side!
I think all we’d need to do is submit a PR for the file https://github.com/wp-cli/db-command/blob/master/src/DB_Command.php#L121 and add the --defaults argument as accepted for it so it will pass it through properly. But I can’t verify this because I can’t figure out how to test that locally. So I don’t know if that solution will work or if there’s somewhere else that needs to be modified instead or in addition to that.
Now that WPCLI is getting back into active dev (there were issues with the automated testing infrastructure), Alain has taken a first crack at refactoring those db subcommands:
I’m squeezing in QA when I can, but if anyone in this thread can follow the above issue and keep the work moving forward that would awesome and allow us to get the “Reset Site” add-on into the add-on library!
Looks like this is finally resolved and working as of WP-CLI 2.6.0
I’ll get to updating the add-on at some point soon so that it passes --defaults correctly to the command.
