I have custom statuses working on the control panel for my plugin. However, there are a few issues I have with custom statues.

Looking through the database, I am unable to figure out exactly where the custom status is stored. I have my table 'craft_pluginName' with my records. My field layouts exist and so does everything else needed for my element type.

However, I still can't find the custom status. Browsing through the 'craft_content' table I see the content, related to my element type. Yet I still don't see anything related to a status.

Is the assumption that my table 'craft_pluginName' is supposed to contain a column named 'pluginNameStatus' and I then have to hook that into the element type (for a lack of better term)?

Edit: More research uncovered that 'craft_elements' has id, type, enabled and the typical time stamps. The column 'enabled' is a boolean so it can be only 0 or 1. Updating that value manually in the database updates the 'status' on my element type index view..

I feel that this 'status', which is shown when your element type has 'hasStatus' set to true. I do not feel that this really allows us to use custom statuses as you are more than likely going to have more than two options for a custom status. In my case: 'pending', 'approved' and 'denied'.

So I am still at a loss on how we actually use custom statuses in our element types, as the default right now is either on or off...

2 Answers 2


Short answer: Your custom statuses will be stored in your own 3rd party table.

Based on everything you've mentioned in this thread, it sounds like you've figured out how to at least define your custom statuses. Now, you'll want to store that status along with the rest of your data in your own custom table.

As an example of how the status data is typically handled, let's take a look at the native Users element type...


You'll notice that in both the Model and the Record, "status" has been created as its own column. This is exactly what you will need to do in your own Model and Record. (Of course the enum "values" will be your own.)


For starters I'd classify statuses in two groups - static statuses and dynamic statuses:

  • Static statuses are set explicitly
  • Dynamic statuses change according to other circumstances (other attribute values, lunar phases, whatever)

For static statuses you'd go with the approach Lindsey outlined and just define a column for that where to store everything, however, things get more interesting when you start tackling dynamic statuses.

For that, you should look at the Entry element type.


You'll want to look at the EntryElementType::getElementQueryStatusCondition() method - adding this method to your Element type will allow you to use "status" criteria when searching for elements. As a nice side-effect, this will also make the status filter in the Element index work nicely.

Another method worth looking at is the EntryModel::getStatus() method - implementing this method ensures that your Element type actually returns the correct dynamic status when asked for it.

  • Thanks Adris, I went with a static and used my own enum. The EntryModel::getStatus() also solved my other issue, great to have some talented developers and P&T thinking about the little things! Commented Jul 14, 2014 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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