Running:

meteor

would get stuck on Download meteor-tool@3.0.38 which would eventually exit with a “killednloading” message.

For anyone else stuck scratching their heads, it seem to be an out of memory issue.

parse error: failed at &:extend(.clearfix all);

Since the required version is written explicitly in SailsJS package.json it’s not enough to just update your own project dependencies to the newer grunt/less versions (duh! took me a while before I realized that).

You do not have sufficient permissions to access this page error.

After a bit of searching it seemed it could be a corrupt db, so I reinstalled, but the same thing happened. Then I had a hunch, this was the first time I was trying to setup a custom table prefix. Sure enough changing the prefix back to just “wp” in the installation form fixed it.

WordPress: v3.2.1

Must be something messed up in the install script or somewhere refers to the default prefix where it should use the custom one.

When trying to setup the test database for my new rails app I kept getting stuck with this error message:

$ rake db:test:prepare

rake aborted!
Text file busy - db/test.sqlite3

Tasks: TOP => db:test:load => db:test:purge
(See full trace by running task with --trace)

Turns out the file was in use… If you have guard running in the background, that needs to be closed down while you run the rake test db commands.

Unfortunately it wouldn’t even install, giving the following error:

PHP Parse error:  syntax error, unexpected $end in 
/(...)/wp-content/plugins/social-counter-widget/scw_stats.class.php on line 73

A quick check revealed that it was a mistyped php open tag on line 70 that caused the problems. If you need to fix it before the plugin author submits an updated version just change “<?” to “<?php” on line 70 of the wp-content/plugins/social-counter-widget/scw_stats.class.php file.

Recently I was trying to get an installation updated as well as some of the plugins. What should have been a straightforward task, turned out to be several hours of messing around with permissions and trying to figure out why even 777 isn’t enough for the updates to NOT fail and what user should own what.

Well it turns out that it’s only partly the fault of WordPress as it is an issue with the FTP server. Still some better messaging would be helpful…

There were mentions about a patch and fixes in potentially in the 3.2 WP version related to the error I was getting:

Could not copy file.: /public_html/wp-admin/css/theme-editor.dev.css

However only after stumbling across this page I found an easy and quick solution.

Turns out it was enough to just switch from Pure-FTPD to Pro-FTPD.

While developing cross-subdomain authentication we suddenly realised that it didn’t work on Opera. After a bit of research it turns out that it’s not the setting of the cookie path (“.local.bnt”) that is the problem, but the way Opera checks which part of the domain name is the top level domain:

“Here at Opera we went for the rule-of-thumb method: When Opera is checking a cookie whose target domain matches certain criteriea (e.g. it is not a .com domain), we do a DNS name lookup for the target domain, to see if there is an IP address for that domain. If there is an IP address for the domain (e.g. example.no) we assume that the domain is a normal company domain, not a co.uk like domain, and therefore safe. If there is no IP address we assume that the domain is co.uk-like and therefore unsafe, and only allows the cookie to be set for the server that sent the cookie.”

So that’s the problem right there and with an easy fix once you know the above… However the whole article is worth a read as it does shed some light on the multiple problems related to top level domains and cookies.

If you want to keep your random local domain name make sure your hosts file contains not only your sub domains, but the main one as well even if it is not used directly.

127.0.0.1    www.local.bnt
127.0.0.1    local.bnt

With several people working on the same page while we were recreating some JS functionality from scratch I’ve noticed one of my buttons suddenly stopped working. Scratched my head a bit, and for a minute thought that maybe it’s not having a “return false;” in my jQuery live() event handler.

Turned out though that it was actually one of the other developers actually putting a “return false;” in their event handler that just happened to target the same element…

Ideally we needed to propagate the event through a variable number of events but prevent the default behaviour of a link kicking in. preventDefault() to the rescue!

$('#tag').live('click', function(event){
    (...)
    event.preventDefault();
});

Now, before blindly applying this piece of code I’d encourage everyone to first read up on why “return false;” is evil.

And for a quick reference here’s a table featured on a related StackOverflow question:

All you need is your own Db adapter and Queue class.

For the adapter you only need to overwrite the send() function. The highlighted code below is the only change to the original class (2 lines affected…). You could actually apply this without extending Zend_Queue, but this way will be easier if you ever need to update your Zend library.

<?php

class TS_Queue_Adapter_Db extends Zend_Queue_Adapter_Db {

    /**
     * Send a message to the queue
     *
     * @param  string     $message Message to send to the active queue
     * @param  Zend_Queue $queue
     * @param  Timestamp $timeout
     * @return Zend_Queue_Message
     * @throws Zend_Queue_Exception - database error
     */
    public function send($message, Zend_Queue $queue = null, $timeout = null){
        if ($this->_messageRow === null) {
            $this->_messageRow = $this->_messageTable->createRow();
        }

        if ($queue === null) {
            $queue = $this->_queue;
        }

        if (is_scalar($message)) {
            $message = (string) $message;
        }
        if (is_string($message)) {
            $message = trim($message);
        }

        if (!$this->isExists($queue->getName())) {
            require_once 'Zend/Queue/Exception.php';
            throw new Zend_Queue_Exception('Queue does not exist:' . $queue->getName());
        }

        $msg = clone $this->_messageRow;
        $msg->queue_id = $this->getQueueId($queue->getName());
        $msg->created = time();
        $msg->body = $message;
        $msg->md5 = md5($message);
        $msg->timeout = $timeout;

        try {
            $msg->save();
        } catch (Exception $e) {
            require_once 'Zend/Queue/Exception.php';
            throw new Zend_Queue_Exception($e->getMessage(), $e->getCode(), $e);
        }

        $options = array(
            'queue' => $queue,
            'data' => $msg->toArray(),
        );

        $classname = $queue->getMessageClass();
        if (!class_exists($classname)) {
            require_once 'Zend/Loader.php';
            Zend_Loader::loadClass($classname);
        }
        return new $classname($options);
    }
}

Your Queue class only needs to extend the send() function again to allow you to pass the timeout through. obviously you can use this class to add other functionality too.

<?php

class TS_Queue extends Zend_Queue {

	/**
	 * Send a message to the queue
	 *
	 * @param  mixed $message message
	 * @return Zend_Queue_Message
	 * @throws Zend_Queue_Exception
	 */
	public function send($message, $timeout = null){
		return $this->getAdapter()->send($message, null, $timeout);
	}
}