d'Hinnisdaël

Me again. Sorry for wasting your time ?Everything is working as expected now. I overlooked the vps permission and only now found it — after stumbling through this support thread.

Great fan of the module! However, I haven't yet gotten it to work for non-superusers. The modal for selecting pages aborts with an error »ProcessWire: Unrecognized path« and »The process returned no content.« Now I guess it has to do with them not having the required permissions to access the root Admin page, but is there another way to allow editors to use the module?

Field exports don't seem to work properly with the module enabled. When exporting a Fieldset (via Setup » Fields » Export), I get the following error: Call to a member function add() on null (MinimalFieldset.module, line 74). $wrapper seems to be unset in this specific context. Uninstalling the module gets rid of the exception. Could you check if you see the same thing (I'm on 3.0.117) or if I just have something misconfigured?

Wonderful! Well done and thank you for taking the time and releasing this. I've been thinking about the exact same thing for a while now. Could you make the vertical spacing optional, via another checkbox maybe? I have quite a few layouts where the secondary column has a lot fewer inputs and would prefer to have them on top.

What do you think about making the module extensible via hooks? I had a client request a sitemap that included videos. Now, methods of storing videos differ: file fields, video URLs, embed codes, and so on. I suspect there's no straightforward way to include videos in the sitemap using just this module. However, implementing this on a site-by-site basis would become simple if there was a way to hook into the sitemap creation process and append different definitions like video or news item yourself. Of course, I could create the whole sitemap from scratch — but your module does a lot of things very well and I'd love to build upon that.

