Is this correct adherence to Liskov Substitution Principle?

I used to have a base object with subtypes behaving in all but the same way — the difference being in their render methods. This base class defined a default render method, overridden by Some subtypes who have their dependencies wired in.

<?php

    class SubType1 extends BaseType {
        
        function __construct(string $userData) {

            $this->userData = $userData;
        }

        function render (ParserHelper $parser) {

            return $parser->render();
        }
    }

    class SubType2 extends BaseType {
        
        function __construct(string $userData, array $settings) {

            $this->userData = $userData;

            $this->settings = $settings;
        }

        function render (XmlHelper $parser) { // doesn't implement same interface as ParserHelper

            return $parser->getResponse($this->userData);
        }
    }

    class BaseType {

        function render () {

            return "I'm in A";
        }
    }

Keep in mind that the following classes are utilized in this way

    $renderer = $typeFinder->search(( // define critical objects in user facing client. this definition is frequently performed and would be an inconvenience to constantly pull dedicated $parser before definition
        new SubType1("John"),

        new SubType2("Ann", ("dark_mode" => true))
    ));

Then, internally, where the actual consumption is being done, we had

    $dependencies = $app->autoWire($renderer, "render"); // the violation here

    $renderer->render(...$dependencies);

So, in trying to maintain the same interface, BaseType was made abstract with all the consistent behavior retaining their default positions. The user facing client still looks the same. However, the underlying classes were refactored to

<?php

    class SubType1 extends BaseType {
        
        function __construct(string $userData) {

            $this->userData = $userData;
        }

        function render () {

            return $this->regularParser->render();
        }
    }

    class SubType2 extends BaseType {
        
        function __construct(string $userData, array $settings) {

            $this->userData = $userData;

            $this->settings = $settings;
        }

        function render () {

            return $this->xmlParser->getResponse($this->userData);
        }
    }

    abstract class BaseType {

        abstract function render ();

        function initialize (ParserHelper $parser, XmlHelper $xmlParser):void {

            $this->regularParser = $parser;

            $this->xmlParser = $xmlParser;
        }
    }

Then consumed with

    $renderer->initialize($app->get(ParserHelper::class), $app->get(XmlHelper::class));

    $renderer->render();

Is it ideal to plug in those dependencies to even subtypes who won’t be using them? Does this obey the open/closed principle as well? It doesn’t look like it to me. The subtypes are safe as far as creating new ones is concerned. But there’s the caveat that their parent must receive that parser first. There goes the "closed" part of the principle.

I realize a decorator object who works with the contents of $decorated->userData should do the trick, but I can’t wrap my head around how to decouple the decorated user-facing subtype constructors from the decorator; while still allowing decorated autonomy to pick what parser best suits it. MAYBE that client facing subtype just has to swallow the bitter pill of defining the parser each time

I have an idea on how to use the decorator pattern, retain the subtype signature, leave them closed. It looks like this

<?php

    class SubType1 extends BaseType {
        
        function __construct(string $userData) {

            $this->userData = $userData;
        }
    }

    class SubType2 extends BaseType {
        
        function __construct(string $userData, array $settings) {

            $this->userData = $userData;

            $this->settings = $settings;
        }
    }

    abstract class BaseType {

        // define common functionality
    }

    interface Renderable {

        public function render();

        public function setApp();
    }

    class SubType1Decorator extends SubType1 implements Renderable {

        function __construct (string $userData) {

            parent::__construct($userData);
        }

        function render () {

            return $this->app->get(ParserHelper::class)->render();
        }

        public function setApp(App $app) {

            $this->app = $app;
        }
    }

    class SubType2Decorator extends SubType2 implements Renderable {

        function __construct (string $userData, array $settings) {

            parent::__construct($userData, $settings);
        }

        function render () {

            return $this->app->get(XmlHelper::class)->getResponse($this->userData);
        }

        public function setApp(App $app) {

            $this->app = $app;
        }
    }

I don’t know if this ticks all the boxes. The consumption will be refactored to

    $renderer = $typeFinder->search((
        new SubType1Decorator("John"),

        new SubType2Decorator("Ann", ("dark_mode" => true))
    ));

Renderer internal consumption:

    $rendererDecorator->setApp($app);

    $rendererDecorator->render();