Silverstripe-framework: $class::add_extension() and missing addWrapperMethods

[axllent]

I upgraded a site from 4.2.1 to 4.2.2 and experiencing an issue that I am having great difficulties explaining (but I'll do my best).

What I am experiencing is some inconsistencies when extending classes statically. What appears to he happening is that classes that are extended with $class::add_extension() are losing (or aren't being assigned) their addWrapperMethods (ie: from Dataobject::defineMethods());

Although it doesn't appear to affect all DataObjects, it is as simple as MyDataObject::add_extension(<EmptyDataExtensionClass>); and one looses all access to all has_many, many_many etc associations. Extending the same DataObject with the same Extension via yaml works however.

As I said, not all DataObjects are affected, so I'm guessing a race condition or something, I really don't know.

This issue appears only to affect SilverStripe 4.2.2 and hasn't existed since 4.0-alpha.

I hope someone can shed some light on this please?

[robbieaverill]

Possibly related to #8613

[chillu]

Closing in favour of other ticket. @axllent if that PR doesn't address the issue in your context, please reopen.

[axllent]

Would you mind referencing that PR/Ticket @chillu, or is it the one mentioned earlier (#8613)?

[tractorcow]

I'm going to re-open this ticket, since I don't believe that these issues are the same. #8613 relates to remove_extension() and class hierarchy and this with add_extension() and extra methods.

[maxime-rainville]

I'm setting the impact to high here because this looks like a regression in a patch release.

I've had a go at reproducing this, but didn't manage to however. I tried applying an extension to a Dummy DataObject in my _config.php to see if I would loose extensions applied via my YML config. I tried renaming the classes to see if it would trigger some race condition.

Can anyone find a systematic way of triggering the described behaviour?

[axllent]

Hi @maxime-rainville - this is a hard one to reproduce without sending you down a rabbit hole, however it is related to a specific module of mine (ftsearch). I'll try summarise....

The module allows you to configure any DataObject to be included in a search, and automatically extends (based on whether it is Versioned or not) relevant relationship models to trigger events (ie: relating to search reindexing). This extending is done statically via this function.

Anyway, when this module is enabled I loose controller access to (for example) some page's has_many objects, so templates started showing up with missing data.

I apologise again but there is no easy "just do this and you get the issue" scenario. If you prefer to discuss it further outside of the issue tracker then just let me know please (and where, slack?).

[maxime-rainville]

I had another look with ftsearch installed. Didn't manage to replicate the issue.

Your attachFTSearchListener() method does some unusual things. I'm not sure if this is something we should or shouldn't support. Your method is accessing and editing a lot of configuration and relations definitions and extensions from a _config.php, which may be triggering the race condition you were talking about.

I'm not quite sure what could have change in 4.2.2 to break this.

[axllent]

Thank you for looking into that @maxime-rainville. I am aware it is complicated - the idea behind it was that the attachFTSearchListener() would recursively extend a series of dataobjects (those to be indexed), and automatically extending associated dataobjects so that "triggers" are set for when a change is detected. The only way I saw possible was extending them via the static DO::add_extension(), which as I pointed out has always worked as expected.

So with that concept in mind, how would you suggest I approach the solution in a "usual manner"? I'm completely open to suggestions, I don't mind rewriting the entire thing, in a manner that doesn't require one manually having to extend each and every object (and all associated DOs) manually and individually.

Given you can't replicate the problem it makes it difficult to find out why it is not working. I could (if you wanted) provide you with the actual code + sspak where this issue does happen.

[kinglozzer]

[axllent]

[maxime-rainville]

[axllent]