adrian

@ryan Regarding the forum's 403 mentioned earlier: It's not a permissions problem on the forum — the request never reaches the forum software. What's happening 403 server: awselb/2.0 /talk/discover/unread/ 403 server: awselb/2.0 /talk/discover/ 403 server: awselb/2.0 /talk/discover/15/ 403 server: awselb/2.0 /talk/index.php?/discover/unread/ 200 server: Apache/2.4.68 /talk/ ← app responds normally 200 server: Apache/2.4.68 /talk/search/ , /talk/online/ 404 server: Apache/2.4.68 /talk/discoverxyz/ ← app responds normally The 403 comes back with server: awselb/2.0 and a bare nginx/WAF-style error page (<h1>403 Forbidden</h1> plus MSIE padding comments) — that's an AWS load balancer / WAF rule, not Invision Community. If it were an IPS permissions denial you'd get an Apache response with the themed "You do not have permission" page. The rule is matching the literal /discover/ segment anywhere in the request line: /talk/discover/unread (no trailing slash), /talk/discover/15/, and even /talk/index.php?/discover/unread/ in the query string are all blocked, while /talk/discoverxyz/ sails through to the app and 404s. It's not user-agent based either — curl, Chrome and Googlebot UAs all get the same 403, and it's independent of login state since cookies never get evaluated. IPS's Discover/activity streams (/discover/unread/, /discover/<id>/) are the most database-expensive pages on an IPS board and a magnet for crawlers hammering every stream permutation. Blocking /discover/ at the edge is a standard load-shedding move. So this is almost certainly an intentional (or over-broad) WAF rule added by whoever runs processwire.com's infrastructure — the collateral damage being that logged-in members lose the "unread content" feature entirely.

Just wanted to drop by after finally having a use for this. Just a great solution @Robin S - thanks again!

Thanks for the updates @monollonom - I am curious though. I am using: $p = $event->arguments[0]; in a FieldtypeQRCode::getQRText hook and it still seems to be working fine. Am I not understanding what the changes are supposed to have broken?

Thanks - Kontor actually sounds fantastic - I've been offering my team to build a replacement for Hubspot (I really hate all these SaaS tools that people want to use), but they won't see the light :) I am still a bit confused about Folio vs Verk, because I feel like Verk can already be used for everyday projects and tasks, etc and I worry about users needing to use one tool for personal and another for one for page-linked tasks etc, but that might just be me.

Hey @maximus - thanks as always. Can you please explain how this would integrate with Verk, or does it supersede it?

Thanks @Robin S - should hopefully be fixed in the latest version.

Any chance you have a browser plugin like Grammarly installed?

@Saugatdai - if I have the module correct, you're probable better off posting your issue over here: https://processwire.com/talk/forum/62-padloper/

I recently extended PrivacyWire (via hooks) to handle opt-in and opt-out models and during my research the one key thing I discovered is that the province of Quebec also requires the opt-in model, so I also use Maxmind's region_code to allow support for specifying which model is used at the region, and not just country level. I also added support for showing a "Opt out request honored via privacy signal" temporary toast message when the browser has set a Global Privacy Control (GPC) policy, rather than either of the opt-in or opt-out banners. @maximus - does the module support these options?

Claude is always asking me to test things via Tracy console. This is why I added to the copy MD for agent, including the Copy All button at the bottom. It lets it understand the file/template/data structure and also to run comparisons on the data retrieved when refactoring code or adding new features. I much prefer this to giving Claude direct access to the site DB - this way I can check each query it's about to make and to choose whether I provide it with the complete results or not. Not that it is a real lock, but Tracy does have a setting to prevent all access to superusers with another role so if they don't know about Tracy then you could keep them out. Best bet would be to define this setting via $config>tracy rather than in the module settings so it's harder for them to override.

Hi @Robin S - sorry for delay in responding, but thanks for the follow up. I haven't used that module regularly in so long. Anyway, glad you figured out an approach that works for you. Cheers.

This is exactly why I tweaked mine to look like this with the top/bottom border (box-shadow) on hover. You get the definition you need with a nicer grey (IMO). with: .PageList .PageListItem:hover { box-shadow: inset 0 0.5px 0 0 #ccc, inset 0 -0.5px 0 0 #ccc; border-radius: 0 !important; }

But don't all elements have the grey border which helps to separate them from the background - I think that is why #fbfbfb works.

I agree with @Peter Knight - I set --pw-main-background: #fbfbfb; on all my sites, but I am sure#f5f5f5 would also be a better default.

So does that mean that 2.0 fixed all the issues that you just reported as being present in 1.4.1? Can I make 2.0 the new master version?