tpr

You would just need to add test files to your module, not the whole testing module. You or someone who is interested could install the tester module and run the tests. I can think of data saving and retrieval tests that could be tested on the backend. Frontend (e2e) testing us another thing, I used Cypress a few times but there are many other available. With Cypress it is easy to simulate user inputs and interactions. I can spend some time to set up a simple test if you wish, so you could use that as a base. But it is easy enough to just get started with the official docs.

Not my business (and no offence) but have you considered adding unit tests (there is none in the repo)? This is a sensitive area where accuracy is crucial, tests could improve the overall quality a lot. I can recommend ProcessNetteTester if you don't have any other preferred. In general tests for user supplied modules in PW are very rare (perhaps close to zero as I know, including my own modules), although it would be a sign of quality if there were some conditions to only accept modules with tests to the modules directory.

So are you creating a new image for this effect? If so, have you considered using CSS backdrop-filter? https://css-tricks.com/almanac/properties/b/backdrop-filter/

You definitely took it at face value 🙂

Try pulling your mask bit lower 🙂

The naming of "has" sounds a bit unintuitive to me as well, since it involves getting a true/false, so it can lead to confusion when reading the code where the returned id is used. Maybe something like this? (somewhat similarly to the C# TryGetValue()) $pages->tryGetId(selector);

I usually supplied "translation keys" instead of the default translation to translation functions, and translated them in all languages, eg. __('btn_submit') instead of __('Submit'). This way they rarely needed to be changed, only when the translation changed to something completely different.

Glad it helped. I know it can be a powerful feature even though I haven't had a chance to use too much. You may also take the relatively new built-in extended template overrides into account (available when $config->advanced = true). But that would need another template to use so AOS is more flexible.

Sure, because they are field settings. This feature wasn't tested and used too many times (by myself) but when I opened a local PW site I usually use for testing, the following was filled int he FieldOverrides textarea in AOS: [Enable any markup in any CKEditor] ?field = "inputfieldClass=InputfieldCKEditor" useACF = 0 usePurifier = 0 Apparently it works, but it's important to know how. AOS is loaded in the admin only, so if you override a field like this, you won't see useACF=0 if you dump the field settings in the frontend (eg. with Tracy). But in the admin the value is overriden, so you can add any markup and it will be saved to the DB. On the contrary, if you decide to remove this override later on, the data won't be changed in the DB automatically unless you re-save the page again.

That sounds me rather as an issue with vex dialogs, are their features rely on animations somehow? Edit: perhaps this? https://github.com/HubSpot/vex/issues/285

There's no harm but then I would have to modify the current submodule toggle (and role setting) behavior. The idea was to enable/disable a submodule in the top section and hide the corresponding settings section below. If I would remove the "show if" conditionals to show all settings, one wouln't know whether the submodule he is configuring is enabled or not (without scrolling to the top to check). Perhaps the easier solution would be to add some kind of text or icon to indicate the on/off state.

Here I added some code snippets that may help:

Isn't AdminOnSteroids pagelist tweaks suit your needs? https://github.com/rolandtoth/AdminOnSteroids/wiki/PageListTweaks Show pagelist actions on full row hover: makes pagelist actions visible on hovering anywhere in the pagelist, not only on the page title

I've checked on a site that was using .latte extension and a rather old module version (0.3.7). After the update I had to re-add the admin template check, otherwise I got errors complaining undefined variables, that I set in ready.php. public function ready() { if ($this->wire('page')->template == 'admin') { return; } In theory this could also work: 'autoload' => 'template!=admin', but unfortunately all pages go 404 because PW doesn't find template files (I guess). Furthermore there's a simpler way to set fuels, so the entire "fuels" array item in the getDefaultData() could be deleted: $view->fuel = $this->wire('fuel')->getArray(); I removed the ignored templates module setting and there were no errors. First I emptied and saved it to make sure it's removed from the db. With these settings this particular site was working OK (Tracy as well). Unfortunately I don't have any other sites locally on my computer to but I can copy prod sites and check (all uses .latte).

Thanks, these seem to be useful updates. I'll try to try things out on the weekend. I wouldn't mind if somebody could take over this module. I'm doing asp.net and angular things nowadays and I don't plan to go back to php, and I have no time to jump back and forth, unfortunately. I started a major rewrite that affected filters and macros, namely I built a separate module that contained helper methods that could be used separately and by Latte as well. I added a great number of unit tests (via ProcessNetteTester) but the overall project was halted because of time. I can handle this over as well, though that one is really a time-consuming one 🙂