https://wordpress.org/latest.tar.gz fails in England, Scotland (and elsewhere?) when trying to install WordPress using Ansible's get_url ["HTTP Error 429: Too Many Requests"] — so let's try wget as an interim workaround

[holta]

Thanks @shanti-bhardwa, @jvonau and @tim-moody for helping to diagnose this overnight.

WordPress might or might not ever fix downloads of their own product (so that people can download WordPress using Ansible's get_url) but in the meantime we need to act, for implementers who are currently being completely blockaded.

Prior work:

• WordPress "Recommended" + "Optional" PHP Modules #2836

[holta]

This PR works.

It's unfortunate that wget isn't very savvy or flexible in the way it saves files, but good enough!

e.g. wget doesn't blast away any existing symlink /opt/iiab/downloads/wordpress.tar.gz (rather it overwrites the other end of the symlink, which might have a filename with an outdated WordPress version number if someone was really upgrading from an older version of IIAB).

Not a big deal (curl is generally more sophisticated than wget, though curl -o has the same issue in this particular case). In any case it may be more wise to stick with wget's User-Agent string — for somewhat safer downloads over coming years.

(Given that wget is WordPress's official recommendation at the moment...)

https://wordpress.org/support/article/how-to-install-wordpress/#step-1-download-and-extract

[holta]

wget cheat sheets:

• https://gist.github.com/Dammmien/4af98e05f9c51c2da007cc70d62bf562
• http://cheat.sh/wget

[holta]

Better now!

@shanti-bhardwa this is now being merged, please try it and let us know!

cd /opt/iiab/iiab
sudo git pull
sudo ./runrole wordpress   # Or if nec: sudo ./runrole --reinstall wordpress

[holta]

And if @shanti-bhardwa and his friends in Scotland confirm this is working well for them in coming days — these 2 files should probably be linted/clarified/simplified going forward:

• roles/wordpress/defaults/main.yml
• roles/wordpress/tasks/install.yml

[jvonau]

Instead of the blind deleting of wordpress.tar.gz why not use the 'wp_tar_gz' test to decide if wget is to be used? That would allow downloading to /opt/iiab/downloads in advance should there be some other issue downloading the file that might crop up in the future.

[jvonau]

https://github.com/iiab/iiab/compare/master...jvonau:wp_dl?expand=1

[holta]

/opt/iiab/downloads/wordpress.tar.gz does not serve a material purpose.

Something like /tmp/wordpress.tar.gz would be far more sensible.

(But a different filename within /tmp might make more sense.)

[holta]

The larger point is that IIAB currently keeps too many theoretically well-intended files kicking around — that are counter-productive as they create useless complexity.

[jvonau]

The resulting wordpress.tar.gz file has always hung around afterwards in downloads so there is no real change there, have a look at:
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/unarchive_module.html

• name: Unarchive a file that needs to be downloaded (added in 2.0)
  ansible.builtin.unarchive:
  src: https://example.com/example.zip
  dest: /usr/local/bin
  remote_src: yes

But might suffer the same issues as get_url does.

[holta]

https://github.com/iiab/iiab/compare/master...jvonau:wp_dl?expand=1

I see this treats /opt/iiab/downloads/wordpress.tar.gz as a marker and prevents WordPress from being installed.

Which raises 2 questions:

1. Should IIAB be blocking the install of WordPress? (I don't know, this seems well-intended but heavy-handed, but this can certainly be debated.)
2. If IIAB really should be trying to outsmart the implementer and block the (re)install of WordPress (do WordPress experts really agree?) then I would use another marker e.g. the existence of /library/wordpress perhaps? To avoid bureaucratizing, most important!

[holta]

https://docs.ansible.com/ansible/latest/collections/ansible/builtin/unarchive_module.html

Indeed, Ansible's unarchive command is usually the best choice, to avoid all intermediary bureaucracy,

But might suffer the same issues as get_url does.

If only there was a way to notify WordPress.org that they are accidentally blocking people from installing their own product.

(Not just people in the UK using Ansible to try to install WordPress, but very likely others too.)

[holta]

WordPress 6.0 is releasing on May 24, 2022 — pre-release reviews are very pretty positive:

"WordPress 6.0 Field Guide"
https://make.wordpress.org/core/2022/05/03/wordpress-6-0-field-guide/