Page 1 of 1
1.0.2 -> 1.1-beta5 question?
Posted: Mon Oct 30, 2006 7:31 pm
by brentil
I just uploaded all the files for the 1.1-beta5 into my current 1.0.2 Serendipity installation. I'm used to most of all the other upgrades I've done over the last 2 years having upgrade steps as soon as I load the website the next time. I went to the website as soon as the files finished uploading and there were no prompts/etc to upgrade or update anything. The site says "Powered by Serendipity 1.1-beta5 and PHP 5.1.5" at the bottom, but I'm unsure if my install is properly upgraded or not. Running around the site everything seems to be working properly too.
Is this the common behavior of a 1.0.x to 1.1-beta upgrade?
Posted: Mon Oct 30, 2006 7:37 pm
by brentil
Just found my first error, so maybe it wasn't correct, or this is a beta bug.
I was making a new Category, clicked the "Image" button to go into the tool to add images to use for my media and got the following error.
Code: Select all
Select file to insert
Click the file you want to insert:
SELECT i.id, '' AS orderkey, i.name, i.extension, i.mime, i.size, i.dimensions_width, i.dimensions_height, i.date, i.thumbnail_name, i.authorid, i.path, i.hotlink, i.realname,
a.realname AS authorname
FROM serendipity_images AS i
LEFT OUTER JOIN serendipity_authors AS a
ON i.authorid = a.authorid
WHERE 1=1
GROUP BY i.id
ORDER BY i.date DESC LIMIT 0, 9
/ Unknown column 'i.realname' in 'field list'
Posted: Mon Oct 30, 2006 7:41 pm
by brentil
The "Media library" page throws the same error as above.
Using the add media page added the file but then throws an error.
Code: Select all
Adding image...
File brentil.gif successfully uploaded as /home/users/uploads/PostIcons/brentil.gif
Thumbnail created.
Done.
INSERT INTO serendipity_images ( name, extension, mime, size, dimensions_width, dimensions_height, thumbnail_name, date, authorid, path, realname ) VALUES ( 'brentil', 'gif', 'image/gif', 3447, 58, 68, 'serendipityThumb', 1162233559, 0, 'PostIcons/', 'brentil.gif' )
INSERT INTO serendipity_images (
name,
extension,
mime,
size,
dimensions_width,
dimensions_height,
thumbnail_name,
date,
authorid,
path,
realname
) VALUES (
'brentil',
'gif',
'image/gif',
3447,
58,
68,
'serendipityThumb',
1162233559,
0,
'PostIcons/',
'brentil.gif'
)
/ Unknown column 'realname' in 'field list'
Re: 1.0.2 -> 1.1-beta5 question?
Posted: Mon Oct 30, 2006 10:28 pm
by garvinhicking
Hi!
Maybe while you uploaded the files, you had a visitor on your page who triggered the update. Usually we recommend for high-traffic blogs a temporary .htaccess block like outlined here:
http://www.s9y.org/37.html#A3
However, don't despair.
Edit your serendipity_config_local.inc.php file and set versionInstalled to '1.0.2' and save that file, then go to your blog, and then you'll be able to run the missing upgrade routines again.
If you can't edit the mentioned file, have a look at the fixperm.php script mentioned in the FAQ.
HTH,
Garvin
Posted: Mon Oct 30, 2006 11:17 pm
by brentil
I'm so used to me being the only one who ever goes to my blog I didn't think that was going to be an issue. Looking at my logs though it looks like google decided to do an index of my site for the first time in 2 months.
Got it working now, thanks.

Posted: Wed Nov 01, 2006 11:09 am
by ads
I got the same error (i.realname column does not exist) using a PostgreSQL database as backend.
After some digging i found out, that the column is added in:
sql/db_update_1.1-alpha4_1.1-alpha5_postgres.sql
with the command:
ALTER TABLE {PREFIX}images ADD COLUMN realname varchar(255) not null default '';
But the commands should be:
BEGIN; -- even ddl changes can go into a transaction
ALTER TABLE {PREFIX}images ADD COLUMN realname varchar(255);
ALTER TABLE {PREFIX}images MODIFY COLUMN realname SET DEFAULT '';
-- make sure any column has the default value
UPDATE {PREFIX}images SET realname='' WHERE realname IS NULL;
ALTER TABLE {PREFIX}images MODIFY COLUMN realname SET NOT NULL;
COMMIT;
Kind regards
Posted: Thu Nov 02, 2006 12:34 pm
by garvinhicking
Hi ads!
Thanks for your updated syntax! I changed our SQL file accordingly to prevent this in the future.
Best regards,
Garvin