I have been using your one click WP app for years now, starting with 14LTS to now 18LTS.
I use this for all of my WP setups because it is a decent setup that allows me to shave start up time.
Now you have added the Quickstart script and changed some of the default configuration in the vhosts. I would like to know how this is going to work with specific setups and what is happening with the setup.
Where is the $domain variable being pulled and how does that work. How does this affect custom vhost configurations and setting up my own SSL (I have sites that utilize wildcard ssl certs and subdomains that are created on the fly)
Moving this into production without more knowing what has changed is not responsible. I know the differences between 16 - 18 and where to get them, this new Quickstart though not so much.
I could investigate this more but hoping that someone can break it down for me or give me a link to more thorough documentation on the new Quickstart script.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hello. First, I apologize if the recent changes caused issues with your automation. The change that was made to the vhost file had two parts:
Rather than just using a default the file uses the $domain variable as a placeholder for the FQDN to be used on the site. This is filled in by the interactive script triggered on the first login.
UseCanonicalName is now set in the configuration.
These changes were put in place to address CVE-2017-8295 which can allow an attacker to cause WordPress to send a password reset email allowing the installation to be compromised.
Adding the interactive script also allowed us to add a prompt to kick off certbot automatically based on the FQDN provided.
It is possible to use cloud-init user data provided via the API or the option on the create page to get around this. The script that is run on first login is located at
/opt/digitalocean/wp_setup.shin the image. This bash script can be used as an example to write a user data script to fill in the variable and disable the script during first boot.
To do this in the most simple way you could use:
replacing [FQDN] with your domain. This snippet will
Great questions. The one-click is more tailored to the new user who just wants to spin up a working system, or the advanced user who just wants to skip some steps and go straight to production. If you need to automate deployments it makes more sense to build your own deploy scripts. We may frequently update our one-click images to address software updates, vulnerabilities, new practices, or to address common misunderstandings that drive ticket volume. These can happen without notice, and we do not keep a public change-log (not against it, just not something we currently do), as they have no impact on previously deployed systems.
While there are other systems out there to assist in automating software deployments, we offer a function that can help you deploy direct from our control panel or API:
We actually have an example for using this to deploy Wordpress on Ubuntu 16 (shouldn’t be much adjustment for 18):
With that said, I’ll ping @ryanpq and see if he can provide some answers about the current iteration of the Wordpress one-click.
No worries about the changes, although frustrating at times, change is a good thing!!
Thanks for the detailed response I really appreciate it and will put this to good use.