Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check previousStep for null #2504

Merged
merged 2 commits into from
Apr 17, 2024
Merged

Check previousStep for null #2504

merged 2 commits into from
Apr 17, 2024

Conversation

fritzmg
Copy link
Contributor

@fritzmg fritzmg commented Nov 27, 2023

Currently a click on the back button within the checkout module might not be recognized if the value of the button is empty for whatever reason, e.g. if you adjusted the template to

<button type="submit" class="submit previous button" name="previousStep"></button>

for example, or if the previousLabel variable is empty for whatever reason. A click on the back button in this case will instead be interpreted as a click on the confirm/next button. This PR changes that by always checking whether the back button was used - by way of checking if Input::post returns null or not.

@aschempp
Copy link
Member

not sure why an empty label would be valid?

@fritzmg
Copy link
Contributor Author

fritzmg commented Nov 27, 2023

not sure why an empty label would be valid?

The following would be valid and would lead to the same issue:

<button type="submit" class="submit previous button" name="previousStep"><?= $this->previousLabel ?></button>

This sends an empty string for the previousStep POST variable.

@aschempp
Copy link
Member

aschempp commented Dec 6, 2023

there's a few other places where we do this comparison, could you maybe fix them too? I quickly searched for Input::post() and it found our action buttons for example.

@fritzmg
Copy link
Contributor Author

fritzmg commented Dec 11, 2023

Hm, not sure which places these are? Which action buttons do you mean? It only really matters in the checkout module where there is a back button I think.

@fritzmg
Copy link
Contributor Author

fritzmg commented Jan 22, 2024

/reminder @aschempp

@fritzmg fritzmg changed the base branch from 2.8 to 2.9 February 2, 2024 11:23
@fritzmg
Copy link
Contributor Author

fritzmg commented Feb 2, 2024

Rebased to 2.9 now.

@aschempp
Copy link
Member

aschempp commented Feb 5, 2024

I checked this again. Isotope does not generate <button> elements, but <input type="submit">. So I am assuming you changed the markup yourself? You should add <button value="1"> to make sure the button actually submits an input, that should solve the problem, shouldn't it?

@fritzmg
Copy link
Contributor Author

fritzmg commented Feb 5, 2024

It does not matter if you use <button> or <input> - and that was not really the point anyway. This issue is not an issue that occurs out of the box with Isotope, only when certain changes were made (intentionally or unintentionally) - see the initial description. The check should always be a null check in this case for defensive programming, otherwise you can end up in a situation where the Back button makes a purchase instead.

@qzminski
Copy link
Member

qzminski commented Apr 4, 2024

I have approved this change. If the "go back" button is submitted and has no value attribute, then it gets an empty string:

CleanShot 2024-04-04 at 09 30 15

If we hit the "next step" button, then the previousStep is not even in the $_POST, so Input::post() would return null.

@aschempp
Copy link
Member

Confirming this with Symfony forms as well: https://github.com/symfony/symfony/blob/4ce4e5ed87acc87d90d7f516b14289c4f49139ef/src/Symfony/Component/Form/SubmitButton.php#L45

I'll update the PR to include all the other places where Isotope does that check.

@aschempp aschempp added the bug label Apr 17, 2024
@aschempp aschempp added this to the 2.9.0 milestone Apr 17, 2024
@aschempp aschempp merged commit 279b382 into isotope:2.9 Apr 17, 2024
@aschempp
Copy link
Member

Thank you @fritzmg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants