Opened 10 years ago
Closed 16 months ago
#37336 closed defect (bug) (maybelater)
Pre-existing page with slug /embed/ does not work as described
| Reported by: | smerriman | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Embeds | Version: | 4.5 |
| Severity: | normal | Keywords: | needs-patch needs-unit-tests close |
| Cc: | Focuses: |
Description (last modified by )
In #34971, embeds were added to static frontpages, and there was a discussion of how this would affect an existing page with a slug of /embed/.
The solution was:
- an existing page with slug /embed/ will work as is and disable the pretty embed URL
- new pages can't be created with a slug of /embed/.
However, this did not work properly. On a site of mine, there is a page with URL /embed/ that was working fine prior to this upgrade. Now:
- if you visit /embed/, you are redirected to the homepage.
- if you attempt to edit the page, the slug previews as /embed-2/, meaning editing the page content and saving has the unwanted side effect of forcing the URL to change and all links to the page to break without warning.
Suggested changes:
- fix whatever is incorrectly redirecting the URL
- allow a slug of /embed/ to continue to save as-is if it already exists.
Change History (4)
#1
@
10 years ago
- Description modified (diff)
- Keywords needs-patch needs-unit-tests added
- Version trunk → 4.5
#2
@
6 years ago
- Keywords close added
- Milestone → Awaiting Review
@swissspidy Do you still think this should be fixed? It's been quite a while, thinking it may not be safe to close as a wontfix.
At a broader scale, could maybe add a Site Health check that scans the database for potentially problematic post slugs (any that match rewrite rules for instance). But also not convinced that is a good idea.
#3
@
6 years ago
While it still might be worth fixing (as #34971 did not fully resolve the issue apparently), 4 years with no additional reports on this make it sound like it's not really an urgent issue. So yeah, it can probably be closed as maybelater.
A Site Health check for embed post slugs seems interesting, but at that point I'd rather fix the bug for the user instead of having them fix their URLs.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Thanks for your report! I could reproduce this by manually changing a post's slug in the database (simulating an already existing post with that slug).
This means a visitor cannot access a post with that slug, which is of course a no-go.