Why the notion of "content type" is relative to slug instead of content type yaml key ?

[david-saisondor]

Question	Answer
Relevant Bolt Version	5.1.7
Install type	Composer install
PHP version	7.4
Web server	Apache

Hello,

If I create a such content type :

article:
    name: "News"
    slug: news
    singular_name: "New"
    singular_slug: new
    fields:
        [...]

In the database table 'bolt_content', column 'content_type' will contain 'news' instead of 'article' for each content of this type.

I don't understand the logic behind this behavior. I think slug should only councern URL and nothing else.
In previous example, if after filling ten news pages I realise that 'http://my-domain/news' is not fun and should be changed to 'http://my-domain/breaking-news' I can't do that simply by changing the slug in contenttypes.yaml. If I change the slug, Bolt will not be able to retrieve existing contents in database.
If 'article' should have been used as content type name, there would be no problem anymore.
Perhaps there is something I missed ? (I'm a Bolt newbie)

[andysh-uk]

I have to say, I agree with this.

When I first started working with Bolt, I thought "slug" was just for URLs, which is typically the case in other CMSs.

This also applies to setcontent calls - I was quite surprised that it goes by the "slug" not the content-type key name.

[david-saisondor]

At first glance, it seems problem resides here:

in /src/Configuration/Parser/ContentTypesParser.php:44

foreach ($tempContentTypes as $key => $contentType) {
    if (is_array($contentType)) {
        $contentType = $this->parseContentType($key, $contentType);

        if ($contentType) {
            $contentTypes[$contentType->getSlug()] = $contentType;
        }
    }
}

I'll try to find time to perform some tests, with replacement of $contentTypes[$contentType->getSlug()] = $contentType; by $contentTypes[$key] = $contentType;

Even if in case of there is no bad side effects after change for new projects, I'm affraid this modification should be a breaking change for existing projects.

[david-saisondor]

As I suspected, this slug problem impacts the app in all over places ; backend menu, selector queries, content parser, routing, container...
This is far beyond my skills, since it would require a general rewrite of Bolt core.

[Halopend]

I assume there is some internal restful api calls which work off of the slugs. I actually quite like the simplicity of it as it enforces a certain level of restraint on projects, but I do think a clearer delineation between the backend/front end would be useful. Especially since the desire to mess with the structure of slugs on the front end can break backend path resolutions.

I never figured out how to handle slug “translations” due to how interlinked everything is.