gallery2/config.php

line 30 - @ini_set(’display_errors’, 1);
line 134 - $gallery->setDebug(’buffered’);

1st error:
Unknown column ‘g2_Item.g_renderer’

grep -r ‘renderer’ *

modules/core/classes/GalleryStorage/schema.tpl:

CREATE TABLE DB_TABLE_PREFIXItem(
…
DB_COLUMN_PREFIXownerId int(11) NOT NULL,
DB_COLUMN_PREFIXrenderer varchar(128),

ALTER TABLE g2_Item ADD g_renderer VARCHAR(128) NULL AFTER g_ownerId;

2nd error:
Unknown column ‘g2_Comment.g_author’

grep -r ‘PREFIXauthor’ *

modules/comment/classes/GalleryStorage/schema.tpl:

CREATE TABLE DB_TABLE_PREFIXComment(
…
DB_COLUMN_PREFIXdate int(11) NOT NULL,
DB_COLUMN_PREFIXauthor varchar(128),

ALTER TABLE g2_Comment ADD g_author VARCHAR(128) NULL AFTER g_date;

perhaps this may help someone else out there.

so, a query of the form:

SELECT a.id FROM alpha a, beta b
LEFT JOIN gamma g ON (g.id = a.gamma_id)
WHERE b.id = a.beta_id

would report error #1054 - Unknown column ‘a.gamma_id’ in ‘on clause’

whereas:

SELECT a.id FROM (alpha a, beta b)
LEFT JOIN gamma g ON (g.id = a.gamma_id)
WHERE b.id = a.beta_id

… would not.

in case you failed to detect the subtle difference between the two, it’s the inclusion of the now-apparently-very-important parentheses around the list of tables before the LEFT JOIN.

this ‘bug’ has been reported to mysql ab (even though they claim is not a bug).

here are the three most important classes of url’s to preserve:

1. category

MT — /archives/{category_name}
WP — /category/{category-name}

2. monthly archive

MT — /archives/{year}/{month}/
WP — /{year}/{month}/

3. post

MT — /archives/{year}/{month}/{slug}.html
WP — /{year}/{month}/{day}/{slug}/

you’ll note that none of the wordpress url’s contain the archives/ prefix. you can use this to your advantage in the url rewrite rule you’ll define in your .htaccess file.

RewriteRule ^archives/(.*) mt-wp.php?$1

in the above example, everything after archives/ in the incoming url will be passed to a php script called mt-wp.php which will do the work of determining which of the above three url classes it is, reformatting the url to the appropriate one used by wordpress, and either redirecting to that url or serving it up by proxy.

for [1] you will merely replace underscores with dashes. for [2] you will use the query string as-is. [3] is slightly trickier and is the reason why you’ll handle redirection (or proxy, using a socket connection or the cURL library) in a [insert language du jour here] script instead of a set of three RewriteRule’s.

movabletype’s post slugs are more brief than the ones wordpress generates, and, whereas movabletype does not include the full date of the post in its url, wordpress does.

unless you were in the habit of writing a slew of posts any given month with utterly similar headlines, it should be sufficient to use just the first two words from movabletype’s slug, in addition to the month and year, as keys to locating that post in your wordpress database. break up the slug portion of the url into words using the underscore as your delimiter, and concatenate the first two words together with a dash: word1_word2_word3 becomes word1-word2.

now, query:

SELECT guid FROM wp_1_posts
WHERE post_name LIKE ‘{word1}-{word2}%’
AND post_date LIKE ‘{year}-{month}%’

i find it wonderfully convenient, especially for the purposes of this exercise, that wordpress provides the full url to the post in the guid column.

*substitute wp_1_posts for the table containing the posts you’ve imported from movabletype.

if you’ve been following so far, generating code in your language of choice to do all of this should be a walk in the park. i leave it to you…

GIVE UP.

what a sordid history “your” browser has endured!
it is time you sent it off on an ice floe.

‘The proposed default behavior for version targeting in Internet Explorer solves the problem of “breaking the web” in much the same way that decapitation solves the problem of headaches.’

README

mysql_query(”SET character_set_client = utf8;”);
mysql_query(”SET character_set_results = utf8;”);

those two lines should go right after your mysql_connect() and mysql_select_db().

after several hours of trial-and-error i arrived at the above solution as if by magick. here’s hoping it helps someone else…

here’s a workaround: add a variable to the part of the url in the player code containing the location of the rss feed that will change, say, every minute or ever second; a timestamp.

so, for example if you have the blip.tv show player on your homepage displaying any videos on myshow.blip.tv containing the search term ‘otters’…

&file=http%3A%2F%2Fmyshow.blip.tv%2Frss%2Fflash%3Fsearch%3Dotters

you would add a timestamp:

%3Dotters%26ts%3D<?php print(date(”YmdHi”)); ?>

the above would ensure the show player is up-to-the-minute.

so why can you not serve a ‘plain vanilla’ cookie (only name or name and expires attributes provided) during a redirect and expect it to still be there afterward? security.

to quote the above rfc:

unverifiable transactions typically arise when a user agent… resolves redirection (3xx) responses from an origin server… when it makes an unverifiable transaction, a user agent must enable a session only if a cookie with a domain attribute D was sent or received in its origin transaction, such that the host name in the request-uri of the unverifiable transaction domain-matches D.

this restriction prevents a malicious service author from using unverifiable transactions to induce a user agent to start or continue a session with a server in a different domain.

so now you know. if you really want to construct your application such that cookies get served ‘between’ pages (i.e. upon completion of a script that processes a form and then redirects to an appopriate follow-up or confirmation page), you need to serve a fully-qualified cookie (domain included and most likely path also, e.g. ‘Set-Cookie; variable=…; domain=…; path=/; expires=…’).

and to think that for years i never knew this behavior was by design, and have implemented methods to ensure that my cookies always get served on the arrival page after any redirect — as you can imagine this method requires not-so-nice forwarding and later detection of data delivered in get or post variables; not to mention that the set-cookie headers themselves must be echoed before any content is delivered (lest ye see a “headers already sent” error).

for example,

header(”Set-Cookie: permanent=important; expires=Sun, 17-Jan-2037 23:59:59 GMT”);
header(”Set-Cookie: temporary=trivial”);

may not work as expected, whereas if you switch the two around, you’re good to go.

i wonder if rfc-2109 mentions anything about this…

p.s. yes, i do prefer netscape’s standard for set-cookie syntax.