Negation flag for hooks

[alexanderkladov]

Hi,

First of all, wanted to say huge thanks to you guys for developing this awesome tool! I was stoked, when I found it over a year ago and still use it to this day. I can't even count the amount of times it saved me, when I was in FTP jail. In my opinion, it's still one of this tools most underrated & powerful features! Hopefully you won't ever faze out FTP support completely and will leave it in the core for basic file sync & db transfer.

Anyway, here is my question: is there a way to instruct Wordmove to not run any hooks, just like how we can already use flags to ignore specific content during the sync process (i.e. themes, plugins etc)?

The reason I'm asking is because I'm actually using WP Migrate DB as a DB migration tool (instead of built-in DB tool in Wordmove), which I've configured to run via WP CLI through a series of before/after hooks, combined with pre-saved WP Migrate DB profiles. The problem is that I don't always want to run these hooks, because I sync files much more often, than the DB. And, at the moment, I have to resort to commenting out the entire hooks section in movefile.yml for whatever environment I am about to move, whenever I don't want the DB to be migrated.

Don't get me wrong, I still use the built-in DB tool and I am glad it's there, but I only use it once for the initial site deploy (since WP Migrate DB requires a working WP site on both ends to run), after that I use WP Migrate DB to handle subsequent DB manipulations. Your resent forbid feature came in very handy for that, since after the initial deploy, I can just completely "disable" built-in DB migration tool and don't have to call --no-db all the time. Thanks guys 👍

[alessandro-fazzi]

Hi @alexanderkladov ,

a --no-hooks should® be an easy feature to reach. But having that, you would find yourself invoking wordomve w/ the flag most of the time.

What I'd do in your scenario is to duplicate the production environment having thus a production and a production-with-db. In the first I'd remove database concerning hooks, in the latter I'd preserve the hooks. This way you would be able to

wordmove push -t -e production

or

wordmove push -t -e production-with-db

and fire up WP Migrate DB at your will.

[alessandro-fazzi]

Take this tip in consideration if you are concerned about duplicated configurations maintainability.

[alexanderkladov]

Hi @pioneerskies,

OMG, of course!!! I've already used the hell out of ERB aliases & local variables with interpolations. Even found out that I can declare & use the environment name (i.e. staging, live/production etc) using variables, like <% hosted_env_name = "live" %>. And then I call them like this:

######
# Live
######
<% env_name       = "live" %>
<% vhost          = "https://domain.com" %>
<% wordpress_path = "public_html" %>
<% db_host        = "localhost" %>
<% db_name        = "database_name" %>
<% db_user        = "database_username" %>
<% db_pass        = "super_secret_database_password" %>
<% ssh_host       = "ssh.domain.com" %>
<% ssh_user       = "ssh_username" %>
<% ssh_pass       = "super_secret_ssh_password" %>
<% ssh_port       = "ssh_port_number" %>
<%= env_name %>:
  vhost: <%= vhost %>
  wordpress_path: <%= wordpress_path %>
  paths: *paths # global paths alias for all environments
  forbid: *forbid # global forbid alias for all environments
  database:
    host: "<%= db_host %>"
    name: "<%= db_name %>"
    user: "<%= db_user %>"
    password: "<%= db_pass %>"
  exclude: *exclude # global exclude alias for all environments
  ssh:
    host: "<%= ssh_host %>"
    user: "<%= ssh_user %>"
    password: "<%= ssh_pass %>"
    port: <%= ssh_port %>
  hooks:
    # all sorts of hooks below

So now I can just use your genius suggestion and all I'll have to do is make a few unique declarations, while still maintaining a single source of environment-specific variables declared, like so:

