Trahald

It seems that posts made from the admin panel don’t have this problem, because the timestamp on them is 1 hour behind the real server time. Why is that?

Anybody know anything about this?

What does the wp_insert_post() $postarr ‘to_ping’ element do?

How does one interact with ping controls?

Is this so obscure that no one knows anything at all…? ??

From this thread, it seems this can be accomplished by adding the defining the following within a plugin:

function wp_new_user_notification($user_id, $plaintext_pass = '') {
}

Which then disable the wp_new_user_notification() function.

Does no one know anything about this?

Anyone have any insight on this issue?

Does anybody know what the ‘to_ping’ parameter is about?

I got this working, both remove_accents() and sanitize_title_with_dashes() work. All I had to do was set header(‘Content-Type: text/html; charset=utf-8’); in the display script.

Just to note, the difference between remove_accents() and sanitize_title_with_dashes() [other than adding the dashes of course] is that the latter sanitizes out all character other than %, alphanumeric, _ and -, and it also trims whitespace.

Well I ended up going with exec-php, and one of those minor little issues is the wpautop filter. I found that one should use the Disable wpauto plugin (https://www.ads-software.com/extend/plugins/disable-wpautop/) if embedding php code.

As well as disabling the WYSIWYG editor (Users->Your Profile), otherwise it’ll keep escaping your <?php ?> tags.

I get ‘Segmentation fault’ error. When I run it in interactive mode, I get ‘*** glibc detected *** double free or corruption (!prev): 0x09b7ff28 ***’

I am getting these errors too with a WordPress related cron job I’ve made (cron run like ‘* * * * * php /path/to/file’). The cron includes wp-config.php so that the script has access to $wpdb, but while the cron seems to run OK, the emails I get (due to MAILTO=… in the crontab) were containing ‘/bin/sh: line 1: 32682 Segmentation fault’ stuff (though that only happened a few times and I can’t repeat it), and now contain (repeatedly, every time):

‘*** glibc detected *** double free or corruption (!prev): 0x08493740 ***’

I was able to trace this to wp-settings.php and then to wp-includes/wp-db.php, and then to:

if ( ! isset($wpdb) )
	$wpdb = new wpdb(DB_USER, DB_PASSWORD, DB_NAME, DB_HOST);

If I delete this, the glibc error goes away. Of course then the script itself can’t work.

The error doesn’t happen if in the cron I use ‘wget domain.com/file’ instead of ‘php path/to/file’. So I’m using wget instead to run the cron.

I even tried changing DB_NAME to another database on the server, but that didn’t suppress the glic errors.

Anyone have any idea on this? Why would ‘wget [scripturl]’ have no errors but ‘php [scriptpath]’ does?

After dozens of hours of wasted effort, I finally figured out the problem. My WordPress was an upgrade, and so my wp-config.php was lacking the following:

define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);

Adding this fixed the problem. Such a ridiculous error, but I’m glad to have it solved ??

I’ve analyzed write_post(), wp_write_post(), wp_insert_post(), and even upgrade.php’s wp_install(), and still don’t see anything related to any sort of escaping or character encoding.

But the issue with wp_insert_post() also holds for wp_install() – if I install a blog via WP’s install.php whose title contains umlauts, the blog_title is set fine; but if I make a test script that utilizes wp_install() to create the blog, and pass the $weblog_title via GET instead of post or from some query to a temporary database table that contains the string, the blog title gets all messed up. Even though if I echo $weblog_title during this script, it comes out correct.

I also tried passing the title string with my own POST form, but even that didn’t work.

Is WordPress doing any sort of modification of the $_POST array or something? I see that in wp-settings.php, stripslashes_deep() and add_magic_quotes are being applied to $_POST, but I tried both applying this to my the $post_array I’m passing to wp_insert_post and that didn’t work, and also commenting out these lines from wp-settings didn’t break the Dashboard posting, that still worked anyway.

I’m just about at my wits end with this umlaut stuff (and also the trademark symbol). Does anyone know anything about this? I just don’t understand why these characters would work fine if input via WordPress’s default forms, but get all messed up if passed with a plugin or external script.

Note that I’m using WP 2.3.

I’m having a similar issue wih umlauts, and also some other special characters (like the TM trademark symbol). I think it has to do with the wp_insert_post() post function and escaping the data. I think editing the import script to use utf8_encode() to encode the post_content should allow the import to succeed, though the actual characters are still often messed up.

If anyone knows a true solution I’d love to hear it.