hexalys

I shall add that in some cases the “X or more links will put a comment in moderation” settings does not stop spam comments from being approved as well. ??

• This reply was modified 7 years, 8 months ago by hexalys.

Same here. Intense Debate does not honor that WordPress settings.

I mostly bypass the saving mechanism of the plugin. Because I wanted this to work with the Regenerate Thumbnails plugin and my custom retina @2x implementation. Here is roughly how I am doing this now:

In my ‘wp_update_attachment_metadata’ filter, I intercept your AJAX request and save a ‘thumb_meta’ array in the ‘attachment_metadata’ like this:

if (!empty($_REQUEST['action']) && $_REQUEST['action'] === 'cptSaveThumbnail' && defined('DOING_AJAX')){
	$targetImg = json_decode(stripcslashes($_REQUEST['active_values']));
	$singleImg = count($targetImgData) === 1;//else it's a selection
	$selection = json_decode(stripcslashes($_REQUEST['selection']));
	$same_ratio = !empty($_REQUEST['same_ratio']);//TODO
	$ratio = number_format($targetImg[0]->ratio, 2, '.', '');
	$x = (int)$selection->x;
	$y = (int)$selection->y;
	$x2 = (int)$selection->x2;
	$y2 = (int)$selection->y2;
 	//custom 'thumb_meta' meta field with array of ratio sizes or names
	//Note that I use X and Y just for more perf/more-compact data
	$thumb_data = array('x' => $x, 'y' => $y, 'X' => $x2, 'Y' => $y2);
	if (!$same_ratio && $singleImg) //individual crop, go by name
		$data['thumb_meta'][$targetImg[0]->width.'x'.$targetImg[0]->height] = $thumb_data;
	else
		$data['thumb_meta'][$ratio] = $thumb_data;
}

Then for each ‘wp_generate_attachment_metadata’ wp core filter, I re-inject $data[‘thumb_meta’] from the saved wp_get_attachment_metadata. It’s necessaary because technically the attachment metadata is always completely regenerated, and only keeps the saved _wp_attachment_metadata[‘image_meta’] one as part of the initial base for attachment_metadata filters.

And finally I use the ‘image_resize_dimensions’ filter for the cropping with something along the lines of:

$meta_ratio = number_format($dest_w/($dest_h?$dest_h:1), 2, '.', '');
//match a ratio target with special crop-thumbnail
if (!empty($data['thumb_meta'][$meta_ratio])){
  $selection = $data['thumb_meta'][$meta_ratio];
  $src_w = $selection['X'] - $selection['x'];
  $src_h = $selection['Y'] - $selection['y'];
  $src_x = $selection['x'];
  $src_y = $selection['y'];
//override wp's cropping
return array(0, 0, (int)$src_x, (int)$src_y, (int)$dst_w, (int)$dst_h, (int)$src_w, (int)$src_h);
}

I think that the most ideal way to go… Eventually you could save the cropping data as a separate post-meta to make it easier. I initially felt it was better off injected in the same metadata. Admittedly, it’s a bit of a headache.

Let me know how you’d like to do it. So I can port my cropping data to the new meta field model you choose. Or change it right now to match your storage method. I haven’t used it that much yet. But I am about to heavily use it and I critically need the crop data saved for image regeneration use, for a current project.

Err no never-mind, ignore the above!

If you happen to be on a host with no secure connection for the admin,
just add those SSL constants in your config:

define(‘FORCE_SSL_LOGIN’, false);
define(‘FORCE_SSL_ADMIN’, false);
define(‘FORCE_SSL’, false);

That’ll takes care of the warnings. For those who may have this problem.

Yes, I like the idea of “the output always in a new tab”. However, the backtrace is not the most important data. One tab just for that may be a bit much… The reason I cancelled the redirect was to debug bad queries and POST data mainly. i.e. I needed a lot more info. Although useful, it wasn’t so much about the backtrace itself.

I would consider adding a minimal report of previous queries (with perhaps highlighted failed queries), and the previous post data submitted, put in that same tab too. Anything most pertinent about POST requests in a perhaps shorter more condensed view is good.

Technically, you can actually start gathered data to save in the db, early, by detecting a ‘POST’ REQUEST_METHOD ahead of time. Sadly almost all (non ajax) POST requests in WordPress seem to do redirects/rewrites (a real pain to debug). So I think having info about previous POST request, retroactively, is extremely useful. Thanks

The goal is to have a temporary debug view of POST requests. When you save a Post for example, like many form POSTs in wordpress, it will redirect to another GET request when finished, which prevents you from seeing what happened during the POST request (such as what was submitted, which queries were run etc…). It’s particularly useful to debug queries.

Nods @jbx, I personally managed to upgrade but figuring the drastic changes was a PITA.

Sadly, Niall now made it impossible to easily remove the “new” public_init filter/sequence and customize it, so I can’t really help with any easy solution.

For savvy phpers who need a hint… Now the only “wp like” solution one could think of is to remove the filters() used in Facebook_Loader::public_init(), then call the Facebook render functions for what you need, directly in your template…

