ExpressionEngine White Screen

Admin White Screen

I’ve only come across the administration area throwing a white screen when using ExpressionEngine 1.67 on a PHP 5.3 server and only if extensions are enabled. I’m not sure if the newer versions of the 1.x branch have this fixed so this might not work for you.

The issue has to do with how the variables are being passed and called; PHP 5.3 changed how references were handled so the method ExpressionEngine 1.67 uses no longer works. To fix you have to modify “/system/core/core.extensions.php” with the below changes that are on the ExpressionEngine forums:

<?php
//system/core/core.extensions.php around line 115 modify:
if (sizeof($args) == 1)
{
    $args = array($which, '');
}
 
if (version_compare(PHP_VERSION, '5.3') >= 0)
{
    foreach ($args as $k => $v)
    {
        $args[$k] =& $args[$k];
    }            
}  
?>
 
<?php
//and likewise around line 174 modify:
{
    $php4_object = FALSE;
    $args = array_slice(func_get_args(), 1);
}
 
if (version_compare(PHP_VERSION, '5.3') >= 0)
{
    foreach ($args as $k => $v)
    {
        $args[$k] =& $args[$k];
    }            
}  
?>

Front End White Screen

Then there’s the front end white screen; so far I’ve encountered this type of white screen in both the 1.6 and 2.0 branches of ExpressionEngine. Luckily, whenever I’ve ran into a white screen on the front site it’s always due to various path configurations which is easily fixed by over riding the configuration file.

Expression Engine is one of those programs that stores as much as possible in the database including file and path directory paths. To get around this permanently I’ve gotten in the habit of using a default config.php file for all any Expression Engine site I work on; it’s the first thing I do before anything else.

This new configuration file uses the $_SERVER super global to dynamically determine the paths and makes allowances for development, staging and production environments.

<?php
if ( ! defined('EXT')){
	exit('Invalid file request');
}
 
$conf['app_version'] = "167";
$conf['license_number'] = "";
$conf['debug'] = "0";
$conf['install_lock'] = "1";
$conf['db_hostname'] = "";
$conf['db_username'] = "";
$conf['db_password'] = "";
$conf['db_name'] = "";
 
if('dev.site.com' == $_SERVER['HTTP_HOST'])
{
	$conf['db_hostname'] = "";
	$conf['db_username'] = "";
	$conf['db_password'] = "";
	$conf['db_name'] = "";
}
elseif('dev.site.com' == $_SERVER['HTTP_HOST'])
{
	$conf['db_hostname'] = "";
	$conf['db_username'] = "";
	$conf['db_password'] = "";
	$conf['db_name'] = "";	
}
 
$conf['avatar_url'] = "http://".$_SERVER['HTTP_HOST']."/images/avatars/";
$conf['avatar_path'] = $_SERVER['DOCUMENT_ROOT']."/images/avatars/";
$conf['photo_url'] = "http://".$_SERVER['HTTP_HOST']."/images/member_photos/";
$conf['photo_path'] = $_SERVER['DOCUMENT_ROOT']."/images/member_photos/";
$conf['sig_img_url'] = "http://".$_SERVER['HTTP_HOST']."/images/signature_attachments/";
$conf['sig_img_path'] = $_SERVER['DOCUMENT_ROOT']."/images/signature_attachments/";
$conf['prv_msg_upload_path'] = $_SERVER['DOCUMENT_ROOT']."/images/pm_attachments/";
$conf['theme_folder_url'] = "http://".$_SERVER['HTTP_HOST']."/themes/";
$conf['site_url'] = "http://".$_SERVER['HTTP_HOST'];
$conf['captcha_url'] = "http://".$_SERVER['HTTP_HOST']."/images/captchas/";
$conf['captcha_path'] = $_SERVER['DOCUMENT_ROOT']."/images/captchas/";
$conf['emoticon_path'] = "http://".$_SERVER['HTTP_HOST']."/images/smileys/";
$conf['theme_folder_path'] = $_SERVER['DOCUMENT_ROOT']."/themes/";	
$conf['db_type'] = "mysql";
$conf['db_prefix'] = "exp";
$conf['db_conntype'] = "0";
$conf['system_folder'] = "system";
$conf['cp_url'] = "http://".$_SERVER['HTTP_HOST']."/".$conf['system_folder']."/index.php";
$conf['doc_url'] = "http://expressionengine.com/docs/";
$conf['cookie_prefix'] = "";
$conf['is_system_on'] = "y";
$conf['allow_extensions'] = "y";
$conf['multiple_sites_enabled'] = "n";
?>

