Here are some coding standards errors caught by Coder module
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | help-cleanup_1.patch | 1.99 KB | add1sun |
| #2 | help-cleanup_0.patch | 1.83 KB | add1sun |
| help-cleanup.patch | 1.49 KB | add1sun |
Here are some coding standards errors caught by Coder module
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | help-cleanup_1.patch | 1.99 KB | add1sun |
| #2 | help-cleanup_0.patch | 1.83 KB | add1sun |
| help-cleanup.patch | 1.49 KB | add1sun |
Comments
Comment #1
RobRoy commentedNeed to fix both @Drupals, not just the one in the array.
Comment #2
add1sun commentedCoder module did not catch that so we should probably add an issue to their queue on that. Here is a new patch with both @Drupals corrected.
Comment #3
add1sun commentedCorrected patch.
Comment #4
webchickAh-ha.
Ok, this one is good and ready to go, *except* that it contains a string change (changes something in t()), and we are currently in a "string freeze." Basically, when translators go to make a translation of Drupal, they'll run a script that dumps out all the stuff in t(). But, if you change any string even by one character, it forces translators to re-translate that string all over again. While this is acceptable for bugs in documentation, this is a simple cosmetic change, and thus should be pushed to 6.x.
So! The way to do this is to re-roll the patch for 5.x-dev *without* the @Drupal -> @drupal changes, and roll a separate one with the string fix for 6.x-dev. Make sense?
Comment #5
add1sun commentedNow that we've released I'm putting this as a 6 dev patch, as is.
Comment #6
keith.smith commentedpatch no longer applies
# patch -p0 < help-cleanup_1.patch
patching file modules/help/help.module
Hunk #1 FAILED at 21.
Hunk #2 succeeded at 86 (offset -4 lines).
1 out of 2 hunks FAILED -- saving rejects to file modules/help/help.module.rej
Comment #7
add1sun commentedAFAIK, this patch is no longer necessary since there was a mass cleanup patch on HEAD since this patch. I'm closing this.