Before getting into Importing, I would familiarize yourself with both the standard post type and post_meta as well as custom post types and taxonomies. If your end goal would benefit from the latter, you will save yourself quite a bit of headache utilizing them during the import preparation.
If you prefer working with the database directly, a dump/convert/import is always possible, of course. The schematic attached below would answer any questions you’d have there.
Another option, in the vein of the importer, would be to send posts from the old site to the wp-json api endpoints of the wordpress site and handle the migration that way.
As @Rarst mentioned, there isn’t really a shortcut, but as @Max noted in his comment the Importer can at least assist you in the process on the WordPress side.
The below just elaborates on and consolidates links for those points.
Using WordPress Importer ( Tools > Import )
There are a multitude of options, (and an even greater multitude of things to consider before using any of them), for importing content into wordpress. This would be the safest method to take.
You can familiarize yourself with many of them here: Importing Content into WordPress
Including:
- Blogger
- Drupal
- Excel Spreadsheet/CSV/XML/JSON
- Google Blog Converters
- Joomla
- LiveJournal
- Magento
- Mambo
- Movable Type
- Nucleus CMS
- Plone
- Posterous
- SPIP
- Tumblr
- TypePad
- etc, etc, you get the point
That pages also lists various plugins for importing an export of a previous cms (multiple types listed).
CSV, XML, RSS… any manner really. You will have to create the file it needs to process, of course.
Database Dump > Import
(Without knowing any info on the current DB), you could dump the old DBs pages content, and convert it into an sql import.
Don’t even consider this if you don’t really know what you’re doing, though. You could seriously muck things up. But a viable option if you’re comfortable with it.
I would not consider this a wordpress solution, just noting it as an approach.
Import Bridge with WP-JSON API
If you still have access to the old DB/site, you could utilize the wp-json api by writing something on your end that posts to the appropriate endpoint on the wordpress end for each entry in your old DB.
You may normally build this for keeping things in sync, but it could work as a one-time import tool as well.
Expanding on this in lieu of OP’s additional questions in comments:
First, you will want to bookmark this resource for dealing with the WP_REST_request class
Assuming we have written a bit of code on the old site that grabs the relevant content and puts it into a formatted POST object, and assuming a custom endpoint:
[Old Site Data ] POST http to route http://new-WP-site.com/wp-json/v2/plugin_namespace/v1/posts/
On the WP end, /plugin_namespace/v1/posts/ we would create. To make this happen, we first extend the WP_REST_Controller class.
Then inside our class we register our routes using register_rest_routes().
Something like:
public function __construct() {
add_action( 'rest_api_init', array($this, 'register_routes' ) );
}//end __construct
public function register_routes() {
$version = '1';
$namespace="plugin_namespace/v" . $version;
$base="posts";
register_rest_route( $namespace, "https://wordpress.stackexchange.com/". $base, array(
array(
'methods' => 'GET',
'callback' => array( $this, 'this_is_a_callback_function' ),
//'permission_callback' => array( $this, 'key_permissions_check' ),
),
array(
'methods' => 'POST',
'callback' => array( $this, 'this_is_a_callback_function' ),
//'permission_callback' => array( $this, 'key_permissions_check' ),
),)
);
}//register_routes
public function this_is_a_callback_function(WP_REST_Request $request) {
//if posted in body like form data
$posted_data = $request->get_body_params();
}
From this point $posted_data has what was POSTed, and you can walk through it, or pass it on to another function that does.
That function would need to build the post_array out of each entry, and pass that along to wp_insert_post()
An approach could be made utilizing WP_REST_Server::CREATABLE in place of methods => POST as well. Mine is just a quick/incomplete example.
Also I commented out the permissions_callbacks, but that callback function is where your authorization checks would normally go.
Note that wp_insert_post() will allow you to pass an array of meta as well, but wp_update_post will not. wp_insert_post also requires a title and content values. If you pass any ID other than 0, it will run wp_upate_post.
You may want to look at using something like requestb.in while sorting out your old site code to check what it is sending, and postman works quite well for checking the api’s response.
As I mentioned in the comments, ngrok could be used to do the non-wp to wp migration completely in a dev environment.
Hopefully that gives you enough info to translate it to whomever you need.
Relevant WP Tables (posts)
Whether building an sql import or writing some other bridge,
for posts, the tables to map to on the wordpress end of things would be:
Table Name : data in table
wp_posts : the posts
wp_postmeta : post meta values
wp_term_relationships : posts to taxonomies
wp_term_taxonomy : taxonomies
wp_terms : tag and category values
Here is the full database schematic
