Usagov 1685 fix site banner #1769
Conversation
… uses the \Drupal::state()
There was a problem hiding this comment.
I have some disappointing news: I see a problem. I'm testing this a little differently than you described, but I think the principle is the same:
- I'm editing the blocks in a "normal" browser window
- I opened an incognito window to view the site as the "anonymous" user
- Each time I change a block and save in the first window, I go back to my "incognito" window and refresh the page to see what Ms. Anonymous sees.
At first I was really confused because it seemed as if it was working sometimes and not others, and I could tell the cache was getting refreshed during the "working" page loads because they'd be really slow. Well, it turns out that was probably because I was clicking around and looking at other pages.
I turned on my debugger to see when this code gets executed, and if the CMS user saves the block and then loads a page to look at the header, your new code is executed then ... because a logged-in user gets the full page re-built.
But if the CMS user just saves the page and doesn't leave the admin area, and the anonymous user views the page, we don't hit preprocess_region for this header block (assuming that an anonymous user has looked at it before, of course).
Have you tried to get some code like this to run when the block change is saved in the first place? (I would assume yes, and that it wasn't so easy.)
|
Thanks for reviewing! I'm going to take a look at this and see what's going on. |
…t in the hook and changing the status. Needs cleanup
… document the new code.
|
@akf Good news! I think I found a new way to add the site banner (I found it last week but I've been doing some testing) |
There was a problem hiding this comment.
This is working beautifully, but again I have frustrating news. :-(
After testing this out as you describe, I decided to look at the Configuration Sync report at http://localhost/admin/config/development/configuration (log in as a Site Admin for that) and I saw that 2 blocks, named block.block.site_banner_32 and block.block.site_banner_34, would be deleted on next import. (I deleted one myself; it must have been number 33.)
So, in other words, they would be deleted the next time we deploy code!
So while this is cleaner in a lot of ways, your initial implementation, where someone needed to clear the cache or maybe just visit some pages while logged in to get the banner to show up, was preferable.
I still think there should be a way to get this to work properly, possibly combining ideas from the two approaches. The underlying issue here is that any changes made in the CMS, need to be saved as content in the database (not as exportable configuration). I forgot that blocks fall into the "exportable configuration" category!
I hate to bring nothing but disappointment, so I looked around a bit and I found this: https://www.reddit.com/r/drupal/comments/ut42uf/comment/i97egf6/
They're suggesting using config_ignore, which is a project that still appears to be going strong.
I would say check in with @mdranove but he's just started vacation (perhaps when he gets back?) because he has experience with config_split. It looks like they are entirely compatible: https://sitestudiodocs.acquia.com/8.0/user-guide/setup-config-ignore-and-config-split
| - The `usa_site_banner_entity_insert` is a hook that runs when a Content Admin creates a site_banner. This hook creates a block by calling the `usa_site_banner_create_block` function and then places it in the `header_top` region if necessary by calling the `usa_site_banner_place_block` function. | ||
| - The `usa_site_banner_entity_update` is a hook that runs when a Content Admin updates a site_banner. This hook creates a block if necessary by calling the `usa_site_banner_create_block` function and then places it in the `header_top` region if necessary by calling the `usa_site_banner_place_block` function. | ||
| - The `usa_site_banner_place_block` is a fuction that places a Block in a region by setting the `status` value of the Block. Since in order to change the value you need to have a Block created, this function calls the `usa_site_banner_create_block` function in case there is no Block for the site_banner. | ||
| - The `usa_site_banner_create_block` is a function that creates a Block for a site_banner based on the BlockContent data. | ||
| - `web/themes/custom/usagov/templates/field--block-content--field-place-above-header.html.twig` | ||
| - For some reason the checkbox added text below the site banner so I added this empty file to prevent this text from appearing. |
There was a problem hiding this comment.
Actually I can explain this one! The checkbox is part of the block content, so the block will render it, and it will fall back on the default theme if nothing is supplied. This is a fine way to suppress it; it still shows up in the admin area (where we want to see it!) because the admin area has a different theme.
There was a problem hiding this comment.
I'm curious what all of this means for the Benefits Redirect Modal. Should I move forward with the implementation that mirrors how the gov banner is currently done on the prod? Or should I change it?
There was a problem hiding this comment.
Just closing the loop for @YaritzaGarcia, Chris and I DM'd about this. He'll move forward with the existing implementation and we'll expect to update both when we have a better approach (probably based on this newer work).
There was a problem hiding this comment.
Thanks for the update and for reviewing! I will take a look.
|
Hi @YaritzaGarcia! We're all super-busy and since this is not a show-stopper, I'm changing the PR to a "draft" (so someone doesn't merge it by accident) for now. |
Jira Task
https://cm-jira.usa.gov/browse/USAGOV-1685
Description
I added a variable to Drupal's state to check if the banner is already placed or not. If that variable isFALSEand the banner is supposed to be visible, it runs the "drupal_flush_all_caches();" function.I changed all the code for how we place a site banner but the interface and the process in which a content admin adds it remains the same. These were the things I did:
usa_twig_vars.moduleusa_site_bannerType of Changes
Testing Instructions
bin/initandbin/drush cimlocalhost/admin/content/block+ Add content block.Place above header.header_topregion.header_topregion.Saveto create or update the Site Banner block.Change Requirements
Validation Steps
Security Review
Reviewer Reminders
Post PR Approval Instructions
Follow these steps as soon as you merge the new changes.
Review in Testand add a comment. State whether the change is already visible on cms-dev.usa.gov and beta-dev.usa.gov, or if the deployment is still in process.