Saved (not published) page name change is applied if database cache is cleared

[lordscarlet]

Which exact Umbraco version are you using? For example: 8.13.1 - don't just write v8

8.14.1

Bug summary

If a change is made to a page name, and that change is saved but not published, if the database cache is cleared, the change takes effect on the published page.

Specifics

If I have a page, with page name "ABC", it exists at www.mysite.com/abc. I then decide to change the page name to "123", but I am not ready to publish, so I save the change. Everything remains as expected.

However, in the meantime, if the database cache is cleared, the page will no longer live at www.mysite.com/abc. This page will return a 404. It will exist at www.mystie.com/123.

Additionally, if the page is subsequently published, a record is not added to the Redirect URL mapping.

I have been able to reproduce this in both 8.14.1 and 8.10.1

Steps to reproduce

1. Create a page
2. Publish it
3. Change the name
4. Save it (don't publish)
5. Browse to URL in step 1, page will display as expected
6. Rebuild Database Cache
7. Reload Memory Cache
8. Browse to the URL published in step 2
9. The page will respond with a 404
10. Browse to the URL based on step 4
11. The page will render

Expected result / actual result

Expected

1. The URL should remain the same until the name change is published
2. When published, the previous url should be mapped in Redirect URL Management

Actual

1. After the database cache clear, the page now lives at the not-yet-published new URL
2. After the database cache clear, the page does not live at the currently-published existing URL
3. Once published, the previously-published existing URL does not redirect to the new URL

[nul800sebastiaan]

Thanks @lordscarlet for the bug report. I can reproduce. Obviously it's not ideal but... there's also almost never a good reason to have to rebuild those caches(!). If you have reasons to rebuild those caches I'd love to hear exactly what problem you're trying to solve there but generally it is a good idea to keep away from those buttons.

That said, we would love to get this specific problem fixed. We could use a little help, if anyone would like to dig in some deeper there.

[umbrabot]

Hi @lordscarlet,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[lordscarlet]

@nul800sebastiaan it happens more often than you would hope for us. Perhaps we have some configuration that is wrong, or some serious data issues from a 10+ year old Umbraco database that has made it's way to v8. I know that we have thus far been unable to get the Published Cache Status to show as ok.

Database cache is NOT ok (rebuild?). ContentStore contains 27288 items and has 5 generations and 1 snapshot. MediaStore contains 179 items and has 1 generation and 1 snapshot.

We have not had the time to try and dig that up. Over the past 12-18 months we upgraded from v4.11 to v8.14.1.

I don't know if here is the place to discuss, but I know that one instance is:

We have 8 servers running the Umbraco instance. 6 are load balanced as the front end serving content to the public. 1 is for the back office. The last is load balanced to the back office server, but only receives traffic if the first server is unreachable. At times, when we publish a node, it gets published on 5 of the 6 front end servers (for instance). When this happens, we have found that there are other nodes with the same problem, but we did not notice at the time because the LB loaded one of the "good" servers. Once that happens, the best approach we have is to rebuild stuff.

For what it is worth we have over 54,000 rows in cmsContentNu

Obviously even having to do it once could have some pretty bad repercussions.

Regardless, if someone on our team has a chance to look at this we will grab it. We haven't worked around the caching portion of the code yet, but hopefully it is pretty straight forward.