Leaderboard

This week ProcessWire 3.0.214 is on the dev branch. Relative to 3.0.213 this version has 16 new commits which include the addition of 3 new pull requests, 6 issue fixes, a new WireNumberTools utility class, and improvements to various other classes. A newly added $files->size($path) method was added which returns the total size of the given file or directory. When given a directory, it returns the size of all files in that directory, recursively. Improvements were also made to ProcessWire's log classes (WireLog and FileLog) with new methods for deleting or pruning all log files at once. This version also fixes an issue with the front-end page editor (PageFrontEdit) when used with InputfieldTinyMCE. For more details on these updates and more see the dev branch commit log. Something else I've been working on this weekend is a vulnerability scanner blocker and throttler. I don't know if this is an issue for every site, or if it's because this is an open source project site, but we seem to get a lot of vulnerability scanner bots hitting the site. Sometimes they hit the site pretty hard (with hundreds of thousands of requests) and our AWS cluster servers and databases must scale to meet the demand, using more resources, and thus increasing cost. This is annoying, having to scale for a hyperactive vulnerability scanner rather than real traffic. And it always seems to happen in the middle of the night, when I'm not nearby to manually block it. So I'm working on a module that detects vulnerability scanner traffic patterns and then blocks or throttles requests from their IPs automatically. Once I've got it functioning smoothly here, I'll also plan to add it to ProDevTools board download thread in case it's useful to anyone else. Thanks for reading and have a great weekend!

I couldn’t resist the hype and created a simple module using the ChatGPT API to process field values. You can find it on GitHub here: https://github.com/robertweiss/ProcessChatGPT ProcessChatGPT is triggered upon saving, if you select it in the save dropdown. It processes the value of a page field, which can be set in the module config, using ChatGPT. The processed value can be saved back to the same field or to another field on the same page, which can also be set in the module configuration. You can add commands to the value that will be prefixed to the source field content. This way, you can give ChatGPT hints on what to do with the text. For example, you could add ›Write a summary with a maximum of 400 characters of the following text:‹. One of my clients is already using the module to summarise announcement texts for upcoming music events on their website (Let’s face it, nobody reads them anyway 😄). If anyone finds it useful, I would be happy to submit it to the official module list.

On this side, I don't really find the spambots or seo bots to be much of an issue, so I mostly ignore them unless they get too aggressive. It's instead the vulnerability scanners that tend to be the issue here. They are fine when they are throttled. But when they are unthrottled (as is usually the case), they eat up a lot of resources. Here's just one basic example: a vulnerability scanner might send through thousands (or tens of thousands) of URL variations looking for SQL files that it can grab, with dozens of different names each, like db.sql, database.sql, backup.sql, [domain].sql, database-[domain].sql, db-[domain.sql], [domain]-db.sql, and so on and on and on. Then add all the extension variations, .sql, .sql.gz, .sql.tar, .sql.tar.gz, and then add every URL with a trailing slash in the site as the prefix path for every check. So just a scan for SQL files in-the-open might account for tens of thousands of requests. And it'll try to do them all in a very short period of time, making the server like ours scale to meet the demand. Yet this is just an example of one vulnerability check out of thousands that it'll do. Once a vulnerability scanner gets started, it'll run for potentially days. But I usually block them well before that. Once I get an email from AWS about things scaling, I watch the logs pretty closely and then start blocking IPs. But the goal is to have the module just block them automatically. What the module does is that it allows you to define suspicious patterns in GET or POST requests, or user agent strings (and it comes with several patterns to start). For example, you might have patterns to match things like wp-login.php, those SQL request variations mentioned above, requests for .py, .cfm, .rb, .exe files, or others that you don't use on the server, requests containing SQL commands in the query string... these are just obvious examples. Then it lets you define a number of strikes till the IP is out. So for every pattern match, the IP gets a strike. So if I set it to "3 strikes and you are out" then once it gets 3 pattern matches, the IP is blocked for a period of time, also defined with the module. If additional strikes occur while an IP is blocked, the block time gets reset so it starts over, ensuring it's always blocked that set amount of time from the last strike.

Or maybe better update the docs so that they can reference blog posts. We have many important explanations in blog posts and the should be linked from/to the docs imho 🙂

