ixiter

Great!
I just updated the plugin and it works pretty good.
Thank you for your great work..

Update:
I disabled all plugins, uninstalled synchi and reinstalled it. Synchi was the only activated plugin. Still the same “bug”.

I switched to twenty-eleven and still the same problem.

Tested with
Ubuntu Chrome, FF
Win7 Chrome, IE9

This is really kinda strange.

Sorry for late reply.
Yes, I am using the latest plugin version.

Chrome/Ubuntu.
synchi 4.3

I found out that it works with a fresh WP. So it might be one of my other plugins.
I will try to find it out and keep you updated.

The local timezone offset is calculated wrong in the plugin, since WP overrides the systems offset. So in WP, date('Z') always returns 0.

We can fix it, without using a hard coded offset like you did in your example.

Do this …
EDIT FILE: /wp-content/plugins/facebook-import-comments/classes/FacebookCommentImporter.php

FIND (line 201): $timeOffsetToLocal = date('Z');

REPLACE WITH: $timeOffsetToLocal = timezone_offset_get(new DateTimeZone(get_option('timezone_string', 'UTC')), $createdDateTime);

Good that you found a way to increase the memory_limit.
I wasnt sure if you are able to change php.ini or are allowed to use ini_set in wp-config.php, since the .htaccess soluton didnt work. So I didnt mention these ways. Thanks for your update.

Internal Server Error 500 may occure, when this parameter is not allowed. But it shouldnt result in that mess after removing the line again.
I will try to find solutions for even less memory usage.

The error msg fpor the sitemap file doesnt say that much. I have no idea what could be wrong. The generated sitemaps do follow the guidelines.

File copying errors and problems have nothing to do with the plugin. I guess there are problems with your server or hosting provider.

The memory_limit is already 64MB ??
It seems, 64 MB isn’t enough for your blog. Try a value of 96MB or 128MB with jdingman’s solution.

As dicussed in my blog and explained in emails already, the error is not
produced by the plugin. It is the result of a missconfiguration in your blog. For some reason, your main URL is set as a WP page in your Blog.

The plugin creates a sitemap file “sitemap.xml” in the root folder of your Blog, whenever you publish, delete or edit a previous published article or page in your blog. Then it notifies Google, Yahoo, ASK and MSN about the new sitemap file. Usually the search engines read the new sitemap file within a few minutes or hours after notification.

Yes, all you need to do is installing and activating the plugin.
You can set some options in the plugin’s options page.

Oops … yea, my bad. Fixed it.
The 2nd thing .. how much you wanna show of the post. The first x characters, the first x words?
My code displays the first 250 chars. But this is just an example.
Its the quick an dirty way. All HTML tags are removed. If you have a link or an image in the first 250 chars, it will not be displayed.

<div class="featured">
<?php
global $wpdb;
$sql = 'SELECT ID,post_title, post_content FROM '.$wpdb->posts.' WHERE post_password="" AND post_status="publish" AND post_type="post" ORDER BY post_date_gmt DESC LIMIT 3';
$result = $wpdb->get_results($sql);
foreach($result as $row){
?>
<h2><a href="<?php echo get_permalink($row->ID);?>" rel="bookmark"><?php echo $row->post_title;?></a></h2>
<?php echo substr(strip_tags($row->post_content), 0, 250 );?>
<?php }?>
</div>

@dressedinvalue: I guess it shouldnt be restricted to category 1.

I would try this …

<div class="featured">
<?php
global $wpdb;
$sql = 'SELECT ID,post_title FROM '.$wpdb->posts.' WHERE post_password="" AND post_status="publish" AND post_type="post" ORDER BY post_modified_gmt DESC LIMIT 3';
$result = $wpdb->get_results($sql);
foreach($result as $row){
?>
<h2><a href="<?php echo get_permalink($row->ID)" rel="bookmark"><?php echo $row->post_title ?></a></h2>
<?php } ?>
</div>

I didn’t test this!
It should show the 3 most recent posts that aren’t password protected.
Maybe there is another way, than calling $wpdb directly.

Yea, got it. I will add this in one of the next updates.

Thank you manunkind.
What exactly do you mean with that option you want?
Is it about multipage articles and pages ?

erm .. sorry. Found it.

Well, I got the problem fixed, but still dont get, why it works.
I simply inserted a
header('Content-Type: text/plain; charset=' . get_option('blog_charset'));
right above the switch/case in wp-admin/admin-ajax.php.
When I insert it in case 'autosave', it doesnt work.
Its even more a miracle, since a text/xml header is set, immediately before the response is sent.
Plus .. it doesnt work, when I use tex/xml instead of text/plain in my patch.