Some data types do not store entity references in entity reference fields for various reasons. An example is the Viewsreference module, that allows an editor to add various filters on a View based on taxonomy term references. However, these are stored as serialized data in the field value so they are not found by Term Merge.
As a short term solution I subclassed the TermConfirm form and added a submit handler for these data types. In the additional submit handler, it would be nice to have the same methods and properties available. However, these are currently defined as 'private' so they can only be accessed from the class itself.
Make helper methods on MergeTermsConfirm protected, so they can be access from a subclass.
None.
Helper methods on MergeTermsConfirm are now protected, so they can be access from a subclass.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | term_merge-make_helper_methods_protected-2981761-3.patch | 2.18 KB | idebr |
| #3 | interdiff-2-3.txt | 705 bytes | idebr |
Comments
Comment #2
idebr commentedAttached patch makes the following helper methods on MergeTermsConfirm protected, so they can be access from a subclass:
getSelectedTermIds()getSelectedTermLabels()loadSelectedTerms()Comment #3
idebr commentedIn addition to the methods in #2, these properties should be
protectedas well, so they can be used from a subclass:tempStoreFactorytermMergervocabularyComment #4
wilfred waltman commentedThanks @idebr, usefull patch.
Comment #5
legolasbo@idebr,
Could you please provide some more information about the use case which lead to your subclassing the form? Perhaps that's a use case we should just support by default.
Comment #6
idebr commented#5 I have updated my use case in the issue summary:
A more elegant solution would be to make the Term Merger pluggable, so the selected terms and make the target terms available in the plugin instead. I suppose this is out of scope for this issue though.
Comment #7
legolasboAm I correct in thinking that adding something like a
TermsBeingMergedand aTermsHaveBeenMergedevent would be enough to fit the bill for your use case? You'd be able to subscribe to the event and add/remove certain terms to/from the list of terms to be merged and/or update any references to now merged terms in depending configuration like the views use case you mentioned in the summary?If that's the case, then this issue relates to #2974904: Event or Hook desireable
Comment #8
legolasboThe question in the last comment still needs answering.
Comment #9
idebr commentedYes, the suggestion in #7 would work just as well. I'll close this issue as it is no longer necessary for my use case.
My apologies for the late response, I lost track of this issue.