Template Access Log is a straightforward module that logs changes made to template level access settings: the useRoles option, or applicable roles and/or role-specific permissions. This module is primarily intended for use cases where an audit log is needed, and (at least for now) it just logs data to a log file template_access_log.txt and provides no admin view (apart from what can be found from the logs section in admin). Data is logged as JSON: 2023-03-18 18:42:05 admin https://example.com/processwire/setup/template/save {"template":"basic-page","template_id":29,"use_roles":1,"permissions":{"view":[37,1061,1062,1125],"edit":[1062],"add":[1061,1062],"create":[]},"permissions_changed":{"edit":[-1061]}} This is something that I needed for some projects, so thought I'd share it here in case someone else has use for it as well. I may add more features later, but at the moment it's already doing pretty much everything it needs to for my use case(s) 🙂 GitHub: https://github.com/teppokoivula/TemplateAccessLog Packagist: https://packagist.org/packages/teppokoivula/template-access-log

I oftentimes create a checkbox field called 'test' and assign it to certain templates. I check the box if the page is a test page. These pages may exist on the live site and I don't want to hide or unpublish them, but at the same time, I don't want them to appear in the XML Sitemap. (not part of this tutorial, but I also noindex,nofollow those pages using a meta tag in the head so search engines don't index them) In that case, you can remove them from the WireSitemapXML like this in /site/ready.php: $wire->addHookAfter('WireSitemapXML::allowPage', function(HookEvent $event) { $page = $event->arguments('page'); if($page->hasField('test') && $page->test) $event->return = false; });

Using RockMigration's MagicPages feature: <?php public function editFormContent($form) { $form->add([ 'type' => 'markup', 'label' => 'Published at', 'value' => date("Y-m-d H:i:s", $this->published), ]); } No additional fields needed as @Jan Romero said 🙂

mail sent... let's see

Incoming update of Duplicator v1.5 --- Encryption is being implemented, if you want to give a try, the feature is available on the branch feature-encryption : - https://github.com/flydev-fr/Duplicator/tree/feature-encryption More infos and Instructions can be found by reading or running the script generate-keys.php on a terminal. --- I shared infos with Steve, I also want to share it with you : => Test on a Package of 687MB on PHP8.1 Do not take care of performance info given on this post, see 👇

Use decimal, already in the core, see (FieldtypeDecimal uses InputfieldFloat): https://github.com/processwire/processwire-requests/issues/126 https://weekly.pw/issue/367/ "Float and integer fields are now considered compatible with the newly added decimal field, making it possible to convert these from one type to another." If you feel like applying custom formatting in the admin, see :

Thanks for all of your comments and suggestions. I renamed the module to PromptChatGPT (thank you @gornycreative for the input!). The renamed repo can be found here: https://github.com/robertweiss/PromptChatGPT Additionally, I have included the composer vendor folder by default, which seems to be a better and easier way to distribute modules. Thanks to @wbmnfktr for bringing this to my attention. Regarding the curl/ssl errors, as you have already deduced, these seem to be linked to the external dependency https://github.com/orhanerday/open-ai. Therefore, if the issues you mentioned persist, we should consider creating a new Github issue there. For easier debugging, I have added a ›test settings‹ option to to verify if ChatGPT responds correctly. I have also included a new option to select templates that should include the dropdown option.

Perhaps obvious, but do not use float for money. It will result in rounding errors. Also, regarding allocations (if you go this way), consider early if you need more than one per payment. E.g. if you need to allocate payment per invoice/order row, or allocate overpayment separately, etc. And also give some thought to how you'll handle returns/rebates etc. (In my experience two-way sync is rarely necessary, since PW makes querying data easy anyway. But you will likely need some hooks to keep things like order payment status in line with payments.) I recently built a system that handles event registrations and product sales, and my approach was basically "approach 3". One question is if you need to also handle accounting reports, and at what level. Honestly this is all relatively simple until debit/credit entries, cost centres, accounts, etc. get into the picture. In my case I do need to handle that, so each order/allocation logs a separate accounting row, which I later use to produce a sensible report. Including actual time of each event, which is super important here.

@joshua Wow, you're faster than light 🔦 Thank you 🙂 https://github.com/webworkerJoshua/privacywire/releases/tag/1.1.2 Tested this on one of my sites and it works like a charm.

🤡 How to provide solutions to the community for free forever working on ProcessWire ? 🤖 Apply to the following job, do physical activity to prevent hypertension and improve mental health 👇

Most likely this commit in ProcessField.module (now) at line 2562 - $value = $sanitizer->words($value); + $value = $sanitizer->getTextTools()->strtolower($sanitizer->words($value));

That's because there isn't one yet. I have the search functionality somewhere back in my mind. Promised! I thought I keep it simple. As mentioned above the search functionality will come, yet I'm not sure about which way I go here. For now the whole setup is more a proof-of-concept but we will get there. You are absolutely right about that. For now in an upcoming version I went another route with this as just plain white and shadows didn't work out that well on the eyes as well. I have some thoughts and ideas here to solve this dead end kind of browsing. I guess we will have this next week. Depends on other projects. You can just send a pull request with an updated version of the recipe. There is no rule against several solutions in one recipe. In my opinion this would be actually really awesome to show and tell that there are different ways. So feel free to either submit a new or updated recipe. I really appreciate both! In case you update the existing recipe you want to update the version, if available or give a new one, and add yourself to the authors. I updated the recipe sample here. In case you or someone else need additional data points like ProcessWire min/max versions or similar. Just add it to the recipe, let me know in the PR and we get it sorted. Thanks guys for all the great feedback and ideas!

https://github.com/elabx/FieldtypeRecurringDates Well a few summers later, finally got like a sort of working version. For info please take a look at the repo's readme. It's still super alpha but going to deploy into a couple websites to replace Recurme so wish me luck. This module is only a Fieldtype and Inputfield, there are no "markup" modules as there used to be in Recurme. I'd appreciate any testing or any kind of comments.

Then I must say that the bad performances was due to my machine and/or setup (caddy/php-fpm, thats is quite bad and sad on Windows). On the Windows Server, performance are 🚀 ! A backup of a setup of 2.11GB, once compressed, 801MB, the whole process took 107sec ✅ 🎉🎉 encryption: 2.5sec decryption: 3.5sec Not bad 🙂

<?php public function editFormContent($form) { $form->add([ 'type' => 'text', 'name' => 'published', 'label' => 'Published at', 'value' => date("Y-m-d H:i:s", $this->published), ]); } public function onProcessInput($form, $input) { $pub = date("Y-m-d H:i:s", strtotime($input->published)); $query = $this->wire->database->prepare( "UPDATE pages SET published=:pub WHERE id=:id" ); $query->execute([':pub' => $pub, ':id' => $this->id]); } 🙂

I think I should add some infos about generating a working API key in the readme 😅

Okay, I got a proper answer once I switched to an account with credits. Awesome. { "request": { "model": "gpt-3.5-turbo", "messages": [ { "role": "user", "content": "This is a test for ChatGPT. Do you hear me?" } ] }, "response": { "id": "chatcmpl-...", "object": "chat.completion", "created": 1679504670, "model": "gpt-3.5-turbo-0301", "usage": { "prompt_tokens": 21, "completion_tokens": 18, "total_tokens": 39 }, "choices": [ { "message": { "role": "assistant", "content": "\n\nYes, I can hear you loud and clear! How can I assist you today?" }, "finish_reason": "stop", "index": 0 } ] } }

I imagine this may also be achieved without an additional database field using FieldtypeRuntimeMarkup: https://processwire.com/modules/fieldtype-runtime-markup/

The "published" hook is in the Pages class. So it should look something like this: $wire->addHookBefore('Pages::published', function($event){ $page = $event->arguments(0); if($page->template->name !== 'templateName') return; $this->message("the Hook has been called"); if($page->hasField("myDateField")) { $newDate = date("d.m.Y"); // Need to call "save" explicitely after publishing since saving is already done by then. // Wrapped it all in a single call, not changing modified user and timestamp again $page->setAndSave('myDateField', $newDate, ['quiet' => true]); } }); You could consider hooking Pages::publishReady instead and set your myDateField there, that would save you the second write to the database.

Another thought, you may want to record invoices separately from orders, to deal with unsatisfied or partially satisfied orders. Alternatively this might be handled by status fields on order lines. At the risk of repeating myself, getting the business specification right is paramount. PS I absolutely agree with @teppo regarding decimal fields. A slip on my part.

BTW, on the frontend I use this https://github.com/brick/money which works well. It is a bit verbose to do math like that, but worth the hassle.

You can view the path history when the page is open in Page Edit, on the Settings tab: And from the API:

Just thinking loud: Maybe it's enough to have some links to the related blog post in the docs. Sometimes I'm missing some code examples, so I'm searching through the blog and almost every feature is well documented and explained there, too.

Another reason for doing some deep thinking about the entity model before choosing. If payments can only ever belong to an order (and only one order) then they should be children of the order otherwise they risk being orphans. If payments can cover more than one order, then they should stand alone, but you need to do serious thinking about how they are allocated to each order if the amounts don’t match exactly. This might be achieved via an “allocation” field (float or decimal) in the order and the payment. And/or you might need to split orders down into order lines. An accurate understanding of the business model is required. Plus how it might evolve. Then do the entity modelling. Lastly decide how to implement in PW. And don’t forget that @Robin S‘s excellent ConnectFields module is just the biz for maintaining many-many relationships (e.g. between the two allocation fields referred to above).

We need to think about pros and cons when choosing. The pro arguments for 1 is that you have all data in a page tree visually related and that you can easily delete all related data deleting the corresponding order branch. As always, these pros are also the cons for the the opposite solution (3). Choosing 3 you can more easily see the lists of payments and fulfillments records. You can delete orders without deleting connected payments and fulfillments records if you need, but you also have to deal with the housekeeping when deleting by yourself. If you build the dedicated UI for all that in admin it might not even matter. As for me, feel inclined to go the 3rd root and do not see any arguments going the 2nd.

Exactly. I'm happy that you see and understand the potential and that you share that 🙂 Definitely 🙂 Thx for the comment! Having everything in one huge migrate.php does not only have the drawback of getting messy quickly. It does also mean that your migrations get slow, because whenever you change anything in that file all migrations will run, no matter if they are necessary or not. If you have everything in separate files on the other hand you get cleaner code, easier to understand chunks and RM will only trigger the migrations that have changes since the last page load, which makes page loads usually be ~1s here even when migrations run. Yep! 🙂 If you understand the principle once, then you will instantly understand every project you are working on that follows the same simple principles.

ChatGPT is soon to replace Google, Stackoverflow and Quora for answering questions like these. I have used it to either confirm or throw speculation on topics and directions of research. I have asked it very technical academic questions in certain fields and it has given balanced views for just about everything, including outsider views and newer untested views on certain problems. Very fun. It has even been able to tell me when a problem that I thought still existed has already been resolutely solved. Such a time saver! My main comment, though, is that the marriage of page classes and migrations is truly groundbreaking in terms of modular design and in particular the ability to bring over single files that can instantly put in (or remove) scaffolding for demos. This has been AWESOME for live brainstorming and troubleshooting or providing clients with examples of how extensible the system is and how quickly modifications and improvements to functionality can be built out. This has made me more excited about using RockMigrations - I was a bit on the fence when the automation was centralized in migrate.php because of how unwieldly automation scripts can get in other applications I use - but bringing things that involved scaffolding into their respective page classes allow me to really just use migrate.php for mod installations, configuration, general hooks and other core modification processes. This is way easier to navigate, share and especially train on. This method is very easy to coach new devs on also.

Chatsonic examples: How to create a page with the API of ProcessWire? How to return an array in ProcessWire?

Note to anyone using potentially using this module: A page-edit-redirects permission has been added to the core - https://github.com/processwire/processwire/commit/dafceffc6f5d2d10c395faa1586ef0993633e6de - and once this hits the master branch I intend to rework this module so that it provided a list of redirects in the system. As the permission can be added to any user role, management of those redirects will happen in the page editor instead of the 'cloned' redirects editor this module currently provides. Cheers, Chris

Nice. Does the module offer a UI under the admin tree? I'm asking because there are naming conventions for PW modules. And the prefix "Process" is usually reserved for modules that have a page associated under the admin tree. Like ProcessPageLister etc. You might want to consider renaming your module before submitting it to the directory.

ChatGPT helped me to improve RockMigrations - it's a little scary but it really saved me time today. First, I wanted to support single paths (not json) in the workflow file definition: That worked after I adjusted the variable defaults of input.PATHS to "{}" so that the parsing does not throw an error. No idea why it actually seems to parse the json even if the if-condition is not met, but it works now, so I'm happy with that. Then, as that worked quite well, I tried to fix a warning that I've been getting for quite some time and that worked even better: All updates are on the dev branch.

@wbmnfktr Have you given Jeffrey Star's 7g firewall a try? Very simple install straight into your .htaccess file.

Sounds great for sure! Thank you in advance.

I also sort of have this scenario and decided to use separate Time fields to indicate start and end time of each occurrence. I just have to assume that the occurrences have the same time.

This week the focus was on core updates and we have a quality mixture of minor issue fixes, pull request additions, and other improvements in ProcessWire on the dev branch. My favorite addition was from a PR by @matjazp that makes improvements to ProcessWire's pagination module, MarkupPagerNav. See more updates and PRs in the dev branch commit log as well. There's still more to add before we bump the version to 3.0.214, so stay tuned for that next week. By the way, if you've recently launched any new sites in ProcessWire, please add them to our sites directory. I think most of us are already subscribed to the ProcessWire Weekly email, but just in case you aren't, you can subscribe here. The email content is from weekly.pw written by @teppo and is great to read, highly recommended! Thanks and have a great weekend!

WEBP to JGP Converts WEBP images to JPG format on upload. This allows the converted image to be used in ProcessWire image fields, seeing as WEBP is not supported as a source image format. Config You can set the quality (0 – 100) to be used for the JPG conversion in the module config. Usage You must set your image fields to allow the webp file extension, otherwise the upload of WEBP images will be blocked before this module has a chance to convert the images to JPG format. https://github.com/Toutouwai/WebpToJpg https://processwire.com/modules/webp-to-jpg/

Great to see someone tackling this 🙂 I wish you all the best for the challenge 🙂 Do you have some screenshots? And maybe a short description how the module works from a technical point of view? Why did you split the finding part in a separate module?

@snck I am currently working on implementing Repeater Matrix support. It is basically working but needs some more thorough testing. ATM the setMatrixItems() method seems to be working well. If you like, you can grab a copy from https://github.com/gebeer/RockMigrations/tree/repeatermatrix and test it out. This is how you create a Repeater Matrix field: // first create the blank field $rm->createField('repeater_matrix_test', 'FieldtypeRepeaterMatrix', ['label' => 'Product Content Blocks', 'tags' => 'products']); /** * Set items (matrixtypes) of a RepeaterMatrix field * * If wipe is set to TRUE it will wipe all existing matrix types before * setting the new ones. Otherwise it will override settings of old types * and add the type to the end of the matrix if it does not exist yet. * * CAUTION: wipe = true will also delete all field data stored in the * repeater matrix fields!! */ $rm->setMatrixItems('your_matrix_field', [ 'foo' => [ // matrixtype name 'label' => 'foo label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], 'bar' => [ // matrixtype name 'label' => 'bar label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], ], true); Still need to test the other methods for removing/adding items etc. But this one should work. At least it was working in my tests. When testing is completed I will make a PR so @bernhard can implement.

Yes, the blog is a PW website. I've had the honor to write one post there some time ago 🙂 I agree that it would be nice to have it on github so that everybody can contribute. But we have lots of blog posts and converting all of them would be a lot of work I guess. But realistically I think nobody would ever contribute a lot except from maybe reporting typos... So I doubt it would make a huge difference if everything was hosted on github.

Is there a simple way to turn the cookie banner active/inactive in the module settings? I would like to prepare a default banner for my projects that is not shown by default.

I did indeed. And was quite happy in some instances. To be honest... I don't know if it was the 7g or another version. Somehow the 7g sounds unfamiliar at the moment. I might say it was 5g or so. Not sure at the moment. But for sure it was from perishablepress.com. It was recommened quite a few times. Yet it wasn't always working back in the days in all instances and therefore I went on and looked for more solutions and ended somewhere around Cloudflare and some other CDNs. Nowadays I almost always (if possible) sign up and stay there at Cloudflare. I really love what you get there.

TL;DR Just copy this folder to your module and get fully automated releases, tags, changelog and with one additional line of code (see note below!!) also fully automated version numbers for your PW modules! Update: There is a problem with this approach. Grabbing the version number from JSON does not work in the modules directory at the moment. See the discussion here: https://github.com/processwire/processwire-issues/issues/1690 Background/long story: @dotnetic asked me some time ago to use conventional commits for my modules. It was totally new to me, here is the link: https://www.conventionalcommits.org/en/v1.0.0/ I've since adopted that workflow to most of my modules, as it is really just copy and pasting the .workflow folder (and you can simply copy that folder from RockFrontend: https://github.com/baumrock/RockFrontend/tree/main/.github/workflows) This workflow is great, because It will create new releases automatically for you: https://github.com/baumrock/RockMigrations/releases It will create new tags automatically for you: https://github.com/baumrock/RockMigrations/tags (This is something that I always forgot and someone was asking for it long time ago, because tags are important if someone uses composer to manage their modules, as far as I understood. Now I can't forget them any more 🙂 ) It will create a changelog for you automatically: https://github.com/baumrock/RockMigrations/blob/main/CHANGELOG.md And last but not least: It will create version numbers automatically for you. One thing that has always been annoying though is that you have to make sure that the version number that is automatically created matches the version number that you set in your modules .module.php or .info.php file. I have always tended to have everything in my .module.php file, but I just recently noticed that this can lead to problems if you are using PHP8 syntax in your module and the website still runs on PHP version <8 --> You end up getting a fatal error whenever the module is loaded, which totally breaks ProcessWires module backend. The solution is easy though: Just split your module config into two files - the .module.php with all the module's logic and the .info.php file with only the array that defines the module's info array. Thx for that reminder @BitPoet! Here is the HelloWorld's info.php file with some helpful comments: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.info.php I did that today for RockMigrations and I realised that you can even fully automate the version numbering of your module, because the conventional commit workflow creates a package.json file that holds the version number in a json string: https://github.com/baumrock/RockMigrations/blob/main/package.json All you have to do is to grab that json string and write that version into your module's info.php file: https://github.com/baumrock/RockMigrations/blob/92a33ba4e7146a69fb1f52d5b67270b66d9f1e54/RockMigrations.info.php#L5-L9 Afraid of a performance penalty? You don't have to. The module's info is cached by PW and only updated on modules::refresh! Maybe other module authors like @adrian or @Robin S or @kongondo or @teppo or @netcarver or @Macrura or @flydev want to adopt that workflow as well. Thx for reading and have a great weekend 🙂

@bernhard I made a little tweak to the rf-scrollclass script. Okay it was not me directly. Instead I asked a certain AI if it is possible to alter the script... just for scientific purposes of course 😉 I want to add multiple rf-scrollclass attributes to one DOM element: <header class="rf-scrollclass" rf-scrollclass="scrolled@20 scrolledmobile@15"> Now the class "scrolledmobile" gets added at 15px, the "scrolled" class gets added at 20px - all on the same element. This gives me the ability to use css media queries for some responsive tweaking of the position of my fixed navbar (for example!) header { position: absolute; top: 40px; width: 100%; z-index: 100; @media @min-m { &.scrolled { top: 20px; position: fixed; } } @media @max-s { top: 30px; &.scrolledmobile { top: 15px; position: fixed; } } } Long story short, here's the updated script: (function () { let scrollElements = document.querySelectorAll("[rf-scrollclass]"); for (i = 0; i < scrollElements.length; i++) { let el = scrollElements[i]; let attrs = el.getAttribute("rf-scrollclass").split(" "); for (j = 0; j < attrs.length; j++) { let parts = attrs[j].split("@"); if (parts.length != 2) return; let cls = parts[0]; let y = parts[1] * 1; window.addEventListener("scroll", function () { scrollpos = window.scrollY; if (scrollpos >= y) el.classList.add(cls); else el.classList.remove(cls); }); } } })();

Yes! Seriously, someone pls email @ryan about this. If no one else will do it, I'll do it. My new favorite ProcessWire infographic:

Following steps: Download the latest stable version of PW here Unzip the files Rename index.php > index_new.php and wire folder to wire_new Upload the files via FTP to your website root folder Rename ./index.php to ./.BAK.index.php and ./wire/ to ./.BAK.wire/ on server side Rename ./index_new.php > ./index.php and ./wire_new/ to ./wire/ Refresh the whole site > you maybe forced to relogin. Reload the modules by clicking the button on example.com/processwire/modules/ in the upper right corner After that you could use the ProcessWireUpgrade module to upgrade the other modules. Steps are also documented here: https://processwire.com/docs/start/install/upgrade/ if you have troubles have a look right here: https://processwire.com/docs/start/install/troubleshooting/#troubleshooting-upgrades Cheers 🙂

I guess they are able to trash pages but just don't see the trash button on the page list? Modules > Core > ProcessPageList > Check the checkbox to allow non-superusers to use the trash button from the pagelist