Phoenix Content Management Tutorial

Editing a React website should not require opening a code editor every time a headline changes. Phoenix content management gives content editors a more familiar workspace: Google Sheets. You edit text or image references in a spreadsheet, use a Phoenix publishing command, and let the website read the updated content from Firestore.

This tutorial walks through that workflow, from your first text edit to replacing an image and giving teammates access. It also explains what to check when a change does not appear, and how to avoid accidentally publishing more than you intended.

This guide describes the workflow as of 2020; tools, authorization screens, and interface labels may have changed since then.

How Phoenix Content Management Works

The Phoenix setup described here connects four parts:

• Google Sheets provides the editing interface for website content.
• A spreadsheet script, available through the Phoenix menu, sends content updates to Firestore.
• Cloud Firestore stores the content that the React application reads.
• Firebase Storage holds images whose URLs can be referenced in the spreadsheet.

The publishing path for text is straightforward:

Google Sheets → Phoenix publishing script → Firestore → React website

Images take a slightly different route. You upload an image to Firebase Storage, copy its usable download URL, and publish that URL through the spreadsheet.

Phoenix is not a general-purpose page builder in this workflow. The React application already has components that know how to display particular content fields. Updating a heading changes the heading's content; it does not automatically create a new layout or component.

The exact spreadsheet structure and section-selection behavior depend on your project's implementation. Preserve the existing template rather than treating the sheet as an unrestricted document.

Before You Start

You will need access to:

• The Google account authorized to edit the content spreadsheet.
• The correct Phoenix spreadsheet for your website.
• The website where you will verify changes.
• The Firebase project, if you will upload images or investigate stored content.

Spreadsheet access and Firebase access are separate permissions. Being able to edit a sheet does not necessarily mean you can browse Firebase Storage or inspect Firestore.

Before publishing, confirm whether the spreadsheet controls a development site or a live production site. Unless your team has added a preview or approval mechanism, treat Update Section and Update All as publishing actions, not draft-saving actions.

For your first test, choose a small, reversible text change. Copy the original value somewhere safe so you can restore it quickly.

Update Website Text

1. Sign in and open the spreadsheet

Sign in to the Google account your team uses for Phoenix, then open the content spreadsheet. If you use multiple Google accounts, verify the active account before editing or authorizing the script.

Look for the Phoenix menu near the top of the spreadsheet. This custom menu contains publishing commands such as Update Section and Update All.

If the menu is missing, allow the sheet to finish loading and try reopening it. If it still does not appear, ask the project maintainer to confirm that you have the correct spreadsheet and that its script is installed and working.

2. Locate the content field

Find the section and field that correspond to the text you want to change. In the demonstrated setup, editable content appears in column B; your sheet may also identify it with a content heading.

Use the surrounding labels to confirm what the field controls. A page can contain several headings, descriptions, or button labels that look similar.

Edit the content value without renaming field identifiers, deleting neighboring rows, or changing the sheet structure. Those labels and positions may be part of the script's mapping to Firestore.

For example, a safe first edit might be:

Existing heading: Learn about our services
Updated heading: Explore our services

Avoid adding HTML or Markdown unless your developer has confirmed that the corresponding component supports it. A plain-text field may display markup literally.

3. Publish the relevant section

Follow your spreadsheet's convention for selecting the section you edited, then choose Phoenix → Update Section.

The tutorial's workflow uses this command to send a section's content to Firestore. The exact way the script determines the current section is project-specific, so do not assume that selecting any individual cell always produces the same result.

Google Sheets saving your cell edit is not the same as Phoenix publishing it. Until you run the publishing command successfully, the website may continue showing the previous content.

4. Authorize the script if prompted

The first time you run a publishing command, Google may ask you to authorize the script. Review the requested permissions and confirm that the script belongs to the Phoenix integration your team expects.

In the 2020 workflow, an unverified-app warning may show an Advanced link followed by an option to continue to the script. That is not a warning to bypass automatically. Proceed only if your project administrator has verified the script and explained why those permissions are needed.

If the owner, application name, or permissions look unfamiliar, stop and ask for help. Do not grant access simply to make an error disappear.

After completing a legitimate authorization flow, return to the spreadsheet and run Update Section again if the original operation did not finish.

5. Verify the website

Open the affected page and check the updated text in context. Depending on how the React application fetches content, it may appear immediately or after a page refresh.

Check more than spelling. A longer heading can wrap awkwardly, and a longer button label can crowd nearby elements. Review both a desktop-sized window and a narrow mobile-sized window before considering the update complete.

Replace an Image with Firebase Storage

1. Prepare the replacement

Resize and compress the image before uploading it. Choose dimensions appropriate for its display size rather than uploading a large original simply because it is available.

The original workflow recommends compressjpeg.com for JPEG compression. Use a tool appropriate to your file type, and inspect the result for visible artifacts. For sensitive or unpublished assets, use a compression method approved by your organization.

Match the existing image's aspect ratio when possible. A much taller or wider replacement may crop unexpectedly in a fixed-size component.

2. Open the correct Firebase project

Sign in to the Firebase console and select the project associated with your website. Use the project navigation to open Storage.

Do not confuse Storage with the database area. Firestore holds structured content, such as text and image URL fields. Storage holds the image files themselves.

The database navigation may appear under Database in the interface used by this tutorial. Navigation labels and placement can vary, so identify the service rather than relying on a panel being on a particular side of the screen.

3. Upload and select the image

Upload the prepared file to the appropriate Storage folder, following your team's naming conventions. A descriptive filename makes later maintenance easier.

For a straightforward replacement, consider uploading under a new filename instead of overwriting the old asset. This preserves a rollback option and helps avoid confusion from cached images.

Select the uploaded file to open its details. Locate the file's download URL or the URL available through its file-location details.

4. Copy a browser-usable URL

Copy the actual image download URL, not the Firebase console page address or a Storage reference beginning with gs://.

For a conventional React image element, the content field needs a URL the browser can load. A Firebase Storage download URL commonly has this general form:

https://firebasestorage.googleapis.com/v0/b/PROJECT_ID/o/ENCODED_FILE_PATH?alt=media&token=DOWNLOAD_TOKEN

This is an illustrative format, not a URL to construct manually. Copy the value supplied for your uploaded file, preserving its query parameters.

Treat token-bearing download URLs as shareable access links. Do not use this public-image workflow for confidential assets or broaden Storage permissions just to fix an inaccessible image.

5. Publish the new image reference

Return to Google Sheets, find the existing image URL field, and save a copy of its current value. Paste the replacement URL into that field, then choose Phoenix → Update Section for the relevant section.

Uploading a file alone does not change the website. The application needs the updated reference in its content data.

Verify that the image loads, crops correctly, and remains clear at the displayed size. If your content model includes alternative text, update it when the image's meaning changes.

Share Editing Access and Coordinate Publishing

1. Invite the right collaborators

Open the spreadsheet and click Share. Enter each collaborator's email address and grant editing access only to people who need to change content.

Avoid broadly enabling public editing. A spreadsheet connected to a live website should be treated as a publishing interface.

Give Firebase access separately, and only when a teammate needs it. Someone who updates copy may not need permission to upload or delete assets.

2. Explain the publishing boundary

Tell collaborators which fields they can edit, how to select a section, and which website receives the updates. Each editor may need to complete the script's authorization process, depending on the integration's configuration.

Agree on who publishes when several people are editing. Otherwise, one teammate may publish another person's unfinished revisions.

3. Use Update All deliberately

The workflow also provides Phoenix → Update All to publish content across the sheet. Use it when you intend a broader synchronization, after reviewing the affected content.

Do not assume it is a required final step after every successful section update. For a single text or image change, a section-level publish is generally the narrower action.

Troubleshoot Common Problems

The sheet changed, but the website did not

Confirm that you ran the publishing command, not just edited the cell. Check for script errors, verify the selected section, and make sure the sheet and website belong to the same environment. Refresh the page to account for applications that fetch content only on load.

Publishing reports an authorization error

Check the active Google account and whether authorization completed. If permission is denied or the script remains blocked, ask the maintainer to investigate its configuration. Repeatedly clicking Allow will not fix missing project access or a broken integration.

The image is broken or still looks old

Test the copied URL directly in a browser. Confirm that it identifies the image rather than the console page, and that no query parameters were lost. If the URL works but the site still shows the old image, verify the published field and investigate caching before uploading repeatedly.

You published the wrong content

Restore the previous text or image URL and republish the affected section. Google Sheets version history can help recover older values, but restoring the sheet alone does not necessarily restore Firestore. The corrected content must still be published.

Takeaway

Phoenix makes routine React website updates approachable by using Google Sheets as the editing interface. Keep the workflow deliberate: edit the intended field, publish the smallest necessary scope, and verify the live result. For images, prepare the asset, upload it to Storage, and publish its usable URL. Clear permissions and recoverable previous values make the process safer for everyone.