1.0.8.21

[ecartz]

We are getting ready to release 1.0.8.21, so now would be a good time to set up a new test store. Please remember that bugs that you report now are ones that you won't have to patch in later.

Full download: https://github.com/CE-PhoenixCart/Phoen ... 0.8.21.zip

This release will feature a fix for installing layout modules as well as many other changes mentioned at viewtopic.php?f=28&t=2030

This is also a release candidate for 1.0.9.0. 1.0.9.0 will not have full PHP 8.2 support. That is currently planned for 1.0.9.2 as part of the new development for the 1.0.9.* series. The greatest obstacle at the moment is strftime. We have a plan for strftime in a future release (currently planned for 1.0.9.2) but aren't ready to implement it yet.

[kudos]

Just want to give a BIG BIG thank you to all the team and others that have worked on code and addons for phoenix

i will make a test install and test the best i can here.
thank you, ill continue my donation for along time yet for sure.

rob

[ecartz]

The update package:

update_1.0.8.20_1.0.8.21.zip

[heatherbell]

Might just be our configuration but just in case anyone sees display issues on create_account after update, Localization>Customer Data Groups widths needed to be changed from 12 to col-sm-12 (or whatever width desired).

[zipurman]

The admin login process hook of "processActionFail" doesn't ever get called on failed admin logins.

[zipurman]

The admin login process hook of "processActionFail" doesn't ever get called on failed admin logins.

I was able to work around this by calling the listen_injectSiteEnd and checking to see if !empty( $_POST[ 'username' ] ).

[ecartz]

It looks like it should get called if

1. There haven't been too many recent login attempts.
2. A correct username is given.
3. An incorrect password (for that username) is given.

If any of those things is false, then it won't get called. I.e. you can't use that particular hook if there have been too many recent login attempts nor if the username does not exist in the database.

[zipurman]

It looks like it should get called if

1. There haven't been too many recent login attempts.
2. A correct username is given.
3. An incorrect password (for that username) is given.

If any of those things is false, then it won't get called. I.e. you can't use that particular hook if there have been too many recent login attempts nor if the username does not exist in the database.

I was expecting processActionFail would mean any failed login. Thanks for clearing that up. I have a working solution without it

[burt]

processActionFail could potentially be moved to the else { block of code (adds to the action_recorder table) towards the bottom of the file.

processActionFail may be more useful there ?

[ecartz]

But then it wouldn't be called when the password is incorrect for the given (correct) username. It still wouldn't be called for a non-existent username. It would be called for too many attempts.

What Preston seems to be requesting is to make something that runs regardless of the failure scenario. And I wouldn't be surprised if someone else (now or later) wanted something to provide custom behaviors for each scenario:

processActionSuccess: login succeeded.
passwordVerificationFailed: login failed because the password was incorrect for the username. This is when processActionFailed triggers.
usernameNotFound: the username is not in the administrators table.
tooManyAttempts: cannot perform the login action because too many attempts have been made.
processActionFailed: for any case other than success. Note that this is when processAction triggers.

So in fact, it looks like Preston could get the effect that he wanted by adding a processAction hook listener. Since processAction will trigger any time it doesn't redirect before then. I.e. in all but the success case.

These (Success/Failed) hook points have only existed since 1.0.7.16. The processAction hook point dates back to 1.0.7.0.

We could replace processActionFailed with passwordVerificationFailed and add usernameNotFound and tooManyAttempts. We can't rename processAction, as that is part of the action system. I.e. we'll automatically have a processAction hook point because we have a process action.