DA / Wordpress - force updates (core/plugins/theme) via Ansible

ShadowM

Verified User
Joined
Jan 31, 2007
Messages
10
As all know when customers deploy Wordpress sites the one thing they forget is to keep their site/plugins/themes up to date.
In this i therefore started researching a way to force updates via Ansible.

To share what i have its posted below.

Dependancies :
- have wp-cli installed as command-tool

if it is not present then create tasks in a/your Ansible playbook :

YAML:
- name: Check if wp-cli management tool exists.
  ansible.builtin.stat:
    path: /usr/local/bin/wp
  register: wp_cli_result
 
  - name: Update wp-cli management tool if it was present
  ansible.builtin.shell: "/usr/local/bin/wp cli update --yes"
  when : wp_cli_result.stat.exists
 
- name: Download and install wp-cli management tool if it does not exist
  ansible.builtin.get_url:
    url: https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
    dest: /usr/local/bin/wp
    mode: '0755'
  when: not wp_cli_result.stat.exists

The playbook itself as to executing an unconditional upgrade of WP-core, plugins and themes is below:
-> remember, some items are additional for future purposes.

YAML:
---
# tasks file for directadmin

- name: make sure wp-cli is latest
  ansible.builtin.command: wp cli update

- name: Set facts
  ansible.builtin.set_fact:
    user_dirs: []
    wordpress_sites: []
    wordpress_paths: []
    wordpress_unwanted_files: []

- name: Find homedirectories of users
  ansible.builtin.find:
    file_type: directory
    paths:
      - "/home"
    recurse: no
    excludes:
      - "backup"
      - "tmp"
  register: home_dirs

- name: Show found homedirectories
  ansible.builtin.debug:
    var: home_dirs

- name: Add directory list
  ansible.builtin.set_fact:
    user_dirs: "{{ user_dirs + [item.path] }}"
  with_items: "{{ home_dirs.files }}"

- name: Show found homedirectories
  ansible.builtin.debug:
    var: user_dirs

- name: Find homedirs with wpconfig.ini
  ansible.builtin.find:
    file_type: file
    paths: "{{ user_dirs }}"
    recurse: yes
    patterns:
      - wp-config.php
  register: wordpress_users

- name: Show found wordpress users
  ansible.builtin.debug:
    msg: "{{ item.path }}"
  with_items: "{{ wordpress_users.files }}"

- name: Set paths for wordpress sites to perform actions on
  ansible.builtin.set_fact:
    wordpress_paths: "{{ wordpress_paths + [item.path | dirname] }}"
  with_items: "{{ wordpress_users.files }}"

- name: Show content of wordpress paths
  ansible.builtin.debug:
    var: wordpress_paths

- name: Get Siteversion of wordpress site
  ansible.builtin.command: wp core version --allow-root
  args:
    chdir: "{{ item }}"
  with_items: "{{ wordpress_paths }}"
  register: version_result

- name: Show version_result
  ansible.builtin.debug:
    var: version_result.results
  with_items: "{{ version_result.results }}"

- name: Update Siteversion of wordpress site
  ansible.builtin.command: wp core update --allow-root
  args:
    chdir: "{{ item }}"
  with_items: "{{ wordpress_paths }}"
  register: core_update_result

- name: Show update_result
  ansible.builtin.debug:
    var: core_update_result

- name: Update Plugin version of wordpress site
  ansible.builtin.command: wp plugin update --all --allow-root
  ignore_errors: yes
  args:
    chdir: "{{ item }}"
  with_items: "{{ wordpress_paths }}"
  register: plugin_update_result

- name: Show plugin_update_result
  ansible.builtin.debug:
    var: plugin_update_result

- name: Update Themes version of wordpress site
  ansible.builtin.command: wp theme update --all --allow-root
  args:
    chdir: "{{ item }}"
  with_items: "{{ wordpress_paths }}"
  register: theme_update_result

- name: Show theme_update_result
  ansible.builtin.debug:
    var: theme_update_result

- name: Reset rights on worpress installations to correct user and group
  ansible.builtin.command: chown -R {{ item.1.pw_name }}.{{ item.1.pw_name }} {{ item.0 }}
  with_together:
    - "{{ wordpress_paths }}"
    - "{{ wordpress_users.files }}"

- Glowsome
 
I'm just about to move on to doing this, watching with interest. If you have updated things since 2022 please let us know.
 
It's a great concept, and I totally get why you'd do this for the client's security and server integrity.

