<p>For starters I'd classify statuses in two groups - static statuses and dynamic statuses: </p>

<ul>
<li>Static statuses are set explicitly</li>
<li>Dynamic statuses change according to other circumstances (other attribute values, lunar phases, whatever)</li>
</ul>

<p>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.</p>

<p>For that, you should look at the Entry element type.</p>

<pre><code>/app/elementtypes/EntryElementType.php
/app/models/EntryModel.php
</code></pre>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2014-07-14T17:46:39.473Z
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!
Jason McCallister
CC BY-SA 3.0
2014-07-14T10:00:03.340Z
2014-07-14T10:00:03.340Z
Andris Sevcenko
<p>Short answer: Your custom statuses will be stored in your own 3rd party table.</p>

<p>Based on everything you've mentioned <a href="https://craftcms.stackexchange.com/questions/907/how-to-integrate-custom-statuses-in-a-workflow-style-custom-element-type">in this thread</a>, it sounds like you've figured out how to at least <strong>define</strong> your custom statuses. Now, you'll want to store that status along with the rest of your data in your own custom table.</p>

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

<pre class="lang-none prettyprint-override"><code>/app/models/UserModel.php
/app/records/UserRecord.php
</code></pre>

<p>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.)</p>

<pre class="lang-none prettyprint-override"><code>/myplugin/models/MyElementModel.php
/myplugin/records/MyElementRecord.php
</code></pre>

CC BY-SA 3.0
2014-07-14T04:07:23.320Z
2014-07-14T04:07:23.320Z
2017-04-13T12:51:00.303Z
Lindsey D
<p>I have custom statuses working on the control panel for my plugin. However, there are a few issues I have with custom statues. </p>

<p>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. </p>

<p>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.</p>

<p>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)?</p>

<p><strong>Edit:</strong> 
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.. </p>

<p>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'. </p>

<p>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... </p>

<plugin-development><elementtype>
Where exactly are my element type custom statuses stored and used?
# Where exactly are my element type custom statuses stored and used?

(Asked by: username_0 on 2014-07-13)

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...

**Tags:** plugin-development, elementtype


---

## 2 answers

### Answer by username_2 on 2014-07-14. Score: 4 | Accepted answer

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...
/app/models/UserModel.php
/app/records/UserRecord.php

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.)
/myplugin/models/MyElementModel.php
/myplugin/records/MyElementRecord.php


---

### Answer by username_1 on 2014-07-14. Score: 5

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.
/app/elementtypes/EntryElementType.php
/app/models/EntryModel.php

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.

> **Comments:**
> **username_0**: 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!  

---

