ergophobe
msg:4444496 | 3:04 am on Apr 24, 2012 (gmt 0) |
I've done things both ways, but I've never converted a large site. Depending on how granular the data is, it would be hard or easy (or you could hire someone to cut and paste if it's only a couple hundred pages or less).
Personally, I will never go back to custom-coded unless it's a truly custom application. You just get so much leverage from community-contributed add-ons and you get a nice headstart and can spend more time on creating and curating content.
Can't really be much help with respect to your specfics though.
|
jamie
msg:4446767 | 6:37 am on Apr 28, 2012 (gmt 0) |
thanks for the comments ergophobe, i especially like
"Personally, I will never go back to custom-coded unless it's a truly custom application"
my head spins thinking about the conversion though!
|
jamie
msg:4446769 | 6:44 am on Apr 28, 2012 (gmt 0) |
out of interest, which cms do you prefer?
|
ergophobe
msg:4446978 | 7:54 pm on Apr 28, 2012 (gmt 0) |
For a simple blog, I use Wordpress like everyone else.
For a more complex site, something with structured data and varied presentation, Drupal.
|
milosevic
msg:4458499 | 1:55 am on May 28, 2012 (gmt 0) |
I've done things like this several times.
Choose a CMS where you can import content from spreadsheets (e.g. Feeds module for Drupal).
Use a script to either extract content from the DB or scrape it from the site, whichever is easiest.
Format this for import (ie aggregate it into a .tsv spreadsheet)
Import the content into the new CMS.
I've also imported content manually via SQL statements (with an early version of Drupal 7) but it's a massive headache.
|
ergophobe
msg:4460683 | 5:01 am on Jun 2, 2012 (gmt 0) |
I'll second what milosevic said and just clarify that it tends to be a massive headache because you're bypassing any API the system has, so it's easy to get something slightly wrong - fail to update a particular table or something like that. It can be rough and usually takes some trial and error to get the SQL right.
|
|
