Leaderboard

ProcessWire automatically sanitises the names of files that are uploaded to a Files field. For example, a file named "Café meals under $30.pdf" will become "cafe_meals_under_30.pdf" after it is uploaded. Since v3.0.212 ProcessWire stores the original unsanitised filename of each uploaded file, and this is accessible via $pagefile->uploadName https://processwire.com/blog/posts/pw-3.0.226/#file-and-image-improvements https://processwire.com/api/ref/pagefile/upload-name/ So if I have a field named "files" on my page and I want to provide downloads of the files with their original filename I can output links like this: $out = ''; foreach($page->files as $file) { // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } echo $out; So far, so good. But I want my site visitors to be able to view PDFs in the browser rather than force a download, yet if they do download them after viewing them I want the files to get the original filename. For this I can use a URL hook to deliver the PDF via PHP rather than directly loading the file. In /site/ready.php: $wire->addHook('/view-pdf/{page_id}/{filename}', function($event) { $id = (int) $event->page_id; $filename = $event->wire()->sanitizer->text($event->filename); if(!$id || !$filename) return 'Invalid request'; // Get the Pagefile via PagefilesManager $pm = $event->wire()->pages->get($id)->filesManager; $file = $pm->getFile($filename); if(!$file) return 'File not found'; // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); // Set headers and output the PDF content header("Content-Type: application/pdf"); header("Content-Disposition: inline; filename=$original_name_unencoded"); header("Content-Transfer-Encoding: binary"); header("Accept-Ranges: bytes"); @readfile($file->filename); return true; }); In the page template file: $out = ''; foreach($page->files as $file) { if($file->ext === 'pdf') { // Deliver PDF files via the URL hook $out .= "<p><a href='/view-pdf/$page->id/$file->basename'>$file->uploadName</a></p>"; } else { // Other files receive a download attribute // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } } echo $out;

Happy 1st of September! Now that we've got the new main/master version out and running smoothly, I've been catching up with some client work this week. I'll need to do some of that next week too. But we'll also be fine tuning the core and fixing anything that comes up in issue reports. We may have have another master version out with these kinds of minor updates before digging into more major updates, feature requests and PRs on the dev branch this month. If you've not yet upgraded to 3.0.226 yet, I'd encourage you to give it a try. So far all reports have been positive and I've not heard of anyone running into any upgrade issues yet. Thanks and have a great weekend!

xss_sanitization option as of v 6.4 can be turned off via configuration: This turns off DOMPurify. https://www.tiny.cloud/docs/tinymce/6/security/#turning-dompurify-off A not so nuclear option might be to define a very limited content filtering option by setting very liberal/empty invalid styles: https://www.tiny.cloud/docs/tinymce/6/content-filtering/#invalid_styles Finally, you can extend_valid_elements if you want to additively include lots of formats you don't want to get stripped out. This preserves the rules set for valid_elements (including the default rules) and throws a layer on top of that.

This is the next module beside the FrontendLoginRegister module which is based on the FrontendForms module. As the name suggests, it has been designed to easily create a contact form for your site with the following characteristics: Fast and easy integration of a contact form inside a template by using only one line of code Show/hide certain fields of the form depending on your preferences and needs Beside the default fields you will be able to extend the form with additional fields if needed Highly customizable (change order of fields, add custom CSS classes,...) Run as many forms on one page as you want Possibility to offer file upload to upload multiple files, which can be sent as attachments Usage of all the benefits of FrontendForms (fe. CAPTCHA, various security settings,...) Multi-language IP of the sender will be send with the email too, so you can use it for IP-blocking if you will get a lot of spam from a certain IP To render a complete working contact form, you will only need to add this line of code to your template: echo $modules->get('FrontendContact')->render(); The output can differ from the image above, because it depends on your settings and customizations, but it will looks like similar to the form in the image. This module is completely new and therefore alpha stage - so be aware of using it on live sites! It works as expected in my tests, but it will need further testing. You can download the module here: FrontendContact or you can install it via the Processwire upgrade-module from the module directory. Alternatively you will find all files inside GitHub. You will also find a more detailed description on the the download page. Live example of this module: https://www.schulfreund.at/kontakt/ As always, please report issues or wishes here or directly on GitHub. Thanks for testing!

@Robin S This is really neat the more I look at it. I wonder if I can drop the upload name into a template field so the admins have a visual frame of reference on the admin screen. Will try this out.

Could you give more details about what you mean by this? Are you trying to import files via the API and this fails somehow? Or you mean that the $ character is not retained in the filename after you add the file to a Files field? If it's the latter I wrote a tutorial you might find useful:

updating this topic for visibility. The best tutorials and working repo I have come across so far are from 0x3 Studio: https://blog.0x3.studio/a-very-simple-to-offer-a-connect-wallet-option-for-your-website-thanks-to-rainbowkit/ The project is bootstrapped using NextJS and RainbowKit. This leaves me with some questions as to whether or not I want to integrate the functionality into a pre-existing ProcessWire site or create a Next.js SPA on a subdomain that accomplishes the functionality I am trying to achieve. It seems like there is not much documentation on working with NextJS and PW at the moment, although these modules seem to be pointing in that direction: Inertia.js for ProcessWire https://github.com/joyofpw/inertia Vue with headless PW: https://medium.com/icf-church-developers/processwire-vue-js-a-lovestory-d4d5bca365 Currently it's beyond my understanding on the best marriage with a front-end framework and/or PW either as a headless CMS, API, or non-headless, but the above examples are leading me into interesting territory.

Version 1.0.0 of the MarkupMenu module released: https://github.com/teppokoivula/MarkupMenu/releases/tag/1.0.0. This release includes a relatively minor, but also potentially breaking change: new argument $root was added to the MarkupMenu::renderArrayItem() method, between some of the existing params. Since this method is hookable this could be a problem for existing code, so I figured it was best to increment major version.