# Starting development on a Reset Site add-on

**URL:** <https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864>\
**Category:** Local Add-ons\
**Created:** [June 26, 2019, 3:39pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864 "2019-06-26T15:39:38Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 14, 2020, 10:26pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/21 "2020-09-14T22:26:52Z")

</div>

I put in a workaround where I run this inbetween site up/down for the one I wanted to test:

```auto
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.

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 16, 2020, 5:30pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/22 "2020-09-16T17:30:29Z")

</div>

Is there anything left to do to be listed officially on [https://localwp.com/add-ons/](https://localwp.com/add-ons/) and in the App?

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 16, 2020, 8:56pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/23 "2020-09-16T20:56:19Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 18, 2020, 7:47pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/24 "2020-09-18T19:47:04Z")

</div>

Hey @sc0ttkclark – Thanks for your patience with this!

A couple of things I noticed when trying to QA this:

1. 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`.

2. 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?

Can you try building a `tgz` file so that I can try manually installing the build?

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 18, 2020, 7:59pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/25 "2020-09-18T19:59:41Z")

</div>

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](https://github.com/moderntribe/local-reset-site-addon/releases/download/1.0.3/local-reset-site-addon-1.0.3.tgz)

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 18, 2020, 8:03pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/26 "2020-09-18T20:03:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 18, 2020, 9:08pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/27 "2020-09-18T21:08:24Z")

</div>

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:

```auto
  "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`?

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 18, 2020, 9:32pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/28 "2020-09-18T21:32:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 18, 2020, 9:32pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/29 "2020-09-18T21:32:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 19, 2020, 8:52pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/30 "2020-09-19T20:52:07Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 19, 2020, 9:32pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/31 "2020-09-19T21:32:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 19, 2020, 9:33pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/32 "2020-09-19T21:33:49Z")

</div>

Latest package: [https://github.com/moderntribe/local-reset-site-addon/releases/download/1.0.4/local-reset-site-addon-1.0.4.tgz](https://github.com/moderntribe/local-reset-site-addon/releases/download/1.0.4/local-reset-site-addon-1.0.4.tgz)

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 21, 2020, 4:01pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/33 "2020-09-21T16:01:06Z")

</div>

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?

 ![image](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/2X/c/c9bee899b194c6e88f153e247eaf2e7197384925.png)

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.

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 21, 2020, 4:14pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/34 "2020-09-21T16:14:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 21, 2020, 7:33pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/35 "2020-09-21T19:33:18Z")

</div>

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:

```auto
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?

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 21, 2020, 7:47pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/36 "2020-09-21T19:47:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [September 23, 2020, 5:31pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/37 "2020-09-23T17:31:26Z")

</div>

> [@sc0ttkclark](#):
>
> 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.

That sounds like a plan!

> [@sc0ttkclark](#):
>
> I’d rather not introduce a series of CLI commands that replicate `wp db reset` as the solution here.

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:

 ![image](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/2X/f/f2b52fa0cfdd5cb3915377957b0aa254127b90d1.png)

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!

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [September 25, 2020, 3:05pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/38 "2020-09-25T15:05:03Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\
**Post date:** [July 28, 2021, 4:24pm UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/39 "2021-07-28T16:24:08Z")

</div>

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:

> <https://github.com/wp-cli/db-command/issues/185>
>
> Bug Report
> Yes, I reviewed the contribution guidelines.
> Yes, more specifically, I reviewed the guidelines on how to write clear bug...

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!

---

<div class="post-metadata">

**Author:** ![sc0ttkclark](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sc0ttkclark/32/4763_2.png) [@sc0ttkclark](https://community.localwp.com/u/sc0ttkclark)\
**Post date:** [February 22, 2022, 4:23am UTC](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864/40 "2022-02-22T04:23:59Z")

</div>

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.

[Previous page](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864.md?page=1)

[Next page](https://community.localwp.com/t/starting-development-on-a-reset-site-add-on/12864.md?page=3)