netcarver

It's available. Extremely alpha. If you discover a security related issue, please get in contact via the forum PM system. Feel free to post any other issues here. PW Repo Entry: ModuleReleaseNotes Github: ModuleReleaseNotes Thanks to @adrian and @Mike Rockett for their kind assistance.

Changelog styles now improved. Here's a changelog from the update screen - no breaking changes detected... ... and here it is with breaking changes ... Raw markdown also get's labelled...

I forgot to mention that the support file list is not limit to a single readme file. If your module has more than one, they can all be listed and read. This might prove useful for people looking for a self-hosted documenting solution. As an example, here is a screenshot of the readme files from the module itself... Which allows the documentation to be split.

Thanks for the encouraging feedback folks! @Robin S There's an option to turn off the timed author-auto-shock-via-email(tm) feature which should stop it telling you off too much Actually, the module gives you some options here - including doing nothing more than using git to commit your code - which we all do already. But I think I take your point; I guess the module could induce some of our users to nag us about keeping the upgrade process free of yellow notes. Regarding guidance, I think it partially comes down to your own style working and issuing releases. For example, I commit lots of small changes - which makes my commit log pretty long and difficult to review. In my case, forcing myself to either keep a concise changelog file or to git tag my releases and then use the github release-notes feature, can be better for my module users. Even if I didn't want to start using Github's Release Notes or keeping a changelog, simply learning to add a git tag on each version increment is an improvement, as it allows the length of the commit list to be automatically limited to what is relevant. For someone like Ryan, who tends to commit larger changes at lower frequencies, just using the git-tags feature to limit the list of commits to those between your installed version and the newest version is probably all that is needed.

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

Has anyone had any luck getting this textformatter to work on CKEditor fields that are part of a repeater matrix itemtype?

Here are a few links to check out for PW calendars. I'm not recommending a solution here, just signposting. These are in the official PW module repository... https://github.com/ffub/MarkupiCalendar (iCalendar feeds anyone?) https://github.com/netcarver/PW-ProcessGcalEmbed (My old module) http://www.99lime.com/modules/recurme/ (Premium) These aren't (a.f.a.i.k.)... https://github.com/plauclair/Calendar https://github.com/ryancramerdesign/MarkupLoadGCal (Ryan's module) https://github.com/decadeofdefeat/church-website-processwire (Has a calendar implementation in it) https://github.com/lindquist/processwire-calendar https://github.com/UF-Asq-Fab-Lab/Scheduler Hope that helps!

In the past, I've had to delete multiple tens of thousands of records (pages) and did it by pushing the ids of the pages to be deleted into a WireQueue and then, at regular intervals (think cron-driven), pull out small batches of them to delete. To completely empty the queue takes a long time, but the admin interface remains responsive and you simply need to check the number of items remaining in the queue to know how far through the process you are.

A very simple textformatter that was inspired by Diogo's RemoveHeight textformatter. This one strips the height from any images and either adds a custom class or adds a max-width:100% as an embedded style. Github: https://github.com/netcarver/TextformatterFluidImages PW Repo: here.

@adrian Ah, git tags at last. Nice.

By strange coincidence, I was just thinking that maybe PW should have a standard EditorConfig file as part of the suite. Whilst it does not address all of the code styling issues raised above, it would allow us to all get the tabs/spaces/line endings/whitespace trimming right for this project by just using an editor that either supports EditorConfig out of the box, or via a plugin. I've started using it on my current project and it seems to work quite well.

@Mike Rockett Have the permissions changed on the containing directory such that there is no longer any write permission?

Please try... wire('settings') Note the difference in quotation marks - the forum editor changes single quotes to curly quotes (at least, they look like it to me) Such quotes are not accepted as string markers in PHP, so if you copied-and-pasted directly from Macrura's reply, you would probably get an error like that.

@matjazpThank you! I've also issued a couple of very minor pull requests on top of this new feature. Nevermind, I see you already pulled them. Thanks again!

Thank you! I'd also like to throw in a request for the module to optionally make backups of files before overwriting. A simple copy to .<filename>.<definable extension> would be great. Best wishes, Steve

@DaveP I've now initiated a pull-request for your consideration.

@DaveP, I've found this useful over the past week on a client project, so a big thank-you! I think you should change the filename & classname of the module from "TextFormatterInsertDummyContent" to "TextformatterInsertDummyContent" though. At the moment, this module does not appear in the modules list grouped with all the other Textformatters but it is in its own, lonely, "Text" group. Unfortunately, this does require making a breaking change to the module, as the filename and class name (plus internal path names etc) all need to change. The upshot of which is that the module can't be simply upgraded (at least, I think not.) Anyway, I've forked your repo (here) and made some changes. I've also added code to randomise the output on each call. There is also a corporate branch that sources its 50 paragraphs from Corporate Ipsum.

@matjazp Just sent in a pull request for your consideration. I was in need of an admin edit option that would allow me to specify files in the templates/styles/skin subdirectory of a site under development. I therefore added a recursive scan of the templates/ directory to the config options for the root of the editable files. I also noticed that whenever I used the module to edit one of the files (hosted on a linux server) , git would pick up every line of the file as having changed, not just the little edits that had actually been made. It seems that the post of the file through to the back end was converting all the original linux end-of-line characters into Windows end-of-lines. This makes finding and describing edits made by clients very difficult. I therefore added a config option for you to specify what line endings to use on save (Win/Mac/*nix) so the files show no eol differences and git diff shows only what was really changed. Small update to the choice of font-awesome icon too. Thanks for considering!

Thanks to a pointer from Adrian, I just found this thread. Want to cross-reference this post here. There are a few possible ways of handling this and I'd like to work on the issue after I finish my current client work.

This issue hit me a while back too with the RepeaterMatrix field. I ended up posting about it in the Profields support board but, embarrassingly, forgot to let you know about it at the time, jaro. My apologies to all for the oversight.

@Mike Rockett That looks even better - having it as a popup would be good.

If anyone's interested, I've forked Ryan's ProcessWireUpgrade module and added the ability for it to detect if github has a tagged release for the latest version of each listed module (except for the PW core repos which will require special handling). If a tagged release entry is found, it then adds an extra link to the table. This is strictly an alpha "proof-of-concept" experiment, but if you are interested my fork of the repo is here - just replace the current version of the module code with my fork and you should be OK. Providing module authors start tagging their releases on github, it will allow you to navigate to the release notes for review before you hit the upgrade link. As you can see, Mike Rockett has already started tagging his releases - and hence his module gets the extra "Release Notes" link. Worthwhile idea?

It could be as simple as having an offsite link to the github release page for the version. I believe it could be auto-generated, as they all (currently) follow the same format... https://github.com/<user>/<project>/releases/tag/<upgrade-version> =================================== | Known to PW from the module repository? Updated to add: Yes, just trying the locally and it seems to work. Not difficult to pull the repo URL along with the other data and use it to add a "Changes" link next the new version. A little more use of WireHttp() requests to check if the links are sending back a 200 or 404 page and we'll know which items have release tags.

@Mike Rockett I like the use of release and the changelog - please keep it up. In fact, I think I need to adopt this with my own modules going forward. It would be really nice if ProcessUpgrades - or the PW core - could send us to a module's release notes before we decided to update it.

@Macrura Thanks for the reply. It's good to know that you are having success with the module approach - I did take a brief look at it as I like the idea, but I ended up passing it over when I realised there was no support for images out of the box. Could you perhaps issue a pull-request to the module author with your changes? They sound like a worthwhile addition.