Redirects: Revamp - Bulk Creation, Editable Redirects, Clearer Errors, and Improved Help Text

[zcolah]

Intro

We're excited to announce significant updates to the Redirects App within the Zesty platform. These enhancements focus on improving user experience and streamlining the management of redirects.

1. Create Redirects in Bulk

Managing redirects is now more efficient. You can map multiple incoming paths to a single redirect target simultaneously, eliminating the need to create individual redirects for each path. For internal targets, the meta title of the content item is now displayed, making identification easier.

2. Unpublished Target Item Warning

To prevent broken redirects, the app now displays a clear warning if the content item selected as a redirect target has not yet been published.

3. Invalid External URL Error Display

When setting up an external redirect, the system will now validate the URL format and display an error message if the entered URL is invalid, helping ensure accuracy.

4. Edit Redirects After Creation

You no longer need to delete and recreate redirects to make modifications. This update allows you to easily edit existing redirects for any necessary changes or corrections directly.

5. Improved Help Text and Definitions

We've added helpful descriptions directly within the UI to clarify redirect options, eliminating guesswork and the need to memorize technical details.

Definitions are now available for:

• HTTP Code Options:
  • 301 – Permanent Redirect: Use this when content has moved permanently to a new location. Search engines will update their index.
  • 302 – Temporary Redirect: Use this when content is temporarily located elsewhere, and you intend to move it back. Search engines typically don't update their index for the new location.
• Redirect Type Options:
  • Internal: Link to a published content item within your Zesty instance.
  • External: Link to an external webpage outside of your Zesty instance.
  • Wildcard: Create a rule to handle multiple redirects based on a pattern in the incoming path.

6. Future Enhancements

Further improvements are planned for the Redirects App following this initial revamp. You can track progress on these upcoming features via the following GitHub issues:

1. Redirects: Import CSV/XML - DIsplay Error when File Import Fails #3438
2. Redirects: Filter by HTTP Status Code and Redirect Type #3439
3. Redirects: Sort by Date Created, Incoming Path, HTTP Code, Type, and Target #3440
4. Redirects: Improved Search Experience #3446
5. Redirects: Bulk Delete Redirects #3441

Figma

https://www.figma.com/design/9tiAwQg179ezJH48diVdph/Redirects-App?node-id=0-1&m=dev&t=X9cqEkZigmLQs57v-1

Developer Notes: Redirects Table Display

This section defines the column layout for the main table listing the created redirects.

• Column Widths:
  • More Options (Icon Button): Fixed width of 54px.
  • HTTP Code: Fixed width of 120px.
  • Type: Fixed width of 120px.
  • Incoming Path(s): Flexible width, should expand to fill available space.
  • Redirect Target: Flexible width, should expand to fill available space alongside "Incoming Path(s)".
• Layout Behavior: The "Incoming Path(s)" and "Redirect Target" columns should responsively adjust their width to utilize the remaining horizontal space in the table after accounting for the fixed-width columns. Ensure content within these flexible columns wraps or truncates appropriately to prevent horizontal scrolling of the table itself.

Developer Notes: Create Redirect Modal

These notes outline the requirements for the "Create Redirect" modal functionality.

1. Modal Opening Behavior

• Initial Focus: When the modal opens, automatically set the focus to the Incoming Path input field.
• Cursor Placement: The typing cursor should be active within the Incoming Path field immediately upon opening, allowing the user to start typing without an extra click.

2. Incoming Path(s) Input

2.1. Input Rules & Validation

• Space Handling: Automatically replace any space entered by the user with a hyphen (-) in real-time.
• Character Restrictions:
  • Prevent users from entering characters that are not URL-safe. Only allow valid characters for URL paths.
  • Refer to standard URL character safety guidelines (e.g., RFC 3986).
  • Reference Links:
    * Stack Overflow: Which characters make a URL invalid?
    * MDN: encodeURIComponent (Illustrates problematic characters)

2.2. Multiple Path Management

• Add/Remove: Users must be able to add multiple Incoming Path input fields and remove them as needed.
• Minimum Path: If only one Incoming Path field remains, attempting to delete it should clear the input field's content instead of removing the field itself.
• Adding Paths:
  • Clicking the "Add Path" button should append a new, empty Incoming Path input field to the end of the list.
  • Automatically focus the newly added input field so the user can immediately type in it.

2.3. Case Sensitivity

• Requirement: Incoming paths must be treated as case-insensitive by the underlying redirect processing system (Web Engine). For example, /Path, /path, and /PATH should all trigger the same redirect.
• Action: Investigate if the Web Engine currently supports case-insensitive path matching. If not, a separate ticket in the Web Engine repository needs to be created for the Web Engine team. Ask @jjaguilar08 for assistance on this.

3. Dropdown Input Options

3.1. HTTP Code Dropdown

• Provide the following options:
  • 301 – Permanent Redirect
  • 302 – Temporary Redirect

3.2. Type Dropdown

• Provide the following options:
  • Internal – For linking to published content items within the CMS instance.
  • External – For linking to an external URL.
  • Wildcard – For setting up wildcard redirects (ensure backend supports this).

4. Redirect Target Input (Type: Internal)

4.1. Default Suggestions (Empty Input)

• When the Redirect Target input field is empty and focused, display a dropdown suggesting the most recently published content items.
• Include both single-page and multi-page item types in these initial suggestions.

4.2. Search Scope

• When the user types in the Redirect Target input:
  • Search results should only include published single-page and multi-page content items.
  • Exclude Dataset items from the search results and suggestions.

4.3. Keyboard Navigation

• Default Highlight: Automatically highlight the first item in the suggestions dropdown when it appears.
• Arrow Keys: Allow users to navigate up and down the suggestion list using the arrow keys.
• Selection: Pressing Enter or Return should select the currently highlighted item and populate the input field.

4.4. Dropdown Item Display Logic

• For each suggested item in the dropdown, display either a single page or multi page icon based on the model type
• For each suggested item in the dropdown, display its heading on the following priority:
  1. Meta Title (if available)
  2. Else, Nav Link Text (if available)
  3. Else, the URL Path
  4. Else, the ZUID
• Truncation: Truncate the displayed text (Meta Title, Nav Link Text, or URL Path) if it exceeds the available width of the dropdown item (e.g., using CSS text-overflow: ellipsis).

4.5. Selected Item State

• Cancel Button: Clicking on the X icon removes the selected internal item and reverts the input to its searchable state.
• Unpublished Item Warning: If the selected internal item is not currently published, display a persistent, non-blocking warning message below the input field:

  "This item isn’t published yet. Any incoming paths will lead to your 404 page until it goes live."

5. Redirect Target Input (Type: External)

• URL Validation: When the Type is set to External, validate the entered URL in the Redirect Target input.
• Convert Spaces into "-"
• Error Message: If the entered text is not a valid URL format (invalid characters), display an error message:

  "Invalid URL. Please enter a valid URL."

6. Modal Creation Actions

• "Create Redirect" Button:
  • On click, attempt to create the redirect(s) defined in the modal.
  • On success, close the modal.
  • Handle potential errors (see Section 7).
• "Create Another Redirect" Button:
  • On click, attempt to create the redirect(s) defined in the modal.
  • On success, reset the modal fields (Incoming Paths, Redirect Target, Type, HTTP Code) to their default states, allowing the user to define another redirect without reopening the modal.
  • Handle potential errors (see Section 7).
• Table Update: Newly created redirects should appear at the top of the main redirects table.

7. Error Handling: Creation Failure

• Background: Since bulk redirect creation is not atomic (each path is a separate API call), failures can occur for individual paths within a single submission. Failures can be due to system errors or duplicate incoming paths.
• Failure Modal:
  • If any redirect creation fails (triggered by either "Create Redirect" or "Create Another Redirect"), display a dedicated error modal.
  • This modal should clearly list which Incoming Paths failed to be created.
  • For each failed path, indicate the reason for failure:
    • Already Exists (if the path conflicts with an existing redirect)
    • Error (for any other system or validation error during creation)
• "Try Again" Action:
  • Include a "Try Again" button within the error modal.
  • Clicking "Try Again" should re-attempt the creation only for those redirects that failed due to a system Error. Redirects that failed because they Already Exists should not be retried automatically.
  • On successful retry, update the user accordingly (close the error modal and add the redirects to the table).
  • If retry fails again, keep the error modal open with updated information.

Developer Notes: Alert Notifications

Please display non-intrusive toast notifications to confirm successful actions.

• Single Redirect Creation:
  • On successful creation via "Create Redirect" or "Create Another Redirect", display:

    Redirect Created: [Incoming Path]

• Bulk Redirect Creation Summary:
  • If the "Create Redirect" resulted in multiple redirects being created simultaneously (from multiple incoming paths in the modal), display a summary toast instead of individual ones:

    [Number] Redirects Created (e.g. "3 Redirects Created")

• Single Redirect Save:
  • On successful save of editing and saving a redirect display:

    Redirect Saved: [Incoming Path]

• Single Redirect Deletion:
  • On successful deletion of a single redirect from the table, display:

    Redirect Deleted: [Incoming Path]