Update notification for a commercial plug-in

WordPress CMS has a nice auto update feature that displays update notifications for outdated plug-ins and themes in admin panel. Once you got a notification you can go to Dashboard->Updates and install all updates with few clicks while WordPress will automatically download and extract archives, remove old versions and reactivate plug-ins for you.

The only problem is  that it works for plug-ins published on wordpress.org which are open-source so it’s not an option for commercial plug-ins.

Luckily there is a very good solution to this problem: Upgrademe plug-in.

Users of most commercial Wordspress plug-ins suffer from painful manual update process which includes deactivation of the plug-in, deleting it, uploading new code and finally activating it. And obviously they do not get update notifications for commercial plug-in directly to their admin panels. This also applies to free plug-ins that aren’t hosted on wordpress.org for some reason.

Some commercial plug-ins have their own automatic update feature that shows notifications similar to notifications of WordPress auto-update system and some vendors provide their own auto-update plug-ins which are capable of updating their own products. Still their homemade code is limited and not so good and reliable as built-in WordPress update system.

I wish WordPress developers add a way to extend built-in update system with custom information sources but it seems they’re not willing to do so for some reasons.
Well, while there is no “official” way, some hacks are still available and Upgrademe plug-in just uses one of them (and I have to say it does it in a very smart way!).

Once installed on WordPress blog this little plug-in will hack into every WordPress request for fresh update information and add custom data gathered from other sources.  Nothing more! All the  job of displaying update notifications, downloading and installing updates is done by WordPress auto-update subsystem just like it does for any plug-in hosted on wordpress.org.

Enabling auto-updates in your commercial plug-in is extremely easy:

1. Add this small function to the end of your main plug-in file:

   function <plugin_name>_upgrademe()
   {
       return 'http://yoursite.com/latest-version.php';
   }
   

   • Replace <plugin_name> with your main plug-in name w/o extension.
   • Replace http://yoursite.com/latest-version.php with actual URL that will provide JSON data with lates version info. It could be simply static file that you update manually or a script that cooks that data dynamically.
2. Upload latest version script or static file to the URL provided by the function. See https://github.com/meglio/wp-upgrademe for more info on the JSON structure required.
3. Deliver your plug-in along with the Upgrademe plug-in to your users and ask them to install and activate Upgrademe plug-in to get automatic updates.

All natural: update notifications are coming from WordPress built-in update system

There are many benefits of using Upgrademe plug-in but there are also few problems that I believe will be fixed with further development of this great plug-in.

Pros

1. Reliable and forward compatible solution as it is based on usage of built-in WordPress auto-update subsystem.

2. Very small  modification to your plug-in code required.

3. One plug-in could serve update information for multiple plug-ins from various vendors.

Cons

1. Theme update not supported yet. While I see no problem in adding it. It just needs some research and development work.

2. If you install many update-enabled plug-ins on he same blog you may periodically notice a slowdown. It is caused by the Upgrademe plug-in calling all the latest version info URLs for those plug-ins. It would be better if this requests could be scattered over time.

3. You have to deliver Upgrademe plug-in to the end-user and make him/her activate it along with your plug-in.

How it works

Once everything is set up and there is new version available the user will see update notifications for your plug-in like those shown on images above. In fact, those notifications are produced by core WordPress code so if WordPress developers decide to change something in a way they are displayed, you have nothing to worry about.

To notify users about the update upload new version archive to your server and modify JSON version info accordingly. Note that WordPress caches version information for 12 hours so you’ll not see the notifications immediately.  For testing purposes you can delete ’_site_transient_update_plugins’ option from options table and refresh any page in WordPress admin. This will force WordPress to request update information.

Finally, when the users decides to update the plug-in, WordPress automatically downloads and installs it in the same way as it does for for plug-in hosted on wordpress.org:

As we wanted to avoid manual work as much as possible, we developed a small script that servers update info for all our plug-ins. The script takes plug-in name from URL query parameter and responds with version number it takes from filename of plug-in’s archive . So all we have to do now is uploading plug-in archives named  like <plug-in name>.<version>.zip to the server and that automatically fires update notification to end-users. That easy!

That’s it, with a help of Upgradme plug-in you can easily add great auto-update feature to your commercial WordPress plug-in.

Sad but true, except this little thing: Admintasia 2.1. Powered with jQuery and jQuery IU it has all the elements you need to build rich professional user interfaces.

Despite what the name says, it’s not intended for admin areas only but suits great for any kind of rich GUI application. This is likely the only design template of its kind available.
Take a look at some of screenshots:

I started with Admintasia 1.0 then upgraded to Admintasia 2.1. You can get a professional license just for $99.

Now I’m going to build an application skeleton by intrating it with Zend Framework and adding some usual things like login, email template engine and event logging.
Let me know if you’re interested.

This  is not corresponding to SQL standard but it’s already stated in MySQL manual:

Deviation from SQL standards: If ON UPDATE CASCADE or ON UPDATE SET NULL recurses to update the same table it has previously updated during the cascade, it acts like RESTRICT

It was also reported as a bug but rejected years ago.

There could be some complex workarounds for this problem but my solution is simply avoiding natural primary keys and using surrogate (auto increment) primary keys instead. Surrogate key values won’t change so you don’t have to care about ON UPDATE rules at all.

//This is supposed to enable element(s) before jQuery 1.6:
$("some-selector").attr("disabled", "");
//This is supposed to disable element(s) before jQuery 1.6:
$("some-selector").attr("disabled", "disabled");

But now the code above doesn’t change anything. So what’s the problem?

It’s caused by recent modifications to attr method which was used to set both attributes and properties. Since jQuery 1.6 attr method works for attributes only. As for properties like “disabled”, you have to use new prop method introduced in jQuery 1.6:

$("some-selector").prop("disabled", false); //Enables element(s) with jQuery 1.6.
$("some-selector").prop("disabled", true); //Disables element(s) with jQuery 1.6.

But what if you’re not sure about target jQuery version? Then you can check availability of prop method and use it if available:

if (typeof jQuery['prop'] === 'function') {
    // Use new prop method:
    $("some-selector").prop("disabled", false);
} else {
    // Use old-style code:
    $("some-selector").attr("disabled", "");
}

Similar solutions could be used for other properties previously assigned/accessed by jQuery attr method.

Right, even if you strongly pretend to write clean code, multiple dynamic attributes per HTML tag, variable styles or class sets usually result in total mess of HTML and PHP which is very hard to read. This usually happens with form elements or jQuery widgets that require a lot of data converted into HTML attributes, classes and styles.

And PHP “short tags” (<? ?>) do not really any help here, because they do not save you from PHP/HTML mixture which can easily hide hard-to-find mistakes. Putting each attribute on separate code line is also of little help.

How do you like this bit of code? Can you easily get an idea of it?

<li id="opc-<?php echo $_stepId ?>"
    class="section <?php echo !empty($_stepInfo['allow'])?'allow':'' ?>
    <?php echo !empty($_stepInfo['complete'])?'saved':'' ?>"
>

It was actually taken from default Magento templates so it’s relatively “clean”. Sometime inside WordPress you can find some worse, much messy code.

But if some code is more about generated content and data than about static HTML, why not to turn it into just clean PHP? Well, PHP frameworks like Zend Framework already contain view helpers for most common HTML elements like form fields and you can easily add your own. But adding a helper for each complex HTML element could be an overkill. What I constantly missed is something more generic which can just render me HTML tag with attributes specified as associative array. As I didn’t find it, I decided to write it on my own (see download link below) and called it Tag helper.

With the help of my Tag helper we can generate the same HTML as code above does, but using more structured code style:

echo $this->tag('li', '<', array(
    'id' => "opc-{$_stepId}",
    'class' => array(
        'section',
        !empty($_stepInfo['allow'])? 'allow' : NULL,
        !empty($_stepInfo['complete'])? 'saved' : NULL,
    ),
));

Yes, it’s a bit longer but now it’s quite easy to get an idea and check for errors.

The helper allows you to render full HTML tags with a single function call. It accepts attributes as name=>value associative array. It will skip FALSE or NULL attributes while converting TRUE values to attribute name. This helps deal with logical attributes following XHTML rules.
Class and style attributes can be arrays too and the helper will compose attribute values for you.

The helper also allows rendering opening, closing and self-closed tags. Just send ‘<’, ‘>’ or ‘<>’ string respectively to content parameter.

Here is an example of rendering some checkbox group from data array with Tag helper:

