Relative vs. Absolute Paths: Which Way To Go?

A quick search for relative links and image references in my most volumous blog yields about 3000 hits. Switching them to absolute ones is one click away, but it’s no different the other way round: a simple search and replace for about 1700 hits of absolute paths. So which way should I go?

I don’t see myself moving domains in the foreseeable future, but for me relative paths do have the advantage of being shorter to write when making links and such by hand — that’s the reason for the (almost) 2:1 ratio of relative vs. absolute figures I mentioned. Therefore it’s likely I’ll keep using them even if I now switch the ones I’ve produced hitherto into absolute ones. So I’d have to do this change again at intervals, for all the new links.

But it’s the same if I went the other way: despite choosing to use relative paths I’d still occasionally pick up links local to my domain using copy and paste, resulting in absolute paths. Anyhow, I don’t think the occasional cleanup chore would be too troublesome either way to warrant not going through with unifying my policy at this point.

I probably would have gone relative already, if it didn’t hinder direct duplication of hypertext from one site to another. If you bring up the source code for what you see on a web page in order to copy it onto another as such, with links and all, you’ll find out it doesn’t work once the server changes. The relative paths have to be changed into absolute ones before it will.

I wouldn’t want my site to have that hindrance, because I find it highly annoying myself when duplicating material from places such as Wikipedia. From what I understand, they probably do this because it saves capacity on such a high-profile site. Yet others, worried for their material being exploited, do it for the precise purpose of obstructing the free flow of information.

I have neither of those concerns, so going absolute doesn’t pose problems — apart from being cumbersome to use, when crafting markup manually, as I usually like to do. So both ways have very strong arguments going for and against them.

I’d like to have a policy I could stick to, because having to stop and wonder about the practice used in each link I write irks me. From a practical point of view however, the mixed solution I’ve used in the past seems like the most natural and sensible one: to let the circumstances pick the practice in each case. Nevermind the ideal of adhering to a strict policy.

[Ratkaisu] Uuden välilehden avaaminen Ctrl + T -näppäinyhdistelmällä Tekstieditorissa

Olen käynnistänyt Tekstieditorin. Haluan avata uuden välilehden, joten painan Control + T -näppäinyhdistelmää.
Tekstieditori ei avaa uutta välilehteä.
Ongelman syy
Tekstieditorin vakionäppäinyhdistelmä uusien välilehtien avaamiseksi on Control + N, ei Control + T kuten esimerkiksi Firefox-selaimessa.
Otan Muokattavat valikoiden pikanäppäimet käyttöön, ja muutan Tekstieditorissa uusien välilehtien avaamiseen käytettävää näppäinyhdistelmää.

  1. Käynnistän Järjestelmä → Asetukset -valikosta Ulkoasu-sovelman.
  2. Ulkoasu-sovelmassa siirryn sen Käyttöliittymä-välilehdelle ja merkitsen siellä olevan Muokattavat valikoiden pikanäppäimet -kohdan käyttöönotetuksi.
  3. Suljen Ulkoasu-sovelman.
  4. Tekstieditorissa avaan Tiedosto-valikon, ja siirrän hiiren osoittimen valikossa olevan Uusi-kohdan päälle niin, että sen taustaväri muuttuu valittuna olemisen merkiksi.
  5. Uusi-kohdan ollessa edelleen valittuna painan näppäinyhdistelmää Control + T.

Tällöin Uusi-kohtaan liittyvä näppäinyhdistelmä muuttuu vakioyhdistelmä Control + N:stä haluamaani yhdistelmään Control + T, joten nyt voin käyttää näppäinyhdistelmää Control + T uuden välilehden avaamiseen.


Tämä ratkaisu ei ole yhteensopiva Sisennä rivit -liitännäisen kanssa, sillä Sisennä rivit käyttää Control + T -näppäinyhdistelmää. Mikäli ylläolevaa ratkaisua on käytetty, Sisennä rivit -liitännäisen näppäinyhdistelmä ei toimi, vaan sisennys sillä täytyy tehdä valitsemalla Tekstieditorin Muokkaa-valikossa oleva Sisennä-kohta.

A PHP Regular Expression To Look For Unterminated img Tags

After I had finally managed to craft this beast, I felt so proud that I just had to share it:


If I were to try and translate this into common language, it would perhaps go like this: after each occurrence of <img, skip all non-/ characters, and also all occurrences of / immediately followed by a > — up until the next occurrence of >. Unless you have a match at that point — a > without an immediately preceding / — move on to the next occurrence of <img.

And with each part of the expression in parenthesis, between quotation marks, following the corresponding translation: after each occurrence of <img, skip all (“*“) non-/ characters (“[^\/]“), and also (“|“) all occurrences of / immediately followed by a > (“\/(?!>)“) — up until the next occurrence of >. Unless you have a match at that point — a > without an immediately preceding / — move on to the next occurrence of <img.

The outermost parentheses (/(<img...)>/U) grab the contents of the unterminated <img> tag apart from the closing angle bracket, so that it’s easy to pair with a “ />” to properly terminate it. Other parentheses are for defining subpatterns.

Old news, but news to me: WordPress security key definitions in wp-config.php

While investigating an entirely separate issue with one of my WordPress installations, I came across this:

“Beginning with WordPress Version 2.6, three (3) security keys, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY, are used to insure better encryption of information stored in the user’s cookies. Beginning with Version 2.7 a fourth key, NONCE_KEY, was added to this group.

If you don’t find the keys in your wp-config.php file, add the keys definitions with reference to Editing wp-config.php – Security Keys, and upload to your server.”

Step 13: Add security key definitions to the wp-config.php file
WP Codex

Since most of my WordPress installations are pretty ancient, and upgrading them has long since become a routine job, this was the first time I heard about this feature. So my blogs have been lacking in this security feature, until now (I set up the aforementioned keys in each of my wp-config.php files).