Manually import Theme Unit Test Data

Try to use this plugin and place .xml file into root directory.

Can you get access to you Mysql Database?

A best and easy way to import test-data.2011-01-17.xml is to install the plugin wordpress－importer.
So try to download it here

https://www.ads-software.com/extend/plugins/wordpress-importer/

and move it to your FTP dir wp-content/plugins/

Then you can import this test data into your Dev site.
—-
If you still need some manual way, you can try to install another WP site in your localhost and import data successfully, and then export the Mysql(.sql) backup, and import it to your Dev site’s Mysql DB.

Thanks for the pointers, ^C and (hz)i(hz)’ !

In an attempt to help people at the same point in the learning curve as me, below are some things I ended up doing in conjunction with the above issue, involving both WP and site administration.

The skinny: you can manually install the importer, and it will (fingers crossed) then do its thing locally on the .xml file without the need for file servers.

1. I *did* end up allowing ssh access, but using hzizh’ suggestion (also mentioned here) should work, right? The importer, it turns out, is “simply” another plug-in – though I haven’t attempted to uninstall and reinstall it manually.

Steps to allow ssh access
• On my server, I made a (non-admin) user account and installed the site docs in a sensible location within that user’s home directory. Ultimately, it is this user’s ssh login info I yielded to the WordPress file manager.
• On the WP-side, I enabled ssh as a “third way” to download, to avoid having to allow an ftp daemon on my site, by following this thread‘s advice.
• From the options listed under the WP META <dashboard>->Tools->Import, I chose the “WordPress” import type (as the test data is from WP), and ssh was now an option, along with ftp and sftp. The public/private key options are there if you want to be safe, but it isn’t essential in the just-make-it-work sense.

• I wrestled the mod/own monster. Choosing WP do do things for me means choosing to give them permission to do those things for me.

Steps to avoid those ‘Can’t Touch This’ file access errors
• I went in a non-777 direction. That was one fascinating thread, full of personality and the human condition, and relevant because permission conflicts are one of those give-and-take no-user’s lands of culpability that people running their own web hosts get to play both sides of.
• I gave my non-admin user ownership and +w privileges on the site directory, including all its contents and subfolders.
• I gave my web daemon group ownership and +w privileges for wp-contents/uploads and its subfolders.
• I did not edit .htaccess
• I did not give carte blanche 777 to any file or directory.

There are cons to the security choices I made above: WP now has access as a user to my particular site and as a web admin to different aspects of my server and any other sties’ upload areas should I make this a general policy, which would affect, well, just me at this time.

There are pros: assuming my site is otherwise secure and my WP plug-ins are beneficent, they can do some useful things now, and keep my site managed as WP expects it.

Thanks again for hosting this thread, WP, and to the users who are participating in it.

– QM

I’m happy you solve it,BTW, there is a default access of WP files 755 once you install a new WP site, so you needn’t change it to 777 unless some plugins requirement.

Hzizh, are you saying that the import plugin falls into that “needs write permissions” category of plugins? I did have to finagle the ownerships and mod privileges to schmoe:apache-group and 775 respectively. Is there a way to avoid that and still use the WP importer in particular?