Leaderboard

$mydb = new Database('localhost', 'user', 'pass', 'my_other_dbname'); $result = $mydb->query("SELECT * FROM a_table"); [...]

Ah ha moment - I think I got it! Setting the root url in the template seems to have solved the issue. Although I think as per your post @wbmnfktr there's possibly a less destructive/repetitive way to this in future if can get my head round it! <?php $config->urls->root = '/pw/';?>

They do it all the time. No matter how many accounts exists... most of the time all people use just one. I always try to convince clients not to share accounts, but in some cases they flatly express that they will indeed use "shared accounts" no matter what. Their excuse usually boils down to laziness: they do not want to deal with managing users at all. In such a case I ask them at least to call such a user as "shared editor" or similar so that at least we know how to treat that account in question. So for the reasons outlined above, some support for this would be welcome, maybe with some additional logging options so that we can track down such activities even days after...

Hi @adrian, I've made another update to the module. I've removed the inferring of "id" if addRecipientVariables() isn't used, as it was confusing and didn't really work anyway... I'm not getting the comma issue (also using Mac Mail), and multiple batches is working for me also - if it still persists for you after the latest update, please let me know and I'll debug further in the morning. I've added an example to the README which should hopefully explain batch sending/recipient variables a little more: // If using batch mode, the recipient variable "name" is inferred from the `to` addresses, e.g. $mg = $mail->new(); $mg->to([ "user@domain.com" => "A User", "user2@domain.com" => "Another User", ]) ->setBatchMode(true) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p>") ->send(); // to = A User <user@domain.com>, Another User <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User"}, "user@domain.com": {"name": "Another User"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p> // bodyHTML[user2@domain.com] = <p>Dear Another User,</p> // Alternatively, you can omit the `to` recipients if setting `recipientVariables` explictly e.g. $mg = $mail->new(); $mg->setBatchMode(true) ->addRecipientVariables([ "user@domain.com" => "A User", // "name" is inferred "user2@domain.com" => [ "name" => "Another User", "customVar" => "A custom variable", ], ]) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p><p>Custom: %recipient.customVar%!</p>") ->send(); // to = A User <user@domain.com>, Another User <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User"}, "user@domain.com": {"name": "Another User", "customVar": "A custom variable"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p><p>Custom: %recipient.customVar%!</p> // bodyHTML[user2@domain.com] = <p>Dear Another User,</p><p>Custom: A custom variable!</p> // %recipient.customVar% only prints for second email, so not a particularly useful example! // You can also use `addRecipientVariables()` to extend/override the inferred `recipientVariables` e.g. $mg = $mail->new(); $mg->to([ "user@domain.com" => "A User", "user2@domain.com" => "Another User", ]) ->addRecipientVariables([ "user@domain.com" => [ "title" => "A User (title)", ], "user2@domain.com" => [ "name" => "Another User (changed name)", "title" => "Another User (title)", ], ]) ->setBatchMode(true) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p><p>Title: %recipient.title%!</p>") ->send(); // to = A User <user@domain.com>, Another User (changed name) <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User", "title": "A User (title)"}, "user@domain.com": {"name": "Another User (changed name)", "title": "Another User (title)"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p><p>Title: A User (title)!</p> // bodyHTML[user2@domain.com] = <p>Dear Another User (changed name),</p><p>Title: Another User (title)!</p> Cheers, Chris

Hi @alanxptm, this is already there in the edit screen for roles. See the screenshot. You need to tip the checkbox and are done.

Hi @adrian, Got a chance to look at this today. Batch requests (batch mode on, to emails > 1000) now get split up into separate API requests with 1000 emails per request. The only way I could test this was to reduce the limit to 2 and then try sending a batch request to more than two email addresses. Seems to work fine, however I'd recommend enabling test mode and testing with this to confirm that it works correctly for emails being sent to 1000+ users prior to sending for real. I've also moved the batchMode setting into the module config, so it can be set to ON by default. Cheers, Chris

They do it all the time. No matter how many accounts exists... most of the time all people use just one. Some just don't want to be responsible for changes so they take the credentials from another user or "admin" account they somehow can get.

This week we’ll take a quick break from core updates and have a look at a new module called UserActivity, just added to the ProcessWire ProDevTools package— https://processwire.com/blog/posts/user-activity-module/

