<p>I think you're on the right track with the case-sensitivity check.</p>

<p>Make sure that not only the class names match up case-wise, but the file names on the file system match case-wise as well.</p>

CC BY-SA 3.0
2014-12-12T09:29:52.443Z
The directory was "fieldTypes" instead of "fieldtypes" - worked on Mac OS X, failed on CentOS. The lesson here being that if your plugin's custom field types aren't listed in the edit field drop-down, or the Type is listed in red with the full class name (instead of whatever getName is set to return) for existing field(s), then it means Craft can't find the class file. Still would of liked to of had this logged somewhere in Craft!
Tom
CC BY-SA 3.0
2014-12-11T21:06:57.103Z
2014-12-11T21:06:57.103Z
Brad Bell
<p>I have a plugin with a FieldType - I used the CocktailRecipes plugin as a template.</p>

<p>It extends BaseFieldType; it has 3 methods (getName, defineContentAttribute [AttributeType::Mixed] and getInputHtml)</p>

<p>It it working fine on a local PHP install.</p>

<p>However, on the server, when I create a new field, the plugin's custom field type isn't listed in the drop-down; this works fine on my local PHP install.</p>

<p>If I use my local install connected to the server's database, I can add the field type - but if I look at the field list in the admin back on the server, the field Type isn't the string returned but the getName function in the FieldType model (as it usually is) - it's the full class name, highlighted in red (it has a wrapping element with a class of "error").</p>

<p>I can't see anything in the log files about why - even in dev mode.</p>

<p>The only differences I can think of between my local and the server setups is that the PHP version is higher on the server - and the server OS is case-sensitive for file names.</p>

<p>I've checked the casing used, and it looks correct based on the CocktailRecipes plugin example.</p>

<p>It feels like the issue is that the class can't be found on the server, despite it being there; and perhaps a casing issue, which is being masked on my local machine, is the reason the issue isn't occurring locally.</p>

<p>Has anyone encountered this issue before? With no error messages being logged, I haven't had much luck digging out the issue.</p>

<p>What I'm basing it on:</p>

<pre><code>&lt;?php

namespace Craft;

/**
 * Ingredients Fieldtype
 *
 * Allows entries to select associated ingredients
 */
class CocktailRecipes_IngredientsFieldType extends BaseFieldType
{
    /**
     * Get the name of this fieldtype
     */
    public function getName()
    {
        return Craft::t('Cocktail Ingredients');
    }

    /**
     * Get this fieldtype's column type.
     *
     * @return mixed
     */
    public function defineContentAttribute()
    {
        // "Mixed" represents a "text" column type, which can be used to store arrays etc.
        return AttributeType::Mixed;
    }

    /**
     * Get this fieldtype's form HTML
     *
     * @param  string $name
     * @param  mixed  $value
     * @return string
     */
    public function getInputHtml($name, $value)
    {
        // call our service layer to get a current list of ingredients
        $ingredients = craft()-&gt;cocktailRecipes-&gt;getAllIngredients();

        return craft()-&gt;templates-&gt;render('cocktailrecipes/_fieldtypes/ingredients', array(
            'name'      =&gt; $name,
            'options'   =&gt; $ingredients,
            'values'    =&gt; $value,
        ));
    }
}
</code></pre>

<p>What works fine locally:</p>

<pre><code>&lt;?php
namespace Craft;

class ECOffers_OfferPeriodFieldType extends BaseFieldType {

    public function getName() {
        return Craft::t('Offer period');
    }

    public function defineContentAttribute(){
        return AttributeType::Mixed;
    }

