-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix CRUDController::editAction ignoring its optional parameter #3961
Conversation
Please keep your commit message subject under 50 chars, as described in the CONTRIBUTING.md file. You can tell us more in the § below it. |
@@ -234,7 +234,7 @@ public function editAction($id = null) | |||
// the key used to lookup the template | |||
$templateKey = 'edit'; | |||
|
|||
$id = $request->get($this->admin->getIdParameter()); | |||
$id = is_null($id) ? $request->get($this->admin->getIdParameter()) : $id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please also document this behavior in the @param
annotation ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not:
$id = $id ?: $request->get($this->admin->getIdParameter());
Thank you for your contribution. 👍 Please next time do not remove the code block around the change-log content. This is wanted to have this. 😉 Could you also please reduce a bit your commit title? It's very long. |
With all due respect, I did read the CONTRIBUTING.md and halfway through considered not making the PR at all because making a PR shouldn't be an hour of work for a 30 second fix. The number of rules and requirements in there discourage busy people like me from fixing small but serious issues like this one. I fully understand the need for a project this large to have proper rules, but the amount of work requested from a contributor should be in line with the size of the PR. I dearly recommend adding a big "Ignore the 1000 rules below for basic and obvious bug fixes" on top of the PR template. I didn't use |
Well, the 50 chars rule is not really specific to our project. It's something that you should know if you use git regulary, so much that even github softly enforces it :
Also, if you use vim to write your commit message, you will see the commit message color change if you break this rule (and others). I understand that you are busy though, so if you don't have the time to do better, we will simply squash merge and change the commit message for you. Finally, I know the CONTRIBUTING.md file is long, but I think it is really full of sound advice. Please do read it, and do read the linked articles. |
Your PR now has 99 commits… use |
I understand your point of view but we can't do another way. It's already hard to maintain 30 sonata projects on out free time, so we don't have the time to try to understand a maybe malformed PR and ask people to update it.
👎 for two reasons:
Don't blame PHP 5.3. It cans do some things sometime. 😛 |
@@ -221,7 +221,7 @@ public function deleteAction($id) | |||
/** | |||
* Edit action. | |||
* | |||
* @param int|string|null $id | |||
* @param int|string|null $id Optional ID to use instead of globally provided default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I was squashing my own commits and accidentally rebased on master hehe, fixed now. As for the contributing - I'm just pointing out it's now damaging the project that contributions are discouraged by the amount of administrative work required. I have in the past on other projects (Symfony and Doctrine most notably) not submitted serious fixes for the same reason, I have paying customers who do appreciate me spending 5 minutes to fix an upstream issue fundamentally, but not spending 2 hours reading contribution guidelines. If that's needed I'll just work around the issue locally, and I'm not the only one reasoning like that. I fully agree for features and invasive changes you need proper argumentation and documentation, I just think (know) it's terribly counterproductive for the project quality to do it for oneliner fixes like this where something is beyond obviously broken. |
LGTM! Thanks for taking time on your busy schedule to fix that :) Our guidelines are quite verbose indeed, and our rules are quite strict, but we try to compensate that by being reactive, so time you "loose" making the PR cleaner should hopefully be forgotten when seeing the PR quickly merged. This workflow works for us and I don't think we will change it : see how the pulse is steady and contributions keep coming despite all that. |
Your point of view, this is again understandable. But please try to understand our: We don't have lot of time, time is important. If someone don't want to add a PR because of that, that's bad but we won't change our rules for that. I'm pretty sure Symfony have those kind of rules for common reasons, despite of having more resources and time than us. |
RTM. Thank you @curry684! 👍 |
Good Job 👍🏻 |
I am targetting this branch, because it's broken in the current branch. Will have to be forward merged into master.
The
CRUDController::editAction
accepted an$id
parameter which was always overwritten, serving 99% of use cases just fine, but not the exceptional case it was added for.Changelog