foreach ($items as $key=>$info) {
    echo $this->tag('div', '<', array(
        'id' => "{$key}-container",
    )) . "\n";
    echo "\t" . $this->tag('label', '<', array(
        'id' => "{$key}-label",
        'for' => $key,
        'style' => array(
            'color' => $info['color'],
            'text-decoration' => !$info['enabled']? 'line-through' : NULL,
        )
    ));
    echo $this->tag('input', '<>', array(
        'type' => 'checkbox',
        'name' => "item-{$key}",
        'id' => $key,
        'value' => $key,
        'checked' => $info['value'],
        'disabled' => !$info['enabled'],
    ));
    echo $info['label'];
    echo $this->tag('label', '>');
    echo $this->tag('div', '>');
}

And here is equal “traditional” PHP code:

<?php foreach ($items as $key=>$info): ?>
<div id="<?php echo $key;?>-container">
    <label id="<?php echo $key;?>-label" for="<?php echo $key; ?>">
        style="color: <?php echo $info['color']; ?>;<?php if(!$info['enabled']): ?> line-through<?php endif; ?>"
    >
        <input type="checkbox"
            name="item-<?php echo $key; ?>"
            id="<?php echo $key; ?>"
            value="<?php echo $key; ?>"
            <?php if($info['value']): ?>checked="checked"<?php endif; ?>
            <?php if(!$info['enabled']): ?>disabled="disabled"<?php endif; ?>
        />
        <?php echo $info['label']; ?>
    </label></div>
<?php endforeach; ?>

You can compare the samples above and decide which code is better to write and read, and more important: easy to extend. I don’t want to say that one have to use my helper everywhere HTML rendering is needed. I feel a bit like reinventing the wheel but it really saves me a lot of time when I deal with relatively complex logic beyond attributes, classes and styles.

Download helper code from here: Tag View Helper.
To use it with Zend Framework project(s) create Pumka/View/Helper folder tree inside your library folder and unpack Tag.php file to library/Pumka/View/Helper folder.
Add helper path in your Bootstrap.php (create _initViewSettings method if you don’t have it):

protected function _initViewSettings()
{
    $this->bootstrap('view');
    $view = $this->getResource('view');

    $view->addHelperPath('Pumka/View/Helper', 'Pumka_View_Helper');
}

If you do not use a framework, you are still able to use the helper class separately as it doesn’t really depend on any of Zend Framework components.

But what if you need to export web pages with JavaScript canvas elements like Flot charts that are plotted on browser side only? All available solutions require installing executables which is usually problematic on shared hosting.

The solution is PDFmyURL.com/ which you can easily use as a web-service: send GET requests with URL of the page you want to export and get PDF file as a response. The service is based wkhtmltopdf. As you can see, it’s good enough to convert pages with Flot charts:

http://pdfmyurl.com/?url=http://people.iola.dk/olau/flot/examples/basic.html.

You can call the service from JavaScript on your pages or from server-side scripts via any HTTP client library like cURL. All wkhtmltopdf options are supported and could be passed as GET request parameters.

Their free service inserts very small watermark to each page which is usually not a problem. But of course you can upgrade to paid service to remove it.

So if you want more correct result count, the extract it from regular Google search page. Alternatively you can use Yahoo or Bing APIs as they report the same numbers to displayed on their regular search pages.

UPDATE: It was found that regular Google search pages display even more rough estimated result count than Google AJAX Search API. For example, query for "pumka.net" (w/ quotes) it reports "About 1,380 results" while only finds 284 pages. Bing reports 55 results while finds 50-52 and Yahoo reports 210 results while finds 55. So using Bing or Yahoo API for analysis of result counts is likely more accurate.

Thank to Flot library, charting for the Web made extremely easy yet powerful and extensible. Flot is jQuery plug-in which means you can use all power of jQuery for setting it up, passing data to it and reacting to its events. Moreover, chart plotting happens on the browser side which means your server isn’t slowed down by producing chart pictures. And this also means you can add interactive features to your chart like point tooltips, zooming, live AJAX updates or display options applied w/o page reload.

Here are some examples of Flot charts with their code (see official examples page for more):

$(function () {
    var d1 = [];
    for (var i = 0; i < 14; i += 0.5)
        d1.push([i, Math.sin(i)]);

    var d2 = [[0, 3], [4, 8], [8, 5], [9, 13]];

    // a null signifies separate line segments
    var d3 = [[0, 12], [7, 12], null, [7, 2.5], [12, 2.5]];

    $.plot($("#placeholder"), [ d1, d2, d3 ]);
});

