Problem/Motivation

Setting a page alias to "/" with Workspaces enabled causes a fatal 500 error on several pages:

TypeError: Drupal\workspaces\WorkspacesAliasManager::getAliasByPath(): Return value must be of type string, null returned in Drupal\workspaces\WorkspacesAliasManager->getAliasByPath() (line 49 of core/modules/workspaces/src/WorkspacesAliasManager.php).

WorkspacesAliasManager::getAliasByPath() returns AliasManager::getAliasByPath(), which can return null rather than a string in this circumstance.

Steps to reproduce

- Enable the workspaces module
- Set the URL alias on any page to "/"
- Save the page

Proposed resolution

Some combination of:
- Validate the URL alias field to ensure "/" is invalid
- Ensure that AliasManager::getAliasByPath() returns a string
- Ensure that AliasManager::getAliasByPath() returns the path if the alias lookup returns null/empty

This issue (https://www.drupal.org/project/drupal/issues/3100350) suggests that setting "/" may be desired in the future, so might be worth focusing on fixing the null response here.

Remaining tasks

Create MR for initial fix attempt

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Issue fork drupal-3577043

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

lee.slater created an issue. See original summary.

lee.slater’s picture

Version: main » 10.5.x-dev

lee.slater changed the visibility of the branch 3577043-slash-url-alias-causes-500 to hidden.

lee.slater changed the visibility of the branch 3577043-slash-url-alias-causes-500 to active.

lee.slater’s picture

Issue summary: View changes

lee.slater changed the visibility of the branch 3577043-slash-url-alias-causes-500 to hidden.

lee.slater changed the visibility of the branch 3577043-slash-url-alias-causes-500 to active.

cilefen’s picture

Version: 10.5.x-dev » main

All changes need to be merged to the main branch first, so repoint and rebase your merge request on the main branch.

cilefen’s picture

Status: Active » Needs work

lee.slater’s picture

I started converting the MR to main, but realised that the code has changed quite a lot and this issue isn't present in the same way. There is a one-off error when replicating the behaviour, but it doesn't permanently break the site like it does in 10.5.x, which is what I was trying to resolve.

Is there a route to applying this fix to 10.5.x, or am I better off applying a patch?

cilefen’s picture

It must be fixed on main first and there can be separate merge requests for release branches in a case like this.

cilefen’s picture

That can all take place in this issue.