Application/Nomination materials custom WP block

[builderpepc]

Background

On the Negri Institute and NEFAC Awards year-specific pages, NEFAC usually has some forms for applications or award nominations, which close after a certain due date passes. Here are examples from the existing website:

Screenshot	Source/Notes
	NEFAI (Negri Institute) 2023
	NEFAC Awards 2023
	NEFAI (Negri Institute) 2021
	NEFAC Awards 2021

A few things are in common between these elements within both programs' pages:

• They appear as bulleted lists of named links on the WordPress frontend.
• They have an open/closed state.
• They have a section title. If the forms are closed, that is denoted in the title.
• The links can go to any destination; some are Google Forms or even PDFs.
  • We won't attempt to auto-detect open/closed state for this reason.

There are some small differences:

• Between NEFAC Awards and Negri Institute pages, the title text is styled differently (along with all other titles on the respective pages)
• Negri Institute pages usually have multiple form links while NEFAC Awards pages usually only have one; however, because they are always in a list, we should be able to handle multiple links regardless of the page.

Requirements

For this ticket, we want to implement a custom block that can represent a set of form links for these pages. Not one link, but a set. This will be editable in WordPress and will be rendered in both the WordPress and Faust.js frontends.

WordPress Editor UI

On the WordPress side, our client would be able to insert a custom block -- let's call it FormList -- which would contain a modifiable list of elements representing each link. There would be a text field to set the title of the section (e.g. "Application Materials"), and there would be a dropdown for the style, with two options: "Default" (similar to most pages, like Negri Institute) and "NEFAC Awards". "Default", as the name suggests, should be selected by default.

There would also be a UI to add a new link to the list; this UI would take in the name of the link, the URL, and the open/closed state (dropdown; open by default). The list of added links should also be visible in the UI, and the open/closed dropdown should be shown next to each added link, such that the client can easily switch the state. There should also be an "edit" button next to each item which allows the client to edit all of the fields (name and URL) without having to delete and re-create links. Because there are usually very few items, we will not worry about the ability to edit the item order for now.

This is very similar to the block Dalton is implementing in #101, and down the line we may indeed try to generalize some parts. For now, though, that block serves a similar but different purpose, so we're better off implementing this separately until we understand exactly what can be abstracted. You can still copy/paste some parts from that code if you would like, until we revisit this later.

With custom blocks, this logic usually belongs in an edit.tsx file (example).

WordPress Rendering

As we've discussed before, our client wants to make sure the live WordPress frontend still looks "normal" even as we deploy changes and insert our custom blocks. Therefore, we need to make sure our custom blocks render in a way that is similar to the existing site content which we are replacing. Reference the following example HTML:

Default style variant (source: NEFAI (Negri Institute) 2021)

<h3><strong>Application Materials — (Closed)</strong></h3>
<p style="padding-left: 30px;">
• <a href="https://...">Application and Recommendation Form</a>
</p>

NEFAC Awards style variant (source: NEFAC Awards 2021)

<p><span style="color: #003366;"><strong>Award Nomination Forms (Closed)</strong></span></p>
<p style="padding-left: 40px;">
• <a href="https://...">Michael Donoghue Freedom of Information Award</a><br>
• <a href="https://...">Antonia Orfield Citizenship Award</a>
</p>

With custom blocks, this logic usually belongs in a save.tsx file (example).

Faust.js Rendering

Similarly to the how the Person list custom block was implemented, our FormList block will separate its WordPress logic from the component used to present the data in the Faust.js frontend. With custom blocks, the Faust.js frontend rendering logic usually belongs in a view.tsx file (example).

Your view.tsx would import a separate, plain React component from somewhere under src/components (possibly a subfolder of that). That component would receive the data fetched from WordPress and render the list of form links, like so:

Figma screenshot (can be found in Summer Drafts tab):

To achieve this, it would probably make sense to define a component that represents one form link, and reuse that component multiple times to produce the list. So, in pseudo-react, your view.tsx might look very roughly like this:

// import your component up here that you created to represent an individual form link
import FormLinkItem from "@/components/...";

// you would specify input types in this line
export const FormListBlock = ... => {
  // you would probably extract necessary data here if needed
  // ...

  return (
    {/* exact title styling is up to your interpretation of the Figma */}
    <h3>{title}</h3>
    
    {/* you might wrap this in something else so it's styled properly */}
    {forms.map((name, url, isOpen) => (
      <FormLinkItem name={name} url={url} isOpen={isOpen} />
    ))
  )
}

The code I wrote here is just a guide; make whatever adjustments you need. It is based heavily on #101. Also, note that the form link titles (and the bar to the left) become grayed out when closed.