changing slugs

[kjam...@ualberta.ca]

Hey Dan,

We're having an issue of slugs changing. The records have not been edited, but the slugs have changed. We're not sure how or why.

Our set up is an internal site behind a firewall. Every night it is copied, the copied data is loaded into a public site outside of the firewall, and any records in "draft" mode are deleted. This means only published records are visible to the public. The steps for this are:

1. delete entire database

2. import entire database from *today's* export from prod

3. build-nested-sets

4. delete-drafts

5. digitalobject:regen-derivatives

6. secondary build-nested-sets [after drafts delete]

7. generate-slugs

8. search:populate

9. clear cache

We're wondering if there have been any reported bugs in slugs or if this could be caused by the build-nested-sets/generate-slugs sequence?

Any advice would be appreciated!

[Dan Gillean]

Hi Krista, 

Do you mean a change of slugs from your internal website to the external one? Or, within a single site, the slugs are changing?

The first thing I would do is compare the "Generate description permalinks from" setting (in Admin > Settings > Global) between your two sites. If they set differently, you will end up with different slugs! See: 

• https://www.accesstomemory.org/docs/latest/user-manual/administer/settings/#generate-description-permalinks-from
  

Additionally, running the generate slugs task (especially if you are using the --delete option when running it) can definitely cause the slugs to change. When run without --delete, it should just populate any slugs that are missing - but if you run it with that option, it will delete all existing slugs, check the value of the "Generate description permalinks from" setting, and then use that when it repopulates all slugs (though the setting just affects descriptions) in the application. 

Technically, I don't think you should need to run that task as part of your scripted 2-site setup's data transfer. It should only be needed if there are issues with missing slugs in the original dataset - which you'd want to correct before copying over anyway! 

More on the generate slugs task here: 

• https://www.accesstomemory.org/docs/2.5/admin-manual/maintenance/troubleshooting/#generating-slugs
  
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-tools/#cli-generate-slugs
  

Rebuilding the nested set should not affect the slugs. The nested set is used to manage ordering in hierarchies, such as in the treeview. More here: 

• https://www.accesstomemory.org/docs/2.5/admin-manual/maintenance/troubleshooting/#rebuilding-the-nested-set
  
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-tools/#cli-rebuild-nested-set
  

Finally, note that we offer a similar 2-site deployment as part of our Premium+ hosting plan. We make the replication script that we use for this service publicly available, here: 

• https://github.com/artefactual-labs/atom-replication
  

It uses Ansible to run the script as a playbook, which sounds like a different approach than what you are doing, but it might be useful to compare. From what I know (and can tell from looking at the playbook), our script copies the database, uploads and downloads directories, and the ES index (so there is no downtime on the public site during re-indexing), and restarts services afterwards. 

Regards,  

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/0cc6f8b2-8e4e-4645-b054-bacff9c913a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.