To allow for more granular theming of the JS-added links.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | apachesolr_505652_3.patch | 527 bytes | bdurbin |
| #1 | apachesolr_505652_1.patch | 533 bytes | bdurbin |
To allow for more granular theming of the JS-added links.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | apachesolr_505652_3.patch | 527 bytes | bdurbin |
| #1 | apachesolr_505652_1.patch | 533 bytes | bdurbin |
Comments
Comment #1
bdurbin commentedAdding patch file.
Comment #2
robertdouglass commentedThat file just patches the .js file. I would have expected a change to the module that renders the block (to add the css class), and to the .css file as well. Can we think of a shorter class name?
Comment #3
bdurbin commentedThanks for taking a look. Those "Show more / Show less" links are actually appended to the blocks on the client side when the page loads. They don't exist on the server when the blocks are rendered.
Are you suggesting that we refactor the blocks display code so that the links are generated at that time, and add the class there? I'd be happy to help explore that if that's the route you'd like to take. Not knowing the reasoning behind the current implementation, I do wonder if the links are added via JS to avoid something that was difficult to solve on the server.
Updated patch with shorter CSS class name.
Comment #4
pwolanin commentedI think you are right with this approach, since indeed this link will never exist without javascript being enabled.
Comment #5
robertdouglass commentedAgree, now that I look at it in closer detail. Committed.
Comment #6
janusman commentedSimple enough, tested, works.
Resulting link:
Comment #7
pwolanin commentedComment #8
francewhoaConfirming #3 works. Much easier to theme and design now. Thanks