Recently Browsing 0 members
No registered users viewing this page.
Send "push" from ProcessWire to Pulseway.
PulsewayPush simply send a push to a Pulseway instance. If you are using this module, you probably installed Pulseway on your mobile device: you will receive notification on your mobile.
To get more information about Pulseway, please visit their website.
They have a free plan which include 10 notifications (push) each day.
Install the PulsewayPush module.
Then call the module where you like in your module/template code :
<?php $modules->get("PulsewayPush")->push("The title", "The notification message.", "elevated"); ?>
___push() ___notify() (the two function do the same thing)
Github: https://github.com/flydev-fr/PulsewayPush Modules Directory: https://modules.processwire.com/modules/pulseway-push/
Examples of use case
I needed for our work a system which send notification to mobile device in case of a client request immediate support. Pulseway was choosen because it is already used to monitor our infrastructure.
An idea, you could use the free plan to monitor your blog or website regarding the number of failed logins attempts (hooking Login/Register?), the automated tool then block the attacker's IP with firewall rules and send you a notification.
- - - - - - - - - - - - - -
11-22-2017: added the module to the modules directory
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.
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.
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.
PW Module Repository: Here
I was wondering if anyone knew what this did?
If so, do you know what modules it actually impacts? Is there another log that lists the action it took?
I'm having some weird problems with PHP duplicate declaration per link below, since this module was run.