Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Customising the CMS /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

add_extension woes...

Go to End

2 Posts   2684 Views

BLU42 Media

Community Member, 71 Posts

2 February 2009 at 7:37am

I'm trying to put together a USDatetime Module for future release and am using a series of Extensions to get the job done. I've run into a bit of a problem that I'm hoping someone can shed some light on.

When trying to add an extension to DMYDateField (which is a child of CalendarDateField, which is a child of DateField - both of which have extensions), I'm only getting one confirmed extension ... the DateField extension. If I comment out the DateField extension, then it defaults to the CalendarDateField extension. It's looking like this:

class A {}
class B extends A {}
class C extends B {}

A::add_extension() // no problems
B::add_extension() // A extension only
C::add_extension() // A extension only

Any ideas on why this is defaulting to the top parent extension? Or better yet, how to implement this sort of behavior?



Forum Moderator, 801 Posts

9 February 2009 at 7:53am

First of all, we're planning a rewrite of the formfield API for better localization support, see
Its good to have extensions like USDateTime as short-term fixes though.

I'm assuming you're calling Object::add_extension('A','<your-ext-name>') instead of A::add_extension()? Static classes (currently) don't know about their classname, hence the two arguments for the method.
The static handling in SilverStripe needs some polish, it might well be the cause of this error. An abbreviated code example which we can fire up and debug would be ideal (perhaps even a unit test class?).