-
Posts
125 -
Joined
-
Last visited
-
Days Won
2
gRegor last won the day on March 18 2016
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,947 profile views
gRegor's Achievements
-
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
-
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.