The “Site” command allows us to manage the websites hosted on the server. Create any type of site on your new server, add an SSL certificate, activate FastCgi Cache for your WordPress installation and more features that will allow you to have total control over your sites easily and reliably, always at a command away and with no complications.
sudo site <domain> <option> <option2>
# Create PHP site sudo site example.com -php # Create WP site with cache enabled sudo site example.com -wp -cache=on # Disable cache sudo site example.com -cache=off # SSL Cert sudo site example.com -ssl=on # List of your sites sudo site -list # Clone a WP site sudo site example.com -clone-from=staging.example.com # Page redirect sudo site example.com -redirection
Create a new site
Create a new website of any type: HTML, PHP, WordPress, Reverse Proxy, etc.
To create a basic HTML site, use the following command:
sudo site example.com -html
To create a site with PHP support.
sudo site example.com -php
All sites using the primary/main domain (not a subdomain) are configured to respond to requests from
www.example.com (See the force-redirect option).
To create a PHP site in conjunction with a database:
sudo site example.com -mysql
The data to connect to the database will be displayed after executing the command.
You can also use the “custom” option to introduce your own data before generating the database
sudo site example.com -mysql=custom or in the same way you can pass the data directly.
# TIP Hack # Use the -mysql option without domain to create a DB and User (MySQL) sudo site -mysql # Custom data sudo site example.com -mysql=custom # Custom data sudo site -mysql=[host,dbname,dbuser,password] sudo site example.com -mysql=[host,dbname,dbuser,password,external_dbuser,external_dbpass] # TIP Use "random" (without quotes) as password to automatically generate a random password.
Installing WordPress has never been so easy, Webinoly automatically configures the entire installation.
sudo site example.com -wp
Use the “custom” option to modify some aspects of the database, in any way you can simply press <Enter> in each question to use the suggested data.
# Installation script of a WordPress site using the "custom" configuration sudo site example.com -wp=custom -cache=on
In the same way, you can pass the data directly from command line.
# WordPress installation script with custom data. sudo site example.com -wp=[<setup_db>,<setup_wp>,<host>,<dbname>,<dbuser>,<dbpass>,<wp_prefix>,<external_db_user>,<external_db_pass>] # Example: sudo site example.com -wp=[true,true,localhost,example_com,example_user,password,wp_] # TIP Use "random" (without quotes) as password to automatically generate a random password.
Webinoly supports the use of external databases for your WordPress site, for example Amazon RDS. It is very simple to configure, during the “custom” installation of your site you will be asked for the “dbhost”, by default it is configured as localhost, but in case of requiring the use of an external database you only have to add the path in the format
You can even save the data from your external database:
sudo webinoly -external-db-save=[user,pass,host:port] and this way Webinoly will use it always by default (as if it were localhost).
* It is important to consider that the url should not contain the schema (http/https) at the beginning, and it should be taken into account that a poor design or implementation in the architecture of this kind of solutions can have a negative impact on the speed of your site, high latency or even multiple connection errors and timeouts.
** It has been successfully tested with Amazon RDS using MySQL, MariaDB and Amazon Aurora as the database engine.
*** Webinoly does not support the use of “sockets” for database connection.
Converting your WordPress site to Multisite has never been so easy.
sudo site example.com -multisite-convert
It will ask and you should go to “Tools -> Network Setup” to select the type of installation (subdomain or subdirectory); Webinoly will do all the configuration automatically once you have selected the type of Multisite you want.
* If your site has been installed with
Together with Nginx this is the best optimization you can do to speed up your WordPress site. Forget about using obsolete plugins like W3 Total Cache, Super Cache or WP Rocket. FastCGI has demonstrated a performance far superior to the time to serve content cached from your server.
To enable/disable (on/off) FastCGI:
sudo site example.com -cache=on
You can also activate it from the creation of your new site as follows:
sudo site example.com -wp -cache=on
You can use the
-wp-cache-plugins (on/off) parameter to skip the question for suggested plugins installation:
sudo site example.com -cache=on -wp-cache-plugins=on.
Nginx Helper Plugin
It is highly recommended to use the Nginx Helper plugin to dynamically renew and purge cached content automatically; in this way we ensure to always display the most updated content when necessary.
It is important to configure the Purge Method of the plugin as “Delete local server cache file”, the support for the purge/url method has been disabled because it is considered a security risk. Similarly, the “Caching Method” should be set to “Nginx FastCgi Cache”.
To modify the global configuration of NGINX & FastCGI Cache read the documentation.
Cloning a WordPress site
You can clone any WordPress site.
This feature is also known as “staging sites” due to its usefulness during the development stage.
sudo site example.com -clone-from=dev.example.com
Every link in your content will be updated automatically, you can disable this option as follows:
sudo site example.com -clone-from=dev.example.com -replace-content=off
Any of these features – if present -, it will not be inherited to the cloned site: SSL cert, force-redirect, default-site or tools-site settings, any custom Nginx file.
Note that WordPress Multisite cannot be cloned, since each site in the network is like an independent site, there is no practical way to clone all the network. If you want to clone just one site inside a multisite network, just use a free WP plugin.
To clone and overwrite an existing site you can use the
-overwrite=on parameter. Also, you can set or change the WP Environment Type of the cloned site using the
Example: Development Cycle # Create a new development site # WP debug mode enabled, cache disabled and noindex for search engines sudo site dev.example.com -wp -env=development # Staging site waiting for client approval # Debug disabled, cache disabled and noindex sudo site staging.example.com -env=staging -clone-from=dev.example.com # Overwrite your old site in production # Cache enabled, debug disabled and index enabled sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on # Updates in local environment sudo site local.example.com -env=local -clone-from=example.com # Push updates to production sudo site example.com -clone-from=local.example.com -cache=on -env=production -overwrite=on
The replace-content option can be used alone in any other WordPress site to search and replace any word or string in your content.
sudo site example.com -replace-content
# To skip questions sudo site example.com -replace-content=[search-this,replace-with]
In case your WP site – to clone or replace content – is connected to an external database, it will be necessary to enter the username and password. To skip these questions you can use the
WordPress Environment Type
sudo site example.com -env=staging
In staging, development and local the FastCGI Cache will be disabled automatically. Also, the option “Discourage Search Engines from indexing this site” from WordPress “Settings > Reading” will be enabled automatically.
In development and local the WordPress “debug” mode will be enabled automatically. And will be disabled when changed to “staging” or “production”.
# Examples: # Keep cache enabled sudo site example.com -env=staging -cache=on # Create a new WordPress site sudo site example.com -env=development -wp # The new cloned site will be set as "staging" sudo site example.com -env=staging -clone-from=sub.example.com -overwrite=on
One of the most powerful tools for configuring your sites on your server is the ability to independently configure each subdirectory of a particular site.
sudo site example.com -html -subfolder=/one sudo site example.com -php -subfolder=/two sudo site example.com -wp -subfolder=/three sudo site example.com -proxy -subfolder=/four # Delete a subfolder site sudo site example.com -delete -subfolder=/xxx
It is even optional to have a site at the root of the domain, that is, it is possible to have only support in the subdirectories configured in any combination of configurations that you need.
# Example with subfolders and empty root + example.com <empty> - /blog <wp> - /downloads <proxy> - /tickets <php> # Another example with static site in root + example.com <html> - /news <wp> - /clients <php>
TEMPORARY ISSUE – Reverse Proxy sites and subfolders are limited due to a recent issue we found. Reverse Proxy sites can only contain Reverse Proxy subfolders, and Reverse Proxy subfolder can only be used in Reverse Proxy sites. This will be fixed soon!
Install WordPress in a subdirectory
You can have more than one WordPress installations under the same domain.
sudo site example.com -wp -subfolder=/test
You should always specify the
-subfolder argument to refer to this site and thus differentiate it from a common installation at the root of the domain.
sudo site example.com -delete -subfolder=/test sudo site example.com -cache=on -subfolder=/test sudo site example.com -multisite-convert -subfolder=/test sudo site example.com -clone-from=dev.example.com -subfolder=/test sudo site example.com -replace-content -subfolder=/test sudo site example.com -env=staging -subfolder=/test sudo webinoly -backup=local -wp=example.com -subfolder=/test sudo webinoly -backup=s3 -add-db-pre=example.com -subfolder=/test sudo httpauth example.com -wp-admin=on -subfolder=/test sudo httpauth example.com -path=/one/folder/ -subfolder=/one sudo log example.com -wp=on -subfolder=/test
Parked domain or alias
A parked domain is an additional or alternate domain that points to a main site. It is a simple way to access your site from different domain names.
sudo site example.com -parked
When executing the command you will be asked to enter the name of the main domain where the new parked domain will point to. In the same way you can use the command as follows to facilitate its use:
sudo site example.com -parked=mainsite.com
Make sure the main site is hosted on the same server.
All requests to this domain will be redirected or forwarded to another domain.
sudo site example.com -forward=example.org
All the request parameters are passed to the new domain. If you want to remove these parameters and force a redirection to a single site you can use the
# sudo site example.com -forward=https://example.org example.com/news --> example.org/news # sudo site example.com -forward=https://example.org -root=on example.com/news --> example.org
Reverse Proxy site
To create a site with Reverse Proxy configuration in Nginx:
sudo site example.com -proxy=[localhost:8080]
# Examples: sudo site example.com -proxy=[127.0.0.1:8080] sudo site example.com -proxy=[https://example.com] sudo site example.com -proxy=[http://example.com:8080]
Some very useful commands to manage your sites.
How can I temporarily disable a site?
At any time you can activate or deactivate a site hosted on your server without deleting it.
sudo site example.com -on
sudo site example.com -off
Delete a website
You should use this option with caution, as once a site is deleted it will not be possible to recover the files.
sudo site example.com -delete
You can also use the “force” option to omit the questions (unattended)
sudo site example.com -delete=force.
# Tip - External Database (Unattended Script) # Do not erase Database sudo site example.com -delete=keep-db # Unattended delete with external DB sudo site example.com -delete=force -external-db=[user,pass] # Revoke SSL Cert sudo site example.com -delete=force -revoke=on
To remove all sites hosted on your server:
sudo site -delete-all
The databases of your WordPress sites that are currently in use will also be deleted. Some other DB’s may not be deleted, so there may be remanent stored data from your deleted sites.
# Extended example sudo site -delete-all=force -external-db=[user,pass] -revoke=on # Keep databases sudo site -delete-all=keep-db
When a site is deleted, if an external database is found, an attempt will be made to use the data from
-external-db , if they are not found, the user will be asked to enter the necessary data. The
-revoke=on parameter will remove and revoke the SSL Cert of a site if found, use the “off” option to keep the SSL cert.
When a site is set as
tools-site cannot be deleted. When
-delete-all is used then these sites are forced to be deleted and each option is set as
default to prevent errors.
Display a list of information about your site.
sudo site example.com -info
List of your sites
To see a list of all your sites hosted on the server, use the following command:
sudo site -list
You will also see some information of each site:
- Site Type: WordPress, HTML, PHP, Parked, Proxy, Forward, Subfolders.
- Assignation: If site is set as “Default” or to access Webinoly “Tools”.
- Alerts: NoSSL, SSL-Staging, AccessLog, NoCache, NoAdminAuth, Debug.
# Filtered list sudo site -list=nossl
Filter options: disabled, main, html, php, wordpress, parked, proxy, forward, tools, default, ssl, nossl, sslstaging, accesslog, noaccesslog, cache, nocache, adminauth, noadminauth, debug, nodebug, wpenv.
-raw parameter is supported to remove format.
When WP Environment Type is not “production”, the site type will be: (WordPress:staging), for instance. To filter these sites you can use “wpenv”.
Settings and Customizations
Configure your sites according to your needs.
Force WWW or non-WWW in a site
By default, Webinoly configures your site to accept both requests in your domain, that is,
www.example.com will be both valid when a main/root domain like:
example.com is used (NOT for subdomains: sub.example.com).
You can force the use and redirect the requests to any of your preferences.
sudo site example.com -force-redirect=<options>
In some special cases where an SSL certificate has been imported from another provider and this does not include the “www” domain or vice versa, we can use the
-ignore-ssl option as follows:
sudo site example.com -force-redirect=root -ignore-ssl.
SSL Certificates with Let’s Encrypt
We take advantage of the facilities provided by Let’s Encrypt to generate free certificates for your site and make it even easier to configure your site easily and quickly.
There is no pretext for not migrating your site to HTTPS, just by executing the following command your new website will be fully configured to navigate securely over HTTPS.
sudo site example.com -ssl=on
During the creation of the certificate, Webinoly will ask for your email account, this email will be used to register the new certificate, in addition to helping you to follow up the periodic renewal process.
If you prefer, you can save your email address:
sudo webinoly -email@example.com to skip questions during the cert request.
* On existing servers this command will update the registered email in Let’s Encrypt.
** Ubuntu internal root email will be forwarded to this email address.
The certificates issued by Let’s Encrypt are valid for a period of 90 days and before that period it is recommended to request the renewal to keep it up to date. Webinoly automatically checks once a week the status of the certificates of all your sites and those that have less than 30 days of validity period is automatically requested for its renewal. Therefore, you should not worry, since Webinoly automatically completes the process to keep your certificates and your sites always in force.
During each weekly renewal check, you will receive an email in the account that you have registered with the current status of each certificate.
Once activated the SSL certificate, Webinoly will automatically configure Nginx to redirect all the traffic from your site from HTTP to HTTPS.
Disable SSL on a site
If for some reason you need to deactivate the use of the SSL certificate in your site, just execute the following command.
sudo site example.com -ssl=off
# Use the "revoke=(on/off)" option to skip questions. (Unattended) sudo site example.com -ssl=off -revoke=on
-ssl=off option can be used even if your site doesn’t even exist anymore as a way to remove and revoke an orphan SSL cert.
Certificates in parked sites
The “-root” option allows you to create certificates for sites where the root of your files is in a different place than usual; this is the case of parked sites, since the parked domain does not even have a root directory or own files, however, it points to another site hosted on the same server.
sudo site example.com -ssl=on -root=mainsite.com
A common and practical example of the above case is in WordPress Multisite installations with Domain Mapping, where you have one or more parked (mapped) domains on your server pointing to a main site.
Certificates on Reverse Proxy sites
The “-root-path” option allows us to specify a different route, as is the case of sites in Reverse Proxy configuration where the files are stored in a location different than
sudo site example.com -ssl=on -root-path=/opt/myapp/web
Only for apps hosted on the same server.
When we need a single certificate to cover all subdomains (* .example.com). This is the kind of certificate we need in WordPress Multisite installations in sub-domain configuration.
sudo site example.com -ssl=on -wildcard
During the creation of the Wildcard certificate, it will be necessary to create a DNS record to verify the ownership of the domain.
To add a site to an existent Wildcard cert:
sudo site sub.example.com -ssl=on -add-to-wildcard=example.com
Only have support for first-level subdomains.
If you want to obtain a certificate on a server or for a site that for some reason is not directly accessible from the outside, you can use the manual validation method.
sudo site example.com -ssl=on -manual=http
The manual method supports “http” and “dns” validation.
The “http” validation will ask you to place a file with a specific name and content on your site. And the “dns” validation will ask you to place a TXT record in your DNS with a specific name and content.
Although Webinoly has a redundant system for the automatic renewal process, we have an option to force it.
sudo site -ssl=renew
This command attempts to renew any previously-obtained certificates that expire in less than 30 days.
We can also force the renewal of all of the certs:
sudo site -ssl=force-renewal-all
Or a specific certificate:
sudo site example.com -ssl=force-renewal
In the case of parked domains, “reverse proxy” sites or certs with manual validation, the parameter
-manual respectively must be included to force the renewal.
Staging environment for certs
We highly recommend testing your projects using the Let’s Encrypt staging environment before using real certs in production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits.
sudo webinoly -conf-value_debug=true
Use the “debug” variable in the Webinoly configuration file to activate the Let’s Encrypt test environment, set it to “false” to deactivate the testing environment.
These are not real certs, they are just intended to be used for testing purposes, you will get errors if you try to access your site using this cert. You should never use these certificates in a production environment.
Custom SSL Certificate
Bring your own Cert!
You can add your own cert of any third-party vendor or your preference.
sudo site example.com -ssl=on -ssl-key=/path/cert.key -ssl-crt=/path/cert.crt -ssl-ocsp=/path/cert.pem
-ssl-ocsp parameter is optional for OCSP support.
Creating a redirection is easy, just run this command and follow the instructions:
sudo site example.com -redirection
Remove a redirection:
sudo site example.com -redirection -delete
# Skip questions (unattended) sudo site example.com -redirection -from=/path -to=/test -http-code=308 sudo site example.com -redirection -from=/path -to=http://example.com sudo site example.com -redirection -from=/path -http-code=410 sudo site example.com -redirection -delete -from=/path
You can also use the
-exact option to define an exact match of URI and location.
What the "EXACT" option does? Take this path: /news https://example.com/news (match) https://example.com/news/local/our-city (match) If you use the "EXACT" option: https://example.com/news (match) https://example.com/news/local/our-city (no-match)
-exact parameter is not needed when
-delete, it will just remove every path that match.
-regex option allows us to use regular expressions.
# Example sudo site example.com -redirection -from='^\.(gif|jpg|jpeg)$' -to=/test -regex=insensitive
Regular expressions on the command line must be written using single quotes, as in the example above. And it supports the following options:
- sensitive – Case sensitive.
- insentive – Case insensitive.
- longest – Specifies the best option and does not continue evaluating regular expressions.
List current redirections:
sudo site example.com -redirection -list
-list -raw option is supported to remove format characters.
NGINX Setup per site
If need to add additional NGINX rules, you can have your own custom configuration file located at
/var/www/example.com and it should be named following the pattern
*-nginx.conf, for example:
custom-nginx.conf would be a valid filename.
Webinoly automatically detects if your site is a domain
example.com (example.com and www.example.com are configured) or subdomain
sub.example.com (only sub.example.com), this is to determine the most appropriate Nginx configuration for each site. Domains with no-valid TLD are configured as subdomain. If for some reason you need to force a certain configuration, you can do it using the
-subdomain option when creating your site or an SSL cert is requested.
sudo site example.com -html -subdomain=true, or likewise
sudo site sub.example.com -ssl=on -subdomain=false.
sudo webinoly -external-sources-update is for internal use only to update some external lists, like public-suffix and timezones.
If you have any suggestions, ideas, or comments, or if you (gasp!) found a bug, join us in the support forum.