Resolve other issues with replaced plugin #25
Conversation
…replaced plugin is still installed but disabled
Co-authored-by: Luke Towers <[email protected]>
|
@LukeTowers at first glance, do you see a problem running this check first? |
|
No, just so long as we make it clear with those two methods that they have the power to prevent a class that actually exists but hasn't been loaded yet from being loaded; since class_alias() is typically a fallback method instead of an overriding one |
…ed plugin models classes
mjauvin
changed the title
| }); | ||
| } else { | ||
| $this->query->where($this->morphType, $this->morphClass); | ||
| } |
There was a problem hiding this comment.
I'm not comfortable with having this in the core, it's pretty hacky to have a vendor-specific conditional in the core and there could be a number of unforeseen issues with invisibly grabbing more data than expected by the developer.
There was a problem hiding this comment.
isn't that what you meant by:
NOTE: We could also explore the idea of having Laravel replace these values at the query level seeing as it's highly likely that other plugins could be extending the replaced plugins and referencing those models in their own data structure.
There was a problem hiding this comment.
I more so meant doing so at the plugin level through an API of some sort, but wasn't quite sure how it'd work or if it'd even be feasible.
…g replaced plugin models classes" This reverts commit 745f205.
Moving the class_alias if block first resolves the loader issue when replaced plugin is still installed but disabled