The above config is for the 1.x branch though most values should work for the 2.x branch with the addition of $config['tmpl_file_basepath'].

Hopefully, this should take care of those white screens.

Portability Is A Good Goal

I’m telling you, it’s a special kind of pain when you’re frantically trying to fix a site you broke through poor planning and execution.

So, we do the most logical thing and abstract out all the system variables into a single point; either a config file or a database usually. For some reason we then go about our task feeling proud that we’ve stopped hard coding, oblivious to the fact that all we’ve done is just minimized the amount of hard coding. And that’s not enough.

According to WikiPedia hard coding

…refers to the software development practice of embedding input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

Now, while that explanation is appropriate for good old fashioned native development, to be sure, I don’t think it’s applicable to web development because for most sites the database is as much a part of the application as the code is (especially when doing maintenance work). By which I mean that, in my experience, storing environment values inside a database isn’t a good idea unless there’s no other way (sometimes a project requires the rules be broken).

Anywho, for most of us who don’t have the natural, innate, knowledge, learning not to hard code was a tough lesson because when we first started developing web sites it was natural to connect the idea of the web site with the code and server it was running on. Hell, I personally remember being shocked to find out it was actually bad to develop a site on the live/production server; just didn’t make sense at the time (stupid, I know). In hindsight it was an obviously silly and short sighted mindset to adopt but changing that was probably the most important choice I’ve made to improve the quality of my projects.

I was reminded of this with painful clarity when a whole slew of issues came up from a client I’m working with. During the course of transitioning dozens of their legacy sites to a new server, some of which hadn’t been updated since the projects were completed some years ago by coders long since forgotten, quite a few started having weird and, not a little insidious, bugs in the new environment. Looking deeper into the issues revealed a nasty amount of hard coding in not only the custom projects, which I would expect actually, but also from various third party commercial and open source projects that were used for the base of the sites.

Here’s an example of what I’m talking about in terms of your everyday configuration file hard coding along with an example of what I’ve learned to do:

<?php
//bad
$path = '/var/www/mysite.com/html/';
$url = 'http://www.mysite.com';
$cache = '/var/www/mysite.com/cache/';
 
//good
$path = $_SERVER['DOCUMENT_ROOT'];
$url = 'http://'.$_SERVER['HTTP_HOST'];
$cache = $url.'/../cache/';
?>

All thanks to the $_SERVER variable, in PHP (though most languages have some way to get that info), you shouldn’t have to ever hard code the paths to pretty much anything within your site. Note though that when executing PHP through CLI scripts or using the exec() function all bets are off (though there are ways to get around that too like using variations on __FILE__ and dirname()). And, yes, there are circumstances that demand hard coding, I know, but those cases are few and far between and usually have people capable of making those changes.

It was the third party programs that really annoyed me though. I find it a little easier to accept an individual inexperienced coder’s exuberance in coming up with a base solution at zero hour. I’ve been there; an issue comes up and the quickest, and less painful, solution is to just throw the path in place with a perosnal promise to come back later and make it elegant. Then… well, life takes over and the promise is forgotten. Happens all the time.

On the other hand though, when dealing with third party projects, both open source and commercial, this type of hard coding, well, that just bugs the crap out of me. It seems like such an obvious design decision yet Expression Engine, Zen Cart and WordPress (for example) all hard code environment variables into the configuration files.

This is especially irritating to me because it’s been my experience that most websites move to a different server at one time or another, so it’s a given that configuration is going to be changed at some point. Keeping the pain of moving the site to a minimum rates a higher priority to me. And, unless I’m missing something, it seems that there’s very little difference between having your installation/configuration script write $_SERVER['DOCUMENT_ROOT'] versus “/var/www/html” to a configuration file.

Something like (as a base example with no sanitization):

<?php
if($_POST['path'] == $_SERVER['DOCUMENT_ROOT'])
{
    $path = '$_SERVER[\'DOCUMENT_ROOT\']';
}
else
{
    $path = $_POST['path'];
}
 
//write it to the config file
?>

As I mentioned above there are definitely times when $_SERVER['DOCUMENT_ROOT'] isn’t appropriate per the requirements or spec but for most projects that I’ve worked with replacing hard paths with the variable has been effective 99% of the time.

Create Expression Engine Plugin

First though credit where it’s due: for this example I used the number_format plugin as a base so a lot of credit goes to Robert Wallis for the nicely written plugin I’m basically leaching from:)

An Expression Engine plugin is essentially a php class with at least one method that translates into an Expression Engine tag and used inside of Expression Engine templates (I don’t think they can be used inside of entries directly though I haven’t confirmed this). They are best left for small tasks though because they can’t have an administrative backend or integration with the Expression Engine l10n stuff or form processing or any manageable settings. No fun stuff for plugins…

