Now the 404 error page is automatically fetched from WordPress (feel free to use the default 404 theme page or a plugin) and propagated on the static site, so you don’t need to manually handle that anymore. This change will be applied on your next deploy.
Added full support for the popular “UberGrid” plugin
The “HardyPress login gateway” is no more case-sensitive and accept both email and username as credentials, to better reflect the regular WordPress behaviour.
We added the possibility, only for selected users, to increase the time before WordPress goes offline (default is 15 minutes). If you have special development needs just drop an email to support@hardypress.com
We released a monitoring tool to check the status of the HardyPress infrastructure: https://status.hardypress.com
You can now optionally provide a custom error document that contains a user-friendly error message and additional help.
We’ve recently deployed a huge update to our backend platform and now we have brand new engine that will speed-up your deploy process up to 50%… and we are working to reduce it even more. This update will also allow us to work on some cool new features and improvements in 2018, so… stay tuned!
In addition to creating and distribute a static copy of your site and hosts your WordPress installation, HardyPress is able to instruct the CDN servers about 301/302 redirects so they will set correct response-headers. It is therefore important to understand how redirects are detected on your WordPress site and propagated to the static version. We […]
You can now download the static generated website as a tarball archive to use it as your wishes. On this archive you will also find a nice file named s3_website.yml that you can use to publish the static site to your own S3 bucket with the s3_website gem preserving redirects and content-type headers.
Just fixed a subtle bug in our deploy process preventing some files to be purged from our internal cache. Sorry for the inconvenience!
You can now set different max-age headers for different types of files. This will allows your users to always have fresh content, continuing to leverage browser cache for static resources such as css, js, images, fonts, etc.
We just upgraded our back-end Docker environment (where WordPress instances are running). You should now get better performances both navigating your WordPress site and generating new deploys.
We just released the possibility to clone a site. This can be very usefull for creating “blueprint” websites or for debugging purposes. You will find the “Clone site” button under the site settings.