YOURLS 1.6 “Till Lindemann” released

I’m thrilled to announce the release of YOURLS 1.6 “Till Lindemann”

\m/ Rammstein \m/

YOURLS released are named after a (metal) music celebrity I like and I thought a non English singer would particularly suit the main feature of this release. If you’re not familiar yet, please meet Till Lindemann, charismatic leader and vocalist of the awesome Rammstein :)

مرحبا العالم! Hej verden! 你好世界! Kumusta mundo! Ciao mondo! Hello world!

The main feature of YOURLS 1.6 is that it’s now fully translatable. Yes! Si! Oui! You can now install and use YOURLS in the language of your choice! When the language of your choice is available, that is :) As of writing there are 6 languages but that list will grow as translators will raise their hand.

If you want to translate YOURLS in your dialect: this is easy. Refer to the wiki page YOURLS in your language.

Lots of cool stuff!

On top of speaking Polish and soon Mandarin, YOURLS 1.6 brings other cool features: the usual bugfix load, security improvements, the ability to define custom API actions and to shorten URLs with other common protocols than just http, like this one. By the way, if you are running a public YOURLS install, you will want to read this: on Public Shortening.

Another new thing you may have noticed is that YOURLS development now happens on Github. Long story short: I want to learn Git on a real scale project, I dig Git’s branching, and I’m curious to see if that will bring more contributions.

And speaking of which… I’m excited to announce that the YOURLS team is finally… a team! Let me introduce Léo, who has come up with nice patches, cool suggestions and fantastic ideas. With the help of Léo as a core committer, expect the development pace to raise from… real slow? to, err… somehow faster! :)

Update now!

Don’t wait a minute: get YOURLS 1.6 and update: delete all your files except your config.php and your /user directory — or simply overwrite, and you’re good to go!

Short URL to this post:

YOURLS 1.6 : translators wanted !

Change of plans for YOURLS 1.6. According to the RoadMap and previous posts here, the upcoming version 1.6 of YOURLS would introduce a new DB schema. But plans are made to be changed!


Localization has always been a long wanted feature for YOURLS (issue #58, opened more than 3 years ago in September 2009). It has always been planned, but low priority. Then, two things happened.

First, a couple month ago, I had to set up a YOURLS instance on a French corporate intranet. It immediately occured to me that the lack of translation API was going to make things a little more complicated than expected, given all the strings that were hardcoded in English. I always picture individual users such as myself not having a problem using simple software in English, but it’s a little different when you have to deal with a larger non-techie population.

Second, recently, @LeoColomb, a long time YOURLS user and prolific hacker, threw a patch in my face with the first draft of the translation API. Yep, in my face!

So, I decided to prioritize that feature. Over the last few days the committing pace has been unusually hectic and as of now, labelled 1.6-polyglot, YOURLS is ready to be fully translated.

Translators Wanted!

What does “ready for translation” mean exactly?

Instead of having hardcoded strings, such as echo "Woah awesome" and return "You are nice", YOURLS now uses the very common gettext functions, and you’ll see code like yourls_e( 'URL added' ) and return yourls__( 'You are nice' );. These functions search for the translated string in a translation file, if available, or otherwise return the original string.

More detailed documentation to help translators will be written later, but it’s a really straightforward simple process:

  1. Download YOURLS.pot, the translation file template
  2. Rename it to [your-locale].po, where [your-locale] is typically language code, underscore, country code (for instance in Portugal that would be pt_PT, while in Brazil it’d be pt_BR).
  3. Install a translation software: it’s nothing more than a text editor capable of reading .po files, showing you the untranslated string and a text box where you type in the translation, and saving a .mo file which is what PHP needs. A cross platform, simple yet complete editor is Poedit. There are also simple web based tools, such as PoEditor where you upload the .pot, translate, and download a .mo
  4. Once you have your fully translated pt_BR.po and the generated, host them somewhere (preferably on a source control enabled environment such as Github or Google Code to make contributions easier) and ping me! I’ll maintain a list of available translations.

To test your translation file as you create it :

  1. Download a nightly build or update via SVN
  2. Drop your pt_BR.po and files in user/languages
  3. Add define( 'YOURLS_LANG', 'pt_BR' ) to your config.php
  4. That’s it! Play with YOURLS

Translators, it’s important you join the party early: you’ll help us make sure the translation API works as smooth as expected, and win the “First YOURLS Translation Ever” award :)