Like most platforms there’s a few conventions that have to be followed but, also like most platforms, they aren’t too troublesome to work with. It should be noted that the syntax for the class uses the php4 syntax so dumb yourself down accordingly.

For example our plugin class will look like:

<?php
class Add_Slashes
{
	function Add_Slashes()
	{
 
        }
}

And the plugin will be executed with the below Expression Engine template tag:

{exp:add_slashes}O'Reilly{/exp:add_slashes}

Now, it’s possible to create template tags that aren’t done in pairs but for this example I’m going to stick with pairs. In case it wasn’t obvious, if you wanted to have a plugin that has more than a single method you would call that method like:

{exp:add_slashes:somethingelse}O'Reilly{/exp:add_slashes:somethingelse}

So that’s the basic syntax. The next thing that needs to be done is that a file has to be created inside the “/system/plugin/” folder. Note that I’m using the default name for that folder (system) so if you renamed it during the installation process use that instead. The file name must be lower case the same as the class name and it must have pi. as the prefix, and begin with the second segment of the tag. So, with our example plugin, the plugin name would be: pi.add_slashes.php. Simple enough. Once the file is saved to the location the plugin is installed. That’s how Expression Engine rolls.

Now we have a working plugin in theory but if you go into the plugin manager you’ll see an error about a missing variable as well as a distorted view of the page. We’re missing something; the $plugin_info array.

Every Expression Engine plugin should have a variable outside of the class called $plugin_info. For our example it should look like the below:

<?php
$plugin_info = array(
	'pi_name'        => 'Add Slashes',
	'pi_version'      => '1.0',
	'pi_author'       => 'Eric Lamb',
	'pi_author_url'  => 'http://blog.ericlamb.net/',
	'pi_description' => 'Exposes PHP\'s <a href="http://php.net/manual/en/function.addslashes.php">addslashes()</a> function via EE tags.',
	'pi_usage'        => Add_Slashes::usage()
);
?>

Obviously, the above lists all the details about the plugin for display in the plugin administration module:

Expression Engine Plugin Manager

You may have noticed the pi_usage key in the array; this method is recommended by the Expression Engine Developer Center for describing the usage of a plugin. Inside the plugin create a method called usage() and just return the instructions. Those instructions will be used on the plugin description page:

Expression Engine Plugin Information

Using all of the above the completed plugin is below:

<?php
$plugin_info = array(
	'pi_name'        => 'Add Slashes',
	'pi_version'      => '1.0',
	'pi_author'       => 'Eric Lamb',
	'pi_author_url'  => 'http://blog.ericlamb.net/',
	'pi_description' => 'Exposes PHP\'s <a href="http://php.net/manual/en/function.addslashes.php">addslashes()</a> function via EE tags.',
	'pi_usage'        => Add_Slashes::usage()
);
 
class Add_Slashes
{
	function Add_Slashes()
	{
		global $TMPL;
		$this->return_data = addslashes($TMPL->tagdata);
        } 
 
	function usage()
	{
		return "This is really just a wrapper for PHP's add_slashes function:
http://php.net/manual/en/function.addslashes.php
 
{exp:add_slashes}
O'Reilly
{/exp:add_slashes}
returns: O\'Reilly
 
";
	} 
 
}

Now, this example was used using Expression Engine 1.6.9 so the process might not work for the upcoming 2.0 (I haven’t looked into that version just yet). It also doesn’t look like EllisLabs is accepting any new submissions to their plugin library so if you’re hoping to distribute your plugin prepare to do it solo and without any help from them.

Still, an easy enough process that any custom functionality you may need for an Expression Engine site should be trivial to achieve.

hKit hResume

The way I saw it, with regular expressions I could only build a plugin that would only work with a single site; whereas with an hKit profile the plugin could, in theory, work with any hResume encoded site. So, clearly, an hKit profile was the best option.

The only problem was that there isn’t any documentation on how to actually create a profile for hKit. I don’t want to go into detail on it, and to be honest I don’t really remember all the details so suffice it to say that brute forcing this thing sucked. Donkey balls. It took forever and the steps needed to build a profile used a methodology I wasn’t familiar with. But, after a long night of tequila I did end up putting it all together though and it works pretty nicely.

First though, here’s how hKit works for pulling in a microformatted URL:

<?php 
include('hkit.class.php');
$hKit = new hKit;
$result = $hKit->getByURL('hcard', 'http://microformats.org/');
?>