In my case, since I don’t want the css bloat of any plugins, and because I now use my own custom javascript async loader, I opted for extending the current Facebook_Loader class with my own custom init process, taking advantage of the new oop structure for that. But I can’t go in details there.

voiceofbsl,

If fb_comments_automatic() is undefined; your plugin is likely not activated…
While the code I gave you should work for just displaying comments. It’s not a complete implementation… It seems like you probably shouldn’t try and do this without the adequate php/wordpress hooks knowledge.

My hint was directed at someone who can understand the fb_apply_filters() hooks in the fb-social-plugin.php. Without that, it’s a little too complicated for me to assist you with details.

voiceofbsl,

Sorry, I forgot to mention that $options is for get_option(‘fb_options’);

You can do this instead:
<?php if (comments_open() && isset($fb_ver) && ($fb_options = get_option(‘fb_options’)) && isset($fb_options[‘comments’][‘enabled’])) echo fb_comments_automatic(”); ?>

Though keep in mind that this will ignore the “Show on” post types selection which was later added with revisions 1.0.x.

And don’t forget you might also need to add the other filters manually in your functions.php, such as fb_hide_wp_comments or fb_get_comments_count, etc… which are normally called within the fb_apply_filters() function.

kletskater,

The “show_on” option is completely different so it will probably break for everybody.

For Matt, this is your issue: PHP Notice: Undefined index: show_on in /xxx/facebook/social-plugins/fb-comments.php on line 51

So people know, to make it work it requires to re-save the settings once.

Also Matt,

Every time one finds inefficient code like this. God kills a kitten!

require_once( dirname(__FILE__) . ‘/fb-activity-feed.php’);
require_once( dirname(__FILE__) . ‘/fb-recommendations.php’);
require_once( dirname(__FILE__) . ‘/fb-like.php’ );
require_once( dirname(__FILE__) . ‘/fb-send.php’ );
require_once( dirname(__FILE__) . ‘/fb-subscribe.php’ );
require_once( dirname(__FILE__) . ‘/fb-comments.php’ );
require_once( dirname(__FILE__) . ‘/fb-recommendations-bar.php’ );

An instead of:
if ( array_key_exists( ‘comments’, $options ) && array_key_exists( ‘enabled’, $options[‘comments’] ) && $options[‘comments’][‘enabled’] )
How about:
if ( isset($options[‘comments’][‘enabled’]) )

Needless to say:
array_key_exists( ‘enabled’, $options[‘comments’] )
is the the exact same thing as:
$options[‘comments’][‘enabled’]

Come one guys. This is utter redundant fail!

WordPress is already a bloated pile of repetitive code with its countless inefficient plugins. Let’s not keep piling needless junk code on top of it please.

That fb-social-plugin.php file alone could be twice as efficient and small, as it is now.

tckrockz,

To customize positions in your template without altering the plugin core; what you can do is disable Facebook plugin’s main init filter which automates the whole sequence, and custom manage each widgets/hooks in your theme.

Put remove_action( ‘init’, ‘fb_apply_filters’ ) in your theme’s functions.php, then apply each filters (or just echo each functions) individually in your templates.

For example, you can do:
<?php if (comments_open() && isset($fb_ver) && isset($options[‘comments’][‘enabled’])) echo fb_comments_automatic(”); ?>
to insert the comments where ever you like, instead of “in the_content() filter”.

You’ll find the list of functions and default filters in the fb-social-plugin.php file for reference.

That’s how I decided to deal with it, to have more flexibility, yet have the benefits of an untouched plugin, which can be updated safely. At least for minor versions.

Down the road, major plugin updates could affect your theme here and there, and/or require a few adjustments for new features. But at least, it prevents from having to touch the plugin at all, and still benefit of its overall functionality and fixes.

I hope it help others too.

The issues I am seeing so far:

Most importantly, the comment are injected everywhere, even if comments are disabled. A choice should be given to include them on pages or not, and if comments are disabled per page or posts, the comments should not be there. It’s really a pain to have to re-hook an official plugin like that… Granted even word-press handles this poorly with no option to remove all comments from pages, other that removing the code from the templates. But this one is a no-brainer.

Using add_filter( ‘the_content’) to inject the comments is quite odd… I don’t mind, but at least could you spread the priorities from say 20 to 30, instead of 30 for all of the hooks, so that we have flexibility with other filters in between.

I am seeing some iframe css issues with the layout. Notably, the recommendations bar iframe brings some unnecessary margin on top of the comments iframe, and forces the browser to redraw with some flickering there once the recommendations kicks in. I would love for the supposedly invisible iframes not to have any height or margin associated with them, messing with layouts.

Also I am not quite seeing what “including full SEO support” refers to. None of the Facebook comments can be seen by bots at the moment. Unless they are synced with WordPress comments. There is no SEO in play here. Perhaps a “planned” mention on this would be appropriate so there is no confusion. Thanks