$(function () {
    var d1 = [];
    for (var i = 0; i < 14; i += 0.5)
        d1.push([i, Math.sin(i)]);

    var d2 = [[0, 3], [4, 8], [8, 5], [9, 13]];

    var d3 = [];
    for (var i = 0; i < 14; i += 0.5)
        d3.push([i, Math.cos(i)]);

    var d4 = [];
    for (var i = 0; i < 14; i += 0.1)
        d4.push([i, Math.sqrt(i * 10)]);

    var d5 = [];
    for (var i = 0; i < 14; i += 0.5)
        d5.push([i, Math.sqrt(i)]);

    var d6 = [];
    for (var i = 0; i < 14; i += 0.5 + Math.random())
        d6.push([i, Math.sqrt(2*i + Math.sin(i) + 5)]);

    $.plot($("#placeholder"), [
        {
            data: d1,
            lines: { show: true, fill: true }
        },
        {
            data: d2,
            bars: { show: true }
        },
        {
            data: d3,
            points: { show: true }
        },
        {
            data: d4,
            lines: { show: true }
        },
        {
            data: d5,
            lines: { show: true },
            points: { show: true }
        },
        {
            data: d6,
            lines: { show: true, steps: true }
        }
    ]);
});

$(function () {
    var sin = [], cos = [];
    for (var i = 0; i < 14; i += 0.5) {
        sin.push([i, Math.sin(i)]);
        cos.push([i, Math.cos(i)]);
    }

    var plot = $.plot($("#placeholder"),
           [ { data: sin, label: "sin(x)"}, { data: cos, label: "cos(x)" } ], {
               series: {
                   lines: { show: true },
                   points: { show: true }
               },
               grid: { hoverable: true, clickable: true },
               yaxis: { min: -1.2, max: 1.2 }
             });

    function showTooltip(x, y, contents) {
        $('<div id="tooltip">' + contents + '</div>').css( {
            position: 'absolute',
            display: 'none',
            top: y + 5,
            left: x + 5,
            border: '1px solid #fdd',
            padding: '2px',
            'background-color': '#fee',
            opacity: 0.80
        }).appendTo("body").fadeIn(200);
    }

    var previousPoint = null;
    $("#placeholder").bind("plothover", function (event, pos, item) {
        $("#x").text(pos.x.toFixed(2));
        $("#y").text(pos.y.toFixed(2));

        if ($("#enableTooltip:checked").length > 0) {
            if (item) {
                if (previousPoint != item.dataIndex) {
                    previousPoint = item.dataIndex;

                    $("#tooltip").remove();
                    var x = item.datapoint[0].toFixed(2),
                        y = item.datapoint[1].toFixed(2);

                    showTooltip(item.pageX, item.pageY,
                                item.series.label + " of " + x + " = " + y);
                }
            }
            else {
                $("#tooltip").remove();
                previousPoint = null;
            }
        }
    });

    $("#placeholder").bind("plotclick", function (event, pos, item) {
        if (item) {
            $("#clickdata").text("You clicked point " + item.dataIndex + " in " + item.series.label + ".");
            plot.highlight(item.series, item.datapoint);
        }
    });
});

Isn’t that code clean and simple, right?
As you can see, flot API is well structured. Chart settings could be easily cooked at server-side, say as PHP array(s) and then output to web page with json_encode function.

Last but not least, Flot library is extensible via powerful plug-in system, which I personally found better than digging into long manuals full of functions and properties, all doing not exactly what you need. Sometimes it’s better to write your own code than rely on features strictly defined by someone else. And Flot library already have many interesting and useful plug-ins you can use as is or modify as you want.

Flot library and its plug-ins are opensource and free for any use. Compare it to 4-digit prices of commercial libraries. Surprisingly, only one man stands behind development of Flot library core. Well done, Ole Laursen. Thank you!
This is yet another example of how little opensource “David” can beat huge commercial “Goliath”.

The problem already was reported on ZF issue tracker but wasn’t fixed: http://framework.zend.com/issues/browse/ZF-9265.
It seems that the cause is a bug in stream_copy_to_stream that was fixed at some point during PHP 5.2.x development.

But as we need to run our code on virtually any hosting we decided to work around this problem by replacing stream_copy_to_stream with fread and fwrite in Zend_Http_Client_Adapter_Socket code.
Notice that Zend_Http_Client_Adapter_Curl is not affected by this problem as it uses internal code for writing to streams. Thus, switching to Zend_Http_Client_Adapter_Curl sounds as the easiest solution. We added automatic switching to it by checking if ‘curl_init’ function exists and if so we use Zend_Http_Client_Adapter_Curl as the adapter for Zend_Http_Client.