For my turn driving the EE blog, I thought I walk you through the creation of a new fieldtype.  Before we get started, I should probably give you a heads up about the approach I’m taking.  One of my professors once described an absolutely brilliant lecture he’d attended where a physicist was explaining some uber-high level ‘physicy’ stuff to an audience of laymen.  He did it by starting with the simplest of analogies.  Of course, the simplest of analogies was totally wrong.  But once his audience grasped the logic of the simplest analogy, he would then draw a new, slightly less simple analogy.  Which—was also wrong.  And he kept building upon all of these simple, but wrong, analogies until the audience could grasp the basics that were NOT wrong.

Or to quote Terry Pratchett, “Actually that sentence is wrong in every particular, but it’s quite a useful lie.” (Night Watch)

So with that in mind, let’s start building our super simple fieldtype.  Continue reading….

Very useful (and timely) post, thanks! I do have a question… I have a fieldtype that requires the Pages module; what would be the best way to go about:

1. Checking that the Pages module is installed (anything wrong with a simple “SELECT `module_name` FROM `exp_modules` WHERE `module_name` = `Pages`” query, and then checking if any rows were returned?)
2. Displaying an error to the user if the Pages module is not installed (also, where would such an error ideally be displayed? When creating the custom fieldtype, instead of showing the field settings?) EDIT: Is there a standard CSS style for backend error/warning messages that an addon should make use of?

Hi Michael,

For where I’m pretty sure you need to check that pages is installed?  Your select from exp_modules makes good sense and is likely the approach I’d take.  And I’m thinking you don’t want to allow the field type to be installed if the Pages module isn’t?  In which case, there are two ways I’d debate going.

1. Shut it down using show_error()

Well- put it in your conditional and consider a language key.  But basically?  That will prevent installation and in a way the user can’t miss.  It’s ‘the ugly’ error message- typically used to tell folks they don’t have access to a url they shouldn’t have managed to get to anyway.

2.  Use flashdata- to display in that slidedown at the top of the cp.  This looks much nicer, but is also a little easier for folks to not notice:

And well- you could just install pages, but in that particular case, I’d be a bit hesitant.

I’d say it’s a toss-up between 1&2 in this case.  And there are likely some other clever approaches as well.  But does that help?

Robin Sowell - 10 April 2012 12:20 PM

Hi Michael,
I’d say it’s a toss-up between 1&2 in this case.  And there are likely some other clever approaches as well.  But does that help?

It does indeed… so far all I’ve done is display an inline “error message” (red-colored text) stating that the fieldtype requires the Pages module in both the “New Custom Field” screen and the “Edit Entry” screen (with the latter not even presenting the input field needed to set a value).

So since I have those fairly blatant messages in-place, I think I’ll give option 2 a try, thanks.

Heh- the inline messages are clever!  (I knew there would be more clever approaches.)

Yep- the options I gave are going to prevent installing it if pages isn’t installed.  But if for some odd reason they then deleted pages (and it does happen), then you’d be stuck without those inline messages to tell them to put it back.

Glad to brainstorm it with you!