Refactor PRG page data sourcing via Directus

[patinen]

🛠 Refactor Description

Refactor the PRG page so that PRG-specific CMS-managed content is fetched from Directus instead of being hard-coded via static imports or constants. This includes PRG images, document links, board/personnel content, and the registry/company info block.

Current page:
https://altzone.fi/en/prg

---

🔍 Reason for Refactor

• Reduce hard-coded content in the frontend and improve maintainability.
• Enable non-code updates for PRG assets, links, board information, and registry info via Directus.
• Centralize PRG fetching behind a dedicated API layer (prgPageApi) for consistency and reuse.

---

🗂 Affected Areas

• Component/Page: PRGPage
• UI Components: Boardcard, CheckPdfButton (data source changes only)
• API/Data layer (new): prgPageApi (or equivalent)
• Constants/Assets:
  • Static PRG hero image import
  • AppExternalLinks values used for PRG PDFs
  • Hard-coded PRG board member data
• CMS: Directus collections + permissions for PRG content

---

🚀 Proposed Changes

1) Directus data model / collections

Create PRG-specific collections for the following:

prg_page (singleton)

Stores PRG page-level content.

• hero_image (file/img)
• registry_info_fi (text)
• registry_info_en (text)

Registry info must preserve line breaks (frontend uses whiteSpace: pre-line).

prg_documents

Stores document links rendered as the PDF buttons.

• key (string, unique) — e.g. action_plan / activity_report / bylaws
• url (string)
• sort_order (int)

prg_board_members

Stores PRG board/personnel (independent from Team page data).

• name (string)
• job_title_fi (string)
• job_title_en (string)
• profession_fi (string)
• profession_en (string)
• image (file)
• sort_order (int)

Configure frontend/public read access for these collections.

---

2) Frontend data access (prgPageApi)

Create a dedicated API module (name TBD, e.g. prgPageApi) to:

• Fetch prg_page (singleton)
• Fetch prg_documents (sorted)
• Fetch prg_board_members (sorted)
• Return a single normalized object the page can consume.

Recommended output shape:

• heroImageUrl
• documents: { actionPlanUrl, activityReportUrl, bylawsUrl }
• registryInfo
• boardMembers[] (name, localized job/profession, imageUrl)

---

3) PRGPage integration

• Replace static hero image import with heroImageUrl.
• Replace PRG PDF URLs from AppExternalLinks with documents.*Url.
• Replace hard-coded board member list with boardMembers[].
• Replace registry-info text with Directus-provided localized value.

---

🛑 Current Code Issues

• PRG board/personnel data is hard-coded in PRGPage.
• PRG PDF links are defined in AppExternalLinks.
• PRG hero image is imported as a static asset.
• Registry/company info is not CMS-managed.
• No dedicated API layer for PRG data fetching.

---

✅ Expected Outcome

• PRG page loads images, document links, board members and registry info from Directus.
• PRG fetching is centralized behind prgPageApi (or equivalent).
• Updates to PRG content do not require frontend code changes.
• PRG board/personnel remains independent from Team page data.

---

📋 Additional Information

• PRG page: https://altzone.fi/en/prg
• Improved performance and readability
• Simplified logic or modular design
• Reduced complexity and improved maintainability

---

📋 Additional Information

Include any extra resources, links, or documentation that will help in the refactor process.