[FEATURE] Automate creation of public links for Rich Text Field images in Summit Events

[rdblake21]

Description

Today, admins must manually create Public Links for images used in Rich Text Fields (RTFs) so they render for Guest Users. This is error‑prone and time‑consuming. Propose an automated mechanism that detects file-backed images referenced in Summit Events RTFs, generates (or reuses) a secure public link, and updates the RTF HTML to the public URL, optionally with an admin-controlled toggle.

---

Problem Statement

• After removing the Guest User Sharing Rule, Files referenced in RTFs are not visible to Guest Users unless a Public Link is created.
• Admins must:
  1. upload the image to Files,
  2. create a Public Link, and
  3. replace the image in the RTF with the publicly accessible version.
• This manual process leads to potential broken images, inconsistent behavior, and additional support burden.

Current Behavior

• Images inserted into RTFs use internal file/version URLs that do not render for Guest Users unless a Public Link exists.
• Admins/Users must follow a multi-step manual process to create and swap the image source.

Desired Behavior

• When an image is inserted or detected in an RTF on Summit Events records, the system automatically:
  • Ensures a Public Link (ContentDistribution) exists for the underlying ContentVersion.
  • Substitutes the RTF’s <img src> with the public URL (or leaves it as-is if already public).
• Provide an opt-in setting (org-level or package-level) to enable/disable automation and configure defaults (e.g., expiry).

---

Affected Areas

• Summit Events objects with Rich Text Fields used on public/guest-facing pages.
• Guest User-facing registration/landing pages.

---

Workarounds (Current)

• Manual: Create a Public Link for each File and paste the image from the public link back into the RTF (documented in upgrade steps).

[kadp89]

Hi! I’ve been working on this problem for a bit and have a prototype coming together. I’d like to get it running and covered by tests before submitting, but I wanted to check first — would you be open to a preliminary PR once it’s functional?

[kadp89]

In working on this, I found that images uploaded through the Rich Text Area editor aren’t stored as ContentVersions at all. When "uploading" through the RTF UI, while it looks like it should actually upload a file to your org, Salesforce keeps them as internal ContentReference objects that sit behind the backend /servlet/rtaImage endpoint. You can see it in the markup: an uploaded image has a URL like https://[domain]/servlet/rtaImage?eid=a0B[...]&feoid=00N[...]&refid=0EM[...]
The eid is the record that owns the field, feoid is the field itself, and the refid value points to a ContentReference. Those records aren’t queryable in SOQL or visible to Apex.

I have a draft PR I could submit which does search naively for ContentVersion download URLs, but now that I understand the problem space a little better, I'm not sure anything short of implementing an overloaded RTA editor will work to capture any uploads, push them to the database as ContentVersions, and inject ContentDistribution URLs. There may be an external/middleware implementation as well, which is beyond my wheelhouse and potentially the scope of the project. To anyone in the future who wants to take a stab at this, I'd suggest starting at one of these points instead of attempting pure programmatic detection via Apex.