Existing "morph" relations #1
Description
This means existing morphs are effectively broken with this plugin. However, due to internal use we haven't explored a correction for this.
So if we install the plugin onto an application with a morphTo relation, it probably will break. This is because the existing application either has an alias or a fully qualified namespace for the reference.
Post plugin install, you now have an alias to that morph with a numeric value. This is great for long-term auditing due to space constraints, but might break existing systems.
We should look into not using the morphable relations, so we can leverage our own numeric mapping for model paths. It was far easier to use morphs though to leverage Laravel functions.
This needs an investigation, because the first implemented project broke a lot of things due to dependencies on morphs.
It would be as easy as updating our existing - getNumericMorphMap to point to our new map, instead of the Laravel map.