I think your question may be quite specific to PHP really, as I can't see any of the other back-end technologies you mention being used like this.
PHP is a funny example as it can be (in a rather ugly manner I may add) viewed as a all-in-one language with regards to a lot of web projects. You can do your traditional "back-end" tasks - such as file and database operations, whilst also building "front-end" mark-up.
This can clearly lead to a spaghetti mess where there is no real separation of concern, so it should really be frowned upon in my mind. For a great example, if you browse the wordpress source you can often get lost - and that is one project where I blame the language, the organisation of the codebase is actually very good.
This can be remedied, somewhat, by using a "templating engine" (such as Smarty)) - but it's still PHP which is building the "front-end" whilst also providing the "back-end" functionality. This was an intentional decision behind the design of PHP however, it is after all a "hypertext processor"!
So PHP can easily fit in to both "front-end" and "back-end" uses, which should clarify your example. Hence you are most likely correct in that PHP will be processing and building all the mark-up for a front-end, but it will be making requests somewhere else to gather the required data - most likely a service wrote in one of the aforementioned languages.
Personally, I feel the whole "back-end" and "front-end" terminology is a bit.. outdated perhaps. I'd rather things were just referred to a client-side and server-side; then there is no real ambiguity.*
Very recently I saw a client spec which required a back-end system wrote in node.js and associated tools, but wanted the front-end build using a PHP framework (Laravel). This comes with many associated costs, and in my mind - isn't an elegant solution and can cause a fair few issues down the line.
Personally speaking, these kind of configurations seem like someone has needlessly shoehorned PHP in to another stack - which means more resources are required than are actually necessitated, maintenance staff need exposure to a wider range of technologies and there are more points of failure.
Furthermore, I also think there are very few scenarios which warrant this kind of intermediary stack; most back-end languages/frameworks are perfectly capable of generating the mark-up required for the front-end. Although I stand to be corrected there.
After reading a comment by @itsbruce, I've decided to clarify what I mean by the ambiguity of my "front-end"/"back-end" terminology.
Traditionally this terminology would've been fine, architecturally web applications were a lot simpler - and dare I say it, a lot dumber. It's a lot cleaner in my mind to say "Server Side" and "Client Side", and this is getting clearer as the current trend of pushing more of the processing and logic in to the client is getting common.
Similarly, and incredibly relevant to this question, is building the mark-up in PHP truly a front-end task? I doubt it, a quick browse of job boards show few front-end developer positions expect PHP experience or knowledge; yet intuition would suggest that the mark-up for the interface is inherently front-end.
The very fact that this question exists acts as an example of how "front-end" and "back-end" are inherently ambiguous, and will continue to be so.
By referring to tasks as "server-side" or "client-side" that ambiguity is lost, you know where the code is executing and what languages will be used. If you said "front-end" in the example the OP has provided, I doubt many people would go "Oh, so PHP on the server right?".