I would like to add sequential numbering to each entry, which is obtained from a global field. After saving the entry, the global field should be assigned the next number (+1). Does anyone have any idea what the code for it would look like (module)?

enter image description here


You can use event hooks to hook into the saving process for elements to achieve this behaviour. In particular, you can use the hooks Entry::EVENT_BEFORE_SAVE and Entry::EVENT_AFTER_SAVE to perform some custom action before or after an element is saved. Both hooks receive a boolean argument indicating if the element is new. You can use that to either set a starting value for your ID field (if the element is new) or update the global counter (if the element is not new).

However, your suggested workflow doesn't appear to be very thought out. For one, what if an editor edits the People ID manually? This would mess with the counter in unexpected ways, and in turn mess up subsequent IDs. Also, I'm not sure why you need a custom ID field and the global counter, but it looks like you're trying to replicate functionality that you already get for free out of the box with Craft:

  • If you only need a unique ID for each person, each entry has that by default once it's saved to the database, so you could just use those.
  • If you need a sequential ID only for people … why? If you just want to know the ordinal number of a person (i.e. how many people there are before a specific person), you can use a simple count query with the positionedBefore parameter.
  • For the global counter: If you only need that to generate the sequential IDs, you don't need it at all if you use one of the suggestions above. If you need it to get a total of all people, you can use a count query instead.

If you edit your question to include the actual problem you're trying to solve, I'm sure someone could suggest a better approach!

  • Hey Moritz, thank you for your answer. The idea is to give people an ID in a simpler (sequential, just numbers) format rather than the UID. The 'People ID' field could be set to 'hidden' or 'unwritable' so that there are no complications. Think of this 'People ID' as a unique number, similar to a sequential invoice number. If you use a count query with the positionedBefore parameter, the 'People ID would always change when an entry is deleted.
    – nicbent
    Jun 29 '21 at 9:34
  • @nicbent Just out of curiosity, what do you need those sequential IDs for? Seems like a lot of work just to have a "nice-looking" ID, since the IDs aren't really supposed to be visible at all. And the sequentiality is already there since all entries have a timestamp. In case you just want something that is less verbose than the UID (for exported reports or something like that?), elements come with both a UID and a regular ID, which is just an integer. Maybe that't sufficient for your use-case?
    – MoritzLost
    Jun 29 '21 at 10:09
  • The functionality is intended for a people database, the 'People ID' would only be invisible in the backend, but visible in the frontend, so that users can search for this value ... I thought about the regular ID, but it is not so elegant, because these are not generated consistently one after the other, but one could possibly overlook this in view of the effort of an extra module
    – nicbent
    Jun 29 '21 at 13:53
  • @nicbent Why would people search for a random ID? If you need to be able to give people a unique identifier to search for a specific person, wouldn't the entry slug work as well? Also, having a sequential ID and exposing it like this allows for user enumeration (or rather, people enumeration), which will be problematic if you ever want to impose any sort of access restrictions. Still, if you absolutely want to do this, the hooks mentioned in my answers should suffice. Let me know if you run into any problems!
    – MoritzLost
    Jun 29 '21 at 13:59
  • @nicbent - is people ID like a customer number or what are you using it for exactly? As Moritz mentions, if you're exposing it via search, just be careful about what information is exposed unless the users of your front end are already authenticated and trusted with the information...TBH using Craft's ID would probably serve the same purpose and be way easier. When people are inevitably removed from the database at some future point in time, you're going to get gaps in the sequence regardless. Jun 29 '21 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.