Yep - that happens! Mac Mail was doing the same to me when testing last night.

@vwatson I think your chances that @ryan sees this question is much higher if you posted in the Pro board instead. My guess is that Ryan simply didn't implement it yet...

I honestly don't know. Never bootstraped ProcessWire into something in the last two years or installed it into a subfolder. Sorry.

I really don't know if this might help here or if you already tried it but in version 3.0.141 Ryan made ProcessWire system URLs/paths now more customizable: https://processwire.com/blog/posts/pw-3.0.141/#processwire-system-urls-paths-now-more-customizable

You're right, this isn't included yet. I definetely need to update the code later ?

It's a pleasure ? Yes, DNT should also be a selectable option. I'll add an suggestion for this feature later. That's true. To add this as a non-breaking feature we could also add the type of accepted cookies as a separate storage option "allowedCookieType" => "all" // "necessary". In this case no existing setup should break.

I agree that there should be a different value for necessary cookies... Maybe the pwcmbAllowCookies in localStorage could have values like "all", "necessary" and "no" instead of just "y" and "n"? I also thought about respecting the "DoNotTrack" choice of the user in the browser. I'm currently working on this, but this simple snippet at the start of the init function should do it: /* if the user activated the "DoNotTrack" function in their browser, respect that choice and do not show the banner */ if (navigator.doNotTrack) { cookieMonster.cfg.allowCookies = "n"; cookieMonster.cfg.selectionMade = "y"; cookieMonster.cfg.storedVersion = cookieMonster.cfg.version; cookieMonster.sendActionBeacon(); cookieMonster.updateStatus(); cookieMonster.sendTrackingBeacon(); return; }

@ryan I also have an idea which is somewhat related: is there a possibility to build upon UserActivity so that one can build a module which is made for logging – saving into the database – what (given) users performed in the PW admin? I am thinking of (re)implementing something like Reno's MarkupActivityLog module https://modules.processwire.com/modules/markup-activity-log/ Could some API features of UserActivity be useful when developing such a 3rd party module?

Whenever I experienced this issue it was somehow related to mod_rewrite. At first I'd make sure mod_rewrite is installed and enabled - which I guess it is, as you can access the admin. If possible restart Apache. Delete whatever cache (template cache, markup cache, WireCache, ProCache, FileCompiler) you use. Even the cache in your browser. Try to set the rewrite base - you will find it in your .htaccess under number 11. A little warning: use another browser or use it in Private Mode while testing your changes. Browsers sometimes cache way too much for way too long. ? And of course: change only one thing at the time.

On first look this sounds like a really nice and handy addition and workaround for several use cases that were already mentioned here. I have to take a closer look how this works out in the backend and frontend of course but I guess I'll be happy to add this to the module - somehow. But as you use cookieMonster.block() for your necessary cookies the stored information (localStorage) says cookies denied/blocked and there might be a difference in these so it might be better to store a different value than blocked.

As some of our customers do have the same request (checkbox for only necessary cookies), I implemented this option in this fork. Till now I only added the option in the vanilla js solution as we don't use jQuery at all. If desired I could add also this option to the jQuery part and open a PR. Technically the button for "only necessary" cookies is the same as the option to not consent at all, just a different position of the button and naming. This is an example of the module frontend.

Thanks for all the great updates (and the new examples) Chris, Latest version is looking good so far - I expect I'll be testing more again tomorrow and will let you know if I notice any issues. Cheers!

Hi, thanks @Robin S for your hook example, but also (in my case) I had a problem to save values inside repeaters. I use 3 fields per/row and out of repeaters everything works fine (PW 3.0.146.). The images below shows my page tree and two different situations (after save). --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Here is another hook example ("cascade" case like on images) but before test, please read setup notes: 1) For the first column field (continents / categories) set parent page inside field setup. 2) For subfields (country and city) set template (eg. "blank") inside field setup. 3) Write selector strings for subfields inside hook configuration (ready.php). PHP (ready.php) <?php namespace ProcessWire; /** * Configuration: * Field names and selectors * * For subfields and after save problem * need to write string selectors here, and leave empty * that part inside field setup. */ $config->names = array( 'continent' => '', 'country' => 'parent=page.continent', 'city' => 'parent=page.country', ); $wire->addHookAfter('InputfieldPage::getSelectablePages', function ($event) { $inputfield = $event->object; $field = $inputfield->hasField; $names = $this->config->names; if (isset($names["$field->name"])) { $selector = $names["$field->name"]; if (trim($selector) !== "") { if (strpos($inputfield->name, '_repeater') !== false) { $id = str_replace($field->name . "_repeater", "", $inputfield->name); foreach ($names as $n => $s) { if (strpos($selector, $n) !== false) { $repeater_name = $n . '_repeater' . $id; $selector = str_replace($n, $repeater_name, $selector); } } } $inputfield->findPagesSelector($selector); } } } ); Here is screen record: Regards.

