Skip to main content

Add a URL Rewriting like feature to cPanel daemon

Comments

5 comments

  • ffeingol
    0
  • 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.
    0
  • 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.
    0
  • 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.
    0
  • 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.
    0

Please sign in to leave a comment.