Ett enkelt sätt att lösa detta vore att i alla ställen i den nya databasen där postid finns uppdatera kolumnen till att vara postid + <max postid i gamla databasen>. På så sätt får alla dina nya poster högre IDs än de gamla och det finns ingen risk för konflikt.

De två andra sätten som verkar passande utan specielltmycket kunskap vore:
- Tömma databasen. Importera den gamla. Lägga in det nya manuellt.
- Rensa alla postids lägre än det nu högsta postid i nya databasen. Det löser problemet med unika nycklarna, men givetvis förlorar du dessa poster från din gamla installation (de går ju dock att lägga in manuellt likt väl).

Gällande numeriska IDs håller jag inte med Conny. Medans stegning från värdet 1 garanterar konflikt så kommer många alternativ att riskera konflikt, vilket man kan vara omedveten av. Oavsett om man använder numeriska eller icke-numeriska IDs så finns det enkla sätt att skala det till både en ny server eller horisontellt. Skillnaden med auto increment är för mig snarare att man slipper seeda IDs själv. Behöver man skala ut det till unika IDs över flera noder behöver man uppenbarligen förändra det (men inte ersätta det), men 99,9% av alla webbprojekt kommer aldrig dit.

Detta tips tilltalade mig rejält. Jag har nu raderat alla posts i den gamla db med id upp till den högsta i nya db. Är det läge att testa då? Hur bör jag spara tabellen wp_posts från den gamla db innan jag importerar den till den nya db?

Gamla databasen: http://filipstad.ifolkmun.se/wp-cont...ads/old_db.gif

Spara backups av så mycket du kan. Före, Under & Efter. Blir det fel någonstans så blir det ordentligt fel. Såpass fel att du kanske inte kan logga in i WP.

Det du bör göra om du har möjlighet är att använda en annan databas i mysql. Det är snabbt och enkelt att byta i WP (wp-config.php - på ett ställe). Detta garanterar att du snabbt och enkelt kan byta tillbaka om något skulle gå fel samt även att du kan testa så att allting fungerar utan att riskera något.

Jag tänkte sätta upp en testsajt först och simulera. Sen tar jag givetvis en färsk backup.

Det borde gå bra med default-inställningar. Backup på båda sajterna, köra mot en ny kopia ifall något går fel vid importeringen samt att ha alla versioner online samtidigt för att snabbt kunna åtgärda det; så borde det inte kunna dyka upp några större problem.

Nu gjorde jag ett försök att importera tabellen wp_posts rakt av, och det gick ju inget vidare. Ska jag ta wp_posts meta först eller kan jag importera wp_posts så den ignorerar alla fel?

Så blev det:

SQL query:

-- -- Dumping data for table `wp_posts` -- INSERT INTO `wp_posts` (`ID`, `post_author`, `post_date`, `post_date_gmt`, `post_content`, `post_title`, `post_category`, `post_excerpt`, `post_status`, `comment_status`, `ping_status`, `post_password`, `post_name`, `to_ping`, `pinged`, `post_modified`, `post_modified_gmt`, `post_content_filtered`, `post_parent`, `guid`, `menu_order`, `post_type`, `post_mime_type`, `comment_count`) VALUES (1700, 20, '2007-10-01 22:43:17', '2007-10-01 20:43:17', 'Har idag kollat med lite folk inom kommun, vart statyn tog vägen som stod vid Konsum. ingen som hitills vet. I morgon börjar del 2, då jag ringer ett annat namn i ärendet. skulle vara kul å veta om den finns kvar, och vad vi kan göra med den?', 'Statyn som försvann - Vi letar - Del 1', 0, '', 'publish', 'open', 'open', '', 'statyn-som-forsvsann-del-1', '', '', '2007-10-01 22:45:11', '2007-10-01 20:45:11', '', 0, 'http://filipstad.ifolkmun.se/2007/10/01/statyn-som-forsvsann-del-1[...]

MySQL said:

#1054 - Unknown column 'post_category' in 'field list'

Är det samma WP version på den information du försöker lägga in och den du har?

Ja, jag uppgraderade den gamla till 2.8.4 (från 2.7) och den funkade i den - innan jag stängde ned den.