Recent Profile Visitors

So you need to start verifying what has actually worked. For example, var_dump($result) in the php script and see what is being returned. Tools like Postman are good for testing this type of thing if you can't figure out how to do it manually. You need to follow each step and assumption until you determine what isn't working the way you expect.
On the javascript side of course do things like use the debugger or even simple alert() statements.
One thing I didn't see in your fetch PHP script is you using header() to set the mimetype to be json since that is what you are trying to return.

You need to load the autoloader before you do anything else. It's not optional. The autoloader figures out where your component libraries are and resolves them for you. It should be the first thing you do in your script.

Agree strongly with the advice given previously. There is almost always a way to design an interface once you think deeply about the general purpose of the task. The internal specifics of each protocol just need to be hidden in the injected class(es), which is very much the point of Dependency Injection.

Hi Slipscream,
The journey into development often begins with a story like yours. There is no greater motivation for learning something than wanting to scratch your own itch. Web development is a complicated multi-faceted pursuit that challenges veteran developers in its complexity and scope. When you have questions, we are here.

Well, no I don't think that RDBMS's support subtypes, although you can model something involving multiple tables that sorta supports it. I have certainly done this in the past, however, my reason had more to do with wanting to write generic code than it did traditional OOP. For example, I had a model with an entity table that was essentially the base of a class. Entities could be these types: member, channel, vendor, stream.
So looking at that, it's not very oop, but relationally it had some major advantages. For example, I required a lot of sophisticated grouping. I had groups that for example, defined for a Member their channels. For a particular channel there could be any number of streams. And for each channel there were groups of admins, moderators, etc.
Because I had built this around a base entity table, as soon as I had put in place the grouping tables, and written code to support these things, I already had essentially created what I needed to relate these different types of things together whether that be as members to channels, or channels to streams, or vendors to channels.
Then there were assets that could be attached to these things, and again, with a generic set of tables that allowed relation of an asset to an entity, it didn't matter if it was a photo in a stream, or a cover image for a channel, or a video for a product sold by a vendor.
Once i created comments and tags, I could comment on or tag anything with tremendous reuse of code and DRY.
As for serializer, there are several things it does that are sophisticated, and fit Doctrine really well. First it goes through a complicated object tree and figure out how to turn that into a sensible data structure. There is also support for annotating a model to include/exclude particular attributes in your model. For example, you might not want a rest api to disclose internal key values, and with Serializer, you can annotate your model and serializer will automagically support that for you.
Your error was simple, and right off the documentation page really...
$output = $serializer->serialize($someEntity, 'json');
echo $output;
Of course, if you're just testing this, you want to set the content-type of the page:
header('Content-Type: application/json');

ORM's are ORM's -- they can be great if you drink the coolaid and accept their limitations and quirks. I do have to say that I far prefer Doctrine2's Data Mapper pattern to Active Record which is used by most of the other framework ORM's and with Ruby on Rails for example.
This is a decent article that touches upon how the Data Mapper pattern is different (and better in my opinion) than Active Record. In general Doctrine2 is more sophisticated and attempts to do much more than the other PHP ORM's. Some of the things you have been attempting to do that involve inheritance aren't even remotely possible in other ORM's without you essentially hacking them.
However, relational databases don't provide or support inheritance of any sort, so you are inevitably trying to force a round peg into a square hole. Probably a decade ago "Object databases" were the hot buzzword, and yet it says a lot that none of the many companies and products emerged with anything that gained a critical mass outside of niche applications tightly bound to specific oop languages. Meanwhile RDMBS's continue to dominate persistent data storage.

I am going to guess that you are doing this in order to provide a REST api?
Having done this a number of times in the not too distant past, I wired this sort of logic into the controller class. If you subscribe to MVC, which is easy enough to do this via adoption of the symfony framework, then it's fairly easy to create a base controller class that inherits from the Symfony controller class, and into this you can build in things that make your REST api easy to deal with.
I mention symfony because you were already using Doctrine if I'm not mistaken, and Symfony already defaults to use of Doctrine.
Once you go down this path, then you have the JMS Serializer bundle which handles serialization of complicated object trees into either of json or xml.
Even if you don't use symfony, you can still use the Serializer library by itself.

One of my goto linux commands:
df -h
Gives you the high level filesystem storage availability.
du -Sh | sort -rh | head -50
Gives you a report of filesystem use, largest files and directories listed first. The '-50' at the end controls the number of listings. Tweak that as you want/need. Should help you get an idea of where your storage has gone to and what you might be able to delete to clear space.

Json has become ubiquitous in the web development world for a few reasons.
When developers started to make heavy use of javascript in order to provide an interactive experience in their web pages, and as Ajax became a prevalent way of supporting interactivity, Json became the preferred way of getting data into javascript heavy apps. Since json is easily converted into javascript objects, this is a lot better than having a server return html or csv or text which then has to be parsed and loaded into javascript objects. Json helped cut out the intermediary steps and required code to either convert javascript objects and data into some other standard before sending it, and provided the same benefit when data was sent in response.
As REST Api's became the preferred way of accessing services, more and more of these services defaulted to JSON rather than using the verbose alternative of XML. JSON consumes less network data than JSON, and is certainly simpler to use than xml.
Obviously for PHP, json is not a native data type, so you have json_decode() to transform json either into PHP object(s) or PHP arrays() depending on the optional 2nd parameter. It defaults to objects, but often PHP arrays are far simpler to work with given PHP's multitude of array manipulation functions.
Conversely, when you need to return json data, json_encode() takes your PHP arrays or objects and turns them into json. Hope this give you some historic context and clarifies a few things.