    public function getInputHtml($name, $value) {
        $offer_periods = craft()-&gt;eCOffers_offerPeriods-&gt;getOfferPeriodsForLocale($this-&gt;element-&gt;getContent()-&gt;getAttributes()['locale']);
        $options = array();
        if ($offer_periods) {
            foreach ($offer_periods as $offer_period) {
                $options[] = array(
                    'label' =&gt; $offer_period-&gt;name.': '.$offer_period-&gt;fromDate-&gt;format('H:i D jS M Y').' - '.$offer_period-&gt;toDate-&gt;format('H:i D jS M Y'),
                    'value' =&gt; $offer_period-&gt;id
                );
            }
        }
        return craft()-&gt;templates-&gt;render('ecoffers/_fieldtypes/offerperiods', array(
            'options' =&gt; $options,
            'value' =&gt; ((!is_null($value)) ? $value:craft()-&gt;eCOffers_offerPeriods-&gt;getCurrentOfferPeriod($this-&gt;element-&gt;getContent()-&gt;getAttributes()['locale'])-&gt;id)
        ));
    }
}
</code></pre>

<p><img src="https://i.sstatic.net/MPtNF.png" alt="Local instance with remote database"></p>

<p><img src="https://i.sstatic.net/KRZBp.png" alt="Server instance with same database"></p>

<plugin-development>
Plugin FieldType giving error on live server - fine locally
# Plugin FieldType giving error on live server - fine locally

(Asked by: username_0 on 2014-12-11)

I have a plugin with a FieldType - I used the CocktailRecipes plugin as a template.
It extends BaseFieldType; it has 3 methods (getName, defineContentAttribute [AttributeType::Mixed] and getInputHtml)
It it working fine on a local PHP install.
However, on the server, when I create a new field, the plugin's custom field type isn't listed in the drop-down; this works fine on my local PHP install.
If I use my local install connected to the server's database, I can add the field type - but if I look at the field list in the admin back on the server, the field Type isn't the string returned but the getName function in the FieldType model (as it usually is) - it's the full class name, highlighted in red (it has a wrapping element with a class of "error").
I can't see anything in the log files about why - even in dev mode.
The only differences I can think of between my local and the server setups is that the PHP version is higher on the server - and the server OS is case-sensitive for file names.
I've checked the casing used, and it looks correct based on the CocktailRecipes plugin example.
It feels like the issue is that the class can't be found on the server, despite it being there; and perhaps a casing issue, which is being masked on my local machine, is the reason the issue isn't occurring locally.
Has anyone encountered this issue before? With no error messages being logged, I haven't had much luck digging out the issue.
What I'm basing it on:
cocktailRecipes->getAllIngredients();

        return craft()->templates->render('cocktailrecipes/_fieldtypes/ingredients', array(
            'name'      => $name,
            'options'   => $ingredients,
            'values'    => $value,
        ));
    }
}

What works fine locally:
eCOffers_offerPeriods->getOfferPeriodsForLocale($this->element->getContent()->getAttributes()['locale']);
        $options = array();
        if ($offer_periods) {
            foreach ($offer_periods as $offer_period) {
                $options[] = array(
                    'label' => $offer_period->name.': '.$offer_period->fromDate->format('H:i D jS M Y').' - '.$offer_period->toDate->format('H:i D jS M Y'),
                    'value' => $offer_period->id
                );
            }
        }
        return craft()->templates->render('ecoffers/_fieldtypes/offerperiods', array(
            'options' => $options,
            'value' => ((!is_null($value)) ? $value:craft()->eCOffers_offerPeriods->getCurrentOfferPeriod($this->element->getContent()->getAttributes()['locale'])->id)
        ));
    }
}

**Tags:** plugin-development

---

## 1 answers

### Answer by username_1 on 2014-12-11. Score: 1 | Accepted answer

I think you're on the right track with the case-sensitivity check.

Make sure that not only the class names match up case-wise, but the file names on the file system match case-wise as well.

> **Comments:**
> **username_0**: The directory was "fieldTypes" instead of "fieldtypes" - worked on Mac OS X, failed on CentOS. The lesson here being that if your plugin's custom field types aren't listed in the edit field drop-down, or the Type is listed in red with the full class name (instead of whatever getName is set to return) for existing field(s), then it means Craft can't find the class file. Still would of liked to of had this logged somewhere in Craft!  

---

