Recently Browsing 0 members
No registered users viewing this page.
I'd like to participate to a documentation about the page flow in PW. I am still a beginner and still have difficulties to see the big picture but I could help to the writing.
What is the flow when a page is displayed or created ? It would be fine to draw a scheme with every stage in which one can add hooks. Something to describe the flow in time.
May be it exists.
What do you think ?
It would be awesome when all the resource about processwire (tutorials, docs, cheatsheet, recipes, videos, api, faq etc...) would be unified on one documentation website called "docs.processwire.com".
The new site would gather infos & data from these resources:
https://processwire-recipes.com/ http://processwire.tv/ https://www.pwtuts.com/ https://processwire.com/docs/ http://cheatsheet.processwire.com/ and would unified it on the final site https://docs.processwire.com.
I think It is far more better to have one endpoint for all the processwire resources & wisdom then mutliple sites. This way it is far more easier to get into the processwire world and choosing processwire as the next main cms for further projects.
The Documentation Site could perhaps look like this (it is just a mockup, so don't expect to much from me ):
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
Today I noticed the Fieldgroups class is missing from the reference, and I wasn't sure why! Does anyone know?
Also, I feel like the docs would be easier to parse/navigate if the API Variables were shown alongside the class they were an instance of.
Config ($config) Field Fields ($fields) Fieldgroup Fieldgroups ($fieldgroups) Fieldtype HookEvent Inputfield InputfieldWrapper MarkupPagerNav Module Modules ($modules) ... Page ($page) Pages ($pages) ... I'm also aware of the API Gen reference page (https://processwire.com/apigen/index.html), which is more robust, but a little harder to parse.