Search the Community

Hi everyone, I have released a new ProcessWire module: KeyHelp. KeyHelp is a ProcessWire admin module for working with KeyHelp, a German hosting control panel. It brings common KeyHelp hosting tasks into ProcessWire Admin, and it can also install fresh ProcessWire sites directly on KeyHelp domains. Repository: https://github.com/mxmsmnv/KeyHelp What it does The module adds a dedicated KeyHelp section in ProcessWire Admin where you can: view a hosting dashboard with server status and resource counts; browse and manage domains, clients, databases, email accounts, FTP users, SSL certificates and cron jobs; update per-domain SSL, Let's Encrypt, HTTPS redirect, HSTS, PHP version and DNS records; open KeyHelp database tools / phpMyAdmin links from ProcessWire; view server information, software versions, resources and service status; cache KeyHelp API responses and flush the cache manually; enable sanitized debug logging; use English or German UI text; restrict the module to one KeyHelp client in single-tenant mode. Screenshots ProcessWire installer The installer can create a fresh ProcessWire site on a selected KeyHelp domain. It can: download the stable or dev ProcessWire archive; unpack it into the domain document root; create a KeyHelp database and database user; generate a random admin URL and strong credentials; run the ProcessWire CLI installer; adapt Apache configuration for KeyHelp; store generated credentials encrypted with the ProcessWire site salt; show a ProcessWire badge and credentials on the domain detail page. It supports both local installs and SSH remote installs, so the ProcessWire admin site and the KeyHelp hosting server do not have to be the same machine. There is also a GitHub module installer for already installed ProcessWire sites. It checks the target installation, downloads a GitHub repository archive, validates PHP syntax and copies the module into /site/modules. Requirements ProcessWire 3.0.200+ PHP 8.0+ PHP curl extension KeyHelp REST API access KeyHelp admin API key The module targets KeyHelp API 2.14 and /api/v2 endpoints. Permissions The module adds granular ProcessWire permissions: keyhelp-view keyhelp-edit keyhelp-delete keyhelp-server Superusers always have access. Notes This is the first public release, so feedback is very welcome, especially from anyone using KeyHelp in production or testing ProcessWire deployment workflows. I built it because I wanted to manage hosting operations from inside ProcessWire instead of switching back and forth between the CMS and the hosting panel. The installer is also meant to make it easier to spin up ProcessWire sites on KeyHelp domains. German documentation is included in the repository. Author: Maxim Semenov Website: smnv.org Repository: github.com/mxmsmnv/KeyHelp

Part 1 of a 2 part Module & Service Reveal. I'm currently working on a new module: ModuleReleaseNotes that was inspired by the work I originally did on making Ryan's ProcessWireUpgrades module "release" aware. In the end, I decided to ditch the approach I was originally taking and instead work on a module that hooked in to the UpgradeConfirmation dialog and the module edit page. Aims My aims for this module are as follows... Make discovery of a module's changes prior to an upgrade a trivial task. Make breaking changes very obvious. Make reading of a module's support documentation post-install a trivial task. Make module authors start to think about how they can improve the change discovery process for their modules. Make sure the display of information from the module support files/commit messages doesn't introduce a vulnerability. Looking at these in turn... Making discovery of a module's changes prior to upgrade a trivial task. This is done by adding a "What's changed section" to the upgrade confirmation dialog. This section takes a best-effort approach to showing what's changed between the installed version and the updated version that's available via the module repository. At present, it is only able to talk to github-hosted repositories in order to ask them for the release notes, the changelog file (if present) and a list of commits between the git tag that matches the installed version and the tag matching the latest version. It will display the Release Notes (if the author is using the feature), else it will display the commits between the tags (if tagging is used by the module author) else it will show the changelog file (if present) else it will show the latest N commits on the master branch (N, of course, being configurable to your liking.) An example of the Github Release Notes pulled in for you, taken from Mike Rockett's TextformatterTypographer Module... An example of a tag-to-tag commit list from the same module... An example of a changelog - formatted to show just the changes (formatting styles will change)... Finally, an example of a fallback list of commits - sorry Adrian ... Making breaking changes obvious. This is currently done by searching for a set of configurable search strings. Later versions may be able to support breaking change detection via use of Semantic Versioning - but this may require some way of signalling the use of this versioning standard on a module-by-module basis. For now, then, you can customise the default set of change markers. Here I have added my own alias to the list of breaking change markers and the changes section of the changelog is styled accordingly (these will be improved)... Make reading of a module's support documentation, post-install, a trivial task. This is done by making some of the support files (like the README, CHANGELOG and LICENSE files) readable from the module's information/settings screen. There is an option to control the initial open/closed state of this section... Here is Tracy's README file from within the module settings page... Make module authors start to think about how they can improve the change discovery process for their modules. There are notes in each of the sections displayed on the upgrade confirmation page that help authors use each of the features... Make sure display of external information doesn't introduce a vulnerability. This is an ongoing concern, and is the thing that is most likely to delay or prevent this module's release lead to this module's withdrawl should a vulnerability be found. Currently, output is formatted either via Markdown + HTML Purifier (if it was originally a Markdown file) or via htmlspecialchars() if it has come from a plaintext file. If you discover a vulnerability, please get in contact with me via the forum PM system. Ongoing... For now, I've concentrated on integration with GitHub, as most people use that platform to host their code. I know a few people are hosting their repositories with BitBucket (PWFoo comes to mind) and some with GitLab (Mike Rockett?) and I would eventually like to have adaptor implementations for these providers (and perhaps GitKraken) - but for now, GitHub rules and the other hosts are unsupported. Links Github: ModuleReleaseNotes PW Module Repository: Here