Pretty obvious stuff; give it a URL, set the type of encoding expected (this time it’s hcard) and it gives back an array with all the goodies.

To work with the new profile you have to place the profile file in the same directory as hkit.class.php. You can download the profile along with the latest version of hKit here.

The concept is the same with the new profile:

<?php
include('hkit.class.php');
$h = new hKit;	
$url = 'http://www.linkedin.com/in/mithra62';
$h->tidy_mode = 'proxy'; // 'proxy', 'exec', 'php' or 'none'
$result = $h->getByURL('hresume', $url);
print_r($result, 1);
?>

The above will pull my hResume encoded info from my LinkedIn profile. Same as the original hcard example. Easy like your sister.

Now go forth and start parsing hresume encoded URLs

Avactis

For the uninitiated, Avactis is created and maintained by Pentasoft Corp; oddly, there’s no website for the parent company so take that for what you will. As mentioned, Avactis is based on a pay model though it’s way more upfront about it than PrestaCart and, while the free version is missing some features, the source is available for modifications. Not too bad in my opinion; at least the more cash strapped shops can still play if they want to.

The different versions of Avactis are Free, Owned ($199), Monthly Leased ($19.95 a month) and White Label ($299) each with their own features and options. Most notably the Free version doesn’t include any (useful) payment modules (Authorize.net anyone?), coupon module, data export and import, quantity discounts or search engine friendly URLs out of the box. They do offer discounts for web developers though (at least 50% and they say up to 100%), and the complete source is available without obfuscation, so at least those functions that are needed can be added which can really ease the pain of paying for the thing in my opinion.

As expected, Avactis has the ability for custom themes though I’m disappointed to see that there doesn’t appear to be any theme community in existence (compared to other cart software packages). The reasoning behind this is probably because Avactis bills itself as being “easy integration with an existing website thanks to unique Avactis tag technology”. And by unique they mean including a php file and calling php function snippets. I’m all for marketing hype but wtf is that?!? Here’s an example:

<?php include('init.php'); ?>
<?php NavigationBar(); ?>
<?php Breadcrumb(); ?>
<?php ProductList(); ?>

It’s called php and EVERY php site does this Avactis not just you. Essentially though, this isn’t a bad strategy and, in fact, is definitely a strength especially without all the hyperbole. Obviously, Avactis can stand alone and doesn’t need to be integrated into a separate site but it’s a good idea to allow easy integration into existing sites.

Avactis PHP shopping cart software

Avactis is packed with all the features any online store would want; content management system, coupon and discount mechanisms, order and customer management, packing slip builder to name a few. Each feature is also highly customizable and usually includes a plethora of options and settings; nice if you build complex product build outs or specific functionality. On the other hand though, this amount of features and customization comes at a cost in terms of ease of use, work flow and a lacking user friendly experience.

The administration interface for Avactis is a nightmare mess of pop-up windows, tabs and accordion widgets. Slick is not a word I would use to describe the experience. Functional or crappy or painful or eyebleedingworstinterfaceeverpleasekillmefortheloveofgod!; those are better words to describe it.

There’s inconsistencies all over the place; for example while editing a product the help widgets will open another pop-up window (sigh…) yet in the main menu hovering over a link will display a tool tip and in the installation process the help widgets are all inline divs.

Avactis Admin Popups

Going through the code yields such codesod qualifiers as the below:

<?php
    /**
     * Defines the possibility of uploading images by file type.
     *
     * @param $file The array consists of the $_FILES variable, for
     * the current file.
     * @return boolean
     */
    function isAllowedImageType($file)
    {
/*        $type = _ml_strtolower($file['type']);
        switch ($type)
        {
            case 'image/gif':
            case 'image/jpeg':
            case 'image/jpg':
            case 'image/jpe':
            case 'image/jfif':
            case 'image/pjpeg':
            case 'image/pjp':
            case 'image/png':
            case 'image/x-png':
                return true;
            default:
                return false;
        }
*/
        return true;
    }
?>

If that doesn’t make any sense to you suffice it to say that the above function is supposed to verify that an image’s mime type matches the list; unfortunately though, the function is, what we call “commented out” and will not be executed. All files sent to the function will validate as true so, essentially, any file type can be uploaded. While it’s entirely possible this is an old function that was replaced with something useful, and it should be noted that I never found any calls to that function (but I really didn’t look too hard), the fact that it’s still in the code-base speaks volumes, to me, about the project maintenance at the very least.