What’s the Roadmap, then ?

On top of localization, which not everyone gets excited about, YOURLS 1.6 will bring the usual load of bugfixes and little enhancements. Better URL sorting and searching in the admin interface, more filters and actions to allow for more flexible and powerful plugins, a smarter API, better security and sanitization functions, plus more awesome and more w00t.

As usual, no ETA, but we’re speaking probably a couple weeks here. It really depends on the translator feedback.

Then it will be time to work on YOURLS 2.0 with the much awaited and needed DB structure change, and more goodness you’ll be able to handle. From a semantic versionning point of view, it just made sense anyway to give such a change its own major release number rather than a simple dot release.

There are even more news to share, but that’ll be another post :)

Short URL to this post:

It’s Alpha but it’s stable. For now!

As of writing, YOURLS version number says “1.6-alpha“. Despite boasting an intimidating “alpha” tag, it’s currently completely stable: I didn’t introduce yet any major change, especially in the DB structure, so feel really free to update today using SVN or with a nightly build. For the record, I’m using that version on and my personal, amongst others.

This said, expect some breakages in the future: I’ll slightly refactor the way action works, I’ll change a bit API returns, probably a few other things, and of course, there’ll be DB upgrading which is always the scary operation of all :)

After the stable version is released, there will be thorough documentation to help plugin authors update their code. No worries, that’ll be quick and simple.

When I’ll start implementing potentially breaker features, I’ll change the version number to something more frightening such as “1.6-alpha-dont-use“, so be sure to check it before you update on a live setup.

So, if you’ve always had ideas or thoughts for something crazy but not necessarily backward compatible, now might be a good time to suggest them :)

Short URL to this post:

Working on YOURLS 1.6 : the next DB structure

What’s up, gents? I’ve begun working on the next iteration and here’s what I’m up to.

YOURLS 1.5 : DB suckage

As everybody knows, the current database design in YOURLS is dumb and very inefficient. Its biggest flaw is that the keyword (ie short url) is repeated in both the URL and the LOG tables, making it absurdly difficult to update a short url without losing all historical data.

Another design decision I regret was to store stuff in case they would be useful to anyone, such as user agents in the log table. Since there’s no core feature using that info and I probably won’t implement any, this should not be there. There’s a plugin API for this.

There are a couple of awesome features I want to work on for YOURLS 1.6, one of them being the ability to store arbitrary data associated to any short URL — think url meta data, the way WordPress does it.

YOURLS 1.6 : previous thoughts

I’ve been pondering about the next DB schema for a very long time now, trying to think about the most state-of-the-art structure I could come up with (given my overall blatant lack of skill for DB things) and addressing all possible future features and current issues. I’ve proposed stuff and a few people have been kind enough to comment. But all this had one weakness : it was complicated and scaring me. Seriously :)

YOURLS 1.6 : smarter yet simple (at least I hope so)

I decided to make up my mind once for good and here is how I see things in YOURLS 1.6:

The main URL table will be properly normalized with a URL id to stop repeating the keyword across tables. I could probably go further in normalization (storing the long URL and title somewhere else, as I first thought) but that’s where I think it becomes too much trouble and hassle for too few benefits.

The URL_META table will store anything you’d like about a particular short URL and will be used by plugins: some tags, a note, a mime type to handle redirection differently, anything.

The LOG table will be trimmed down a bit, which — disk wise — should be beneficial to sites with lots of hits, and properly. Again here I could probably go further and normalize the referrer information, but what bothers me then is the number of DB queries needed for each short URL redirection, which I want to keep at a very minimum.

The LOG_META table, just as its meta sibling, will store anything you’ll want to store about a hit: the user agent, some cookie info, anything.

No big change in the OPTIONS table, just an autoload parameter so plugins will be able to store anything without loading that every time in RAM.

So, that’s it. If you have any thought or any “zomg dude don’t, terrible decision” warning to share, please do. We’ll see later for other DB novelties such as log archives or further optimization. I’d rather stop pondering and start coding :)

Short URL to this post:

Future Database Structure

Even though the 1.5 version is not ready yet, I also have in mind the next release, 1.6, which will introduce a much needed DB rethinking. Currently the DB schema is very weak and inefficient, making it difficult to introduce new features and having lots of redundant data. Another effect of the “never thought this project would get that big” syndrome.

What I have currently in mind is this schema:
DB schema v2

Comments welcome on the wiki page to keep things in one place.

Short URL to this post: