🇺🇸United States @swirt

I think the Merge request !12122 for 11.x is ready for review. See QA steps in previous comment.

swirt → changed the visibility of the branch 11.x to hidden.

swirt → changed the visibility of the branch 11.x to active.

swirt → changed the visibility of the branch 11.x to hidden.

Thanks @mortona2k. I will take a look at the field compare module.

I had reached out to the X-ray audit maintainers a couple years back but they were not interested in combining projects.

I am going to close this now that we have an epic for this undertaking 🌱 EPIC: Merge Module Usage project Active

Thanks again mortona2k for the idea.

@cobblestone.consulting that is great news. I think it would improve both modules considerably.

I put together an epic as a place to do some planning 🌱 EPIC: Merge Module Usage project Active and refining the approach.

I can likely take on the bulk of work in July. Mainly I just want to start the planning and discussion now so that everyone involved is happy with the outcome.

swirt → created an issue.

Released with 1.0.36 →

Released with 1.0.36 →

Released with 1.0.36 →

This is a great solution @kul.pratap. Thank you so much for the contribution. And thanks @mortona2k for reporting it. I will get a release tagged right away.

I think this is where we have to handle rendering of the SDC of the individual alert entries
https://git.drupalcode.org/project/uswds_alert/-/blob/1.0.x/src/Controll...

This is the JS that needs to be replicated https://git.drupalcode.org/project/sitewide_alert/-/blob/2.x/js/init.js?...

The way it works is that the block is just a div target, line 2 in the init.js targets that div and inserts the contents of the alerts found in the endpoint. Our catch is that we have three different targets, so our version of init.js will need to figure out from each item in the endpoint which div it needs to get thrown into.

This is fixed. We now have three distinct blocks.

This is complete.

swirt → created an issue.

swirt → created an issue.

This is fantastic dmundra, thank you for this. It is a great addition to development on this module.

swirt → created an issue.

swirt → created an issue.

This is as complete as can be until we work on the theming and replicating the javascript.

I also updated the home page with the new version of the Readme.

This block as it exists is not yet using the new data endpoint.

I have the block existing, and the new endpoint that has all the data we need.

I am going to bypass the AC of "Block displays only sitewide alerts of style USDS Site Alert" at this time because all of the filtering and placing of alerts happens in the javascript and I think it will be easier to handle modifying the javascript logic once we have all three blocks.

- technically the page visibility isnt required any more as block setting can handle that

I don't agree with this. There is a big difference between the block level page targeting and the individual alert level page targetting. In the several places I am using this module, we need specific alerts to show on specific paged even if they are all the same type of alert.

I do like the idea of having types, but then you also need multiple blocks for being able to place different types in different regions.

If you have the perm shut off for anonymous users, the site will likely try to hit the endpoint to get the data for the alerts, but will not have access to it.
There are likely two solutions:

1. If everyone should be able to see the alert, make sure you grant "view published sitewide alert entities" to anonymous users.
2. If anon users should not see the alerts, then make sure the block perms are not set to show to anon users.

swirt → created an issue.

timozura → credited swirt → .

swirt → created an issue.

Thanks @mortona2k. I do like the features of that module. I had not seen it before. I reached out to the maintainer to see if they have interest in unifying the two.
🌱 Consider merging with Content Model and Site Documentation module Active

swirt → created an issue.

Downgrading this to minor. It may be more trouble than it is worth.

Thanks for reporting this mortona2k and for looking into the cause.

swirt → created an issue.

The schema issues for the View config have been repaired.

Rather than fix the phpcs issues in the event subscriber, I removed it since we won't be firing this on an event, we will be using field or entity validation to trigger the validation.

On other modules I have received updates after the initial round. I think it is related to either of two things

1. Improvements made to the update bot / rector rather than newly announced deprivations.
2. Inadvertantly adding new code to the module that actually contains a deprecation.

Yes the credit awarding is an unfortunate casualty, but it is only a delay, as the this ticket can be closed like the D10 update ticket was once we are firmly in D11 and getting updates to D12. The community understands that credit is not always immediate.

The directions are pretty clear at the top of the ticket, but I agree it would be nice if it spelled out when it is finally safe to close.

swirt → created an issue.

swirt → created an issue.

Thank you so much @Nidhi27 for this contribution.

Fantastic work Nidhi27. This works great. Thank you so much for this contribution.

Functionally, this seems to be working. I can tackle the linting and phpunit issues over the weekend.

swirt → created an issue.

Closing this as it is a duplicate of another ticket that was already completed.

Setting this back to Active so it will continue to get any automated updates

Accept automated changes until this issue is closed
If this issue is left open (status of Active, Needs review, Needs work or Reviewed and tested by the community) and the "ProjectUpdateBotD11" tag is left on this issue, new changes will be posted periodically if new deprecation fixes are needed.

swirt → created an issue.

This is looking fantastic. Thank you @adriancooke

Probably want to force the module weight to make sure this fires AFTER sitewide_alert
https://www.drupal.org/docs/develop/creating-modules/understanding-hooks... →

Looks like maybe we could just implement this hook and then unset $page_top['sitewide_alert']

That lives in the base module. Can we override it by putting it in our module. ( I would not think so, but I have no proof)

swirt → created an issue.

Thank you for your work on this @tom konda. It is appreciated.

Thanks @nidhi27. I added some AC's

Unless you have a site set up with some existing migrations, I suggest using migrate_example which is a submodule of migrate_plus. That can give you some migrations that should then show up as documentable.

Thank you @Nidhi27, I added some AC's to make it clearer.

Hi Nidhi27. No this is not resolved yet. I added some Acceptance Criteria as well.

Hi @nidhi27 I added acceptance criteria. Let me know if you have any questions.

Nicely done @skyriter. I like this new pattern.

swirt → created an issue.

swirt → created an issue.

Good question. Every img tag discoverable within the "content" will show in the report regardless of any alt or title attributes. Usually, true "decorative images" are on templates directly and are not discoverable as content. However, if someone puts a decorative image in the WYSIWYG it will appear in the report.

I think there are a few reasons to have them in the report:

1. An audit is not helpful if it lacks the ability to surface all things.
2. It could be vital to be able to filter for all "decorative" images so they can be examined to see if an editor was being disingenuous and taking the easy way out by labeling them decorative.
3. Yesterdays decorative may need to become tomorrow's content
4. alt attributes on a given media image are the same everywhere they are used, so in the original use of the image it might have been decorative, but in a subsequent instance it might have been intended as content.

It will report every img tag that it can find. The filters should/would allow you to restrict it to only things with errors or warnings.

I think I understand. Are you saying that config/install in uswds_alert will squash the settings (or the config/install in sitewide_alert)?

I think there is a possibility. There is a chance of one thing clobbering the other. Uncharted territory for me. We probably have to do some testing with a site that has a mock existing setup of sitewide_alert and then see what happens when uswds alert is installed after that.

@gxleano thank you for getting this resolved. If you have time, please remove my contrib credit on this. I did not do anything on this issue other than change its status. I appreciate the credit, but would rather earn it legitimately.

This went out with release 1.0.35 →

This went out with release 1.0.35 →

This went out with release 1.0.35 →

This went out with release 1.0.35 →

This went out with release 1.0.35 →

This went out with release 1.0.35 →