These are the recommended system requirements for the WP2Static WordPress plugin.
You may have luck running the plugin in alternate configurations, but when errors occur, please try to meet these requirements to eliminate potential environmental issues.
The WordPress web application is written in PHP. For security and performance, it’s best to use an actively supported PHP version. This means at least version 7.2.
To see which versions are currently officially supported by the developers of PHP visit https://www.php.net/supported-versions.php
If you are using a webserver tailored to WordPress hosting, it should already have these extensions installed. If you’re building a custom server environment, please ensure these extensions are all installed and loaded. You can check the available extensions on the command line with php -i or by creating a php file which prints out the phpinfo() command. You can also find many plugins for WordPress that will display information about your environment, such as the Debug Info plugin.
cURL is used when WP2Static is crawling your URLs to make the static site and also when deploying your site via external APIs. We don’t use the wp_remote_get() and wp_remote_put() commands built-into WordPress for performance and portability reasons.
The PHP DOM extension is required for WP2Static to parse and manipulate HTML files
The ZIP extension is used when choosing the ZIP method of deploying your static site (also used by the Netlify Add-on). It is also used when downloading the Export Log after a failure.
iconv is required by WP2Static for certain string manipulation functions.
Already a requirement to run WordPress, listed here just for thoroughness.
Whether using PHP or the more common PHP-FPM, you may need to adjust some configuration options, depending on the size of your site and how quickly you want the static site generation to run. There are a lot of variables to consider, but these should be a good starting point.
When adjusting these values, verify that the changes have been applied. It will usually need a reloading of the PHP service. Be mindful to change the settings for both command line PHP and PHP-FPM which is usually running your WordPress application. These are usually defined in different configuration files.
WP2Static is designed in such a way as to overcome low limits imposed by some hosting providers. Each request from the client (your browser) to the server (your WordPress application/PHP) needs to complete in the time set by this configuration option.
Where you want to be able to crawl and generate your static site as quickly as possible, this duration will need to be long enough to support that. For most sites on decent hosting, a max_execution_time of 300 (5 minutes is enough).
If you are only running one WordPress site on your development server and want to get the maximum performance when generating your static site, you will want to adjust the PHP-FPM pool’s pm option to static. This will help utilize as many of the server’s resources when crawling, along with choosing the highest number of pm.max_children without the server running out of resources.
You can spend a lot of time researching these settings, but some trial and error can get you some performance gains quickly. Just save trial and error for a webserver that is not user-facing, as mistakes may happen that cause the site to not load or potentially expose sensitive credentials.
You may also need to extend the idle-timeout settings in PHP-FPM if the process between the client and server is exceeding limits.
WP2Static should generally work with any web server capable of running WordPress. This includes Nginx, Apache, LiteSpeed and httpd.
If you choose the Same Server deployment method, which creates a folder for the static site within your WordPress site root, the web server may need a directive allowing to serve static files from that location.
For best practice, you should be running your WordPress site on a development server different than your live site is hosted on. For such a server, not hosted on your local computer, it is highly advised to protect your WordPress site from public access using http basic authentication, IP whitelisting or putting it behind a VPN for only you, your staff and client to access. This will prevent bots, search engines and other unwanted traffic from poking around your development server. It is also recommended to have a firewall on this server, restricting access only to the ports required (typically SSH, HTTP, HTTPS and ICMP).
If you are running a DNS level caching/security service in front of your WordPress development site, such as CloudFlare, this may mistakenly detect WP2Static’s crawling mechanism or your server’s IP as malicious and block access. For a suitably protected WordPress development site, you should not need to run such services, but that is a security decision we cannot make for you.
Similarly, if running caching mechanisms on your web server itself, such as mod_pagespeed, you will need to at least disable the URL modifications that they implement.
There are several settings required in WordPress to ensure smooth static exports with WP2Static.
A static site will replicate the permalink structure you have defined in the WordPress Settings > Permalinks within your admin dashboard. As static sites generally cannot serve content from php files, your permalink structure cannot contain the index.php in them.
So a permalink structure of /%postname%/ will be fine, but/index.php/%postname%/ will not work.
Some WordPress security plugins may throw false-positives of WP2Static’s crawling mechanism. If you have the ability to whitelist certain user-agents, WP2Static used the user-agent of WP2Static.com.
If you’re using the best practice of protecting your WordPress development site from the public or you are hosting locally, you should not need to use any WordPress security (and possibly no caching plugins) and can activate them, for better performance.
Though a static site is itself a great caching mechanism for your live site, when generating your site, you will still benefit from object and page caching where possible with Redis or memcached.
The general steps for optimizing your database setup and query caching for WordPress will also benefit in faster exports of your static site. It is out of the scope for this user guide, but WP2Static doesn’t rely heavily on the WordPress database, so no special attention should be required.
For your WordPress development server, it is good practice to limit access to the WordPress database to only the IP/socket of the WordPress server.