Issue: Page listed as "edit awaiting moderation" does not appear in approval queue

It is hard to tell if this applies to the linked page, but I have discovered the following bugs:

- If a page is rolled back from an approved edit to a rejected edit, the visibility of the page is not updated correctly.
- If a page that is already visible has an edit awaiting moderation, and the current edit and all visible edits are purged (such that the only remaining edit is the one that was awaiting moderation), the visibility of the page is not updated correctly.

In both of these cases, the page would be incorrectly flagged as having an edit awaiting moderation, even though the software has no mechanism for approving the current edit separately from the page. Under normal operation, when the current edit needs review, the page itself is supposed to be sent to the moderation queue.

These bugs first appeared in 4.0.0 Alpha 1.
The two bugs described above should be fixed in the next build.
The upgrade process for the next release will attempt to repair pages that were affected by these bugs (by fixing the flags and sending them back to the moderation queue).

Had another page created by a new user become instantly unusable.

I had to manually push into moderation and then approve it to make it available again


https://chroniclesrp.net/Folklore/Darce?do=history

As soon as they edited it again it went back to the queue. (Properly this time)

It seems that articles getting flagged as spam on creation are not being handled properly.

Following edits flagged as spam are, but with no integration with the spam log this is quite hard to diagnose and change settings.

Confirmed that it is possible and intentional for wiki content to be added to the moderation queue if it sets off the spam checker. In the next build, fixed that this case was not logging in the spam-trigger log.

Thank you for explaining about some of the "unusable" pages, for which I assume you mean the pages where the URL doesn't work. Manually pushing into moderation and re-approving might explain some of the strangeness I was seeing in the history. This process technically should not create a new edit, so I will need to look at that.

After that I need to figure out why the URLs are being damaged in the first place.

In the next build, fixed that spam-checker was automatically unapproving the first edit of a new page rather than the new page itself, if it met the spam rules. Combined with the known issue of a non-blank icon-field always causing a new edit (even on approval), this explains some of the weird history of some pages, where an unapproved edit was shown below the first edit.

Which leaves us the pages where URLs don't work. I have found and fixed the following situation for the next build:
- When an edit includes renaming the page, and that edit triggers the spam-checker, the edit is sent for approval but the title change affects the page's route at the time of the edit. This results in the page not being accessible because the page still wants to use the old title and the old route until the edit is approved. This explains the page that you PMed me about. While investigating this, it looks like some edits might rename the page unintentionally, which I will have to confirm.

This does not explain how a brand new page would become unusable/inaccessible (i.e. your example Darce mentioned above):
Since a new page will only have the original route even if it needs to be approved. If a brand new page becomes "unusable" again, please don't approve it and notify me so I can have a look at it. Unless I have misunderstood what you meant by "unusable" in this case; if you were able to visit the page, but just did not have the Edit link available, then Darce is already explained by my first sentence in this post.

Certain pages unexpectedly being renamed has been escalated to a security issue and will be addressed by the October patches for 4.0.x, and the next build in 4.1.x.

Marking this as fixed, since the problems described in the OP have already been addressed.