netcarver

@bernhard No, I think that's just a function declaration before a class declaration. If in doubt, you can run phpcs on your code. If you are only looking for side-effect warnings just grep your output for "effects"... phpcs --standard=PSR12 file.php | grep "effects" Run it without the grep for the full PSR12 ruleset... phpcs --standard=PSR12 file.php

This does introduce a side-effect to the class file. While it's not "wrong", it is discouraged, and will cause some code checkers to complain about the code. For example, if you are running codesniffer with one of the PSR standards, this would probably be flagged up (not checked.)

Hello @bernhard Ok, it actually isn't a module, it's a collection of tweaks. From my point of view, I'd rather just install the exact tweaks I'm going to use in to the assets/RockAdminTweaks/tweaks folder. If every possible tweak is accumulated in the RockAdminTweaks repo, wouldn't all of them will be copied in to the site when the module is installed or updated? In that case, RockAdminTweaks is likely to become somewhat bloated over time, and bloat is something you seemed to be moving away from when I read the original RockAdminTweaks documentation... The repo I started doesn't have to be the only pool. I started it to learn how how to write tweaks, and to experiment with how a pool could be accomplished. If the tweak pool idea survives, I'd actually much rather have a the pool under the baumrock/ namespace. There are probably other ways of dealing with avoiding bloat + provide a library of tweaks as well, but it seems to me that to avoid bloat the tweaks need to live somewhere outside the module, or there needs to be some mechanism (other than manually deleting unwanted tweaks from the server) that allows the install of the exact tweaks required. Yes, having those in separate files would be much better than inlining them in the addStyles() method. That makes sense.

Great, thanks @bernhard. I have a small number of tweaks (some from AdminOnSteroids) in my public tweak pool already - looks like they will be compatible with this version of your module if the namespace is unchanged.

Hello @TomPich I'd be delighted to receive a PR against the module - or just open an issue to discuss your modifications. This is a very old module now, so it probably could do with a fresh update.

@Robin S I ended up using boot.ini to extend PW's class loader early enough to allow traits to be used in the UserPage class. More on this here.

Here's my first attempt at a public repo for Rock Admin Tweaks. Has the AdminOnSteroids tweaks from above, and my QuickWebAuthnLogin already ported over from RockMigrations.

I was unaware of RockAdminTweaks and have now installed it alongside RockMigrations. Porting the tweaks over is very simple (just a change to the namespace in the tweak file) and I prefer having them in the assets folder as well.

The RockAdminTweaks repo says... Does RockMigrations have the same tweak loading ability from the assets directory?

Ok, if anyone wants to explore this, and has RockMigrations installed, here's a slightly improved version of the above, packaged as a Tweak. QuickWebAuthnLogin.php

@ColtNikolaus No need to ask for permission, doing so adds noise to the forum, creates work for other people, and delays possible answers. What is your actual question?

All we need now is a community library of tweaks and macros. Perhaps it could be called "The Rock Pool" :)

Yes, that's right. I use maybe 5 or so features from AoS and figured porting those over would be a good way to learn both how AoS does it, and how your tweaks work. I'll add as PRs, with attribution to tpr, as I go. Updated to add: First four tweaks from AoS done and in as a pull request. Show extra actions by default. Show template name as a link to the template edit page. "Bypass trash" adds the Delete button to the page action list and also allows permanent deletion from the delete tab when editing pages. Prev/Next page edit links.

Ah, this is user error - ignore my post above. :)

Hi @bernhard I just tried adding the following tweak to the tweaks/ directory, and am getting an error from RockMigrations when the admin reloads. If I remove my attempted tweak, everything works again. I think this is in RM, rather than the tweak file. Thanks for the module, BTW. PageListShowExtras.php

@d'Hinnisdaël Thank you. As an example with trailing hexadecimal video_id: https://vimeo.com/553329597/04c306a466 I've closed my PR for the time being.

Hmm. Anyone know of a canonical list of valid Vimeo url formats?

Thanks for the updates, Bernhard. Seems like I somewhat monopolised things this month :)

Nice - I'll be able to make use of that at PWGeeks next time I update it. Thank you for the tip.

I guess I'm just becomming really lazy as I age, and this tutorial can be taken as a sign of my growing sloth. I have a Yubikey that I use as my 2nd factor on a localy hosted PW site. And I've become tired of typing my admin username + password and hitting enter/clicking Submit + then having to tap the Yubikey to log in. I know, it's a local install, and I could just turn off my 2FA, but then I'd still have to type the username and password, and I'm too lazy even for that now (plus, I've started to hate passwords.) I'd really rather just tap the yubikey to be logged in! As PW's so hookable, I figured it would be pretty easy to modify the login process to allow me to do this, just for this site (well, maybe not just this one). Sure enough, it turned out to be pretty simple - though I do not recommend trying this on any sites hosted in the cloud. Firstly, you'll need the TfaWebAuthn module installed on the site, and have configured it on your superuser account. Once you are logging in successfully with that, add the following to site/templates/admin.php... /** * If there is only 1 superuser with TfaWebAuthn set up on the site, * and if the username is empty on login submission, we change the login_name * to the superuser's account name, and the login_pass to a dummy value to * allow the Session::authenticate hook to be called. * * Although the Session::authenticate method will fail we will hookAfter it * and pretend that it didn't. That will start 2FA credential collection * allowing us to proceed with just that protecting the account. * * For local installs where I have a YubiKey, this will be good enough. */ wire()->addHookAfter("ProcessLogin::loginFormProcessReady", function($event) { $uname = wire()->input->post->login_name ?? ''; if ('' === $uname) { $super_role_id = wire()->config->superUserRolePageID; $supers = wire()->users->find("roles=$super_role_id, tfa_type=TfaWebAuthn"); $num = count($supers); if (1 === $num) { $super = $supers->eq(0); wire()->input->post->login_name = $super->name; wire()->input->post->login_pass = 'dummy_password'; } } }); wire()->addHookAfter("Session::authenticate", function($event) { $super_role_id = wire()->config->superUserRolePageID; $supers = wire()->users->find("roles=$super_role_id, tfa_type=TfaWebAuthn"); $num = count($supers); if (1 === $num) { $user = $event->arguments(0); $super = $supers->eq(0); if ($user->id === $super->id && 'TfaWebAuthn' === $user->hasTfa()) { $event->return = true; // Override earlier failed authentication for this user } } }); As long as you leave the initial login details blank, all you need to do now is hit enter (or click Submit) and then tap the Yubikey to be logged in. Nice :)

Just curious, can that also be done with page classes + magic pages, @bernhard ?

In addition to the great suggestion from @Nicolas, you can also do it by prepending a Markup textfield to the edit form for just that particular template. Here's more code - I'd put this in site/templates/admin.php as this is only an admin feature. $pages->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->return; $id = (int) wire("input")->get("id"); if (!$id) { return; } $editedPage = wire("pages")->get($id); if ($editedPage->template->name === "home") { // CHANGE TEMPLATE NAME HERE $f = wire()->modules->get('InputfieldMarkup'); $f->label = "Notes"; $f->value = "<p>Your HTML Notes in here.</p>"; $form->prepend($f); } });

@Robin S @Mats @Marty Walker @ryan Pull request is in for this fix.

@Marty Walker @Robin S @Mats Could you try the attached version of the module and see if it helps with your issues with Vimeo URL formats? Robin, Mats (I hope I got the right one), I've included you both as you have a similar issue open on the repo. TextformatterVideoEmbed.module

Ok, other things that come to mind are... session.gc_maxlifetime is set to something low. You are using php-fpm and it has a different php.ini file with different settings to the one you looked at before (maybe)