netcarver

Hi @DrQuincy I think you can do this by hooking in to PW's login flow. Here's how I'd attempt to do this - untested - just to give you some inspiration... Create a new field on the User template for their hashed password from your old system. Write a script to populate this field where there's an email match between the old system and the new one. If the new system doesn't have users in it yet, then great, you'll be creating user records for everyone from the old system. Make sure you create a long, random, password for the initial processwire password on any new users you create and leave existing user passwords untouched. Store the hash from your system in the new field on the matching user and save any changes. You need a before hook on the session::login method. Use the name param (in $event->argument(0)) to match on emails if that's how you did it in the old system, if you have exactly one match, and this user has a non-empty value for your old password hash, use your existing pwd checking algorithm to authenticate them from the pass ($event->arguments(1)) parameter. If that works, the plaintext password they submitted to you is the correct password. Now set the PW password on that account using the plaintext password you just verified is correct AND delete the old password hash value. Now the correct password has been stored in the User's PW pass field, just exit the hook and PW should process the login as normal, or call the forceLogin method to log them in and do your own redirect. Basically, as people log in, they will auto-convert their accounts over to PWs way of doing things. Once they convert, the login process just reverts to using PWs method. Potential gotcha: more than one account in the PW system with the same email (if there are already accounts in there.) After a reasonable period has elapsed, you could then deal with seemingly dormant accounts by emailing non-converted users and asking them to login (or otherwise handle them as appropriate.) Hope that helps.

There are several modules that might help. Most by Macrura here in the forums.

Maybe open an issue in the issue tracker if not yet done?

