Skip to main content

There's more than Cpanel in this world

My brother bought simple local e-commerce application. PHP application actually. It's quite simple, the typical add to cart stuff with extra features to track affiliation. Nothing that Drupal/Ubercart can't do. But I can see a reason for people to buy that. Buying off the shelf software is cheap (provided it work out of the box) compared to developer's time to setup an open source equivalent.

I'm hosting all my brother's website so for this one I just created another user inside my Webfaction account, point the php/symlink application to the DocumentRoot inside that user's home directory, create mysql database and all set to go. But there's one problem. Clicking on certain link that supposed to open a popup just load up the main page instead of the desired page.

Since it look like a routing problem, I take look at .htaccess file. There seem to be few rules that route incoming url to the php file. Looking at source code, it turned me off a lot. IonCube encoded. Nah, I can see a reason for them to protect their hardwork. But for me to debug some 'proprietary' code ? No way. So I just asked my brother to request a support.

The first response said that the .htaccess file cannot be uploaded. I don't know how he come to the conclusion. The file is there. So I replied (to my brother) to let them know that the file is there, attached a copy of that file and asked them to verify whether the file is correct or not. I'd also mentioned that mod_rewrite is enabled, in case they're thinking of that. Some other rewrite is working so there's no reason to say mod_rewrite not working.

Another reply that really made me think enough is enough. They're complaining that they can't access something like http://thesite.com/cpanel or http://thesite.com:2083/cpanel. Wth .... so there must be a cpanel in all hosting in this world ??? The problem is simple enough to debug, writing this blog post would take much longer than that.

What I did was rename index.php to index2.php and create my own index.php. There I just print_r($_SERVER) to see all the incoming request variables. Everything look quite ordinary except for the DOCUMENT_ROOT value. My main webfaction account is at /home/myname and the DocumentRoot is located at /home/myname/webapps/thesite which is a symlink to /home/seconduser/thesite. For some reason, the DOCUMENT_ROOT value that end up in the $_SERVER variable is /home/myname/webapps/_ rather than /home/seconduser/thesite. Looked back into the .htaccess file and there's a rule that use %DOCUMENT_ROOT (RewriteCond %{DOCUMENT_ROOT}%1.php -f) which basically check if the %1.php file exists or not otherwise redirect the request to index.php. So that is it. Since DOCUMENT_ROOT value is wrong, the rule doesn't match and always redirect to index.php. My fix - hardcode the DOCUMENT_ROOT value in the rule. Done.

I'm not that annoyed if this is just some open source project. I'm more than willing to spare some of my time identifying the problem and creating patch if required. But for something that need to pay and I can't even read the code, I deserved this rant.

Comments

Popular posts from this blog

PHP with docker

A friend asking about a PHP library and I decided to test whether that library is working. But I don't have PHP environment setup (we're Python shop btw). But thanks to docker, that's easy these days. docker run -it --tty --rm --volume $PWD:/app --user $(id -u):$(id -g) composer require google/apiclient:^2.0 Then we just need to create the script to run, still in the same directory:- include_once __DIR__ . '/vendor/autoload.php'; $GCSE_API_KEY = "nqwkoigrhe893utnih_gibberish_q2ihrgu9qjnr"; $GCSE_SEARCH_ENGINE_ID = "937592689593725455:msi299dkne4de"; $client = new Google_Client(); $client->setApplicationName("My_App"); $client->setDeveloperKey($GCSE_API_KEY); $service = new Google_Service_Customsearch($client); $optParams = array("cx"=>self::GCSE_SEARCH_ENGINE_ID); $results = $service->cse->listCse("lol cats", $optParams); And we can run that script again using docker:- docker run -it --...

The first step in learning new programming language

Is to prepare the basic environment where you can freely try and experiment with the new language features and tools. Maybe because I'm not programmer type person, but more as tinkerer/builder, I hate learning the language syntax and stuff. For years after I started "learning" Python, I can't barely write any Python code. But I have manage to try lot of Python cool apps because I have that environment for me to experiment with all Python based applications. All these cool apps that get me hooked to the language, not the syntax or whatever language features. And in my experiences, this is one reason why people failed to get hooked on the new language they want to learn. They started learning with some of the language syntax and eventually get bored, because not so much interesting stuff there. In whatever programming language, it's the ecosystem that made it lively, and where the real work happened. Early this year, I made it a point to learn Go programmin...

AI coding tools fragmentation

Executive Summary The discussion centers on a tweet by DHH (David Heinemeier Hansson) from January 10, 2026 , arguing against the fragmentation of AI coding tools. DHH contends that developers do not want a separate CLI for every model provider (e.g., Anthropic’s Claude Code, OpenAI’s tools). Instead, he advocates for a unified interface —specifically citing OpenCode —that allows developers to swap models within a single environment. The thread reveals a three-way tension in the developer community between convenience (unified tools), corporate control (walled gardens), and sovereignty (running local models). Key Discussion Themes 1. The Fatigue of Fragmentation The Problem: Developers are exhausted by "model choice fatigue" and the need to manage multiple CLIs. As Rob Zolkos noted, the fragmentation is absurd, leading some to write scripts just to manage their AI CLIs. The Desire: There is a strong consensus (DHH, Will McGugan, Mustafa Ergisi) that a "universal s...