I kept running into the issue of self-invalidating access tokens and wanted the site's content editors to be able to handle the generation of new access tokens themselves. The module, however, limits those functions to superusers. Could you change the module to check for the module-admin permission? It's ProcessWire's internal permission to check who can edit module configurations. It's deactivated by default and has to be created and assigned manually, so there's no additional risk or security concern. On a standard PW installation, it still only applies to superusers. However, it gives people the possibility to allow editors to generate access tokens. So instead of if ($this->user->isSuperuser()) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } it's if ($this->user->isSuperuser() || $this->user->hasPermission('module-admin')) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } (There's a second check somewhere further down). Thanks for considering this. I forked the module for now, but would much rather like this to be incorporated into master.

Would it make sense to add an option to exclude tables from the backup, instead of choosing the tables to include? This would be especially useful with regards to the sessions table. I have a project with a moderate amount of visitors, but 1million+ rows in the sessions table. The backup module fails since the process needs too much memory. If I exclude the sessions table, the export shrinks from 150MB to 30MB, which the server can easily handle. Now, I can already select all tables and leave the table sessions unchecked. However, as soon as I add a field, template, etc., all future backups will be missing that table completely. In that scenario, an exclude option would be the better option. I might just whip up a PR when I find the time, but was wondering if anybody else feels this is necessary or a good idea.

Beautiful, that did the trick. Thanks! Much better than modifying the core search module, and it won't spill over into generic find() calls in the front-end. No idea how I missed the findReady hook in the first place… Final working implementation: // Include unpublished participants in page fields for non-superusers wire()->addHookAfter('ProcessPageSearch::findReady', function(HookEvent $event) { $selector = $event->arguments(0); if(strpos($selector, 'template=participant') !== false || strpos($selector, 'templates_id=76') !== false) { $selector .= ", check_access=0, include=all, status<" . Page::statusTrash; } $event->return = $selector; });

Good point. I've always used it conjunction with some light caching to store the results as JSON.

Unfortunately, this doesn't seem to work for non-superusers. I've been up and down the source of ProcessWire's internal admin search (which powers the page autocomplete input) and it really seems to limit the selection of unpublished pages to superusers. Would be great to have autocomplete inputs respect the Include unpublished setting of a Page field.

For most group-by-property situations, I use Fun with hooks: PageArray::groupBy.

I'm pretty sure that anything beyond basic template selection will not work in autocomplete inputs. I found this comment in the InputfieldPage source regarding custom PHP selectors: Not compatible with PageListSelect or Autocomplete input field types. Also, the field for adding custom code is disabled for autocomplete and page list selects: $field->showIf = 'inputfield!=InputfieldPageAutocomplete|InputfieldPageListSelect|InputfieldPageListSelectMultiple';

From my cursory reading of the source, check_access also seems limited to superusers: // don't allow setting of check_access property, except for superuser if($lowerName == 'check_access' && !$superuser) continue;

Is this an autocomplete inputfield? I just ran into the same problem (a page field not finding unpublished pages for non-superusers, even though Include unpublished is checked). I managed to isolate the issue to ProcessWire's internal admin search that is used behind the scenes of autocomplete fields. Not sure if anything from the last major search update in 3.0.108 might play a role here. This is what's worked for me: Copy the core search module folder from /wire/modules/Process/ProcessPageSearch to /site/modules/Process/ProcessPageSearch/ After lines 422–425 in ProcessPageSearch.module… if(!$status && !$hasInclude && $superuser) { // superuser only $selectors[] = "include=all, status<" . Page::statusTrash; } …insert this: // FIX: include unpublished pages for non-superusers else if(!$status && !$hasInclude && !$superuser) { $selectors[] = "include=all, status<" . Page::statusTrash; } Back in the admin, refresh the module cache (Navigation » Modules » Refresh). ProcessWire will then ask you which version to use for the search module. Pick the one you modified in the /site/ folder. This will basically make it work the same for superusers and non-superusers. I can't report any negative side effects at this point, but in my case it beats promoting all content editors to superusers.

Quick update and version bump to 0.1.0 I updated the module to use the standard ProcessWire variation suffixes. Instead of image.0x200.optim.jpg, optimized images will now be named image.0x200-optim.jpg. Deleting images in the admin or via the API will delete any optimized variations as before, but the process is a lot more straightforward now. I also added a public method $image->removeOptimizedVariations() that does exactly what it says it does.

Dear @horst, thanks for the valuable feedback. Indeed you mentioned a very good point. I suspect I had a slightly different than usual understanding of how to remove image variations created by modules. The current implementation uses a glob (/{page folder}/{original file basename}.*) to delete variations. I'll update the module to use the standard naming scheme — this will have its benefits especially in edge cases, e.g. images will then still get removed if the module is uninstalled or deactivated. Also good idea about having a public method removeOptimizedVariations(). That will be very easy to implement with the previous issue.

In case somebody stumbles upon this thread looking for an ImageOptim plugin, I ended up creating one. It's very much inspired by the TinyPNG module. ProcessWire ImageOptim module To get a sense of where and when to create hooks for optimizing images on upload / resize, these two along with Autosmush could prove helpful.

So I decided to wade into module development and created a wrapper module around ImageOptim, a service that compresses and optimizes images in the cloud. ImageOptim currently handles JPG, PNG and GIF files and, depending on the settings you use, shaves off between 15% and 60% in filesize. Great for bandwidth and great for users, especially on mobile. This module handles the part of uploading images to ImageOptim via their official API, downloading the optimized version and storing it alongside the original image. Download & Info GitHub / Module directory / Readme / Usage Why ImageOptim? There are other image optimization services out there, some of them free, that have outstanding ProcessWire modules. A few things make ImageOptim the best tool for most of my customers: It's not free, i.e. it will probably be around for a while and offers support. However, it's cheaper than some of the bigger competitors like Cloudinary. And it does PNG compression better than any of the free services out there, especially those with alpha channels. Installation Install the module like any other ProcessWire module, by either copying the folder into your modules folder or installing it via the admin. See above for downloads links on GitHub and in the module directory. Requirements To be able to upload images to the service, allow_url_fopen must be set on the server. The module will abort installation if that's not the case. I have only tested the module on ProcessWire 3.x installations. I don't see why it shouldn't work in 2.x, if anyone wants to try it out and report back. ImageOptim account To compress images, you first need to sign up for an ImageOptim account. They offer free trials to try the service. Usage (manual optimization) Images can be optimized by calling the optimize() method on any image. You can pass an options array to set ImageOptim API parameters. $image->size(800,600)->optimize()->url $image->optimize(['quality' => 'low', 'dpr' => 2]) // Set quality to low and enable hi-dpi mode Automatic optimization The module also has an automatic mode that optimizes all image variations after resizing. This is the recommended way to use this module since it leaves the original image uncompressed, but optimizes all derivative images. $image->size(800,600)->url // nothing to do here; image is optimized automatically To change compression setting for single images, you can pass an options array along with the standard ImageResizer options. Passing false disables optimization. $image->size(800, 600, ['optimize' => 'medium']) $image->size(800, 600, ['optimize' => ['quality' => 'low', 'dpr' => 2]]) $image->size(800, 600, ['optimize' => false]) For detailed usage instructions and all API parameters, see the usage instructions on GitHub. Filenames Optimized images will be suffixed, e.g. image.jpg becomes image.optim.jpg. You can configure the suffix in the module settings. Roadmap Asynchronous processing. Not really high on the list. Image variations need to be created anyway, so waiting a few seconds longer on first load is preferable to adding complexity to achieve async optimization. Optimize image variations created by other modules. CroppableImage comes to mind. I don't use any of these, so if somebody wants to help out and submit a pull request — all for it! Add a dedicated page in the setup menu with a dashboard and detailed statistics. ImageOptim's API is very barebones for now, so not sure if that's feasible or even necessary. Stability I've been using this module on production sites for some time now, without hiccups. If you do notice oddities, feel free to comment here or investigate and submit PRs.

@adrian This is great, thanks! I'll take it for a test drive next time I get a chance to upgrade modules on that particular site and report back.

@adrian Sending copies to a list of users would certainly come in very handy! For debugging user registration scripts, I'd usually have to switch Bcc recipients regularly. As for re-branding the Bcc option as "notify other users": sounds good, too. I'm fine with the way it works now and would see the ability to send multiple copies as a priority, but I certainly see your point in simplifying it.

Thanks for implementing the Bcc field, @adrian! It works great on sites using WireMailSmtp. However, on a site using the default WireMail implementation, the bcc() call will fail and abort the whole process. It seems the default WireMail interface does not (yet) have bcc() defined while it is available in WireMailSmtp and others. I'd suggest doing a simple check for the bcc function. For that particular project, I have successfully used the following to fix it. Instead of (line 177): if($this->data['bccEmail'] != '') $mailer->bcc($this->data['bccEmail']); I inserted: if($this->data['bccEmail'] != '') { if (method_exists($mailer, 'bcc')) { $mailer->bcc($this->data['bccEmail']); } else { $mailer->to($this->data['bccEmail']); } } Since the default WireMail will send each to() recipient as a separate mail, the second to() call acts as a de facto bcc address. Maybe that will be enough, maybe you can think of a more sophisticated way of solving it.

I knew I was missing something. Works like charm now, thanks a lot, @Mike Rockett

What's the best way to handle spaces in the original URL? (and whitespace in general) I found that if the requested URL contains spaces, the plugin won't start at all, i.e. there's also no debug screen on matches or compiled jumplinks even when debug mode is turned on. It doesn't seem to make a difference if the links are requested with spaces intact or by directly typing in %20 instead. Also, the pattern itself doesn't make a difference. I tried: GEORGIA GARDNER GRAY.html GEORGIA%20GARDNER%20GRAY.html GEORGIA{space:any}GARDNER{space:any}GRAY.html Is there a preferred way of handling this or am I missing something obvious? Thanks

I had several clients request a version of this module that honors the aspect ratio of a video when using the responsive embed method. For now, the module is using a hard-coded 16/9 ratio. I decided to give it a go myself and forked Ryan's repo. I added functionality to calculate a video's aspect ratio from the oEmbed return values for width and height and made a change to the module's custom db schema to save the aspect ratio. In the (improbable) case the aspect ratio can't be determined, I added a fallback aspect ratio to the module's config. After looking around for a bit, this post about db schema updates for modules with custom databases provided excellent examples on how to handle the schema updates for existing installations. The changes have been tested on several live sites (3.0) and the update went without hiccups. If anyone's interested, here's the commit: https://github.com/[...]/commit/76e9a5e7bba79aef8fae35aaa7a1b7b79e970f90 I'd love to get some feedback on this! Especially from people running this on the 2.7 or 2.8 branch. If all works well, it'd be great to integrate this into @ryan's official repo at some point.

+1 — This is especially important for portfolio sites with multiple large images. Lazyloading is a possibility, but even then progressive loading is visually more satisfying than scanlines. I don't know about the technical details of implementing this in PHP, but I imagine this can't be too complicated. Or do you think this would best be handled by writing a PW module?