On top of that Avactis has one of the most wasteful and useless installation processes I’ve ever seen. Initially, Avactis ships with a very minimal file set that includes a 15 mega byte (MB) file whose sole purpose is to contain all additional files in a gzipped and base64 encoded string. The sole purpose of this is to allow Avactis to programmatically write all source files to the file system during installation. For the life of me I can’t imagine what functional requirement precipitated this design decision. Considering the complexity added to the development cycle this would cause it makes no sense to me; I’m at a loss. I could be missing something though; you never know it may have a really sick benefit that I’m just not privy to.

Are any of those “issues” at all relevant? Not the function and not the installation process. Those are subjective issues that may only matter to me; it’s armchair quarterbacking at it’s finest (if I do say so myself). For everything else, well, that obviously depends on the specific needs of the project. For my needs it’s a pass simply because my clients care about the interface and Avactis looks like it hasn’t been updated since 2002 (at least).

So, while Avactis is a nice program with all of the features any store would ever need I personally feel that it’s not ready for my project.

Wp-Click-Track 0.7.1

On Monday I got an email from Chris asking for some help with one of the WordPress plugins I wrote; wp-click-track. Chris was cool enough to let me post the message he received from Dreamhost:

Hello,

I’m writing you about your database “appmodo”, please write me back as soon as possible.  There seems to be a plugin you are running that is poorly coded (missing table joins) and this 1300+ second query that it is running is causing high server load spikes. If this plugin is not fixed, or disabled, and it causes server problems, we may need to disable the wp_tracking_clicks and wp_tracking_links tables.  You can write me at justin@dreamhost.com.

The problem queries:

# Query_time: 2181  Lock_time: 1115  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 1995  Lock_time: 924  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 1387  Lock_time: 309  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 2016  Lock_time: 930  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

Thanks!
Justin K

Justin did a nice job highlighting what the issue was; I didn’t join the tables together so it would take a really long time to complete the scans if there were a lot of rows in the tables. Another reason to always develop with large data sets; something I obviously didn’t do with wp-click-track.

Your application is useful and popular. Your users love it. Your users love you. But over the next week, something curious happens. As people use the application, it gets progressively slower and slower. Soon, the complaints start filtering in. Within a few weeks, the app is well-neigh unusable due to all the insufferable delays it subjects users to– and your users turn on you.

Anyway, there was no excuse for that; this was shoddy on my part. The only explanation I have is poor quality on my part.

This particular bug affected the line chart on the admin dashboard. Ever wonder why that particular graph took forever to load? Yup, that’s why.

What’s funny, to me at least, was that I had already fixed this particular issue; I just hadn’t released it yet. This particular bug was planned to be released with 0.8 but 0.8 is taking longer to complete than I initially thought it would. So the bug fix languished and sat there. Unreleased.

So yeah, wp-click-track 0.7.1. It’s a good release to get.

Expression Engine Escaping Madness

Expression Engine is built by the same company who put together pMachine, one of my favorite blogging software from back in the day, so I had some pretty high hopes for it. Then I started reading some off the cuff comments about Expression Engine, especially in comparison to my mortal enemy Dolphin CMS, and I started getting a little nervous. Then, when I started seeing how the flow worked, my head almost exploded.

See, all the style and creative stuff is stored in the database. Because Expression Engine has it’s own meta templating language (similar to Smarty in syntax and style; to me anyway) all the templates are available and ready for anyone to make modifications to. On top of that, Expression Engine allows for the inclusion of custom php inside of the stored template files which gets executed with the dreaded and evil “eval()” tag.

Confused? Me too. To help clear things up here’s a snippet of Expression Engine templating code:

{assign_variable:my_weblog="default_site"}
{assign_variable:my_template_group="site"}
{embed="global/header"}
Page Content Here.

It should be pretty obvious what the code above is doing, but because I get a lot of shit for not being verbose (I’m looking at you Reddit), here’s what’s happening:

1. A variable called “my_weblog” is being created with the variable “default_site”.
2. A variable called “my_template_group” is being created with the variable “site”.
3. The header template file is being included.

Not so bad right? I didn’t think so either but there’s also the inclusion of raw php. The below is perfectly valid to do in Expression Engine (assuming the “Allow PHP in Tempaltes” setting is enabled):

<?php
$my_weblog = 'default_site';
$my_template_group = 'site';
include 'global/header.php';
?>

The above is a translation of the Expression Engine code by the way (if you hadn’t picked up on that). This, too, isn’t bad per se, but it does break a few very important rules which I’ll get into in a moment. Annoying and sort of dangerous? Absolutely. But I can see where the appeal lies in allowing this sort of functionality (and, yes, even if you have to use eval() to do so).

