I believe I understand. What I'd do, is have your Parent have methods that returns the appropriate thing:

# parent

sub new {
    return bless {}, shift;
}
sub wordpress {
    my ($self, %params) = @_;
    return My::Dist::Wordpress->new(..., %params);
}

# user code

my $parent = My::Dist->new;

my $wordpress_obj = $parent->wordpress(%params);
[download]

Does that make sense? Again, you can hold the child objects within the parent object if you need to maintain running information about them. Let me know if you'd like a brief example of that scenario.

Note that some parent class code sets up a lot of stuff before returning a child object. Other times not. If not, you could simply do:

my $wp_obj = My::Dist::Wordpress->new(...);
[download]

That bypasses parent->child inheritance, so fetching from the parent obj may be better, again, because you may want to keep track of child info, or you may want all of your DB/config/setup stuff within the parent, then have the parent create the child with a special instantiation call, while passing in this special data. Doing it through the parent object (former example) would have parent do *all* of the config reading, then just pass along relevant details to the relevant child init (this is my preferred way in most situations, so configs etc get read only once).

When I create multi-level inheritance classes, iirc, I 'hide' all of the child classes, so that a user doesn't need to know about them whatsoever. See here for a pretty simple example where I let the parent pull in objects of different types, and dish them out. In that case, there's no state tracking.

Here's a reasonably more complex example, where I have two classes, parent and child, where I stuff the child inside the parent so the parent can use the child directly, and the child can actually use the parent as well. This requires some REFCNT (reference counting) manipulation, so that we don't leak.

I'm using Moose so I'm not using the new constructor method.

Also, it may help you to understand the bigger picture of what I'm doing:

I've got a webserver. I am sitting at my local machine. I am writing modules on my local machine to help me automate operations on the webserver (download website database files, upgrade sites, backup sites, etc.). What I have so far is a Moose module with some helper roles that help determine Apache's DocumentRoot for a website based on a website's domain name. I create Website objects based on the DocumentRoot. The generic Website object knows nothing about what kind of site it's dealing with. It just populates the Website object's attributes with stuff by parsing the Apache config file for the website. From there, I have the Website object determine what kind of website it is by inspecting files in the DocumentRoot. My thinking is that I want to transform the Website object into something more specific based on what kind of site it is so it can run specialized methods on it.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

I would implore you to learn the base Perl way of generating objects in this case.

It appears to me as though you're losing out on a piece of the puzzle here. I do not mean to be disrespectful, but I think a peruse of perltoot and perlobj would really help.

Starting with something that wraps (ie. hides) the constructor (eg: Moose, Moo) may be hindering you from seeing what is truly possible.

An object can create an object of its own kind if designed properly, even with significantly different attributes and settings. You are not wanting to re-bless here, I assure you. You want to create either a same-object, or a sub-object depending on parameters sent in.