Add a URL Rewriting like feature to cPanel daemon

[malex]

Hi,

I'm a developer working with cPanel for more than 10 years.
I create cPanel plugins on a regular basis, using the PHP Live API for instance. I created multiple tools for the web hosting company I'm working for, tools that appear as extra on the cPanel interface for our customers. Furthermore, I'm pretty familiar with cPanel, even to a development point of view.

However, creating a cPanel plugin is a real pain, for multiple reasons, but one of them is that the cPanel daemon does not support any kind of URL Rewriting, at all.

This mean that if I want to use a Framework like Symfony to create a cPanel plugin, I'm fucked, because I can't use the URL Rewriting system and have some nice URL like /something.

To be more precise, this mean that I'm force to work with query string. To give you an example, I'm forced to use / work with URL like this :

https://cpanel.server.com:2083/cpsess0123456789/frontend/jupiter/my-custom-tool/index.live.php?controller=custom-endpoint&arg=1234

I can't use something like this :

https://cpanel.server.com:2083/cpsess0123456789/frontend/jupiter/my-custom-tool/custom-endpoint/1234

Or event something like this as a backup :

https://cpanel.server.com:2083/cpsess0123456789/frontend/jupiter/my-custom-tool/index.live.php/custom-endpoint/1234

I would for cPanel to add some basic URL Rewriting. I'm aware that it's not apache that respond for those URLs, that it's the cPanel daemon, so I'm not requesting a full .htaccess support.

But adding a feature I can activate like "when something does not exist / 404, pass it thought the index.live.php" will be a huge win. It will allow me to use a Framework like Symfony on my project. Right now, I'm force to work with query string, or create a vanilla PHP project the old way.

 

[ffeingol]

https://features.cpanel.net/ would prob. be your best bet.

 

[cPanelThomas]

Well, there was some limited accommodation implemented last year for some things that WP Toolkit does, namely using url fragements *after* index.php.
Example: path/to/thing/index.php/some/more/args/here. Presuming your targeted cPanel version is v106 or higher, you should at least be able to use the (admittedly limited) "backup" position you specified in your third example and it not just 404.

Would the main issue with approach #3 be that we are not slamming the path bits after the .php/ into $_GET or something like that? From what I can tell in the commit which added this accomodation, we were not really doing much more there than ensuring the call doesn't 404 when done that way but instead route to the base document. It certainly makes sense to me in that light that you'd probably still be stuck with managing the query string unpacking yourself.

 

[cPanelThomas]

Thinking on this too... Were we to consider implementing a "proper" rewrite rule for specific pages, would it make sense for the rewrite scheme/regexp to be one of the configuration keys in install.json for the plugin? Certainly when I think about "how I'd probably go about it" that makes the most sense to me.

 

[malex]

Fragments in the URL, so like index.live.php/something is fine with me because it's already managed by Symfony, it can understand it. So as a fallback solution, it's fine with me.
I already tested in, on a cPanel 108, without success I got the 404 cPanel page.

But I'm not against having a better solution, and we need to consider other developer that may not use Symfony / nor PHP.
Having a special config in the install.json seems fine to me. A rewrite scheme/regexp is a great idea and it will keep the backward compatibility too, when the rewrite config is missing, it can behave like the old way.

 

[cPanelThomas]

I did some investigation on the 404s and wound up filing a case on this -- CPANEL-43180.

Long story short, so long as frontend/ is part of the URL, the logic for fragments in the URL doesn't trigger, which more or less defeats the purpose of the task which added the special handling for that within the context of cPanel *unless your plugin somehow lives outside frontend*. I'm not even sure how one would go about abusing the uri field in install.json to accomplish this.

Not sure when I'll get the time to address this, but this one certainly has caught my interest, so I'll try to make time for it soon.