Use services for SchemaMetatagManager instead of using it directly so developers can overwrite it if requried

Unfortunately that means I can't use the same code for D7 and D8. I have been trying to avoid changes as much as possible. But this is obviously the better way to write the code.

Patch no longer applies. Plus rather than calling the service repeatedly, it would make more sense to inject the service into SchemaNameBase and use a variable or method to invoke it. Then we could replicate that in D7 where the only difference between the versions would be the way the method or variable gets constructed.

I would appreciate a patch for both D7 and D8 that works that way.

@KarenS : I will try to re-factor this patch for D8. Any suggestions for the naming of this variable? Before I start to run over all classes :)

I've refactored previous patch and it should now apply.

I'm not very happy with...

• adding the service without DependencyInjection
• usage of service integration in *Trait.php files.

But perhaps this is a new starting point to integrate this patch in current code base.

Patch from #10 breaks the node add/edit form. Please do not use it!

Fix broken patch from #10 (I have previously remove visibilitySelector in SchemaNameBase ...).

It would be better to add the service using dependency injection into SchemaNameBase, thne it will be available to use everywhere. That also lends itself to creating similar code in D7 that won't be much different than D8. D7 wouldn't use dependency injection but still make a common method available to all the other code.

I see you did you dependency injection into SchemaNameBase, but none of the traits use it. I know you can't use dependency injection on traits, but we do know that everywhere the traits are used they are on some class that inherits from that class, so the method should actually work on the traits as well as the base classes.

As a reminder, the "assigned" field is for indicating you're actively working on something, when you're done you should try to remember to set it back to "unassigned". Thank you.

My bad, this does use dependency injection, but we should use the Symfony\Component\DependencyInjection\ContainerInterface class as well, and remove unused use statements. This patch no longer applies, so starting over. Let's see if this passes tests.

I fixed the fatal error in the code above and then ran into a series of additional problems. There are many many places where I am using static methods (creating each method as a stand-alone process that doesn't require the whole Drupal stack so I can test each method separately and quickly), and none of them work if this is switched to a service model (result in "Using $this when not in object context " errors). And changing those statics would require lots of changes to the architecture of the module. For posterity I am attaching the reworked patch, but I'm not going to commit it ATM.

I found a way to make this work:

• Leave the constructor alone, use $instance->set() instead to add the new service.
• Add the service to SchemaNameBase so everything will inherit it from there.
• For the traits, add an abstract method that acts as a contract that the calling class will have that method. Then the traits can also inherit the service.
• Leave the test values alone, they need to call the class statically or the current system of static methods for test values falls apart.

The big winner was the way to make sure traits could use the service, abstract methods are the solution.

Some code cleanup.

Now try to backport this...