The short answer is "use the get_shorturl_charset filter." The long answer is that, depending on the character, that filter is either the whole solution or just the start of one. Here's why, with the colon as the interesting case.

The easy case: the hyphen

YOURLS ships with a bundled core plugin for the hyphen, and it's trivial code: basically add - to the allowed character set.

So, a lot of people starting to build on this, to add any custom char. The thing is a bit more complicated.

Then someone asks for a colon

When YOURLS instantiates, amongst first things it evaluates the "request", ie the abc part in sho.rt/abc.

One of the handy bookmarklets YOURLS has is the "Prefix-n-Shorten" mechanism: just prepend your YOURLS URL to a long URL and shorten it on the fly. So the request can be a full URL, such as sho.rt/https://longurl.com/. When abc is a non ambiguous request, now having a colon becomes ambiguous because it looks like a URL:

The plugin to allow colon

Because everything funnels through yourls_get_protocol(), and because that function is filterable (it ends with yourls_apply_filter( 'get_protocol', ... )), one filter fixes the whole chain. The trick is to teach get_protocol to recognize our own keywords and refuse to treat their colon as a scheme.

The logic of the get_protocol filter, in plain English:

• No scheme detected? Leave it alone.
• The detected scheme contains a slash (http://)? That's a real URL, leave it alone.
• A bare scheme: with no slashes, and the entire candidate string is made only of charset characters? That's one of our keywords – return '' so the colon stops being read as a scheme.

Real URLs survive because they contain a /, a ., an @, or some other character outside the keyword charset, so they fail that last test and keep their protocol. The bookmarklet still works.

The colon plugin is available here if you want to drop it into user/plugins/ and go: Allow Colon in YOURLS short URL.

The one limitation

If you try to shorten a URL whose entire string fits inside the keyword charset plus the colon – think tel:123 or urn:isbn – the plugin will neutralize its scheme and treat it as a keyword. In practice this should not happen, as any realistic URL you'd shorten contains a /, or a . somewhere, which puts it safely outside the charset. But it's worth knowing it's there.

Bonus: which other characters will make tricky keywords?

A few chars will be reinterpreted somewhere down the pipeline starting at yourls-loader.php in the root: ?, + and / will be special cases to handle differently.

Some are modified, or destroyed by the browser, or at the HTTP layer before they reach YOURLS: #, spaces, \, %, so they should never be used at all in keywords.

(Put this in your .bashrc or something)

• It quickly opens Geany, or your default quick file editor, but PHPStorm is already running right there…
• Or the opposite: you just want a quick peak for a single little file, but it slowly cold starts your 4 GB IDE :x

What if your file manager just knew? That's the idea of the following bash script that acts as the default handler for .php files:

• PhpStorm is running? Open the file there, in the existing instance.
• PhpStorm is not running? Open in Geany – fast, lightweight, no wait for a quick glance.

The script

Drop this in ~/.local/bin/open-php:

Then chmod it +x. Also make sure obviously that your IDE and light editor binaries are in the path. To find the exact name of your IDE process, you can use pgrep -a -f [Pp]hp[Ss]torm for example.

The setup

Set open-php as the default application for .php files. Right-click any .php in your file manager, pick "Open With Other Application", point to ~/.local/bin/open-php, and set it as default.

Alternatively, at least if using Nemo (Linux Mint for instance), you can create ~/.local/share/applications/open-php.desktop with the following:

Replace YOUR_USERNAME with your own user name, then register it as the new handler:

From now on, double-clicking a PHP file does the right thing automatically. Heavy tooling when it's already warm, or the lightweight editor when it's not. Best of both worlds!

PostgreSQL support via plugin

PostgreSQL support comes as a drop-in plugin rather than a core feature: we like to keep YOURLS core light and let people add features only if they need it. This plugin intercepts database queries at runtime and translates MySQL to PostgreSQL syntax on the fly – backtick quoting, AUTO_INCREMENT ? SERIAL, RAND() ? RANDOM(), and so on. Obviously this is all transparent to the user and the application.

What will work, what won't

Everything core does, ie shortening URLs, tracking clicks, letting you add or edit short URLs, will work. The vast majority of existing YOURLS plugins will work. The drop-in plugin sits at the database layer and catches everything that flows through it.

To make sure everything core works perfectly, I've made sure YOURLS passes all its unit tests with the PostgreSQL plugin activated, under 3 latest versions of PostgreSQL and latest PHP. This will be easy to check with all future YOURLS releases.

The edge cases would be plugins that execute raw MySQL-flavored SQL directly, bypassing YOURLS' own database methods, won't be translated. I haven't encountered such plugin in the wild but if you have made custom query code, that would be something to fix.

Requirements

You'll need YOURLS 1.10.4, which is coming soon-ish or the current master branch (which is always stable and passing all unit tests). Drop in the plugin, configure your PostgreSQL DSN, and you're good to go. There is even a migration script to transfer everything from MySQL (or MariaDB) to PostgreSQL.

If you've been waiting for this – and I know some of you have been waiting for a long time – it's finally here :)

Your typical Be'Lakor song: enough parts and melodies to make 5 different songs, yet all united in one harmonious masterpiece. I *LOVE* Be'Lakor.

In the meantime, here are my slides (in French) :

Plain old downloadable PDF: WordPress Plugin Unit Tests, or Slideshare stuff below.

The demo plugin and all its tests are on Github: ozh/plugin-unit-test-demo.

WordPress 4.2 Roadmap Wish: update those ugly smilies that have not changed since, wait for it, EVER (for real)

— Ozh Richard (@ozh) December 19, 2014

In my opinion those smileys are super outdated (they haven't changed since the very beginning of WordPress which, in internet times, is the equivalent of Pleistocene) and they suck for three reasons:

• they're ugly. Did I already mention that? :)
• they're too old to live on retina screens
• it's very inefficient to load one image for each and every emoticon, as Julio points out

Over the years a few people have proposed alternatives for core but this is unlikely to happen, as very nicely summed up by WP Tavern. You can find several alternative as plugins, like New Smileys, but they're just another batch of images.

In the short discussion my tweet sparked, Greg pointed me to his way of doing it and I thought it was wonderful: 100% CSS, no image loaded, ideally tuned and adapted for his theme.

https://twitter.com/ScreenFeedFr/status/546148719092314113

A coffee break later*, here is a sample plugin that replaces your smilies with pure and simple HTML markup that you can then easily style: Ozh' CSS Smilies. Hooo those super annoying cute animated little ghosts!

The plugin is just meant to be a start for those who'll want to style their own smilies. Feel free to use and modify to match your theme!

* yeah right. I took me like 90 minutes just to get that half ugly CSS working :/

So, I made this simple banner template as a Photoshop PSD file. Nothing genius but feel free to use. No excuse not to add some fancy eye candy to your best plugins!