-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Settings import/export #5
Comments
Sounds like a good idea. Are you thinking to dump the whole wp_options table (save maybe for options pointing to site URL, or do an automatic URL string replacement where possible), or something more granular? |
yeah exactly, was thinking grabbing everything from |
try branch It adds one option to the WordPress exporter to export only options as a JSON file: Then it adds a simple WordPress importer: As of now grabs everything save for a few sensitive options, has an URL replacement setting, etc. There's one setting to manually tick/untick options to import if you click specific options. Perhaps I will add one more option to only grab and import options starting with |
@JulieSkyVerge @IanMisnerThough @tamarazuk Does any of you use WC Dev Helper in support? I mean on customer sites or their staging, not your local test sites. @ChaseWiseman brought up the question whether WC Dev Helper is the right tool to use for support, as I believe it was conceived merely as plugin dev aid. Do you think the feature outlined in this issue (and attached PR) would be of use to any of you? Or would it be preferable to have a separate support plugin? Thanks! |
@unfulvio I never have, no. The requested feature here would be super valuable, and wherever it ends up, I'd love to use it. I don't feel strongly about it being separate or included with everything else, but I'd be more likely to use the other dev helper features if I was already installing it to easily copy site settings for more difficult troubleshooting. |
thanks for the feedback @IanMisnerThough #6 contains an usable tool, although I'd recommend first checking out on a test environment - still not recommended for use on live sites (unless staging) at the moment |
If we were to have a tool or plugin we install on client sites, I would personally prefer to have one separate from WC Dev Helper. This plugin should be for dev sites only and we should keep building it with that in mind. For instance, WC Dev Helper currently installs and automatically activates a gateway called "Bogus". Having it do this automatically is incredibly valuable on a dev site, but definitely not good for a customer's live site for obvious reasons. When we brought this up previously (it was in Slack I believe), someone mentioned adding "modes" to the plugin so we can switch it to a support-driven plugin that can be active on a live site, but I personally wouldn't want to risk it as we could forget to uninstall the plugin or simply make a mistake and activate the wrong mode. If the two plugins need to share some functions/classes, we can always build a mini-framework for the two to share. |
I've made a PR that updates this mini plugin to our FW (needed to handle the Memberships generator). What features an hypothetical "Support Helper" should have? |
I'm sure we could compile a list -- one that immediately comes to mind is the ability to see all meta for an object on demand, perhaps by adding a query param like |
PR in #6
When trying to replicate an issue, it takes a lot of time to recreate the exact settings for a customer's site. It'd be super useful to be able to export settings and import them locally. Probably could be done simply via a JSON dump of the options and a field to paste the JSON. This would be even better if it supported our various extensions in the same manner.
The text was updated successfully, but these errors were encountered: