Leaderboard

It's spring break here and my kids are going back to school next week after being out for more than a year. Since it's a break week, the weather is great, and it's also the last week of the year-long covid break from school, I've spent a little less time at the computer this week. I've focused on some smaller module projects rather than the core. More specifically: posted a major update and refactor of the TextformatterHannaCode module, and a completely rewritten TextformatterVideoEmbed module. While making these updates, I've also made note of and attempted to resolve any reported issues in the GitHub repositories. Next week, it's back to the core, with both issue resolutions and pull requests scheduled for upcoming versions. Next week I also get my 2nd shot of covid vaccine, and I'm told it may slow me down a bit for a day, but will be well worth it. I had a day of tiredness from the 1st shot, but it was greatly outweighed by feelings of gratitude and reduction of worry. I highly recommend it as soon as you can get it, if you haven't already.

I've been meaning to revise PageimageSrcset for a while now, to remove some features that I felt were unnecessary and to implement a better rendering strategy. The result is PageimageSource. What does it do? It provides a configurable srcset method/property for Pageimage It allows WebP to be enabled for images it generates. It allows Pageimage:render() to return a <picture> element It provides a Textformatter that replaces <img> elements with the output of Pageimage:render() Although it is based on a current module, this should still be considered beta and not used in production without a prior development stage. Here's the README: PageimageSource Extends Pageimage with a srcset property/method plus additional rendering options. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. For an introduction to srcset, please read this Mozilla article about responsive images. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.165 and PHP >= 7.3 are required to use this module. Configuration To configure this module, go to Modules > Configure > PageimageSource. Default Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. WebP If enabled, WebP versions of the image and srcset variations will be generated and these will be returned by Pageimage::srcset(). As with the default implementation, the image with the smaller file size is returned. In most cases this is the WebP version, but sometimes can be the source. Make sure to experiment with the quality setting to find a value you find suitable. The default value of 90 is fine, but it is possible that lower values will give you excellent kB savings with little change in overall quality. For more information on WebP implementation please read the blog posts on the ProcessWire website. Rendering These settings control how the output of Pageimage::render() is modified. Use Lazy Loading? When enabled this adds loading="lazy" to the <img> attributes. It is useful to have this on by default, and you can always override it in the options for a specific image. Use the <picture> element? When enabled, the <img> element is wrapped in a <picture> element and <source> elements for original and WebP variations are provided. This requires WebP to be enabled. For more information on what this does, have a look at the examples in Pageimage::render() below. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Please note that although the module will generate WebP versions of all images if enabled, it will only remove the variations with the 'srcset' suffix. Usage Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset('320, 480, 640x480 768w, 1240, 2048 2x'); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ '320', '480', '640x480 768w', '1240', '2048 2x', ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ '320w' => [320], '480w' => [480], '768w' => [640, 480], '1240w' => [1240], '2x' => [2048], ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. This may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: If no sizes are specified, a default of 100vw is assumed. lazy: Pass true to add loading=lazy, otherwise false to disable if enabled in the module configuration. picture: Pass true to use the <picture> element, otherwise false to disable if enabled in the module configuration. Please refer to the API Reference for more information about this method. // Render an image using the default set rules // WebP and lazy loading are enabled, and example output is given for <picture> disabled and enabled echo $image->render(); // <img src='image.webp' alt='' srcset='image.jpg...' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.webp..." sizes="100vw" type="image/webp"> <source srcset="image.jpg..." sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules echo $image->render(['srcset' => '480, 1240x640']); // <img src='image.webp' alt='' srcset='image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w" sizes="100vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w" sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules and sizes // Also use the `markup` argument // Also disable lazy loading // In this example the original jpg is smaller than the webp version echo $image->render('<img class="image" src="{url}" alt="Image">', [ 'srcset' => '480, 1240', 'sizes' => '(min-width: 1240px) 50vw', 'lazy' => false, ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w' sizes='(min-width: 1240px) 50vw'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w" sizes="(min-width: 1240px) 50vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x0-srcset.jpg 1240w" sizes="(min-width: 1240px) 50vw" type="image/jpeg"> <img class='image' src='image.jpg' alt='Image'> </picture> */ // Render an image using custom set rules and sizes // These rules will render 'portrait' versions of the image for tablet and mobile // Note the advanced use of the `srcset` option passing both `rules` and image `options` // WebP is disabled // Picture is disabled echo $image->render([ 'srcset' => [ 'rules' => '320x569, 640x1138, 768x1365, 1024, 1366, 1600, 1920', 'options' => [ 'upscaling' => true, 'hidpi' => true, ], ], 'sizes' => '(orientation: portrait) and (max-width: 640px) 50vw', 'picture' => false, ]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.1024x0-srcset-hidpi.jpg 1024w, image.1366x0-srcset-hidpi.jpg 1366w, image.1600x0-srcset-hidpi.jpg 1600w, image.jpg 1920w' sizes='(orientation: portrait) and (max-width: 768px) 50vw' loading="lazy"> TextformatterPageimageSource Bundled with this module is a Textformatter largely based on TextformatterWebpImages by Ryan Cramer. When applied to a field, it searches for <img> elements and replaces them with the default output of Pageimage::render() for each image/image variation. Assuming a default set of 480, 960 and lazy loading enabled, here are some examples of what would be returned: Example <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" /> </a> </figure> WebP enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.webp" width="300" srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" loading="lazy" /> </a> </figure> <picture> enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <picture> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" type="image/webp"> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.jpg 480w" sizes="100vw" type="image/jpeg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" loading="lazy" /> </picture> </a> </figure> Because the variation is small - 300px wide - the srcset only returns the source image variation at the lowest set width (480w). If the source image was > 1000px wide, there would be a variation at both 480w and 960w. PageimageSrcset This module is built upon work done for PageimageSrcset, which can be considered a first iteration of this module, and is now deprecated. Migration PageimageSource is a simplified version of PageimageSrcset with a different approach to rendering. Most of the features of the old module have been removed. If you were just using $image->srcset(), migration should be possible, as this functionality is essentially the same albeit with some improvements to image variation generation.

Well, yes and no. Two migration modules already exist in ProcessWire, but neither suited my needs: “Migrations” by @LostKobrakai seems effective but quite onerous to use and has been deprecated in favour of “RockMigrations” RockMigrations by @bernhard is simpler and has a nice declarative method: migrate(). However, it is ideally suited to “headless” development, where the API is used in preference to the Admin UI. This is great for professional PW developers, but for occasional developers like me, it is much easier to use the UI rather than just the API. In addition there @adrian's ProcessMigrator which is designed for migrating page trees. Concept I wanted something to achieve the following: To allow development to take place (in a separate environment on a copy of the live database, or on a test database with the same structure) using the Admin UI. When finished, to permit a declarative approach to defining the migration and implementing it (again in the UI). To allow testing of the migration in a test environment on a copy of the live database. To allow roll-back of a migration if installation causes problems (ideally while testing rather than after implementation!). To provide a record of changes applied. Although not originally intended, the module I developed also allows the selective reversion of parts of the database by exporting migration data from a backup copy. Also, if changes are made directly on the live system (presumably simple, low-risk mods – although not best practice), it allows reverse migration to the development system in a similar fashion. I should emphasise that what I have built is more of a 'proof of concept' than a fully-fledged module. The code is pretty hacky and uses some stuff outside of the module itself. Lots of validation is missing. However, I have used it successfully in a number of small tests and a medium-sized live migration. If there is sufficient interest, I will tidy the code and make it available, but it would still need input from better coders and PW-savants than me to make it into something more widely usable. EDIT: Please note that the module has moved on a bit from this original post - the design has changed somewhat to make it more robust and flexible and additional features have been added. Please see the help file for full details. I still consider it to be at alpha stage, however, so use with care - test before making migrations and always take backups first. Design The module has the following principal components: A PW module “ProcessMigrateData”, bundled with a bootstrap migration in the same ProcessMigrateData folder, to be placed in the site/modules folder; A Page Class “MigrationPage” to be placed in the site/classes folder; Php files migrationActions.php and migrationControl.php to be placed in the site/templates/RuntimeMarkup folder (and migrationActions.js to be placed in site/templates/RuntimeMarkup/scripts). There are also a methods which need to be put in class DefaultPage and a functions in the init.php file. The module requires the FieldtypeRuntimeMarkup module. Migration definitions are held in .json files in the ProcessMigrateData/migrations/{migration name} folder (I might move this). This folder contains up to 2 sub-folders - “new” and “old” which each contain a file called a migration.json file, which defines the scope of the migration in terms of fields, templates and pages, and also one or more of fields.json, templates.json, pages.json and remove.json. The first 3 of these files contain the field, template and file definitions within the migration scope and the remove.json file simply lists fields, templates and pages to be removed. These migration files are mirrored by pages of template “Migration” under a parent /migrations/ of template “Migrations”. The mirroring happens in two ways: If a new migration is created in the module (from the Setup -> DB Migration menu), then initially no json files exist. The json files are created, after the scope of the migration is defined on the page, by running “Export Data” from the eponymous button. If json files exist, but there is no matching migration page, then the latter is created by the module on accessing the DB Migration admin page. In this case, we are in the “target” database so there is no “Export Data” button, but instead “Install” and/or “Uninstall” buttons. Migrations therefore either view the current environment as a “source” (type 1) or a “target” (type 2). Installation The module creates templates called Migration and Migrations and a page below the root named ‘migrations’. Open the admin page “Setup -> DB Migration” to create a migration. One (“bootstrap” is already installed) and cannot be modified. The pic below illustrates the DB Migrations page in the source environment. The status of a migration (as a source page) can be ‘pending’ or ‘exported’. ‘Pending’ means either that the migration data have not yet been exported or that the current export files differ from the source database. On opening this page in the target environment, the individual Migration pages (type 2) are created from the definitions in their respective /new/migration.json file. The pic below illustrates the DB Migrations page in the target environment. In a target environment, a migration status can usually be ‘indeterminate’, ‘installed’ or ‘uninstalled’. ‘Indeterminate’ means either that the migration has not yet been installed (so no ‘old’ files containing the uninstall definition exist yet) or that the current state matches neither the ‘new’ or the ‘old’ state. ‘Installed’ means that the current state matches the ‘new’ definition and ‘uninstalled’ means that it matches the ‘old’ definition (i.e. it has been actively uninstalled rather than not yet installed). When carrying out development work, you keep a note of what fields, templates and pages you have added, changed or removed. The module does not track this – it is a declarative approach, not a macro recorder. Also, it does not handle other components such as Hanna codes and Formbuilder forms. These come equipped with their own export/import functions. You can update a migration page as you go along, rather than keep a separate note of changed components. The migration page also allows you to document the migration and add any number of “snippets”. These snippets do not do anything, but can be a convenient place to store (for example) Hanna code exports for pasting into the target environment and help to make the page a comprehensive record of the migration. See example below: Note that migration pages just define the scope of the migration. It is entirely feasible for other parts of the dev database to be changed which are outside this scope and which will therefore not be migrated. After sync'ing code files to the target environment, the new migration will be listed on the setup page. On the migration page, in the target environment, there are “preview” buttons to see what changes will be implemented. The migration can then be 'installed'. See example of the migration page in ‘installation’ mode below: That's the gist of it, but inevitably there are complications. Happy to discuss and share further if there is interest in this.

Sounds like a neat feature, but this will get somewhat complex ? At the moment automatic description is generated by looking for the (first instance of the) query string (as a whole) within the index, and then converting that + a sensible amount of "padding content" to an excerpt. So far so good. Now, in order to generate an excerpt based on multiple words... Search query needs to be split by whitespace, and perhaps other characters as well. Each word should be matched individually. Preferably words should be matched in any order, just like they are when the query is performed. Here we should probably include more than just the first match, or at least that's my initial gut feeling. Since there may be many individual matches, we need a limit to how much content gets displayed, and we should also have some sort of algorithm in place to figure out which matches to use. Of course some of this may not be strictly speaking necessary: just finding a match with any single word from the query would be pretty much as simple as the logic we now have in place. But in this scenario that would result in somewhat suboptimal results. Anyway, just thinking out loud here. I'll give this a shot and see what I can come up with ? By the way, this is somewhat off-topic but this is one of the reasons I almost never use this operator: using the same content you have on the page, I'm unable to get any matches with "incised streambanks", "stream", or "banks". Might have something to do with MySQL settings (I'm using mostly default settings) but anyway, in my experience this behaviour is so flaky that I really can't be bothered with it. "%=" may not find results in "wrong" order etc. but at least it won't miss direct hits. And as for performance... well, I've never run into a use case where I would've observed any noticeable difference ? (Enough with the off-topic!) I'm not entirely sure about this one yet. Let's see if this makes sense once I grasp the "non-consecutive autodesc" thing.

I made some progress! ? The problem is session blocking: a session is already started and not yet closed when Tracy (or any code in a template file, like I was using for testing) attempts to get the response for the link using the same session cookie. So we need to close the existing session before using WireHttp. It wouldn't be good to close the session during the Tracy module config save because it's probably still needed at that point, so I'm using a hook after ProcessWire::finished when it should be safe to close the existing session. I also made some other minor tweaks for efficiency: only processing the links if they have changed from the existing config data, and moving the instantiation of WireHttp outside the foreach loop. I replaced this code with the following: $existingConfig = $this->wire('modules')->getModuleConfigData($this); $existingLinks = isset($existingConfig['linksCode']) ? $existingConfig['linksCode'] : ''; $savedLinks = isset($data['linksCode']) ? $data['linksCode'] : ''; if($savedLinks !== $existingLinks) { $this->addHookAfter('ProcessWire::finished', null, function($event) { // Make URLs in links panel root relative and get titles if not supplied $tracyConfig = $this->wire('modules')->getModuleConfigData($this); // Close existing session to avoid session blocking session_write_close(); $allLinks = array(); $http = new WireHttp(); $http->setHeader('Cookie', "wire={$this->wire('input')->cookie->wire}; wire_challenge={$this->wire('input')->cookie->wire_challenge}"); foreach(explode("\n", $tracyConfig['linksCode']) as $link) { $link_parts = explode('|', $link); $url = trim($link_parts[0]); $title = isset($link_parts[1]) ? trim($link_parts[1]) : ''; $url = str_replace($this->wire('config')->urls->httpRoot, '/', $url); if($title == '') { $fullUrl = strpos($url, 'http') === false ? $this->wire('config')->urls->httpRoot . $url : $url; $html = $http->get($fullUrl); libxml_use_internal_errors(true); $dom = new \DOMDocument(); $dom->loadHTML($html); $list = $dom->getElementsByTagName('title'); libxml_use_internal_errors(false); $title = $list->length ? str_replace('|', ':', $list->item(0)->textContent) : $url; } $finalLink = $url . ' | ' . $title; $allLinks[] = $finalLink; } $tracyConfig['linksCode'] = implode("\n", $allLinks); // Calling saveModuleConfigData with underscores because we don't need hooks to run again $this->wire('modules')->___saveModuleConfigData($this, $tracyConfig); }); }

If you look at the code in Migrator you'll see that I store images in the migration zip package under a path that matches the path of the page they are associated with, so for example, an image asociated with a blog post might look something like this: Page path: /blog/my-latest-blog/ Images for that pos: zippackage/blog/my-latest-blog/image-1.jpg, zippackage/blog/my-latest-blog/image-2.jpg, etc Then when the migration package is installed on the other site and the new page ID for blog/my-latest-blog/ is determined, the images are then added to that page and installed into the /assets/files/xxxx that matches that new ID. There is so much to consider with all this stuff, but if you run through a full migration of a tree of pages using Migrator you'll see how it stores all this stuff in the zip and how it modifies the paths in RTE fields to match the path of the page and then back to the /assets/files path again.

@MarkE - also, just a reminder about updating the path to images embedded in RTE fields. You might find some useful code for that starting here: https://github.com/adrianbj/ProcessMigrator/blob/b327626606bcdc9cc6c74bd00f9e9d2bcd2cae50/ProcessMigrator.module#L2588

I have made a few minor amendments to the code at https://github.com/MetaTunes/ProcessDbMigrate, so anyone who has downloaded an earlier version might wish to update their copy. I found a few bugs with the image files which I've hopefully fixed - but there is a residual issue: Because the target database might have different page ids from the source database, the module uses page paths not ids for referencing. However images and files are stored in folders using ids. In order to migrate a page with files/images, it is necessary to upload the files in their related folders. The module will then put them in the right folder for the target system, but problems could arise if there is a page in the target system with images/files and its id is the same as the source page id. I'll scratch my head a bit over that one! I just used the module to migrate a site from my first prototype (see the OP) to this version and it worked fine.

Hi, honestly, i've build a lot of sliders in websites with pw, depending of what you're using as js, there are a lot of plugins out there, vanilla, jquery or zepto (i love the vegas one that runs with jquery or zepto ? ) simple ones are even easy to build self made with vanilla js when it comes to a simple admin for it, depending of what you're going to do, image slider with just a simple legend/text, an image field will do the job using the description for the text part if you want to go a little further, just use a repeater... image field(s) in each item, text, richt text, you'll not run into any limit in both cases your user can order the slides dragging the items with their mouse, hard to find something easier ? have a nice day

<?php foreach($page->heroimage as $image): ?> <li> <img src="<?php echo $image->url; ?>" alt="<?php echo $image->description; ?>"> </li> <?php endforeach; ?> You might want to try this instead. In your foreach() the $image has to be adressed and not the $page->image. And also the <li> should probably be in there too.

