Welcome to the AtoM community!
First, if you have command-line access to your installation, there is a much easier method to update the slug or permalink (the unique part of the URL/weblink) so it matches your edited title. There is a command-line task to generate slugs. By default it will only generate slugs where they are missing for some reason, but the task also has a --delete option. When this option is used, all slugs will be generated again - therefore, so long as you are using the default slug generation settings (that use the title or authorized form of name for slug creation), then this should fix the issue.
If you have never worked with the command-line interface betore, we have a 101 deck on the basics here:
You will find many other cheat sheets, guides, and tutorials online.
You will want to run the AtoM slug generation task from the root AtoM installation directory - if you have followed our recommended installation instructions, this is typically /usr/share/nginx/atom.
After running the task, we will also want to clear all caches, to make sure we are seeing the updated content and not an older cached version. First, clear the Symfony cache:
PHP-FPM also has its own cache, so let's clear that as well. The exact commands depend on the version of PHP you are using - assuming you have AtoM 2.6 with PHP 7.2 installed on Ubuntu 18.04, run:
Finally, we will want to reindex the site, so the search index matches our new slugs. Run:
Don't forget that you might want to clear your web browser cache, or else test in a private or incognito browser window, to ensure you are seeing the changes.
In terms of the error message you are seeing:
At a glance, I suspect there may be an issue with the CSV - perhaps the incorrect file encoding, for example. No part of an import should be attempting to update a static page. Are you by chance using MS Excel to prepare your CSV files? Microsoft is notorious for using its own custom character encodings rather than the de facto standard of UTF-8, which AtoM expects. Later versions of Excel seem to have better support for UTF-8 CSV files, but we still hear reports of bad imports due to its use.
The character encoding and line-ending requirements for AtoM are noted in our documentation here:
Instead of Excel, I recommend that you try to install LibreOffice Calc
and use that instead when preparing CSVs for import into AtoM. It's not as user-friendly or as nice looking as Excel, but it is free open source software, and the control it gives you over character encoding (and delimiter / separator characters) is far greater - you can set this before you open any CSV:
If you are trying to update records via CSV import, be aware that there are some limitations - for example, many fields (any fields in the data model that are part of different tables, such as notes) cannot be updated via CSV import, only added to. For more information on how it works and how to prepare a CSV for update import, see:
Another important note. The matching criteria during an update import is currently very difficult to properly use when roundtripping a CSV in the same system. However, the command-line task for CSV import has a --roundtrip option that makes matching much easier when you export a CSV, make changes, and then want to re-import it as an update. See:
Finally, in general, we STRONGLY recommend that you create backups of your data before attempting any large-scale changes, so you can roll back to a previous save point if things don't go as expected! See: