PDA

View Full Version : Moving WordPress from a Proprietary CMS. Possible?



Harold Mansfield
07-31-2012, 01:19 PM
Every now and then I get this call, from someone who had a custom CMS built that has nothing to do with WordPress and is not compatible in anyway, and wants someone to "move it" to WordPress, like you would importing content from another site like a Blogger or Typepad.

Each and every time I tell them that it is not possible. That the website needs to be rebuilt on WordPress. That none of the coding will transfer and to build a script to make it import into WordPress will be more time and money than just rebuilding the site and it still won't work like a normal WordPress import script.

Am I wrong? Is there a way to take any random CMS and import it into WordPress correctly?
I don't see it. Does anyone have any ideas?

billbenson
07-31-2012, 06:01 PM
It's a programming issue. They both are going to have all the information in tables on a database. So yes it's possible, but unless you are a good programmer it would take to much time to be worth it for you IMO.

Harold Mansfield
07-31-2012, 06:17 PM
It's a programming issue. They both are going to have all the information in tables on a database. So yes it's possible, but unless you are a good programmer it would take to much time to be worth it for you IMO.

Could you do it?
And don't you think it would be quicker and cheaper to just rebuild it on what you want, than spend money developing a program to make it compatible?

billbenson
07-31-2012, 08:41 PM
Could you do it?
And don't you think it would be quicker and cheaper to just rebuild it on what you want, than spend money developing a program to make it compatible?

I could do it, but it would take a long time since I'm a wannabe programmer, not a real one. One of the things I've done for myself is create a database of my own that contains everything that is in the online database. In general you shouldn't have two databases with some or all of the same information. But it does make it much easier to change platforms.

The question is, how big is the customers custom site. If its been online for 10 years and say is an ecommerce site with thousands of customer contacts, product descriptions etc., you don't want to manually reenter all of that. If its a much smaller site, it may be easiest to reenter information manually. Kind of one of those "it depends" things.

vangogh
08-01-2012, 12:31 AM
I think it would depend on what needed to be moved. Presumably it's really the database that needs moving. The design and functionality is going to need to be redeveloped to work with WordPress. If the CMS in question is built with PHP then maybe some code could be reused.

With the database you'd have to see how things are stores on the CMS and where the data would go in WordPress and then write something that could take info from the CMS and place it in the right location in the WordPress database. It's possible some data wouldn't really have any place to go or some might not be necessary.

It could definitely be done. The question is it worth the price to convert things or would it make more sense to rebuild from scratch. That would depend on the CMS. It's definitely possible, but it may not be worth the cost.

Harold Mansfield
08-01-2012, 11:37 AM
They want to write a program that imports pretty much all settings, tags, taxonomies, pages, posts, categories, comments, users, and some "other stuff" which hasn't been defined.

I'm not a programmer, but I just don't see it and I honestly don't think it's the way to go at all. To me it's like building an awning between your house and your job, just so that you don't have to carry an umbrella when it rains.

It's much cheaper to buy 3 umbrellas and leave one in the house, the car and at the job. It's actually cheaper to buy a new umbrella every time it rains.

MyITGuy
08-01-2012, 01:12 PM
They want to write a program that imports pretty much all settings, tags, taxonomies, pages, posts, categories, comments, users, and some "other stuff" which hasn't been defined.

I'm not a programmer, but I just don't see it and I honestly don't think it's the way to go at all. To me it's like building an awning between your house and your job, just so that you don't have to carry an umbrella when it rains.

It's much cheaper to buy 3 umbrellas and leave one in the house, the car and at the job. It's actually cheaper to buy a new umbrella every time it rains.
I don't see much of a problem with importing the content/user information (Obviously not accounting for the "Other Stuff")...but granted I haven't worked with WordPress in that much detail. However the "settings" could vary between systems so this would need to be done manually.

If you want to provide a dump of the current DB I'd be happy to take a look at it during some downtime and provide some insight.

Personally I couldn't imagine this process taking more then 3-5 hours to develop, versus how many hours spent on manually recreating this information....

Harold Mansfield
08-01-2012, 01:24 PM
I don't see much of a problem with importing the content/user information (Obviously not accounting for the "Other Stuff")...but granted I haven't worked with WordPress in that much detail. However the "settings" could vary between systems so this would need to be done manually.

If you want to provide a dump of the current DB I'd be happy to take a look at it during some downtime and provide some insight.

Personally I couldn't imagine this process taking more then 3-5 hours to develop, versus how many hours spent on manually recreating this information....

I'll see if they can send something, and get it to you. And if it's something that you want to tackle, Ill put you 2 together.

vangogh
08-02-2012, 12:15 PM
One thing to note is that "other stuff" could cause some issues. There will be a place to store it in WordPress, though it might take some programming to be able to use the data on the site.

For example say the custom CMS allows you to build a recipe and has fields to enter an image and ingredients, etc. WordPress doesn't do that by default. It could be set up to handle a recipe, but you would need some custom programming in your theme. That kind of stuff could affect where Jeff puts the data initially so you may want to think through some things in advance.

Harold Mansfield
08-02-2012, 01:12 PM
It's always the "other stuff" that bothers me. History has taught me that when people are intentionally vague on ALL of the details, that are trying to pull a fast one and get something included that would normally increase the charges, or that they already know complicates the project.

billbenson
08-02-2012, 01:41 PM
One thing to note is that "other stuff" could cause some issues. There will be a place to store it in WordPress, though it might take some programming to be able to use the data on the site.

For example say the custom CMS allows you to build a recipe and has fields to enter an image and ingredients, etc. WordPress doesn't do that by default. It could be set up to handle a recipe, but you would need some custom programming in your theme. That kind of stuff could affect where Jeff puts the data initially so you may want to think through some things in advance.

The way I handle that Steve is extra tables and a separate admin for those functions. I suspect that's the way most plugin's work except they also integrate into the admin panel. I suspect that a lot of plugin's do alter wordpress db tables. If they do that, you are asking for trouble on the frequent updates that wordpress seems to have.

IMO there is a good web development niche for people that want functions that aren't native to Wordpress.

Harold Mansfield
08-02-2012, 01:49 PM
Adding functions to WordPress isn't incredibly difficult. Trying to make functions from some other software integrate and work on WordPress after the fact, is difficult.
It's like taking a Toyota and trying to make it Chevy compatible. Is it easier to replace and retool everything, or to just buy a Chevy?

MyITGuy
08-02-2012, 02:46 PM
One thing to note is that "other stuff" could cause some issues. There will be a place to store it in WordPress, though it might take some programming to be able to use the data on the site.

For example say the custom CMS allows you to build a recipe and has fields to enter an image and ingredients, etc. WordPress doesn't do that by default. It could be set up to handle a recipe, but you would need some custom programming in your theme. That kind of stuff could affect where Jeff puts the data initially so you may want to think through some things in advance.

Agreed...that's why I wanted to look at the database and compare it to the live site to see where data is being pulled from and where it could be placed and how difficult the process would be.

vangogh
08-02-2012, 11:57 PM
The way I handle that Steve is extra tables and a separate admin for those functions.

That's not necessarily a good way to do it. It depends on what and how much data you're adding of course, but in my recipe example WordPress isn't set up by default to take that data exactly as you want, but it can be easily made to. The WordPress database is set up so you can add data to it. It won't cause problems to then upgrade WordPress. The question is where in the database you want to store your data and I think it makes sense to first understand the data and how it will be used to best understand where it should go. Maybe the best solution is a custom table in the database, but there's a good chance there's probably a better location for the data.


that's why I wanted to look at the database and compare it to the live site to see where data is being pulled from and where it could be placed and how difficult the process would be.

I think that makes sense. Naturally none of us knows the specifics of what that "other stuff" is. I'll point again to my recipe example. WordPress lets you create what's custom_post_types. So you could create a recipe post type that accepts data specific to recipes. It's pretty simple to set up and would let admins or whoever add more recipes. Something like that might suggest placing the data in one location. A different use of the dat might suggest a different location.

Here's a page from the codex that talks about the default database setup (http://codex.wordpress.org/Database_Description). There's an image showing you all the tables and how each is related. Click the image a couple of times to get the large version. You'll notice there's a wp-options table that's not connected to anything. I think most plugins and themes will add data in that table. More full featured plugins like shopping carts will often create their own tables.

There are only 11 tables by default. A few are obvious what they're for given the name. The page I linked to goes into more detail about each table. The wp-options table is basically a place to add an option_name (varchar) and then an option_value (longtext). It's pretty generic which is why I think a lot gets added there.

billbenson
08-03-2012, 04:13 PM
That's not necessarily a good way to do it. It depends on what and how much data you're adding of course, but in my recipe example WordPress isn't set up by default to take that data exactly as you want, but it can be easily made to. The WordPress database is set up so you can add data to it. It won't cause problems to then upgrade WordPress. The question is where in the database you want to store your data and I think it makes sense to first understand the data and how it will be used to best understand where it should go. Maybe the best solution is a custom table in the database, but there's a good chance there's probably a better location for the data.


Certainly if you can use the table structure of WordPress that is the best way to do it. I was just referring to the case where a WP table is altered by adding another field to it. I had that happen with oscommerce in the past and it created a lot of problems.

vangogh
08-03-2012, 05:03 PM
Yeah, you wouldn't add new fields to the existing WordPress tables. If you need to do something like that you would be better off creating your own custom table. More than likely though the data that's going to be added can be placed into one of the existing tables. WP has the wp-options table just for that reason I think. It's often a catchall for data that doesn't have any place else to go, but doesn't need a custom table. If everyone added new tables, the database would quickly be overrun with a lot of inefficiency I suspect.