adrian

@teppo - that is what I thought, but I was thrown by the comment for that rule: "After uncommenting, test a URL like domain.com/site/assets/files/test.jpg to make sure you are getting a 404 and not your homepage." Those conditions don't seem to prevent apache from serving up a test.jpg at that path, although it occurs to me just now that Ryan's intention was for test.jpg to be a file that doesn't actually exist - makes sense now! I was also confused by the "prevent PW from attempting to serve images or anything in /site/assets/" - I thought he was talking about subfolders of assets as well. My initial thought was that this rile was actually about preventing hotlinking, so I think I got the intention backwards, hence my confusion ?

Yeah I know - I had a LOT of work to do to fix the queries on a large custom application of mine, but from the reading I did at the time, it was a highly recommended change to better ensure you're getting the results you were expecting. Mine was very data / calculation heavy though, so maybe not as important for typical PW queries.

I know Section 18 isn't new, but it seems like it doesn't work as expected. I feel like it is missing the actual RewriteRule after the conditions, or maybe I am misunderstanding what it's meant to do?

Interesting that Ryan said this when he actually decided to force removal (https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L975) of the new mysql default for "ONLY_FULL_GROUP_BY", rather than properly rewriting the queries to work with the new default.

Try the new version just committed. Not currently, but it should be pretty easy to implement - do you feel like having a go at enhancing the replaceShortcodes() method to handle this? PRs greatly appreciated!

As @Robin S mentioned, I'd be happy to accept a PR for this enhancement!

This is now fixed in the core.

IMPORTANT NOTICE!!! Hi everyone. I just discovered something pretty important with this module. If you are using the Role Name or Custom PHP Code option and matching a page name or path, you MUST be sure to check "No Access" for the "If no match, give all access or no access?" setting. If you don't do this, a site editor could change the name of their branch parent, which would result in no match and hence they could gain access to the entire page tree. I am tempted to actually remove these two matching options to improve security - is anyone using them? To make life easier, I have added a new "Role Specified Branch Parent" option which allows you to select a branch parent on a per role basis, rather than per user. I think in most cases this is the best option to use. Please be sure to check your settings and if you can please switch to the "Role specified" or "User specified" options in the new version. Let me know if you have any questions or concerns. Thanks, Adrian

Actually all of the above, but yes, the Tracy dump is a key part of it - so much easier to see which parts are being added to the selector this way. I do also sometimes modify parts by key, but I also just find my code looks cleaner that concatenating a string with commas at the end of each one, plus you don't have to worry about a possible trailing comma.

PS, here's the thread @Robin S was referring to:

Yeah, @Robin S is mostly correct. The array approach seems like a good idea, but it will end up biting you in many cases. For ease of readability and building up complex selectors, I do build them with a regular php array and then simply implode the array with a comma to get the string selector. This is now my goto approach for any complex dynamic selectors.

Should be fixed now!

https://github.com/processwire/processwire-issues/issues/905

I've just commented on that old closed issue: https://github.com/ryancramerdesign/ProcessWire/issues/1868#issuecomment-500081534 Note that the change needs to happen in ListerPro, rather than the core (I think).

Are other html emails from your system (sent with a wireMail) working as expected? In other words, is it only emails from this module that are the problem?

What about the email provider? Can you try to a gmail address to confirm the problem?

@bramwolf - does it make a difference if you use a different email client? What are you using?

https://github.com/processwire/processwire-issues/issues/896

I hadn't looked - thanks for posting that - it's pretty clear from that @todo that Ryan know about this and that it needs fixing. Obviously calling findOne() if it's a selector isn't enough to get it to return NullPage as things currently stand, but this really should be fixed because with the current behavior you can't simply do a normal: if($result->id) on an in memory selector that returns no results because of the null vs NullPage - this has annoyed me for a long time ?

Thanks for chiming in! Here are some more outputs which I think help to back up the assertion that it should return a NullPage

What does everyone think of this? Shouldn't they both return NullPage? I'd love to hear your thoughts. Thanks!

Not testing in the context of this module, but this looks to work as expected: Does that work as expected at your end?

I don't know - we'd have to get @Pete's input on why that was done, but if you want to put together a PR to add a module setting where these can be configured, I can push to the main repo.

Did it create the WEBP version? Maybe the JPG was smaller so it served that up instead. In my limited experience, it's quite common that the webp version is actually larger :)

It doesn't seem like this is necessary anymore - not sure if the change happened on this update: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/