That being said, my head almost exploded when I saw how the logic was laid out when mixing both the Expression Engine template tags with php functionality. Keep in mind that Expression Engine has a setting that allows you to set when in the processing flow you want the php to be executed. If that sounds confusing just know that in the below example the Expression Engine stuff is executed before the php code.

Here’s what I mean:

{exp:query sql="SELECT name FROM exp_freeform_entries WHERE entry_id = '1'"}
<?php 
$name = '{name}';
?>

The above simply grabs the name from the table and then sets it up for use by php. Once again, perfectly valid usage it would seem, though the more astute people will immediately see the issue.

Since Expression Engine executes the template tags first this is kind of a snap. The thing is though there’s no escaping going on there. The above will work great when the value of name is something like Eric or John but what if the value is “Eric O’Reily”?

Yeah; it’s gonna break with a parse error. But worst of all when it does break the error message you’re going to get is going to reference the call to eval() and not the actual template file. This is going to make debugging a bit of a bitch. On top of that, there’s no native method to escape anything within Expression Engine itself. So adding the usual call to addslashes() isn’t possible.

So, while Expression Engine is pretty snazzy and nice it isn’t without it’s pitfalls. Mind you, the escaping issue isn’t impossible to avoid; it’s more a question of design than anything. It is something that needs to be watched out for because, yeah, doesn’t seem there’s going to be a change anytime soon.

Zend Framework URL View Helper

The Zend Framework URL view helper is used to render a URL that follows the rules setup using the Zend Route module. This is nice because you can change the routes defined for your application and not have to worry about how your URLs are structured.

The basic syntax is below:

<?php 
$this->url(array $urlOptions = array(), $name = null, $reset = false, $encode = true);
?>

Using the above for a template below is an example of the usage and output:

<?php
//outputs /a/b/c/
echo $this->url(array('module' => 'a','controller'=>'b','action'=>'c'), null, FALSE); 
?>

As you can see the URL view helper outputs a simple URL to the module “a”, controller “b” and the action “c”.

Things get a little trickier when you want to pass along some variables though. By default the above example will append any existing variables, that are outside of the MVC paradigm, onto any new URLs created. For example, if the page url is the below:

/*
/a/b/c/foo/4/bar/yes
*/

And you call the below call to the URL view helper:

<?php
echo $this->url(array('module' => 'a2','controller'=>'b2','action'=>'c2'), null, FALSE); 
?>

You’ll get the below:

/*
/a2/b2/c2/foo/4/bar/yes
*/

When I first ran into this issue I was flummoxed. It was kind of a problem (to put it mildly). To get around this you have to set the “reset” value to TRUE. Doing so will keep any existing query variables out of your URL.

To add fresh variables to the URL view helper you use the below syntax:

<?php
//outputs /a2/b2/c2/bar/yes
echo $this->url(array('module' => 'a2','controller'=>'b2','action'=>'c2','bar'=>'yes'), null, TRUE); 
?>

That will, hopefully, keep you from making the same mistake and the subsequent head bashing that would be sure to ensue.

Remove Boonex Footer From Dolphin CMS

The issue was that the client’s site was now being tagged with a Powered By Boonex footer; not cool because the client had purchased a license and shouldn’t have the callout to Boonex. It looked like the site couldn’t reach the licensing server so it was acting like the site wasn’t a valid and licensed version.

I had set up the new server in a pretty locked down way, using a pretty paranoid strategy with firewalls and port changes and all that fun stuff. Unfortunately for my client, this included mod_security which Dolphin requires special configuration for:

If some security module is installed on the server (such as mod_security for Apache), it should be able to be disabled or set up for specific folders.

Not wanting to allow such a blatant security hole into my server following the above just wasn’t acceptable. Instead I decided to just remove the call to the licensing server in the code; it’s just php so I didn’t think it would be too difficult. It wasn’t but it was a little confusing though so here’s the code and process in case anyone else has the need.

BECAUSE I DON’T WANT TO GET SUED: only use this if you’ve already purchased a license. Blah, blah, blah. Oh, and this has only been tested in Dolphin 6.1.

1. First, open up “/inc/design.inc.php”
2. look for a HUGE base64 encoded line (one really long and one underneath is short). You’re going to need to remove both lines.
   It should be around line 500 and indented a few pages in. If you can’t find it search for “base64_decode” and it’ll come up.
3. Replace the both lines with the below:

$s813518='Y3JlYXRlX2Z1bmN0aW9u';$s534634='base64_decode';$s434741='YmFzZTY0X2RlY29kZQ==';$s865127='ZWNobw==';$s734874='Z2xvYmFsICRfcGFnZTsNCg0KJHM0MzUyMzYgPSBiYXNlNjRfZGVjb2RlKCAnWW1GelpUWTBYMlJsWTI5a1pRPT0nICk7DQokczU4OTM1NSA9ICdYMTlpYjI5dVpYaGZabTl2ZEdWeWMxOWYnOw0KJHM3NDM3NjUgPSAnWjJ4dlltRnNJQ1J6YVhSbE93MEtaMnh2WW1Gc0lDUjBiWEJzT3cwS0RRb2tjMFp2YjNSbGNuTWdQU0FuSnpzTkNtbG1JQ2huWlhSUVlYSmhiU2duWlc1aFlteGxYMlJ2YkhCb2FXNWZabTl2ZEdWeUp5a3BJSHNOQ2lBZ0lDQU5DaUFnSUNBa2MwRm1aa2xFSUQwZ2RISnBiU2huWlhSUVlYSmhiU2duWW05dmJtVjRRV1ptU1VRbktTazdEUW9nSUNBZ2FXWW9JSE4wY214bGJpZ2dKSE5CWm1aSlJDQXBJQ2tnSkhOQlptWkpSQ0F1UFNBbkxtaDBiV3duT3cwS0RRb2dJQ0FnYjJKZmMzUmhjblFvS1RzTkNnMEtJQ0FnSUNSelJtOXZkR1Z5Y3lBOUlDY25PdzBLZlEwS0RRcHlaWFIxY200Z0pITkdiMjkwWlhKek93PT0nOw0KJHM1ODYyODQgPSAnVkcxd2JFdGxlWE5TWlhCc1lXTmwnOw0KJHM5ODU0OTUgPSAnTDE5ZktGdGhMWHBCTFZvd0xUbGZMVjByS1Y5Zkx3PT0nOw0KJHM3ODI0ODYgPSAnYzNSeWNHOXonOw0KJHM5NTAzMDQgPSAnYzNSeVgzSmxjR3hoWTJVPSc7DQokczk0Mzk4NSA9ICdjSEpsWjE5eVpYQnNZV05sWDJOaGJHeGlZV05yJzsNCiRzNjc3NDM0ID0gJ1dXOTFJR2hoZG1VZ2JXRnVkV0ZzYkhrZ2NtVnRiM1psWkNBOFlTQm9jbVZtUFNKb2RIUndPaTh2ZDNkM0xtSnZiMjVsZUM1amIyMHZJajVDYjI5dVJYZzhMMkUrSUdadmIzUmxjbk1nZDJsMGFHOTFkQ0J3WVhscGJtY2dabTl5SUhSb1pTQnlhV2RvZENCMGJ5NGdVR3hsWVhObExDQm5ieUIwYnlBOFlTQm9jbVZtUFNKb2RIUndjem92TDNkM2R5NWliMjl1WlhndVkyOXRMM0JoZVcxbGJuUXVjR2h3UDNCeWIyUjFZM1E5Ukc5c2NHaHBiaUkrUW05dmJrVjRMbU52YlR3dllUNGdZVzVrSUc5eVpHVnlJSFJvWlNCaFpDQm1jbVZsSUd4cFkyVnVjMlZ6SUhSdklHSmxJR0ZpYkdVZ2RHOGdkWE5sSUhsdmRYSWdjMmwwWlNCM2FYUm9iM1YwSUR4aElHaHlaV1k5SW1oMGRIQTZMeTkzZDNjdVltOXZibVY0TG1OdmJTOGlQa0p2YjI1RmVEd3ZZVDRnWm05dmRHVnljeTRnVkdobGVTQjNhV3hzSUdKbElHRjFkRzl0WVhScFkyRnNiSGtnY21WdGIzWmxaQ0JoY3lCemIyOXVJR0Z6SUhsdmRTQnlaV2RwYzNSbGNpQjViM1Z5SUdGa0lHWnlaV1VnYkdsalpXNXpaWE11SUZCc1pXRnpaU3dnY0hWMElIUm9aU0E4WWo1ZlgySnZiMjVsZUY5bWIyOTBaWEp6WDE4OEwySStJR3RsZVNCaVlXTnJJR2x1ZEc4Z1JHOXNjR2hwYmlCMFpXMXdiR0YwWlM0PSc7DQokczU0NjY5MyA9ICdibUZ0WlY5cGJtUmxlQT09JzsNCg0KJHM1NDU2MjQgPSAkczQzNTIzNiggJHM1ODYyODQgKTsNCiRzNDM0NjQzID0gJHM0MzUyMzYoICRzOTg1NDk1ICk7DQokczkzNzU4NCA9ICRzNDM1MjM2KCAkczc4MjQ4NiApOw0KJHMwMjM5NTAgPSAkczQzNTIzNiggJHM5NTAzMDQgKTsNCiRzOTM3NTA0ID0gJHM0MzUyMzYoICRzOTQzOTg1ICk7DQokczM4NTk0MyA9ICRzNDM1MjM2KCAkczU0NjY5MyApOw0KDQokczk4NzU2MCA9ICRfcGFnZTsNCiRzOTQ2NTkwID0gZmFsc2U7DQokczg1OTM0OCA9IGFycmF5KCAyOSwgNDMsIDQ0LCA1OSwgNzksIDgwLCAxNTAgKTsNCg0KaWYoIGluX2FycmF5KCAkczk4NzU2MFskczM4NTk0M10sICRzODU5MzQ4ICkgb3IgJHM5Mzc1ODQoICRzNjUzOTg3LCAkczQzNTIzNiggJHM1ODkzNTUgKSApICE9PSAkczk0NjU5MCApIHsNCiAgICAkczY1Mzk4NyA9ICRzMDIzOTUwKCAkczQzNTIzNiggJHM1ODkzNTUgKSwgZXZhbCggJHM0MzUyMzYoJHM3NDM3NjUpICksICRzNjUzOTg3ICk7DQogICAgJHM2NTM5ODcgPSAkczkzNzUwNCggJHM0MzQ2NDMsICRzNTQ1NjI0LCAkczY1Mzk4NyApOw0KICAgIGVjaG8gJHM2NTM5ODc7DQp9IGVsc2UNCiAgICBlY2hvICRzOTg3NTYwWyRzMzg1OTQzXSAuICcgJyAuICRzNDM1MjM2KCAkczY3NzQzNCApOw==';
 