@lemgrago I think at the moment the module only supports a single depth of grouping. I did a quick check and it doesn't work for me either. If it helps you can always declare your routes like: 'firstlevel/secondlevel' => [ ['GET', 'endpoint', Example::class, 'test'], ], 'firstlevel/another-secondlevel' => [ ['GET', 'endpoint', Example::class, 'test'], ], I might add multiple nested groups in the future

@charger So the bug you're facing is due to the fact that repeaters are pages under the hood and the module checks permission those pages as well and since you do not have view access enabled for your repeater template the values return empty. So in version 1.0.5 you just need to enable view access for your repeater template repeater_product_groups and the values should show up. But since you are already enabling view for your repeater field I think it's safe to assume that you want to enable view for template that used by that repeater field too. So for latest version 1.0.6 that I just released you don't have to enable access to your repeater templates. Just enabling access to your repeater field is enough. New Version 1.0.6 Just upgrade the module to the version above and let me know if it solves your problem.

Although the PW backend is really intuitive, ever so often my clients need some assistance. Be it they are not so tech savvy or they are not working in the backend often. For those cases it is nice to make some help videos available to editors. This is what this module does. ProcessHelpVideos Module A Process module to display help videos for the ProcessWire CMS. It can be used to make help videos (screencasts) available to content editors. This module adds a 'Help Videos" section to the ProcessWire backend. The help videos are accessible through an automatically created page in the Admin page tree. You can add your help videos as pages in the page tree. The module adds a hidden page to the page tree that acts as parent page for the help video pages. All necessary fields and templates will be installed automatically. If there are already a CKEditor field and/or a file field for mp4 files installed in the system, the module will use those. Otherwise it will create the necessary fields. Also the necessary templates for the parent help videos page and it's children are created on module install. The module installs a permission process-helpvideos. Every user role that should have access to the help video section, needs this permission. I use the help video approach on quite a few production sites. It is stable so far and well received by site owners/editors. Up until now I installed required fields, templates and pages manually and then added the module. Now I added all this logic to the install method of the module and it should be ready to share. The module and further description on how to use it is available on github: https://github.com/gebeer/ProcessHelpVideos If you like to give it a try, I am happy to receive your comments/suggestions here.

Thx, then I think it's probably the best time for creating seperate accounts for them ? What if one user has the same page opened in two tabs? This would be the same session but could also be unwanted (and overwriting/losing changes).

ProcessWire 3.0.146 contains about 22 commits (relative to 3.0.145) and these commits are largely focused on resolving reports from the processwire-issues repository. However, there have also been several improvements and related additions. One of these additions was a foundational upgrade that adds support for Fieldtype modules to use a custom class for Field objects. This will open more possibilities for improved Field/Fieldtype-specific APIs. Several have asked for improvements in the APIs of Repeaters and other fields, so this is a step that begins the lay the tracks for moving in that direction. Traditionally the API calls for working with Fields and Fieldtypes have not been nearly as simple as those that work with Pages, so this will be an upgrade that narrows and eventually eliminates that gap, longer term. On the core side, I currently plan on using this to improve the API for Repeaters, Comments and Options fields, and perhaps others. Outside of the core, ProFields will eventually take advantage of custom Field objects as well. As usual, none of this will break any existing code, but it will add simplicity for those that work with Field/Fieldtype APIs in ProcessWire. As for other changes in 3.0.146, I think last week’s ProcessWire Weekly did a great job of covering them, so if you are interested be sure to check that out. Next week is partially a holiday week here in the US, so I’ll be on a little bit of a reduced schedule, but will still be working on the core. I’m also releasing a new module into the ProDevTools set of modules next week, so I’ll tell you more about that one in next week’s blog or forum post. Thanks for reading and have a great weekend!