What I have found out is that sending WireHttp requests as https lacks of embedding the ssl certificate things and therefor results in false responses. When I explicitly use http and NOT https, then this code seems to work fine, as it sends exactly the same headers like the browser of the logged in session does: $wire->session->set('wirehttprequestheaders', getallheaders()); $url = 'http://' . $wire->config->httpHost . '/cli.php'; $http = new WireHttp(); foreach($wire->session->get('wirehttprequestheaders') as $header => $value) { if('Host' == $header) continue; $http->setHeader($header, $value); } $response = $http->post($url); // or ->get() or send() if($response !== false) { echo '<pre>'; var_dump($response); } else { echo '<pre>'; var_dump($http->getError()); } My cli.php for testing looks like this: <?php namespace ProcessWire; include('./index.php'); if($wire->user->isSuperuser()) { echo '<pre>'; var_dump(getallheaders()); } else { die('NO ACCESS'); } I never got this timeout behave. Only false or true responses, but always within a second or less. Don't know if this is of any help.

This is great @ryan - Quick question. Digital Oceon doesn't automatically balance between all the read only nodes as RDS does. Is it possible or is it on the roadmap to allow adding multiple nodes in PW and PW distributes between that list of nodes. Could be as simple as an array of dbReaders, with PW randomly selecting from the array for each read request. Or round robin. That would allow it to be much more flexible setup and support self hosting read replicas for example. Otherwise fantastic work this is great.

I know that a runtime field is tempting because it abstracts complexity but such things can quite easily be done via hooks as well. That means you don't need a module and you get even more possibilities: <?php $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $page = $event->object->getPage(); if($page->template != "mytemplate") return; $form = $event->return; if($f = $form->get("title")) { $next = $page->next; if($next) $f->notes = "Title of next page: ".$next->title; } });

Hello, I've just released a new module called PageimageSource which effectively supersedes PageimageSrcset. I've wanted to rewrite this module for a while now, to remove some features that I feel aren't necessary (e.g. UIkit widths / portrait mode), and have a more stripped back module that is more focused on specific functionality. I'd hoped to be able to do this by having a version 2.0.0, indicating breaking changes, but PW doesn't indicate this when upgrading, so the situation where users upgrade and things break would almost certainly happen. I therefore decided to rewrite the module and release it under a different name. I don't expect to do any more work on PageimageSrcset, but will apply any fixes as required. If you are starting from scratch on a project, PageimageSource is the one to use. If you are thinking to migrate a project using PageimageSrcset to PageimageSource, this list of changes should hopefully allow you determine if it is possible: The sizes() method/property has been removed The portrait mode has been removed (still possible through settings though - see the PageimageSource README for an example) UIkit widths -> sizes has been removed All the debug stuff has been removed The render() method behaves differently. It is more geared toward a <picture> implementation (requested by @teppo) Basically if all you've used is the default configuration and the srcset property, migration shouldn't cause any issues. Pretty much any other situation isn't suitable for migration. Cheers, Chris

A bunch of my old clients started having this issue on Dreamhost as well. Like @cstevensjr, I noticed that any domains on a VPS weren't affected. However, some domains on shared hosting plans were affected while other ones were not. Probably a difference between servers, but not certain why shared servers would have different ModSec settings. Anyway, I was lucky to chat with a tech that was patient and knew his stuff. (Shout out to John B!) We worked through one of the affected domains and he figured out what ModSec rules were being tripped by the uploads. So he had to add exceptions to those rules until the uploads worked - even with the Extra Web Security option still enabled for the domain. After we got one domain working, he replicated the same exceptions to the other domains and we tested each one as we went. He kindly shared the list of rules that were causing the problem after I asked for them (in case this issue popped up again or if I had to speak to another agent about another domain). The rules being tripped were: application-multi language-multi platform-multi event-correlation attack-generic If you have to talk to a Dreamhost tech to get this problem resolved, it may be helpful to point them to this post or simply pass them the list of rules being tripped that need exceptions added. Like I mentioned earlier, and unfortunately, these rule exceptions need to be added on a domain-by-domain basis.

Just tried activated it for https://corporate.blue-tomato.com/ which runs on Digital Ocean. Seems it works well.

Bern hard u.can does $wire->addHook('/mymodule/{foo}/{bar}(/{baz})?/', function($e) { return "<pre> foo: $e->foo bar: $e->bar baz: $e->baz "; }); @ bern berna hard @ @bernhard