$s545674=$s534634( $s813518 );$s548866=$s534634( $s434741 );$s947586=$s534634( $s865127 );$$s947586=$s545674( '$s653987', $s548866( $s734874 )

Boonex uses base64 to encode and obfuscate the licensing code so it can’t be modified without a bare minimum of trouble. Not that they had much of an option; php is notoriously hard to encode with any elegance or reliability. Anyway, they chose base64.

All that was needed was to base64_decode the code, and then base64_decode that code (yup, they did it twice). After that I made the changes to remove the HTML that displays the Boonex footer, base64_encoded that, then did it again to create the above.

So, once again, only use the above code if you’ve already purchased a license. Yes, it should work if you didn’t but I don’t want to get sued so it has to be said.

The Horrors of C99.php

A Little History

See, back in the day some php developers were pretty stupid. (Admit it; you were stupid once too.) What other explanation could there be for writing code that allowed the injection of arbitrary routines into a program. Trivially easy too.

To be fair, PHP was to blame a little for this as well. Given PHP’s high adoption, and design, by, and for, newbie programmers allowing such a technique by default was just ill conceived, and maybe even a little negligent. I understand the desire, and sometime need, for a technique that could be dangerous but to enable the feature by default…. damn man…

So, the risk was known, yet code was still being written (like the below example) that allowed remote file inclusion to be possible. Mostly because of the aforementioned default setting.

<?php
$color = 'blue';
if (isset( $_GET['COLOR'] ) )
{
	$color = $_GET['COLOR'];
}
require( $color . '.php' );
?>

BTW, if you currently write code that does anything like the above, frankly, you’re an idiot. You aren’t nearly as smart and clever as you think you are. I promise you this will bite you. Bad too.

About C99.php

So, using a technique like the above opens you up to learning first hand about c99.php. Finding information about the program itself is a little tricky but there are a couple examples that highlight just how devastating it can be.

When malicious intruders compromise a web server, there’s an excellent chance a famous Russian PHP script, r57shell, will follow. The r57shell PHP script gives the intruder a number of capabilities, including, but not limited to: downloading files, uploading files, creating backdoors, setting up a spam relay, forging email, bouncing a connection to decrease the risk of being caught, and even taking control of SQL databases. All these functions become readily available through an easy to use web interface, but now you can fight back.

Using the above explanation, which I agree with, c99.php acts as an interface to control your server. Once it’s on your server an attacker has easy access to view all the files and their contents, make changes to the system, upload new files, manipulate the database(s) and more.

Quite the nasty little script but pretty elegant in how it’s implemented. c99 is a completely standalone script; even the images are embedded inside using base64!

Until a month ago I would have thought the risk of encountering c99.php in the wild would have been small these days. Then, SMACK!!, a client had a site get hacked (quick CYA; that I didn’t’ work on ) using c99. So be warned. It’s out there and if you’re not smart, or if you’re a lazy, lazy, coder, c99 will get you.