System error when trying to create a feature page

[caaster]

The exhibit creators of the SFTJF exhibit (https://exhibits.stanford.edu/sftjf) have created a problem with creating feature pages. I believe this is specific to this one exhibit, and it is a user-generated duplicate page-naming problem.

I am uncertain of the exact steps the creators undertook to cause the problem. This is their best guess of the steps.

1. Two About pages were created:

• Pete Clute
• Leon Oakley

2. Creators wanted the two About pages to be feature pages instead
3. They tried to create two feature pages:

• Pete Clute
• Leon Oakley
  They were unsuccessful.

4. Next, they created two feature pages:

• Pete Clute 2 (I deleted this when I was Zooming with them to troubleshoot)
• Leon Oakley 2

5. They renamed the existing about pages to be:

• Pete Clute - MOVE
• Leon Oakley - MOVE

6. They tried to rename the feature pages as follows:

• Pete Clute 2 tried to rename to - Pete Clute
• Leon Oakley 2 tried to rename to - Leon Oakley
  No success in renaming -- they see a system error page displayed.
  I tried deleting the feature page named - Pete Clute 2 and tried to create a new feature page named - Pete Clute. I got a system error page.

What is needed for this exhibit:
2 feature pages, named as follows:

• Pete Clute
• Leon Oakley
  The exhibit creators will then be able to move the page content from - Pete Clute - MOVE to - Pete Clute, and from - Leon Oakley - MOVE to - Leon Oakley

[jkeck]

Okay, looks as if this is the combination of a couple of issues.

1. How we handle page slugs in Spotlight.
   • Currently, all page slugs are scoped without regard to page type, so an about page and a feature page cannot have the same name. I believe this may be hold-over from when we were initially developing spotlight and thought pages may live at the root of the exhibit (or maybe my recollection is false, either way).
2. Using the history module for the slug.
   • I'm not sure what the rationale behind never letting somebody create a page with a slug that another page has had previously. It seems like it might be useful to work on an unpublished replacement page and then change the name at a later time to make the replacement (or rather, the history module actively prevents us from having that ability).

To solve #1 we can do one of two things, remove the friendly_id scope from the Spotlight::Page class itself and see if that allows the sluggable_type to be the type specific page class instead of the STI base class, or if that doesn't work we can simply add :type to the scope array (old PR for that). Either way, we will then need to write a data migration that updates all the existing page slugs to match either the new scope or sluggable_type.

To solve #2 we should evaluate if there is a real need/use-case that I'm not thinking of for not allowing any page to have the same slug as another page previously had (e.g. in the case of a rename as described above), and remove the history module if that is the case. We'll also want to evaluate if there are any data migrations/cleanup that would be needed/required there.

This all will have to happen up-stream in Spotlight and then be released in order for us to take advantage (and as mentioned, may want to do a bit of analysis). In the meantime, we can remove the old slugs that were applied to the pages for this exhibit, which should allow them to create new pages with the old slugs. This will be completely transparent to anybody using/working on the existing exhibit, so I'll do that this evening (unless I hear otherwise).

[ggeisler]

Nice analysis, @jkeck. Just to add my two cents on issue #2, I can't think of a UX rationale for preventing the curator from creating a page with a previously-used slug. It's non-intuitive (and with multiple curators, possible for curator 1 to delete a page and curator 2 to later try to create a page with the same title and not have any clue why it can't be created) and likely to crop up again as a service issue. So removing that restriction seems like a positive to me, unless there was some other reason for it that I don't understand/remember.

[jkeck]

I did a little more digging into this, and I believe the actual use-case for the History module is that if a user were to Bookmark a page, and then the page's slug was updated (which could happen by updating the title w/o realizing it would break bookmarks) then this allows that page to still be found. It appears then that we probably want to retain the History module. If we were to take action on this, it would most likely be to revive projectblacklight/spotlight#2080 (which I'll at least address the conflict on so it can be evaluated). The data migration required there is certainly sub-optimal. so not sure if it'll ultimately be a path we want to take.