musicmann

From what I understand, the “csv” prefix is for standard built-in WP fields. When this plugin encounters a column header that doesn’t begin with “csv” it assumes it’s a custom field and adds it as such.

Therefore, the column heading needs to be the meta key for the custom field.

There’s no standard prefix for the meta key as different plugins use different prefixes to avoid conflicts. For example, Yoast SEO uses “_yoast_wpseo_” as their prefix. Custom fields created by the Types plugin have “wpcf-” as their prefix.

There are a couple of ways to determine the correct meta key:
1. Go to an entry (post, page, CPT) that has a value for the custom field that you want. Make sure the Screen Options has “Custom Fields” checked. See if there is a listing of Custom Fields Name (this is the meta key) and Value.

2. Look for the value in the postmeta table of your database. This usually involves going into your webhosting account and using something like PHPMyAdmin to view the database directly.

My first thought would be that a “special” character (such as non-English character, an accented character) might be breaking the import.

I don’t see that in Mohammad’s example above, though.

Still, I would suggest trying to encode the file in UTF-8 by opening it with a text editor that can save to that encoding (Notepad on Windows), and see if that helps.

I know I’m replying to old posts, and you guys have probably figured out a way to achieve what you were trying to do, but I want to point out a couple of things:

1. The plugin still works like a champ. I’m still using 0.3.7 on the newest versions of WP. I know there is 0.3.8 out there now, but I was hesitant to use it since it just showed up out of the blue.

2. @mburtis, I notice you’re mentioning headings like “wpv-post-title, wpv-post-post, wpv-post-excerpt”. I don’t think these are gonna work with this plugin. For the standard WP fields, these should be “csv_post_title, csv_post_post, csv_post_excerpt”. Looking at my import files, these don’t change even if you are using a CPT.

You’ll also need to specify what you’re trying to import such as a post, a page, a CPT, etc using “csv_post_type”.

Your custom fields may have any types of prefix and separator (- or _) depending on what plugin you use to generate them. You should be able to see them by looking at one of your CPT entries or by looking at the postmeta table in your database.

If you’re still trying to get this to work, I would suggest skipping the custom categories at first as they can be troublesome with the trouble shooting. Try just csv_post_type and csv_post_title first to see if you can get those two fields to work, and build up from there.

If you’re using Windows, you can try the fix that I’ve mentioned a couple times before to see if it’s what’s also causing your issue.

I’ve copied and pasted it below:
On a Windows machine, what I do is re-open the CSV file in Notepad and do a Save As. In the dialog box, I change it from ANSI to UTF-8. Then special characters can be imported.

On a Windows machine, what I do is re-open the CSV file in Notepad and do a Save As. In the dialog box, I change it from ANSI to UTF-8. Then special characters can be imported.

I’m creating CSV files with Excel, and I’ve seen this issue importing content with Spanish special characters.

The work around that I’m using (since I can’t get Excel to save to UTF-8) is to open the CSV file in good ol’ Notepad (on Windows) and do a Save As. In the dialog box, you can switch from ANSI to UTF-8, and special characters are no longer an issue.

Category Name: Use csv_post_categories as the column heading

Category Description: I assume that’s not possible. In version 0.3.7, author lists “Add support for category descriptions” in the TODO file.

What solved it for you? I have the same thing going on after a site restore. I’ve disabled everything (and tried a few other ideas) with no luck.

Thanks. I hard-coded it in sociable_output.php. Looks great in IE and Firefox, but in Chrome, the Tweet, Like, and +1 boxes are not wrapping to the 2nd line.

That worked!

[Edit: Deleted to avoid confusion by anyone reading this in the future]

I’m currently set on es_ES. I haven’t tried anything other than sorting titles. Let me know if you want me to do other test cases to make sure other sorts continue to occur as planned.

I REALLY appreciate the help!

I tried es_ES.utf8 (which matches my encoding according to wp-config.php), and it’s giving me the original sorting (ad, av, a?).

I’m wondering if this is an issue with my host’s hardware/OS. I use BlueHost. I could try it out on another host that I have a hosting account for to see if I get something different.

Tubal, I couldn’t find a private message option, so I’ll reply here. I tried the changes. Here are my findings:

• When I specify a correct Spanish locale, the ascending sort is (a?, ad, av). Different, but not what I expected. This is what the site is currently showing.
  Ex. sort_query_posts_by('title', 'asc','es_ES');
  Ex. sort_query_posts_by('title', 'asc','spanish');
• When I specify English or an undefined locale, I get the original sorting. That is (ad, av, a?).
  Ex. sort_query_posts_by('title', 'asc','en_EN');
  Ex. sort_query_posts_by('title', 'asc','nonsense');
• When I don’t specify a locale, I get the WordPress sorting.
  Ex. sort_query_posts_by('title', 'asc','');
  Ex. sort_query_posts_by('title', 'asc');

I’m seeing the same issue as well.