##################
# Live, files only
##################
<% env_name       = "live" %>
<% vhost          = "https://domain.com" %>
<% wordpress_path = "public_html" %>
<% db_host        = "localhost" %>
<% db_name        = "database_name" %>
<% db_user        = "database_username" %>
<% db_pass        = "super_secret_database_password" %>
<% ssh_host       = "ssh.domain.com" %>
<% ssh_user       = "ssh_username" %>
<% ssh_pass       = "super_secret_ssh_password" %>
<% ssh_port       = "ssh_port_number" %>
<%= env_name %>:
  vhost: <%= vhost %>
  wordpress_path: <%= wordpress_path %>
  paths: *paths # global paths alias for all environments
  forbid: *forbid # global forbid alias for all environments
  database:
    host: "<%= db_host %>"
    name: "<%= db_name %>"
    user: "<%= db_user %>"
    password: "<%= db_pass %>"
  exclude: *exclude # global exclude alias for all environments
  ssh:
    host: "<%= ssh_host %>"
    user: "<%= ssh_user %>"
    password: "<%= ssh_pass %>"
    port: <%= ssh_port %>

#################
# Live + db hooks
#################
<%= env_name %>-with-db: # can be called like live-with-db
  vhost: <%= vhost %>
  wordpress_path: <%= wordpress_path %>
  paths: *paths # global paths alias for all environments
  forbid: *forbid # global forbid alias for all environments
  database:
    host: "<%= db_host %>"
    name: "<%= db_name %>"
    user: "<%= db_user %>"
    password: "<%= db_pass %>"
  exclude: *exclude # global exclude alias for all environments
  ssh:
    host: "<%= ssh_host %>"
    user: "<%= ssh_user %>"
    password: "<%= ssh_pass %>"
    port: <%= ssh_port %>
  hooks:
    # all sorts of hooks below

That way, if any connection details change, I only have to change them once in the initial environment variables section. Brilliant!

I can't believe I didn't think of it myself. :man_facepalming:

Thank you!

[alessandro-fazzi]

Wow! You sound so happy of the solution that I'm feeling happy too! :D

Now, for science, wouldn't this

##################
# Live, files only
##################
<% env_name       = "live" %>
<% vhost          = "https://domain.com" %>
<% wordpress_path = "public_html" %>
<% db_host        = "localhost" %>
<% db_name        = "database_name" %>
<% db_user        = "database_username" %>
<% db_pass        = "super_secret_database_password" %>
<% ssh_host       = "ssh.domain.com" %>
<% ssh_user       = "ssh_username" %>
<% ssh_pass       = "super_secret_ssh_password" %>
<% ssh_port       = "ssh_port_number" %>
<%= env_name %>: &base
  vhost: <%= vhost %>
  wordpress_path: <%= wordpress_path %>
  paths: *paths # global paths alias for all environments
  forbid: *forbid # global forbid alias for all environments
  database:
    host: "<%= db_host %>"
    name: "<%= db_name %>"
    user: "<%= db_user %>"
    password: "<%= db_pass %>"
  exclude: *exclude # global exclude alias for all environments
  ssh:
    host: "<%= ssh_host %>"
    user: "<%= ssh_user %>"
    password: "<%= ssh_pass %>"
    port: <%= ssh_port %>

#################
# Live + db hooks
#################
<%= env_name %>-with-db: # can be called like live-with-db
  <<: *base
  hooks:
    # all sorts of hooks below

work as well?

[alexanderkladov]

@pioneerskies It was something that's been bugging me for a while, so I admit, I got excited that I got a working solution so quickly, just by using cleaver workaround. I was expecting I'd have to wait for a feature release.

And again, what a wonderful suggestion! To be honest, I did have some issues with Wordmove (or ERB) in the past, when calling aliases like this: <<: *base. That's why I ended up resorting to simply using *base. But I will give it a go and see if it works. For the sake of science, of course. 👨‍🔬

Thanks again!

[alessandro-fazzi]

AHAHAH! You simply made my day with your happiness. Seriously ;)

It's a pleasure to help and it's my goal to find solutions before to implement something new.

And again, what a wonderful suggestion! To be honest, I did have some issues with Wordmove (or ERB) in the past, when calling aliases like this: <<: base. That's why I ended up resorting to simply using base. But I will give it a go and see if it works. For the sake of science, of course.

Science FTW! We have other users in the community using <<: *alias, so I've hope.

Really glad you've found your way anyhow ;)

🥇

[alexanderkladov]

I just tested your suggestion and you are totally right again - the shorter version you suggested works too! Perfect! Thanks again! 👍