Make Me Static, Static Site Generator, Git, Pages and Live Stats
Welcome to the Make Me Static Plugin for WordPress. This plugin is a static site generator and aims to create and maintain a static copy of your WordPress website within a Git repository. This version includes automatic access to a free Git solution and Page provider platform. (so no setup or credentials are necessary) Alternatively the static site can be generated and stored in a GitLab Git Repository that can be used as a source for a static page platform such as CloudFlare Pages. The plugin provides customised sitemap and change tracking which connects to an external crawling service which does all the heavy lifting. We have made great efforts in this version to minimise the configuration required to get going, if you have any problems (with anything) please let is know and we’ll do our best to help. Check out this YouTube video for an introduction to static front-ends and a walk-through of converting a pre-existing WordPress site into a WordPress site with a static front-end. How the service works The plugin connects to a directory service on the Internet at one of the directory URL’s listed below. This in turn will point the plugin to a ‘crawler’ that has been allocated to your site. When you ask the plugin to make a static copy of your site, it will instruct the crawler to visit all the pages on your site to determine which have changed since it’s last visit. Any changed pages will be copied to a Git repository, which in turn can publish pages directly to a page hosting service. The default option is to use a Git account hosted by MadPenguin, and to publish the site on MadPenguin’s page hosting platform. As a result the default options do not require any specific Git or Page hosting configuration to get going. If on the other hand you choose to use a hosted Git service such as GitLab, you will need to enter some credentials for your online account, and from there configure your GitLab account to publish to a page hosting service. Once you have successfully published a static copy of your site, all you need to do is point your domain at the address of the page hosting service, and asssuming your domain matches the one you entered when setting up your profile within the plugin, you should be up and running. The service retains a metadata database for the site which includes file names, sizes and modification times, together with any credentials that have been added when creating a profile. (Sensitive credentials and other information is encrypted at rest). The external service is responsible for all scanning and processing activities to mitigate strain on the WordPress server. The only private data transferred to the external service is the information you enter when creating a profile. All other information is obtained via an anonymous external scan, hence publically available. If you have selected the default Git option, then the service will also retain a static copy of the site. Useful references The service product page Terms and Conditions of Service Privacy Policy Getting Started Service Status Support Forum Make me static directory service URL’s; https://mms-directory-1.madpenguin.uk https://mms-directory-2.madpenguin.uk https://mms-directory-3.madpenguin.uk Other URL’s used to load code; https://assets.makemestatic.com, source for stage-2 crawler UI https://status.makemestatic.com, endpoints that indicate the currently deployed version of a site https://weblogs.makemestatic.com, source for dynamically loaded weblogs data / websockets https://mms-crawler-*.madpenguin.uk, location of the actual crawlers (via websocket) Note that this in an integrated solution, the 3rd party crawling service is owned and operated by the plugin authors on a combination of cloud hosted and on premesis equipment. Live Web Statistics (experimental) If you opt to use the integrated Pages platform, this also provides a live WebStats option that uses the following URL; https://weblogs.makemestatic.com This allows live webstats to be seamlessly delivered into your control panel and updated in real-time via a websocket connection. Do not use this URL directly! This URL is only referenced once you click on the webstats icon next to your profile. How Does it work? The WordPress site is scanned by the MMS service under direction from the WordPress plugin. This off-loads the scanning process to specialised software which aims to minimise the loading on the WordPress server while scans are in progress. There are three types of scan that can be performed; An “update”, which literally only looks at entries with changed sitemap timestamps (this is very quick and great for typo’s and any changes that only affect a single page) A “synchronise”, typically this will scan every asset on the WordPress site and compare a checksum of each asset against it’s database to see if it’s changed since the last scan. Any changes are then transferred to the connected Git repository. A “Git verification”, this is like a “synchronise”, but also scans the Git repository for assets that are no longer referenced by the site (and removes them). As the site is scanned “from the outside” there should be no risk of the plugins actions exposing any data that isn’t already public. By the same token the external service has no ability to modify WordPress so the security footprint of the plugin is tiny. Feature bullet points The plugin provides a way to produce a static copy of your website in a git repository The result is compatible with both Github pages and CloudFlare pages for automatic publication Multiple profiles are supported for (A+B_…) testing Various scan rates are supported from one page per 5s to 7 cores flat out Scheduled updates are supported and automated scanning Currently “Gitlab” is supported with plans for GitHub and on-prem Gitlab Support push services (WebPushr) to automatically notify subscribers on scan completion Issue tracker for each profile to diagnose problems Handles current and historical issues Ability to acknowlede or delete issues when resolved GUI access to the internal asset database Search as you type filtering Pinning (force assets to be scanned regardless of perceived change) Selective / manual queueing of assets for testing Ability to include manual / static assets in the scan (in the WP tree but unmanaged by WP) Ability to exclude specific files and folders Setup Wizard is included for a guided profile creation The Technology The Plugin presents as a WordPress Admin / plugin page Backend connections are made over websockets using PKI The crawler respects Robots.txt, (make sure the “MMSbot” agent is allowed on your site) MMS Javascript runs in an isolated module and CSS “plays nice” with WordPress Global CSS and theming is partitioned and user editable (if you feel the need …) All of the front-end JS code and PHP is either GPL2 or MIT licensed Backend-code is all based on the Orbit Framework (the framework and DB are all MIT licensed) Orbit is a ‘real time’ framework, so the admin panel is 100% reactive. Progress bar updates are typically “per percent” granularity All statuses, totals, etc, are updated as they happen Unless you’ve hit a bug, there is no mileage in reloading the MMS plugin page If you change your license information, it will change in real-time If the crawler allocated to your site changes (perhaps due to a license upgrade) then the appropriate version of the crawler UI will be uploaded “into” the page from the new crawler.
Top keywords
- service18×1.44%
- site18×1.44%
- page13×1.04%
- static13×1.04%
- git12×0.96%
- wordpress12×0.96%
- https8×0.64%
- crawler7×0.56%
- pages7×0.56%
- scan7×0.56%
- git repository6×0.48%
- madpenguin6×0.48%
SQLite Object Cache
A persistent object cache helps your site perform well. This one uses the widely available SQLite3 extension, and optionally the igbinary and APCu extensions to php. Many hosting services offer those extensions, and they are easy to install on a server you control. What is this about? It’s about making your site’s web server perform better. An object cache does that by reducing the workload on your MariaDB or MySQL database. This is not a page cache; these persistent objects go into a different kind of cache. These objects aren’t chunks of web pages ready for people to view in their browsers, they are data objects for use by the WordPress software. Caches are ubiquitous in computing, and WordPress has its own caching subsystem. Caches contain short-term copies of the results of expensive database lookups or computations, and allow software to use the copy rather than repeating the expensive operation. This plugin (like other object-caching plugins) extends WordPress’s caching subsystem to save those short-term copies from page view to page view. WordPress’s cache happens to be a memoization cache. Without a persistent object cache, every WordPress page view must use your MariaDB or MySQL database server to retrieve everything about your site. When a user requests a page, WordPress starts from scratch and loads everything it needs from your database server. Only then can it deliver content to your user. With a persistent object cache, WordPress immediately loads much of the information it needs. This lightens the load on your database server and delivers content to your users faster. Who should use this? If your site runs on a single web server machine, and that server provides the SQLite3 and igbinary extensions to php, this plugin will almost certainly make your site work faster. And if that server provides the APCu extension, this plugin uses it too. Some hosting providers offer redis cache servers. If your provider offers redis, it may be a good choice. You can use it via the Redis Object Cache plugin. Sites using redis have one SQL database and another non-SQL storage server: redis. Other hosting providers offer memcached, which has the Memcached Object Cache plugin. And some large multipurpose cache plugins, such as the LiteSpeed Cache, also offer object caching based on one of those cache server software packages. The cache-server approach to object caching comes into its own when you have multiple load-balanced web server machines handling your site. SQLite doesn’t work correctly in a multiple-web-server environment. But, for single-server site configurations, SQLite, possibly assisted by APCu, performs well. And the vast majority of sites are single-server. APCu APCu is an in-memory storage medium. It lets php programs, like WordPress, store data in shared memory so it’s very fast to retrieve when needed. If APCu is available on your host server, you can configure this plugin to use it. It reduces the typical cache lookup time to one-fifth or less of the SQLite lookup time, which is itself a few tens of microseconds. Performance counts, especially on busy web sites. Please look at Installation to learn how to configure this plugin to use APCu. The plugin works fast without it, and faster with it. WP-CLI: Even if APCu is in use, caching with SQLite is necessary when your web site uses WP-CLI, because WP-CLI programs do not have access to the APCu cache. This plugin writes all cached data both to APCu and to SQLite and makes sure the two are synchronized. WP-CLI You can control this plugin via WP-CLI once you activate it. Please type this command into your shell for details. wp help sqlite-object-cache Credits Thanks to Till Krüss. His Redis Object Cache plugin serves as a model for this one. And thanks to Ari Stathopoulos and Jonny Harris for reviewing this. Props to Matt Jones for finding and fixing a bug that appeared on a heavily loaded system. Thanks to Massimo Villa for testing help, and to nickchomey for a comprehensive code review. All defects are, of course, entirely the author’s responsibility. And thanks to Jetbrains for the use of their software development tools, especially PhpStorm. It’s hard to imagine how a plugin like this one could be developed without PhpStorm’s tools for exploring epic code bases like WordPress’s. How can I learn more about making my WordPress site more efficient? We offer several plugins to help with your site’s database efficiency. You can read about them here.