This issue has novice tasks. If you are an experienced core developer and have multiple commit mentions, please review novices' work on these tasks rather than doing them yourself. Feedback from experienced contributors is valued.
Problem/Motivation
PHP warnings can be produced by the following line of code in views_preprocess_page() if $variables['attributes']['class'] is not set.
$key = array_search('contextual-region', $variables['attributes']['class'] instanceof AttributeArray ? $variables['attributes']['class']->value() : $variables['attributes']['class']);
Steps to reproduce:
- Install minimal profile
- Enable views and views ui
- Go to /node whilst logged in as user 1
Proposed resolution
Fix code.
Remaining tasks
- Write patch (novice)
- Review patch to check it fixes the issue, the change is properly documented and for coding standards. Provide test evidence (novice)
- Keep issue summary up to date (novice)
Comments
Comment #1
Stuart Miller commentedI will take a look at this and see if I can produce an initial patch over this weekend.
Comment #2
Stuart Miller commentedHere is an initial patch file, I will try to add a test.
Views UI module is needs to be enabled in order to reproduce the warnings.
Comment #3
Stuart Miller commentedComment #4
Stuart Miller commentedUpdating previous patch to change array_key_exists() for an isset() as array_key_exists() would return TRUE for a NULL value of the key.
Comment #5
harshil.maradiya commentedhi,
i am not able to reproduce this issue
i have followed following steps
Install minimal profile
Enable views
Go to /node whilst logged in as user 1
installed branch 8.x
please let me know i have missed any steps
Comment #6
Stuart Miller commentedHello harshil.maradiya ,
The views_ui module needs to be enabled as well for the error to show.
Comment #7
alexpottComment #8
dawehnerThank you stuart!
Comment #9
alexpottLet's get a test written as this shouldn't be broken.
Comment #10
Stuart Miller commentedTest added to patch
Comment #11
alexpott@Stuart Miller it's be great if you can submit a test only patch so we can confirm that your test would catch the issue. Thanks!
Comment #12
Stuart Miller commented@apexpott Here you go :)
I hope it's okay, I was unsure if I should be adding some kind of specific assert for the exceptions of if the system catching them is the expected/desired behaviour.
Comment #13
alexpottIt'd be great to have a comment as to why we doing this test. I.e. the views_ui adds contextual_links and the links are processed by views_preprocess_page() - or something like that.
Comment #15
Stuart Miller commentedCurrently waiting on https://drupal.org/node/2194703 as test is to be added to class mentioned here.
Comment #16
Stuart Miller commentedAttached is patch file containing only the test for this.
Automated test will fail as it should to show that previous patch must be applied as well to correct the issue stated here.
Comment #18
star-szrThanks @Stuart Miller! Since we have the fix as well it's good practice to post the test + fix (combined) patch as well in the same comment. Once we have that then the test-only patch usually only needs to be posted again if there are significant changes made to the test.
Here are some items that can be fixed up:
This should be a complete sentence (end in a period) per https://drupal.org/node/1354#drupal.
Should be public.
The comments are wrapped really conservatively - they should be as long as possible within 80 characters (same reference as above).
Comment #19
Stuart Miller commentedThanks for you comments, I have amended the patch accordingly.
Both patch and test in same patch.
Comment #20
star-szrLooks great. Test passes and fails appropriately and fix looks good. Great work @Stuart Miller!
Comment #21
rajeev_drupal commentedGreat work @Stuart. Fixes works fine for me as well!!
Comment #22
damiankloip commentedThis makes sure no exceptions are thrown etc.. but I think we should assert that we can still see the view too? as you could have an empty body from that response and it would till pass.
So at the very least, a
$this->assertResponse(200)?Comment #23
alexpott@damiankloip good point! We definitely should be testing that the view is being rendered.
Comment #24
Stuart Miller commentedI have added in an assert for the response code as well as one to check that the view appears on the page via a class name.
Thanks for pointing that out.
Comment #25
star-szrThanks! Please post an interdiff when updating patches :)
Minor docs/typo cleanup, leaving at 'Needs review' but these are easy fixes:
This is a bit terse, how about "When a user"?
Again a bit terse and there's a typo on 'received'. How about something like:
Check that the correct response was received from the last request.
Having said that, I'd also suggest that we don't need to comment every single line of this test method. I think this one in particular could definitely do without a comment :)
fontpage should be frontpage, and similar to the above comments maybe we can add a 'the' between Check and frontpage :)
Comment #26
Stuart Miller commentedSorry about those typos, that's pretty sloppy!
I have amended and this time attached an interdiff from the previous patch #19
Thanks
Comment #27
star-szrThanks @Stuart Miller, that looks good to me.
Comment #28
webchickCommitted and pushed to 8.x. Thanks!