gRegor

To clarify and gently push back on this, prefers-reduced-motion isn't just for people who may have a preference for no animation. Personally I'm fine with animations. It's an accessibility feature that allows people who may be affected by animations (e.g. vestibular disorders) to send a signal to websites from their OS or browser. It's good practice to check for that and respect it, when possible, especially if they're non-critical animations.

Updated the thread title and first post, appears to be resolved either way (new site, or fluke on old site). Thanks!

In a similar accessibility vein, you might consider supporting prefers-reduced-motion to toggle animated/static content.

A fair question to ask. I haven't used the ProcessWire API docs section with the new design extensively yet, but my initial reaction is that it's not too bad. Search is still front and center at the top, and that's usually how I have navigated it, e.g. by searching "mail". I don't find the permalinks for individual items causing much extra scrolling so far, seems comparable (https://processwire.com/api/ref/wire-mail-tools/ vs https://processwire.com/api/ref/wire-mail-tools/?oldsite=1, for example) There might be a PW way to make it more customizable, but it's also always an option to set up user stylesheets in your browser to tweak the site.

Love the new look! Congrats! A couple small things with Javascript disabled: the sections down the page like "Total control over the design" don't show anything in place of those animations. It would be nice to have some static image fallback in that case. Also in the ProcessWire Weekly subscribe prompt at the bottom, the caret on the button does not appear when JS is off, so it just looks like a form input with a circle next to it.

Edit: this appears to be resolved as of at least 2025-08-08, whether due to the new site design launching or due to a temporary fluke earlier on. I noticed today that on some API reference pages like https://processwire.com/api/ref/wire-mail-tools/, the CSS for the code sample appears to have broken a bit: code is appearing all on one line, syntax highlighting is slightly off. Screenshot attached. It does not appear to affect individual method pages, e.g. when I click into https://processwire.com/api/ref/wire-mail-tools/from/ it looks correct. I'm on Windows 10, Chrome 138.0.7204.169 Screenshot:

With the help of this thread and this StackOverflow response, I think this is working for me with TinyMCE so far: In site/ready.php: $wire->addHookAfter('MarkupHTMLPurifier::initConfig', function(HookEvent $event) { $config = $event->arguments(0); $def = $event->arguments(1); $config->set('HTML.SafeIframe', true); // Allow YouTube and Vimeo $config->set('URI.SafeIframeRegexp', '%^(https?:)?//(www\.youtube(?:-nocookie)?\.com/embed/|player\.vimeo\.com/video/)%'); }); Then, in the PW admin for the textarea field > Input tab > Custom Settings JSON: { "extended_valid_elements": "video,source,iframe[src|width|height|title|frameborder|allow|referrerpolicy|allowfullscreen]" } Note the list of attributes in square brackets after the "iframe". You can use wildcard `[*]` if you want to allow any attribute, though I haven't experimented with that. Finally, clear the HTMLPurifier cache from Tracy Console as described in that GitHub conversation: $purifier = new MarkupHTMLPurifier(); $purifier->clearCache(); This is very fresh, I'm still testing it out, but it seems to work. Might still need to add that bit from SO for the `allowfullscreen`: $def->addAttribute('iframe', 'allowfullscreen', 'Bool');

I think I have this working, but part of it feels hacky. In the form config, I set the destinationPath to the final location (no intermediate temp directory): $destinationPath = $this->config->paths($this) . '.uploads/'; $destinationPath = $this->config->paths($this) . '.uploads/'; Calling processInput() will handle the upload and move the file to that destination using the original filename. That process also sets up a Pagefiles object as the value of the InputfieldFile. This is where it gets kinda hacky: That Pagefiles object defaults to the current admin page that the form is uploading via, so it sets the paths to that page ID instead of the destination path. Despite this, that is not where the uploaded file is. Example dump of the object (key parts): ProcessWire\InputfieldFile Object ( [className] => InputfieldFile [attributes] => Array ( ... [value] => ProcessWire\Pagefiles Object ( [count] => 1 [url] => /site/assets/files/####/ [path] => /full/path/to/site/assets/files/####/ [items] => Array ( [uploaded-filename.csv] => Array ( [url] => /site/assets/files/####/uploaded-filename.csv [filename] => /full/path/to/site/assets/files/####/uploaded-filename.csv ... [filedata] => Array ( [uploadName] => Uploaded-Filename.csv ) ) ) ) [type] => file ) ... ) Finally, I can get the basename of that uploaded file, build the correct path to the file with `destinationPath`, and use $files->rename() to rename it to the desired scheme: $form->processInput($this->input->post); // should add a check for $form->getErrors() here $field = $form->get('scores_upload'); $original_filename = $field->value->first()->basename(); $result = $this->files->rename( $field->destinationPath . $original_filename, $target_filename );

Hm, well a bit of progress: I realized that InputfieldFile has its own usage of WireUpload already (source). I was originally thinking that it uploaded the file only to a tmp directory, then I had to manually use WireUpload to move it to the long-term location. The InputfieldFile method will largely work, but unfortunately it doesn't let me call `setTargetFilename()` on the WireUpload, so I might not be able to enforce the naming scheme I was using. I'm still really curious why this stopped working after the upgrade. So far, comparing versions, InputfieldFile seems to work pretty similarly.

I've looked through quite a few threads and the source code, but unfortunately have not found exactly what I was looking for. I recently upgraded to PW 3.0.246 on PHP 8.2 and I'm wondering if there's some breaking changes I need to adjust for: I have an admin module using InputfieldFile (noAjax) that prompts for a CSV file and uses WireUpload to handle it by creating a unique name and moving the file to a longer-term location. This worked pretty smoothly on PW 3.0.165 (I think it was around that version), but seems to be failing now with "Unable to move uploaded file". Code snippets below. This is inside a Process module called ProcessMemberScorecard. These aren't large files and all the directories exist and should have correct permissions: // start out by creating a WireTempDir based on the class name $destination = $this->files->tempDir($this->className)->get(); // then an InputFieldWrapper is created and field configs with importArray() $wrapper->importArray( [ [ 'type' => 'file', 'name' => 'scores_upload', 'label' => 'Scores File', 'description' => 'Select a CSV file to upload', 'icon' => 'upload', 'extensions' => 'csv', 'destinationPath' => $destination, 'maxFiles' => 1, 'maxFilesize' => 10 * 1024 * 1024, 'noAjax' => true, 'descrptionRows' => 0, ], // more field configs... ] ); Then on POST request, the form is processed and a WireUpload is run: if ($this->input->requestMethod('POST')) { $form->processInput($this->input->post); $ul = new WireUpload('scores_upload'); $ul->setValidExtensions(['csv']); $ul->setMaxFiles(1); $ul->setOverwrite(true); // this appears to correctly set the full system path for /site/modules/ProcessMemberScorecard/.uploads/ and that folder exists and has a lot of previously uploaded files from this module $ul->setDestinationPath($this->config->paths($this) . '.uploads/'); // set up final filename for destination $dt = new DateTime(); $tmpname = bin2hex(random_bytes(8)); $ul->setTargetFilename( sprintf('%s-%s.csv', $dt->format('Y-m-d'), $tmpname ) ); $results = $ul->execute(); if (count($results) == 0) { foreach ($ul->getErrors() as $error) { $this->log->save('scorecard', $error); $this->error($error); } return $form->render(); } // get final filename from $results[0] and do additional processing } I'm still getting errors like "Unable to move uploaded file to: /site/modules/ProcessMemberScorecard/.uploads/2025-03-04-a4604381bbe12d34.csv" I have tried changing the permissions on that `.uploads` directory in the module to 0777 (bad!), but still getting the same error. Is there something in newer versions of WireUpload that prevent moving files into folders with a leading dot? I couldn't find anything like that in the source code, but just trying to think though all the possibilities. Thanks for any help!

Version 0.2.3 of the ProcessWire IndieAuth Module is released: Fixed a bug when adding profile information to a token response Install now attempts to add the introspection-endpoint Improved admin: list of granted access tokens Add an option to no longer advertise the backwards-compatible link-rels. These remain on by default; future release may change to off by default. More in the changelog

This is great! I don't currently run AdminOnSteroids module, so I'm wondering what the easiest way to add this CSS to the admin area is?

Version 0.2.2 of the ProcessWire IndieAuth Module is released: Admin tools to support the Client Credentials flow and manually adding a token when testing Added an Introspection endpoint Updated client information discovery. It now prefers the JSON document and falls back to parsing microformats2. Scoped dependencies so this can more easily run on the same site with ProcessWire Webmentions without conflicts More in the changelog

Related: a helpful lib I've been using for URL normalization and parsing is https://sabre.io/uri/

4.25.18 appears to still have the issue. It's in these lines: $info = parse_url($_SERVER['REQUEST_URI']); $parts = explode('/', $info['path']); I added some debugging and a proof of concept workaround (surely not correct) for the missing path: $info = parse_url($_SERVER['REQUEST_URI']); if (array_key_exists('path', $info)) { $path = $info['path']; } else { $path = '/'; } $parts = explode('/', $path); I think the more correct thing to do is ensure a full, valid URL is passed into parse_url() to ensure the path gets parsed correctly. I can file a github issue if that helps.

@adrian Oh interesting, I had just updated it before posting, but I see there's actually 4.25.18. PW might have had .17 cached as the newest version. I'll update again.

I'm experiencing this in production, not with Laravel. It appears to happen when the path has an empty segment, e.g. https://gregorlove.com//xmlrpc.php?rsd This isn't a valid URL on my site, I know it's just someone scanning for vulnerabilities, but I saw this error in the Tracy logs: Warning: Undefined array key "path" in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 ProcessWire: 3.0.210 PHP: 8.1.27 TracyDebugger: 4.25.17 Update: The issue appears to be that `REQUEST_URI` in this instance is `//xmlrpc.php?rsd`. Running parse_url() on that does not return a path segment because it parses `xmlrpc.php` as the host and `?rsd` as the query. The following explode() line expects that path. I think there needs to be some more sanitization before using the result of that parse_url().

I've been loving BT's The Secret Language of Trees

Hey all, I've looked at some other threads and github issues, but didn't find what I was looking for: https://processwire.com/talk/topic/21616-file-upload-inside-custom-module/ https://processwire.com/talk/topic/619-what-does-it-mean-destinationpath-is-empty-or-does-not-exist-upload_file/ https://github.com/processwire/processwire-issues/issues/885 I'm on PW version 3.0.165. I have a module using InputfieldFile to upload a CSV, then move it to a unique filename within a subdirectory in the module. Then it processes the CSV into a db table. That's actually all working smoothly, except I still get error messages on upload "destinationPath is empty or does not exist [field label]" and "Missing required value [field name]" Below is the relevant code. A couple notes: 1. I have both `required` and `requiredAttr` set because I wanted to avoid them clicking submit without selecting a file (it's happened, haha). I've tried turning those off and it fixes the second error "Missing required value" but not the first one about destinationPath 2. I can't seem to debug the $destination created by tempDir(), because I think it is removed when the request ends, but I presume it must be working OK because the CSV file ends up in the `/.uploads/` directory I specify, and is processed into a database table. 3. `/site/assets/cache/` directory is chmod 0777 and owned by "nobody" (yes, I know, I need to tighten this down :) Thanks for any assistance! Worst case I guess I can tell them to ignore the red message since it is actually working. <?php $destination = $this->files->tempDir($this)->get(); // debugging shows $destination = /site/assets/cache/WireTempDir/.ProcessMemberScorecard/0/ $form = $this->modules->get('InputfieldForm'); $form->attr('action', $this->page->url . 'upload-scores'); $form->attr('enctype', 'multipart/form-data'); $wrapper = new InputfieldWrapper(); $wrapper->importArray( [ [ 'type' => 'file', 'name' => 'scores_upload', 'label' => 'Scores File', 'description' => 'Select a CSV file to upload', 'required' => true, 'requiredAttr' => true, 'icon' => 'upload', 'extensions' => 'csv', 'destinationPath' => $destination, 'maxFiles' => 1, 'maxFilesize' => 10 * 1024 * 1024, 'noAjax' => true, 'descrptionRows' => 0, ], // additional checkbox fields, not relevant ] ); $form->append($wrapper); if ($this->input->requestMethod('POST')) { $form->processInput($this->input->post); $ul = new WireUpload('scores_upload'); $ul->setValidExtensions(['csv']); $ul->setMaxFiles(1); $ul->setOverwrite(true); $ul->setDestinationPath($this->config->paths($this) . '.uploads/'); $dt = new DateTime(); $tmpname = bin2hex(random_bytes(8)); $ul->setTargetFilename( sprintf('%s-%s.csv', $dt->format('Y-m-d'), $tmpname ) ); $results = $ul->execute(); if ($errors = $ul->getErrors()) { foreach ($errors as $error) { $this->error($error); } return $form->render(); } if (!$results) { // older, probably not needed since both required and requiredAttr are set $this->error('Please select a CSV file to upload'); return $form->render(); } // handle processing at this point, // then redirect to the next step where user confirms // the final result } .

Well the table entries are simple enough, so I'm going to just try removing them. I'll report back if my site implodes, but I suspect it will be fine. ?

I posted in the release thread, but that thread is several months old so I'm reposting here to get more eyes on it: After upgrading to 3.0.210 and running Modules > Refresh, it warned: I don't think I've had InputfieldTinyMCE installed before unless it was from an early 2.x version (site's been on PW since ~2014). It's definitely not the new InputfieldTinyMCE. I don't recognize JqueryFancybox. I checked in db table `modules` and there are entries for InputfieldTinyMCE and JqueryFancybox, no date in the created column (0000-00-00 00:00:00), so I'm guessing these are quite old? I know the site hasn't had those folders in /modules over the last several years at least. Is it safe to just remove those entries from the modules table?

Just upgraded from 3.0.165 and the process went very smoothly as always. Only odd thing is a notice when I run Modules > Refresh: I don't think I've had InputfieldTinyMCE installed before unless it was from an early 2.x version (site's been on PW since ~2014). I don't recognize JqueryFancybox. Doesn't seem to be causing any problems, but is there something else I need to update? Edit: I checked in db table `modules` and do have entries for InputfieldTinyMCE and JqueryFancybox, no date in the created column (0000-00-00 00:00:00), so I'm guessing these are quite old? I know the site hasn't had those folders in /modules over the last several years at least. Is it safe to just remove those entries from the modules table?

Not ProcessWire-specific. $this-> is the way to access properties and methods within the object, as part of Object Oriented Programming. More: https://www.php.net/manual/en/language.oop5.properties.php

Bump. This is now in the modules directory! ? The first post has been updated with current details.

I heard back from Ryan via email: