Setting URL alias without '/' prevents all article edits

Error in browser console

{
    "message": "assert(str_starts_with($autoSavePath, '/'))"
}

{
    "status": 500,
    "data": {
        "message": "assert(str_starts_with($autoSavePath, '/'))"
    }
}

Below is the code to fix the issue :

-          assert(str_starts_with($autoSavePath, '/'));
+          // Ensure autoSavePath starts with '/'
+          if (!str_starts_with($autoSavePath, '/')) {
+            $autoSavePath = '/' . ltrim($autoSavePath, '/');
+          }

Rather than adding '/' to paths that dont start with it, we should add validation to the entity form fields

Validation for entity fields are not yet impletemted
file: experience_builder/ui/src/components/form/inputBehaviors.tsx

  const validateNewValue = (e: React.ChangeEvent, newValue: any) => {
    // @todo Implement this.
    return { valid: true, errors: null };
  };

This should be updated to

  const validateNewValue = (e: React.ChangeEvent, newValue: any) => {
    const target = e.target as HTMLInputElement;
    if (target.id === 'edit-path-0-alias' && typeof newValue === 'string') {
      if (newValue && !newValue.startsWith('/')) {
        return {
          valid: false,
          errors: [
            {
              keyword: 'value',
              instancePath: '',
              schemaPath: '',
              params: {},
              message: 'The alias path has to start with a slash',
            },
          ],
        };
      }
    }
    // @todo Implement for other entity fields.
    return { valid: true, errors: null };
  };

Thanks @akhil for the input!
You're right — adding frontend validation makes sense for better UX and to prevent invalid input early on. I'll update the PR to include this validation inside validateNewValue().

Also, I think we can keep the backend fallback (str_starts_with) check just to be safe in case any invalid alias somehow bypasses the UI (e.g., via API or future form changes).

Let me know if you'd prefer removing the backend fallback.

Right now I’ve added backend validation to ensure alias starts with /, which resolves the layout error.
Also noticed that the error message “The alias path has to start with a slash” is already being shown in the UI if / is missing — but the page still gets saved.
Should I go ahead and update the frontend logic to block submission if the alias is invalid?
Attaching the screenshot.

It looks like it's actually an assert that's triggering this. Changing to major because of that.

@akhil babu in #5:

Rather than adding '/' to paths that dont start with it, we should add validation to the entity form fields

💯

Updated the patch to add client-side validation to ensure alias starts with /.
However, currently we’re still able to publish even if the alias doesn’t start with /
Attaching screenshot to show the client-side error.

@meghasharma I'm pretty sure the publish issue is because of 📌 Publish checks validation constraints, but not form validation Active , so you shouldn't need to worry about that here.

Thanks @penyaskito for the clarification!
Yes, the client-side validation is now working correctly and shows an error when the alias does not start with /.
Since the publishing behavior is related to #3521759 and not this issue, I’m moving this back to Needs review.