-
Posts
128 -
Joined
-
Last visited
-
Days Won
4
gRegor last won the day on November 27
gRegor had the most liked content!
About gRegor
- Birthday 12/26/1978
Contact Methods
-
Website URL
https://gregorlove.com
Profile Information
-
Gender
Male
-
Location
San Diego, CA
Recent Profile Visitors
7,994 profile views
gRegor's Achievements
-
Looking for easiest way to turn off autocomplete for admin login prompt
gRegor replied to gRegor's topic in General Support
I also learned that this mostly doesn't matter in modern browsers, since they'll ignore it. But hey, this security scan will pass now! 🤣 -
Looking for easiest way to turn off autocomplete for admin login prompt
gRegor replied to gRegor's topic in General Support
Hooking after that method wasn't as bad as I was thinking, so this is my current quick solution: wire()->addHookAfter('ProcessLogin::buildLoginForm', function(HookEvent $event) { $form = $event->return; $form->get('login_name')->attr('autocomplete', 'off'); $form->get('login_pass')->attr('autocomplete', 'off'); $event->return = $form; }); -
We have a site that is having some security scans run and they want us to disable autocomplete on the username/password field for the ProcessWire login form, using the autocomplete="off" attribute. I see that buildLoginForm is hookable, but would prefer to avoid rebuilding the entire form. Is there another hook (or simpler way that I'm forgetting) to target those two input fields and add the attribute? I may also just manually update the core file and make a note to re-apply it when we update PW, but fingers crossed there's a simpler way I'm missing. Depending on the results of this thread, I might file a feature request to make it a configurable option. Thanks for any help!
-
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:
-
TinyMCE media plugin in combination with purifier does not work
gRegor replied to Didier B.'s topic in General Support
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