* * * * *
How not to design a PHP web site
I don't even know where to begin.
One of the tasks our team is currently working on for “Project:
SocialSpace2.0 [1]” is to separate the user uploaded content (images, videos,
etc) to its own webserver (what we're calling “the static content”) to make
it easier to scale out the site.
My task is to figure out how the content is uploaded to the site. This is not
an easy task. The proprietary PHP framework (where have I heard that tale
before [2]?) consists of over 400,000 lines of undocumented code (but of
course!) spread across 3,000 files (really!) that is a prime example of why
object oriented programming can be a Bad Thing™ (early on in the project, I
was curious as to how far down the rabbit hole this code went, so I spent
some time starting with the topmost PHP file and replacing each
require_once() function call with the code it referenced; I stopped after
including over 15,000 lines of code and that's before anything is executed).
The automagical code is amazing. Even though I changed
> $EO->set_setting('FS_IMAGE_UPLOAD_PATH','uploads/images/ );
>
which is relative to the DOCUMENT_ROOT and thus, hard to move to its own
domain, to
> $EO->set_setting('FS_IMAGE_UPLOAD_PATH','/home/spc/tmp/images/');
>
the content is still save to the old location, thus making it harder to move
the content to its own domain.
Going further—the actual upload control on the webpage is a Flash program
(lovely), which apparently is controled by some Javascript (oh it's getting
better) that is generated on the fly (can you feel the love) and yet still
manages to hardcode the destination directory.
Wow! I'm seriously impressed by the previous team's work.
This is going to be painful, I can tell.
[1]
gopher://gopher.conman.org/0Phlog:2010/05/29.1
[2]
gopher://gopher.conman.org/0Phlog:2009/09/07.1
Email author at
[email protected]
