# Rename by Title

Plone derives the id of a content object from its title only once — when the
object is created. Renaming the object later is a separate, manual step.

The *Rename by title* behavior removes that step: whenever the title of a
content object changes, its id (and therefore its URL) is regenerated from the
new title.

## Behavior

When the behavior is active on a content type:

- Editing the title through the REST API or the classic edit form renames the
  object. Editing any other field leaves the id untouched.
- The new id is normalized the same way Plone normalizes ids on creation,
  honouring the editor's preferred language (`A brand new title` →
  `a-brand-new-title`).
- If a sibling already occupies the normalized id, a numbered suffix is
  appended (`taken-title-1`). That suffixed id then stays stable — further
  edits of the same title do not count the number up.
- The rename runs with elevated privileges, so an editor who may modify the
  content but not delete it in its parent folder can still trigger it.
- Old URLs keep working: the rename registers a redirect, and requests to the
  previous URL answer with a redirect to the new one.
- Renaming re-validates the container constraints. If the object's type is not
  addable in its parent — content created programmatically past the
  constraints, or a constraint tightened afterwards — the rename is skipped
  and logged as a warning. The edit itself still goes through.

It does not matter whether `title` comes from a behavior such as `plone.basic`
or from a field declared in the type's own supermodel XML schema.

### Staging

Working copies are never renamed — their id belongs to the staging mechanism,
not to the title. When a working copy is applied, the title is written back to
the baseline and the **baseline** is renamed instead.

## REST API

Nothing needs to be sent explicitly; the rename is a side effect of changing
the title.

```javascript
await fetch('/Plone/original-title', {
    method: 'PATCH',
    headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({ title: 'A brand new title' }),
});

// The content now lives at /Plone/a-brand-new-title
const response = await fetch('/Plone/a-brand-new-title', {
    headers: { 'Accept': 'application/json' },
});
```

Requests to the old path are redirected:

```python
import requests

response = requests.get(
    'http://localhost:8080/Plone/original-title',
    headers={'Accept': 'application/json'},
)
print(response.json()['id'])  # a-brand-new-title
```

Clients that cache content URLs should follow redirects, or re-read the `@id`
from the response after a title change.

## Configuration

The behavior is opt-in. To activate it on a content type, add
`wcs.backend.content.behaviors.auto_rename.IAutoRename` to the FTI's behaviors
list via GenericSetup:

```xml
<object name="MyContentType" meta_type="Dexterity FTI">
  <property name="behaviors" purge="false">
    <element value="wcs.backend.content.behaviors.auto_rename.IAutoRename"/>
  </property>
</object>
```

Enabling it on an existing site needs an upgrade step importing that profile.
Existing objects are not renamed retroactively — their id follows as soon as
their title is edited the next time.