TR.Martin

It’s a diving catch at the warning track! the crowd goes wild!!!

Thank you Hostgator for the investigation and communicating the results, I was not expecting a response here, but it’s very much appreciated.

To bring this issue full circle I’m closing it.

Happy holidays everyone.
TR. Martin

Way ahead of you,
already reinstalled, just waiting to see if I get another nasty-gram.

yea I saw the sourceforge comments in the file and followed the trail trying to get some sense of the library’s history and it seemed legit to me.

When I say Hostgator inoculated the file I mean they flat out deleted it from the plug-in directory. I didn’t even get a chance to do a compare or anything, a little upsetting.

Since the library is popular I’m willing to bet someone somewhere misused it or something and it got caught up in the security net and wound up on a bad list somewhere.{speculation]

I couldn’t get Hostgator to give any specific details about the concrete security risk, so at this point I’m just keeping an eye on it.

I hope this isn’t a omen of the future, or a refactoring of the file might be necessary to avoid problems in the future. ugh….

Ooops sorry about that.. I thought I had set the topic state to resolved. I’ll get it this time.

Sayontan,
Thanks for the quick response. I did some more digging and found there’s an album sort option in the flickr album itself and it’s not obvious. I can manage the sort order using that option on the flickr side.

Just for future reference if someone is trying to the change the sort order of a photoset/album, they need to go to Flickr and set the ‘arrange by’ in the album organizr at the top of the album page.

Once again a great plug-in and thanks for the help.

Cheers,
Todd Martin

Well Drat…
Did some more investigating and it seems this issue is more complex than I originally thought. If an admin has permalinks enabled all the links with “?attachment_id=815” get a redirect(301) to “the pretty URL’ which from what I can tell is the attachment page instead of the actual media link.(not a 100% sure on that, been too busy to give this the time for a root cause analysis, but I’m pretty sure)

since this is not a functional issue I’ll go a head and close it..

However if you’re looking for an enhancement items it would be nice to have an option to choose whether the post gets populated with the attachment link as from wp_get_attachment_url() or the attachment page from get_attachment_link()

It would be a nice to have, just for a slight performance improvement (no more 301 redirects) and some future proofing in case Google Analytics changes and starts dinging website for the 301s.

Cheers and Thanks,
Todd Martin

P.S. love the plug-in

There that looks much better..

My fix/hack was nothing elaborate.. I disabled the CRP cache so the intermittent apply_filters() would be executed.
then added this simple routine to my functions.php file.

/* Make sure the results provided by the Contextual related Posts(CRP) plug-in are honoring the quarantine time.
 * if a post is choosen by CRP check it's ID and if it's still in quarantine, remove it from display */
if ( function_exists( 'get_crp' ) ) :
function contextual_related_ID_filter($data){
	$x=0;						// index for array received from CRP.
	$roles = array('editor','author','administrator','realtimesubscriber');

	/* first check user role if they have rights no need to filter the CRP results */
	if(is_user_logged_in()){											// if user is logged in ?
		if(check_user_role($roles))										// then check their granted roles.
			return $data;												// if user allowed show show next link
	}

	/*public user we need to filter the results*/
	foreach($data as $i){
		if(is_quarantine($i->ID)){
			unset($data[$x]);
		}
		$x++;
	}
	return $data;
}
add_filter('get_crp_posts_id','contextual_related_ID_filter');
endif;

With cache disabled and hooking ‘get_crp_posts_id’ it works well enough. if I find an ID match for a post in quarantine I just remove it from the list. So my list of related posts can be decreased, which is good enough since it’s some what ephemeral, (I know I’m operating outside the norm) I also didn’t want to interfere with the actual relation ship mathematics schema, I felt it was a lighter touch to just hold back a post at rendering time. its a small price to pay.

I hadn’t thought of the cron job solution, that’s interesting. I’ll need to tinker with that to see how well it works.

thanks for the help
Todd Martin

I will be the first to admit my use case model is definitely out there in the corner , but here’s the situation. My website is a traveling/sailing website and I’m catering to two very different users: ‘public’ (aka anyone on the internet) and ‘private’ (friends and family).

As a security precaution (and management efficiency) I created a quarantine period for all my posts once they are published. This allows the ‘private’ users to see things in real-time but the ‘public’ visitors get the information delayed by the predetermined quarantine period (currently a week). If there are any internet bad guys out there thinking they can track me in real time and possibly try to rob me or the boat they’ll always be a few steps behind.

To accomplish this I’m hooking all the publication points (eg. WordPress core, yoast sitemap, Social media auto-poster, etc) and verify the post is either out of the quarantine period or the user is logged in and trusted.

On your plugin you’re hooking the publish event where the post would definitely be in quarantine but the published results can be displayed either during the quarantine period or after it has elapsed or a trusted visitor is viewing the page and that’s where I run afoul with the caching scheme.

So you can see my particular setup is time dependent and not the normal use case model everyone is use too. I hope this helps..

Cheers & Thanks
Todd

Thanks for the quick reply,

For right now it’s easier for me to disable the caching and hook the get_cpr_posts_id. I’ll look into hooking the Get_crp my site is pretty small so I’m not overly concerned with the performance hit.

Meanwhile I’ll go ahead and close out this question as resolved..

Cheers & Thanks
Todd Martin

This broke me as well. A configuration setting would be great!

thanks
Todd Martin

I have this exact same problem if there’s a [caption][/caption] short code in the first 300 characters of the post the text from the caption is included in the %excerpt%, all the excerpt keywords behave this way. I traced it down to the function nxs_doQTrans() in nxs_functions.php there’s a line of code #555
‘$txt = preg_replace(‘/\[caption[\s]{0,}(.*?)\][\s]{0,}(<a[\s]{0,}.*?<\/a>)[\s]{0,}(.*?)\[\/caption\]/ims’, ‘<p $1> $2 <snap class=”wpimgcaption”>$3</snap> </p>’, $txt); // WP Image with Caption fix
‘
by translating the [caption] shortcode to something ‘strip_shortcodes()’ cant match, this work around/fix, is purposefully adding the caption text to the excerpts..

My question is, “Adding the shortcode [caption] text to the excerpt the way it’s supposed to work or is it supposed to remove the [caption] text?”

Thanks,
Todd Martin

Did some more debugging: none of the other %xxxEXCRPT% fixed the problem and it looks like Twitter is the only media site that does not handle HTML escape codes properly, I think it’s expecting everything to be in UTF-8 characters.

For now I’ve hacked up nsFormatMessage() with a call
‘$msg = htmlspecialchars_decode($msg, ENT_QUOTES);’
right before the return. This seems to have solved the Twitter problem for 90% of the characters. There are cases where htmlspecialchars_decode() will not fix everything such as someone encoding a quote with " instead of "

While not optimal I’m going to go ahead and mark this issue resolved. If you find some free time it would great to have an official solution from you guys so I don’t have merge code when there’s an update.

Thanks for the help, much appreciated.
Todd Martin

Boo-Yah!!
Installed the new version (1.46) and tested it.
Everything is working perfectly, marking this issue as “resolved”

Thank you very much!
Todd Martin