SHS-5775: Implementation: Social Media Footer Block

[codechefmarc]

Summary

Adds config and update hook to create new social media footer block.

Need Review By (Date)

2024-09-09

Urgency

low

Steps to Test

1. Login to the site as a Developer role
2. Under the Content menu, hover over "Blocks", then "Add content block", then click "Social Media Footer Block"

4. Fill out the fields for description, icon size, layout, and add as many links as you wish
5. Click "Save and configure" at the bottom
6. When on the "Configure block" screen, select "Footer" as the value for the "Region" field
7. At the bottom, click "Save block"
8. View the front-end of the site and scroll all the way to the footer area
9. Verify that there is a new social media footer block present, with the correct styles according to the selected icon size and layout

Grid layout:

List layout:

10. Masquerade as a user who does not have a developer role, for example someone who only has "Site manager" role
11. View the front-end of the site and scroll all the way to the footer area
12. Hover over the social media block and click the pencil icon
13. Verify that the only thing a non-developer role can do is edit the block, not remove it or configure it.

PR Checklist

• PR Checklist
• Humsci Basic PR Checklist

[codechefmarc]

@cienvaras - I've added the template suggestion so this is now ready for your review.

[cienvaras]

@codechefmarc Works as expected, thanks!

@ahughes3 Ready for you to test.

[cienvaras]

@ahughes3 This one is ready to review, includes both backend (SHS-5675) and frontend (SHS-5676) work.

[joegl]

👀 I did a cursory review of this and looks good. I just want to take a closer look at the database update and .module hook. @codechefmarc There's a conflict in the hs_paragraph_types.module if you want merge in the latest 11.2.5-release and resolve it that'd be great 👍

[cienvaras]

@joegl Merge conflicts fixed!

[joegl]

@codechefmarc I'm curious why you went with a custom block built via the UI and a new paragraph type, instead of creating a custom block plugin programmatically. Because of the large hook to format the icons based on the link URL's, it feels like a block plugin could have worked really well here and kept everything organized in a single block instance with a configuration form, instead of piecing together hooks and field/paragraph configuration. I think this could all comfortably fit into a single block plugin and would prefer that route if possible.

[codechefmarc]

@codechefmarc I'm curious why you went with a custom block built via the UI and a new paragraph type, instead of creating a custom block plugin programmatically.

@joegl - This was discussed internally before we started this ticket and we thought it was best to create a block via the UI because of the repeating mulit-value field with the paragraph, maintainability, and the ability to more easily add fields to this block if needed via the UI. I certainly can see it both ways - there are pros and cons to building this way vs a custom block plugin.

[codechefmarc]

@joegl - Reverted permissions to 11.3.1-release version. Ready for a retest. Thanks!

[joegl]

@codechefmarc I'm curious why you went with a custom block built via the UI and a new paragraph type, instead of creating a custom block plugin programmatically.

@joegl - This was discussed internally before we started this ticket and we thought it was best to create a block via the UI because of the repeating mulit-value field with the paragraph, maintainability, and the ability to more easily add fields to this block if needed via the UI. I certainly can see it both ways - there are pros and cons to building this way vs a custom block plugin.

Ok, that makes sense. I think the use of a new paragraph type to capture a multi-value field for a block is a bit out of scope for the intended use of paragraphs. A basic URL field comes with a title and URL which could suffice for the label and URL being captured here. A single block plugin also would probably be easier to maintain than all the configuration and module hooks here.

We can still move forward with this implementation and I understand the reasons you chose this route. But I do want to push again to use a custom block plugin instead if possible.

[codechefmarc]

@codechefmarc I'm curious why you went with a custom block built via the UI and a new paragraph type, instead of creating a custom block plugin programmatically.

@joegl - This was discussed internally before we started this ticket and we thought it was best to create a block via the UI because of the repeating mulit-value field with the paragraph, maintainability, and the ability to more easily add fields to this block if needed via the UI. I certainly can see it both ways - there are pros and cons to building this way vs a custom block plugin.

Ok, that makes sense. I think the use of a new paragraph type to capture a multi-value field for a block is a bit out of scope for the intended use of paragraphs. A basic URL field comes with a title and URL which could suffice for the label and URL being captured here. A single block plugin also would probably be easier to maintain than all the configuration and module hooks here.

We can still move forward with this implementation and I understand the reasons you chose this route. But I do want to push again to use a custom block plugin instead if possible.

@joegl - I'm going to create a new PR to address this and create a custom block instead of one via the UI. For the moment, I'll keep this PR open, but will mark it as don't merge and once we're happy with the other PR, we can close this one.