After upgrading to Elements CMS 2.0 I encountered several challenges in getting the “related items” work again and in converting to pretty URLs. Consulting Claude pointed to a number of possible bugs and proposed manual fixes to the generated PHP files and CMS library. It was a bit tedious process, but my notes blog is now up and running again, with pretty URLs. Since these manual fixes might be overwritten by future updates I’m reporting them here so they can hopefully be considered in future updates.
Challenge 1: Generated index.php uses relative paths, breaking getRelatedItems() In the generated notes/post/index.php, $sourcePath is set as a relative path ('../../cms/posts'). This works for loading the current post, but when getRelatedItems() is called internally, the working directory may differ and the relative path fails to resolve. Fix: use __DIR__ . '/../../cms/posts' instead.
Challenge 2: Wrong query parameter in third IIFE In the same generated file, the third IIFE block reads $slug = $_GET['tag'] ?? $_GET['slug'] ?? null instead of $_GET['item']. This causes the related items component to always load the wrong post, returning no results.
Challenge 3: Pretty URLs hardcoded to false in collection index.php In the generated notes/index.php, $prettyUrls is hardcoded as 'false' === 'true', which always evaluates to false. This means post links on the overview page always use ?item= query parameters even when pretty URLs are configured. Fix: use $prettyUrls = true or \CMS\CMS::detectPrettyUrls() with appropriate context.
Challenge 4: date field renamed to date_published in CMS 2.0, but getRelatedItems() not updated The CMS 2.0 migration renamed the date frontmatter field to date_published, but the related items scoring and sorting logic still references the old date field. Posts migrated from CMS 1.0 that only have date_published are therefore excluded from related item results.
Challenge 5: Post shows itself as a related item The self-exclusion check in Collection::getRelated() only compares slugs ($item->slug() !== $sourceItem->slug()). Due to date-prefixed filenames, slugs can differ between the loaded item and its file representation, causing a post to appear in its own related items list. Fix: also compare filenames and titles.
Hope this is helpful. Happy to share the corrected code if useful.