I'd like to be the Devil's Advocate here and mention something. I'd say whilst 98% of updates work well, theres a small % chance though that the forced update/plugin hasn't been tested with their version of WP. Also, if the update doesn't play nicely with other plugins, you could be left there going through installs troubleshooting issues for customers if they are not on a managed plan, restoring backups etc rolling back changes. Customers have been quick in the past to shout at providers that have "broken their site". I had a customer very angry at me when he'd selected auto updates and a plugin trashed his site, saying it was my servers that broke his site. Wasn't too much of a problem rolling back with a recent backup, but it's hassle no provider really needs.

If you are paid extra to manage these plans for customers, then it's an excellent idea to add value and bring in extra revenue if you have the time and expertise to troubleshoot.

Maybe educate customers on how to use staging, which I find is an excellent way to perform updates.
 
Educate customers to use staging? Good luck with that! I'm guessing your customers are developers - mine are completely non-technical and if I break a site I'm the one who has to fix it. On the other hand, if I leave updates to customers none will ever happen and sites eventually get hacked. I speak from bitter experience.

I agree the untested plugins are a problem and I'd be interested in checking that with any automation. WordFence flags them as "abandoned" after a while and I agree that eventually a decision needs to be made (manually) about the risk.

I often have to make decisions about unfixed vulnerabilities as well. Disabling a vulnerable plugin (or not) might cause more harm than good. For example, a privilege escalation vulnerability might or might not matter depending on whether a site actually has unprivileged users. Also lots of plugins (too many!) need license renewal or a database upgrade. You can't automate everything.

The two extreme approaches would be to either leave everything alone until it breaks following the "if it aint broke" principle, or update everything and deal with the consequences of the bugs and compatibility breaks. You should make it clear to customers which camp you're in, or whether you're somewhere in between. In all cases good backups are a big part of the solution, and that's really why I want to automate things. The WP-rollback plugin is also useful.
 
Educate customers to use staging? Good luck with that! I'm guessing your customers are developers - mine are completely non-technical and if I break a site I'm the one who has to fix it. On the other hand, if I leave updates to customers none will ever happen and sites eventually get hacked. I speak from bitter experience.

I agree the untested plugins are a problem and I'd be interested in checking that with any automation. WordFence flags them as "abandoned" after a while and I agree that eventually a decision needs to be made (manually) about the risk.

I often have to make decisions about unfixed vulnerabilities as well. Disabling a vulnerable plugin (or not) might cause more harm than good. For example, a privilege escalation vulnerability might or might not matter depending on whether a site actually has unprivileged users. Also lots of plugins (too many!) need license renewal or a database upgrade. You can't automate everything.

The two extreme approaches would be to either leave everything alone until it breaks following the "if it aint broke" principle, or update everything and deal with the consequences of the bugs and compatibility breaks. You should make it clear to customers which camp you're in, or whether you're somewhere in between. In all cases good backups are a big part of the solution, and that's really why I want to automate things. The WP-rollback plugin is also useful.
Ok, I agree most of my customers aren't WP developers, and in an ideal world would be great if they could use tools we provide. I do tell my customers if they break it and I have to fix it, I charge a fee for this. It's only fair as it's my time and they took the risk. I do keep 30 days worth of backups so if they notice somethings broke a few weeks down the line as they aren't monitoring their site I can still roll back and take a look at what's broke for them.

It is a challenge to know who does what and what's going to be a vulnerability in the future like you say with all the variables thrown in the mix: Users, Privileges, Plugins, Themes, WP Core etc. I do manage a few WP sites and I charge an extra fee for this, other customers who don't want managed WP, they are told the same as above. Most of the time, updates go well, but occasionally you'll have a user with a theme that has a few obscure plugin dependencies and they sometimes cause the issues. 1 plugin of note is Elementor, as some of the plugins for that cause issues and can be very memory hungry.

Another issue (very occasionally) is the customer will upgrade and then their PHP version won't work. Dead simple to adjust that setting for them, but I wouldn't expect a general customer to know anything about that!

I have 1 customer, who i'll be expecting a call from sometime in future as he's set his site to auto-update core and plugins automatically. One update 8 months ago brought his site down. Didn't take long to debug the naughty plugin but it's a pain sometimes.

Thanks for noting wp-rollback. I haven't heard of that plugin before. Is it simple to use? I generally rely on backups and staging when I update sites.

If you eventually manage to effect a script that updates them, post it here. If it's useful, timesaving and works, I would even consider a small fee for it as it would save my time in the long run.
 
Back
Top