If anyone is using wire-cli, and you find you're getting a lot of PHP warnings about not being able to set session parameters after headers have been sent, this may help. You may need to add a custom session function to site/config.php to prevent ProcessWire attempting to setup session handling when it's bootstrapped by wire-cli from the command line. YMMV, but this seems to be working for me. NOTES: Adjust the path if your admin interface is not at /processwire/. If you need sessions on the public (non-admin) paths of your site, remove the "ADJUST THIS PATH..." line and change the final line to "return true;". /** * Custom Session Control * * - Keeps non-admin pages free of cookies/sessions * - Unless there is already a session cookie * - Prevents session start on CLI invocation (wire-cli etc.) * - Allows admin pages to use sessions */ $config->sessionAllow = function($session) { if ($session->hasCookie()) return true; $req_uri = $_SERVER['REQUEST_URI'] ?? false; if (false === $req_uri) return false; // CLI invocation? if (0 === strpos($req_uri, '/processwire/')) return true; // ADJUST THIS PATH IF NEEDED return false; };

Some VPN software has something like a "Local Network Sharing" setting. If your VPN has such an option, might be worth seeing if that fixes this for you.

I don't have any idea - but could you let us know what error(s) you are getting, as that might help?

@ttttim I just switch a site over from PostmarkApp to Brevo with your module and quick change to the sender id. Seems to work fine at first glance. Thank you for your module!

Hi @bernhard thanks for the recent improvements to the livereload feature! Please ignore my suggestion above - it was just a "I wonder if..." kind of thing. What you've done with adding things to the error and ajax pages are great.

Ah, I like PostmarkApp for transactional stuff, but their monthly limit is a quite low on the free tier (though I am thankful for it.) Brevo's limits are somewhat better. I will be trying out this module soon, as I'm just calling brevo's API directly at the moment and want to use a module for this.

@Chris-PW Welcome to the plugin-author's club :) Would you be able to create a github account and create a repository for this? It's the next step to getting this published in the PW modules DB.

Very timely, thank you for this, and congratulations on your first public module release!

Works great, thank you both!

@BitPoet It's been a while, but would you consider publishing this module to github + the PW modules directory? That would make it more discoverable for PW folks. Thanks for the code though!

@bernhard I only found this post here in the forum - and not realising this had changed - went looking for it in the RockFrontend config settings. Pehaps the title of this thread could be changed to reflect that this is no longer available in RockFrontend?

Is this still an option? If so, I can't seem to find this in the module config for RockFrontend. Also, the screenshots seem to be from RockPageBuilder?

Ok, everything seems to work out of the box if you first install PWs PageFrontEdit module (which I didn't do as they were all fresh installs!) I guess this is what fulfills Alfred's JQuery dependency without the need to edit the _init.php file. @bernhard Could the code catch this by default? So if the need for alred is detected server side, but PageFrontEdit is not installed, add a message about installing it? Could also be added to the alfred script so it pops up an alert about installing PageFrontEdit?

Hi @imandreas Yes, I changed this in _init.php and Alfred now runs as expected. My point is that I think this should be included automatically within the RockFrontend site profile, or be in the RockFrontend documentation for Alfred. Or perhaps the code for Alfred could pop up a JS alert box indicating the need to load JQuery - which would save having to look at the console. $rf->scripts() // load uikit ->add('/site/templates/uikit/dist/js/uikit.min.js', 'defer') // load custom javascript of this project ->add('/site/templates/scripts/main.js', 'defer') // load jQuery from /wire to allow ALFRED testing ->add('/wire/modules/Jquery/JqueryCore/JqueryCore.js', 'defer') // <<< Added // minify on production ->minify($config->debug ? false : true); This is just to get things running for testing - would need to conditionally include it only if alfred is needed.

@bernhardI've been trying to get Alfred working on my local ddev stack - but have failed so far. I've added the needed {alfred($page, 'fieldname')} code to the latte template to trigger alfred inclusion on the page render - and the script is being included, and is download from the server. I view site, while I'm logged in as superuser (ddevadmin). Just like iamandreas, I get the following... I've checked the role rockfrontend-alfred is present, and the ddevadmin is a superuser. I've now tried this with a PW dev & PW master codebase, in three separate ddev installs - one with the default docroot - and have had the same result on each one. Setup was super easy with ddev and then rockshell, and they all had your RockFrontend site profile installed. So, it looks like jQuery isn't being included in the scripts when needed maybe?? Anyway, will dig some more.

Hey @bernhard - I will be trying out RockPageBuilder on a project soon - but for now, I think a config setting for the livereload feature, that allows a superuser to configure which templates to livereload pages for, would be a neat feature for anyone who doesn't get RockPageBuilder. Personally, I would only use this feature for local development though.

Just started using RockFrontend on a local site and I'm relly enjoying livereload when updating .latte templates. In fact, as I work with my admin pages in a window on the left, and the site in a window on the right of my screen, I wanted to get livereload when saving pages in the admin - but only for the basic-page template. So here's a little hack. Adding this to site/templates/admin.php, before the line require($config->paths->core . "admin.php"); works great, and I now get livereload on page save or file changes. Not sure how well this will work with Alfred though as I'm not using that yet. $pages->addHookAfter('saved', function($event) { $p = $event->arguments(0); if (in_array($p->template->name, ['basic-page'])) { // Update array as needed $touchfile = __DIR__ . "/.lastupdate"; touch($touchfile); } });

Yes, that's right - it's all included in the original email. Ideally yes, but it's now possible for what the first recipient sees to be totally benign, just requesting the message be forwarded to another decision maker in your organisation. Once the forward happens, the message the 2nd recipient sees can be totally different to what the first recipient saw. So now the content of the forwarded message needs to be validated - not just a quick check that the first recipient actually forwarded a message to the 2nd recipient. If that's already part of the standard-operating-procedure (SOP) in your organisation, then I think you are OK. If that's not the case, then the SOP needs to be updated so validation of the forwarded content actually happens.

Looking forward to the upcoming ddev 1.23.0 release as it should (finally) have fixed support for generating .avif images.

Looks like the next level of Business Email Compromise just became unlocked (if it wasn't already.) Lutra Security have a nice write-up on the attack they are calling "Kobold Letters". Basically, email clients change the DOM of the email when they forward it, allowing different CSS to apply between the first recipient viewing an email, and subsequent recipients. Allows an innocent-looking "request to forward to the CFO" phishing email to the CEO to become a "request to send funds/data" when received by the CFO from the CEO. Explict verification of the request contents needed now, not just a "Did you send me a message?" question which only verifies that the message was forwarded. Something to be aware of if you work in a team or are responsible for any kind of staff training on phishing etc.

@BrendonKoz Topic and forum links added to the activity list. Please reload your page to see them. I still need to add detection for the links to new topics and replies - but that will be another day, as will looking at the update date on PWGeeks.

@BrendonKoz Thank you for the feedback, and I'm glad the PWGeeks Catalog is of use to you! WRT. the activity tracker: whilst links to the forum topic could easily be added, I haven't yet done it and it was a deliberate decision I made at the time. I don't think I wanted to store the additional URL data in the SQLite DB, but can't recall exactly why now. As you say, it would be rather useful if they linked over to the actual posts on the forum. I'll take a look the next time I update this part of the site. To answer your Q about the PWGeeks catalog: that timestamp is meant to be the last time github/gitlab/pw etc report the project as being updated - but looks like I have a bug there and it's just showing the last time the cached data was updated for just about everything.