PW 3.0.164 master – Core updates

[ryan]

In preparation for the next master version, this week no new features were added, but just like last week, more than a dozen issue reports were resolved. Having focused largely on fixing various issues over the last month, I feel pretty confident that the current dev branch is significantly more solid than the 3.0.148 master version. It adds and improves a whole lot, and also fixes a lot. And to the best of my knowledge, there aren’t any new issues between 3.0.146 and 3.0.164 that haven’t already been fixed. Basically, I don’t think it makes any sense to keep all these updates exclusive to the dev branch any longer, so have merged it to master, today. Consider it a soft launch, as I haven’t made it an official tagged version yet. Maybe I’m shy, but wanted to wait till Monday before Git tagging it and making it official. The master branch has a different audience than the dev branch, and so there’s always that possibility that some new issue will appear that hasn’t on the dev branch, and wouldn’t have. So we’ll let it marinate on the master branch for the weekend before broadcasting it very far. By this time next week, I should have a blog post ready that covers all that’s new in this version, which is 226 commits ahead of the previous master (3.0.148), so there’s a lot to cover. 

I want to thank you all that have been helping to identify and report issues on GitHub as they come up. Having covered a lot of issue reports over the last month, I can see a lot of effort goes into preparing many of the reports. Your work is appreciated. This month I focused primarily on the reports that I thought were likely to make the most difference to the most people. I also focused on issues that I thought could be accommodated without introducing potentially new issues or new code to test. Of course, not every report could be covered, and there’s always more to do, so I’ll be getting back to it on the dev branch here soon. In addition, I’ve held off on some new things I’ve wanted to add for awhile (a feature freeze of sorts) in preparation for an end-of-month master version. I’m looking forward to outlining all that’s new in next week’s blog post. Until then, thanks for reading and if you get a chance to test out the new 3.0.164 version, please do and let me know how it goes (both master and dev branches are identical right now). I hope you have a great weekend!

[Ivan Gretsky]

Thanks, @ryan!

Sometimes I think that ProcessWire is so mature and feature rich that only fixing the issues at hand can make it stand out even more than adding the new stuff (until the the stuff is added and I start thinking that I could not live without the features just added))) Thank you so much for keeping the right balance.

[schwarzdesign]

 @ryan In the spirit of closing up Github issues, could you take a look at issue #1133? Changing passwords on the profile page does not work if the old password is pasted instead of typed in manually. Edge-case, admittedly, but when a client stumbles upon this it's pretty disruptive. As far as I can tell it's just a jQuery event that needs to listen to paste events as well as input events, so it should be a one-line fix. Though of course I don't know the code base so well, so I might be mistaken ?

Same for issue #1111 about titles getting cut off in the page tree.

Thanks!

[ottogal]

Isn't it a rather common security consideration to not allow passwords to be pasted?

[MoritzLost]

14 minutes ago, ottogal said:

Isn't it a rather common security consideration to not allow passwords to be pasted?

No, that's a common misconception. There's no security benefit at all (it can be bypassed super easily), but comes with multiple downsides (worse UX, higher chance of typos). It may even decrease security because it discourages the usage of password managers. See security.SE, NCSE and web.dev for reference.

By the way that's only slightly related to this issue. The profile page does allow passwords to be pasted; but the inputs for the new password are only activated after the old password field has been typed into, and that event handler only listens for input events, not paste events.

[ryan]

@schwarzdesign

Quote

In the spirit of closing up Github issues, could you take a look at issue #1133? 

I was never able to duplicate that one. Pasting in old password makes the new password editable when I test here. But I think this one has come up before and it had something to do with some other admin enhancement module, but I don't remember for sure.

Quote

Same for issue #1111 about titles getting cut off in the page tree.

There's a reply in that thread that says it only happens of entity encoding textformatter is disabled for the title field. I think it's rare for someone to disable that textformatter on the title field and something I wouldn't usually recommend doing. But I think we can also accommodate the request in that report, just wanted to return to it later when back on the dev branch because it's a change of behavior that I think needs more thorough dev branch testing.

 

[ottogal]

46 minutes ago, MoritzLost said:

No, that's a common misconception. There's no security benefit at all (it can be bypassed super easily), but comes with multiple downsides (worse UX, higher chance of typos). It may even decrease security because it discourages the usage of password managers. See security.SE, NCSE and web.dev for reference.

Thank you for the insight - I wasn't aware of this.

[MoritzLost]

10 minutes ago, ryan said:

I was never able to duplicate that one. Pasting in old password makes the new password editable when I test here. But I think this one has come up before and it had something to do with some other admin enhancement module, but I don't remember for sure.

@ryan Thanks for the reply! Sorry, I failed to mention that I'm talking about pasting text through they context menu (right-click -> paste). In this case, they keyup event is not triggered, because no key was pressed. Pasting with CTRL / CMD + V works fine.

Quote

There's a reply in that thread that says it only happens of entity encoding textformatter is disabled for the title field. I think it's rare for someone to disable that textformatter on the title field and something I wouldn't usually recommend doing. But I think we can also accommodate the request in that report, just wanted to return to it later when back on the dev branch because it's a change of behavior that I think needs more thorough dev branch testing.

Great, thanks ? We use Twig for most of our ProcessWire sites, which comes with autoescaping. In this case, having the formatter on leads to double escaping, and it's easier and more consistent to have Twig handle escaping everything by default.

[d'Hinnisdaël]

On 8/3/2020 at 3:56 PM, ryan said:

There's a reply in that thread that says it only happens of entity encoding textformatter is disabled for the title field. I think it's rare for someone to disable that textformatter on the title field and something I wouldn't usually recommend doing. But I think we can also accommodate the request in that report, just wanted to return to it later when back on the dev branch because it's a change of behavior that I think needs more thorough dev branch testing.

I would second MoritzLost's viewpoint here. Most template engines auto-escape output — so as soon as you use Twig or Latte for your views, it's best to disable the entity formatter for all fields and let the template engine handle it.