Config autodiscovery

[nlemoine]

Hi @pioneerskies

Today, tooling is everywhere. This is great but configuring is often tedious and error prone. I often have to repeat some informations multiple times, at multiple locations. An so on when some value changes.

wp-cli FTW

The whole discussion about adapting wordmove to the WordPress in a subdirectory structure (#597, #590, #591) and the possibilities offered by wp-cli gave me some ideas for improvements.

Most, maybe all, config values could be handled automatically by wordmove.

wp config get can grab all the necessary informations to make it work and your movefile.yaml file could finally look like:

global:
  sql_adapter: wpcli

local:
  wordpress_path: '/path/to/project' # could event be optional if wordmove.yml is placed inside project root

# would require wp-cli installed on server
production:
  wordpress_path: '/path/to/project' # could event be optional if wordmove.yml is placed inside project root 
  ssh:
    host: host
    user: user

Super ideally, it would even grab the different stages from wp-cli.yml: https://make.wordpress.org/cli/handbook/running-commands-remotely/

So i could run wordmove pull -d -e @production.

What do you think?

[alessandro-fazzi]

Dear @nlemoine ,

thanks a lot for this suggestions. The reasoning about the @environment calls, is totally new and stimulating for me!

Not only I'll take them into consideration, but my long term goal, since I've introduced the support to wp-cli, is to move a lot of actions locally done by wordmove to wp commands invocations. just to name a few:

• wp db export
• wp db import
• wp db drop

I've waited a long time before introducing wpcli integration; I've waited even more to make it the default. The goal was to wait for the dev community to adopt wp-cli as a standard WP development tool.

I think and I hope the time has come.

Unfortunately, Wordmove's codebase is in a bad state from the maintainability point of view and I really don't feel myself comfortable introducing other big changes into what I consider a mess.

Because of this fact, I've decided to think a big refactor in the design of this software and I've actually started to write it down. I think to have found a nice path (https://github.com/welaika/wordmove/pull/587/files) but I'm still far away from the goal. My hope is that once finished, the sotware will be atomic, modular and someway functional, thus easier to modify and to extend for me and for other contributors.

But I cannot lie: I'm neither half way from the goal at the moment.

Hoping to be working for granting Wordmove others 9 years of life, I've to ask for everybody's patience in the meantime :)

[nlemoine]

Hi @pioneerskies,

Sorry for the late late reply. I'm finally getting a bit of spare time.

You're right, wp-cli is definitely the way. This will probably sound silly but why don't you switch to PHP? Wordmove could exist as a wp-cli or a phar package. Your tool is targeting WordPress developers, unfortunately, they often aren't very good at Ruby (like me) which narrows down the number of potential contributors.

[alessandro-fazzi]

@nlemoine now that I'm at 91 commit on that branch, I'm quite sure to be near the goal of simplifying the whole architecture. Second goal: adding documentation to the code; while I'm working on re-writing tests, I'm documenting all the classes I'm writing new tests for.

I've the hope this will make it easier to contribute; if not directly with PRs, with a chance to produce more technical insights. Morover implementing new features and fixing bug should become really easier.

Unfortunately I 80% hate PHP but 95% love Ruby. Maybe when I'll ship a cleaner code, someone will be in a better place to port the whole thing in PHP...but I really couldn't stand to do any free-time/open-source work using PHP: it'd be a nightmare for me! 😅

[nlemoine]

Unfortunately I 80% hate PHP but 95% love Ruby

Sorry, I had to ask 😄

[alessandro-fazzi]

I'm going to close this one for housekeepings. Discussion could eventually continue in PR #624