Multiple Domain plugin for WordPress

For a few projects in the past, I had to find a way to make WordPress work with more than one domain. There are a couple plugins to do that, but they are outdated and/or don’t work well. So, I wrote this plugin.

Check this out: https://wordpress.org/plugins/multiple-domain/

Multiple Domain allows you having more than one domain in a single WordPress installation. This plugin doesn’t support more than one theme or advanced customizations for each domain. It’s only intended to enable constant navigation under many domains. For a more complex setup, there is WordPress Multisite (MU).

When there is more than one domain set in your host, all links and resources will point to the default domain. This is the default WordPress behavior. With Multiple Domain installed and properly configured, it’ll update all link on the fly. This way, the user navigation will be end-to-end under the same domain.

You can also set an optional base URL. If you want only a set of URL’s available under a given domain, you can use this restriction.

Photo credit: Roya Ann Miller

Passing Node args to Mocha tests

This is a real quick tip. I was looking around on the internet for a way to pass Node arguments when calling Mocha binary. And I couldn’t find anything useful. Then I tried the following and it worked:

$ test node --expose-gc ./node_modules/.bin/mocha [...]

The --expose-gc argument is just an example. You can pass any argument accepted by Node program.

In my specific case, I was trying to load dotenv config. In the end, the project’s MakeFile looked like:

test:
    @NODE_ENV=test node -r dotenv/config ./node_modules/.bin/mocha \
        --require should \
        --reporter spec \
        --harmony \
        --bail \
        tests

.PHONY: test

Photo credit: Matt Benson

Mixing HTTP and WebSocket routes in a Koa-based application

I’ve started to use the koa-websocket package. And it took me some time to figure out how to mix HTTP and WebSocket routes in a single Koa-based application. I’m not sure if this solution is obvious, but I’m sharing it anyway.

First of all, we’ll need two separate routers for regular HTTP and WebSocket routes:

// Creating a Koa app instance.
const app = require('koa')();
// "Websockifying" the application.
const socket = (require('koa-websocket'))(app);
// Loading router package
const router = require('koa-router');

// Here they are, our 2 routers
const http = router();
const ws = router();

Then, we can write our routes, plugging them to the specific router:

http.get('/', function *(next) {
    this.status = 200;
    this.body = 'Hello!';
});

ws.get('/socket', function *(next) {
    this.websocket.send('Hey!');
    this.websocket.on('message', function (message) {
        console.log(message);
    });
});

Finally, let’s make the app use the routers we created:

app.use(http.routes()).use(http.allowedMethods());
app.ws.use(ws.routes()).use(ws.allowedMethods());

Notice that the second router was added to app.ws instead of app directly.

And… That’s it.

Photo credit: Aron Van de Pol

SplFileObject is faster than fopen/fgets

I had some memory issues recently when reading a file line-by-line with PHP. So I found that SplFileObject is faster and uses less memory than fopen followed by a loop with fgets.

Here is a simple before & after code:

Before

$handle = fopen($path, 'r');
if ($handle) {
    while (($buffer = fgets($handle, 1024)) !== false) {
        // Do something with $buffer ...
    }
    if (!feof($handle)) {
        throw new Exception('Error: unexpected fgets() fail');
    }
    fclose($handle);
}

After

$file = new SplFileObject($path);
while (!$file->eof()) {
    $buffer = $file->current();
    // Do something with $buffer ...
    $file->next();
}

UPDATE
2015/09/08 09:13AM

Maybe you notice an incompatible result when comparing SplFileObject against fopen followed by fgets. So I recommend you to make some tests by your own. Distinctions in the server setup and PHP version are two things that can result different results.

Simple Gallery now as a jQuery plugin

One year ago I wrote a very simple image gallery script, based on jQuery. Now I updated it and completely rewrote it as a jQuery plugin. The code is available on GitHub: https://github.com/straube/simple-gallery

Photo credit: Jessica Ruscello

Regras de ouro para o trabalho remoto

Enquanto escrevo esse post, calculo que fazem mais ou menos 5 anos que eu trabalho remoto. Nesse tempo, tive uma passagem de 1 ano por um emprego in loco, mas nunca deixei de tocar as minhas empresas em paralelo, atendendo os clientes, planejando e executando tudo que fosse necessário.

Trabalhando de casa ou de espaços de coworking, aprendi na prática muita coisa sobre como se relacionar com os clientes e fornecedores, como planejar, acompanhar e executar projetos, e sobre como se virar quando tudo dá errado, ou chega perto disso. Com a minha recente mudança para os Estados Unidos, trabalhar remoto ganhou um significado muito mais importante, porque se antes eu podia ir visitar o cliente ou dar um jeito de passar um dia ou dois por perto dele, essa alternativa não existe mais.

Somando tudo isso, achei que seria útil escrever um texto com algumas dicas de trabalho remoto, mas aí encontrei esse artigo do Diego Eis, no Tableless, e ele já falou tudo aqui, então aproveitem:
6 dicas para se dar bem em freelas e trabalhos remotos

Propel ModelCriteria : leftJoin + useQuery

Ao usar os métodos leftJoin e useQuery de uma ModelCriteria (classe Query), sinalize o tipo de JOIN no useQuery:

// ...
->leftJoinFoo()
->useFooQuery(null, \Criteria::LEFT_JOIN)
// ...
->endUse()
// ...