You can certainly implement a system that uses end-to-end encryption and has the server portion written in PHP [1]. You'll just have to implement the crypto part as something that runs on the "ends" - that is, the browsers, so realistically you'll need to implement it in JavaScript - and your PHP code would serve this JS to the endpoints. The PHP code would also need to serve up the public keys [2] for everybody who is supposed to have access to the data being encrypted. Depending on how you're going to store the private keys, the PHP would probably store (and serve) a "wrapped" (that is, encrypted) version of those, too.
The server-side (PHP) portion of this whole project ends up being slightly more complicated than a typical web app. It needs to be able to authenticate users, which is normal, but without enabling the admins impersonate users (this is not normal) [3]. It probably needs to be able to store (and control access to) private-per-user data (the wrapped secret keys), per-user public data (the public keys), and restricted-access shared data (the actual encrypted user data). Depending on what sort of data is being stored, how much of it, whether you need to be able to adjust who has access to it after-the-fact, and whether it needs any kind of searchability, you may run into any of a host of additional complexities. Secure end-to-end systems are hard. [4]
The client-side (JS) portion of this thing is going to be where the heavy lifting occurs, crypto-wise, though. That's kind of awkward, because JS isn't great at crypto. There exist pure JS implementations of the standard crypto functions, but they tend to have problems (like being relatively slow, and potentially exposing side-channel vulnerabilities such as timing attacks). Some browsers support performing native crypto operations using data from JS, which is faster and more secure (assuming you trust the browser developer, which you kind of need to here), but it's not yet universal.
[1] You probably shouldn't. PHP is a poor choice for any highly-security-sensitive code, as it is relatively easy to make security mistakes in. Secure code in (modern, fully-patched) PHP is certainly possible, but I would recommend using a language that makes it harder to shoot your own foot off, like Java, C#, VB.NET, or perhaps Go or Python.
[2] This presents a security weakness you need to figure out a way around, because the endpoint system - the user and their web browser - have no way to tell if the public keys sent to the client (to which the data is being encrypted) are the right public keys. A malicious server admin could add their own public key to the list of keys, and then any data encrypted with that list of keys would be readable by the malicious admin. You need some way of verifying key authenticity.
[3] One tricky bit here is that, while the server should never store the user's password, the server does typically see the password, briefly, when creating the account and whenever the password is used (logging in, changing the password, etc.). A malicious server admin could modify the server to steal this password. If that password is all that is needed to log in as that user - for example, if knowing the user's password allows you to unwrap the user's private key - then the malicious admin could then decrypt the data that they aren't supposed to have access to by impersonating a legitimate user.
[4] Honestly, this sounds like a project for somebody both more experienced in information security and as a developer. It's not an easy problem, and crypto is hard to do right.
