This project has moved. For the latest updates, please go here.

Use of custom fields, ideas? suggestions? drawbacks?

Jun 7, 2010 at 4:16 PM
Anyone have any documentation or examples of good uses of the 'custom fields' portion of graffiti? I have only played around a bit with them, but wonder if anyone has any real world examples of practical things that can be done with them, and what, if any limitations exist. Also, any guesses as to whether or not this is an area that is likely to be eliminated, expanded upon, or just left 'as-is' in future updates? I have a small external database that I am considering integrating in with graffiti, and am trying to decide between using the custom fields, versus having 'real' database tables to store the data and then using a widget or chalk to display this formatted data as a post in my website. The advantage of using the custom fields I assume would be the built-in ability to then search on those fields like any other blog post. The advantages of using 'real' database tables is the ability to provide a better UI for inputting and updating those fields and using familiar CRUD routines to access the data.
Coordinator
Jun 7, 2010 at 4:43 PM
Edited Jun 7, 2010 at 8:30 PM

Documentation

This feature is used heavily by developers so I doubt it would be removed. At least 4 of my plugins rely on it and I know several other developers who comment regularly on here use them as well for things such as an event calendar plugin. I also use them to generate a podcast compatible feed with a custom plugin. This feature may grow in the future, perhaps adding more field types or whatever, but the speed at which Graffiti is moving right now is a snail's pace so dont expect any amazing things right away.

Custom fields are not currently searchable, though I think thats a feature worth adding because I often include imporant information like people's names in those fields. Custom fields are stored inside of two columes of the posts table, one containing field names and index values that refer to parts of a string stored in the second field. Its really a simple and effective way to store a varying number of fields, but not really the best for searching and accessing by other means on the back end.

Another or quirk is that when you add a custom field, you currently can only add them them to the first level categories. You could add them to the sub categories if the list of categories included sub cat but it does not. To work around, when adding a custom field, you can edit the category number in the url to get to a page that lets you apply them to only a sub category. Otherwise if you have any sub categories, all will get the custom fields from their parent. Thats usually not a big deal but a modification to the category list will be needed for the infinite category levels of 2.0.

I think if you're using a lot of custom fields, I would think you're better off using separate tables for easier querying and alternate data entry methods as you said.

Coordinator
Jun 7, 2010 at 4:44 PM

My events plugin is using them to assign the date and times for the event and my RSS extensions plugin uses them as well. Several other plugins use them for similar purposes. Custom fields are integral to the system to allow expansion and customization without database modification, so they definitely will not be eliminated. As to whether or not they will be expanded upon, there are no plans right now, but that is not to say that there won't be in the future - it just depends on what people may come up with or have a need for. I personally have been thinking about the ability to add custom fields to things other than posts, actually (primarily users), but haven't put a ton of thought into it yet.

I don't necessarily agree with your advantages of using "real database tables" either - the custom fields have pretty decent interfaces for setting values, and if you want something more complex, you can always update Graffiti to do that. And I really have no idea what you mean by "familiar CRUD routines" and don't see how there is any issue with how you view/edit/delete custom fields at all - they are pretty simple to work with.

Jun 7, 2010 at 5:46 PM
By familiar CRUD routines, I mean the large base of existing code I already have to do basic Create/Read/Update/Delete. Other advantages of using 'real' tables (i.e. storing in strongly typed SQl server database), is the ability to easily do things like "select count(*), select max(xxx), " etc, i.e. basic SQL commands that are trivially accomplished when data is stored in strongly typed table structures (as opposed to the way graffiti stores them). I can see advantages and disadvantages to both methods, but now knowing that those fields are not searched by Graffiti, makes me come down on the side of using an external database for my particular project I had in mind. Thanks for all the additional information everyone.
Coordinator
Jun 7, 2010 at 6:21 PM
I use custom fields in pretty much every site I deploy. Basically any data that needs to be tied to a post I use a custom field. Like everyone already said, they aren't going anywhere. I do hope we can extend them more over time. It would be nice to add in the same kind of flexibility you have with a theme config file into custom fields. The key is going to be how to offer that kind of flexibility of keep the current simplicity.
Coordinator
Jun 7, 2010 at 6:51 PM
jkillebrew wrote:

Custom fields are not currently searchable, though I think thats a feature worth adding because I often include imporant information like people's names in those fields. Custom fields are stored inside of two columes of the posts table, one containing field names and index values that refer to parts of a string stored in the second field. Its really a simple and effective way to store a varying number of fields, but not really the best for searching and accessing by other means on the back end.

If anyone does have a custom field that they would like to add to the index for the built in Graffiti search, Kevin provided me information on how to do that here: http://stackoverflow.com/questions/2072877/graffiti-cms-search-custom-fields