grapepress

My workaround for now has been to add the class block-lite-bg-dark the <header> and #nav-bar in the header.php file. This works for the time being, but basically forces the text to always be white for all pages.

Addendum: My friend is trying out different Featured Images for some of the above pages, so some of the above examples will no longer illustrate the problem.

If you do $related = Jetpack_RelatedPosts::init() instead of $related = Jetpack_RelatedPosts::init_raw() then you’ll get access to all of the RelatedPosts data that is stored (including img data, if any). The only downside is if there are filters or other effects to the regular data that you’re wanting to circumvent (in which case then Raw is the best way to go).

I recommend going the init() route because Jetpack has already done the work of trying to find an image to use for each post (eg, such as when there is not a Featured Image defined).

Yeah, I’ll be curious to hear if Mike has interest in integrating this.

@topkai probably is asking for Google’s recently improved reCaptcha service to be integrated into Fast Secure Contact Form. The newest version (of reCaptcha) only uses a captcha when necessary, so it is a lot easier and faster for users that Google’s algorithm thinks are not robots.
https://thehackernews.com/2014/12/Google-reCAPTCHA-code-in-PHP.html
https://developers.google.com/recaptcha/

This might be related to the following Github Issue, so I’d recommend you have a look at that, and if it seems like the same issue post what you’re observing there.
https://github.com/Automattic/jetpack/issues/124

Edit: Nevermind. Just saw that you posted there already (https://github.com/Automattic/jetpack/issues/1072). ??

I did some more digging, and it looks like this is actually by design. There’s code in orgSeries-setup.php that excludes the front page from having the Series Meta displayed. So I suggest the following:

Leave %postcontent% as-is, and instead add the following to one’s functions.php:

// Add Series Meta information to posts that belong to a series (for Blog Index/Home).
function add_series_meta($content) {
	if ( is_front_page() && function_exists('wp_seriesmeta_write') ){
		if ($series_meta = wp_seriesmeta_write()) {
			$addcontent = $content;
			$content = str_replace('%postcontent%', $addcontent, $series_meta);
		}
	}
	return $content;
}
add_filter('the_content', 'add_series_meta', 1000);

That should fix things, while leaving the existing functionality alone.
??

I am seeing this issue as well. This can be fixed a few different ways:

a) You can add the following to your index.php:
if(function_exists('wp_seriesmeta_write')){echo str_replace('%postcontent%','',wp_seriesmeta_write());}
The replace is to get rid of the unneeded %postcontent%.

Or

b) You can remove %postcontent% from the “Series Meta” field in the Options, and then add the following to any files where you want the Series Meta to appear (eg, index.php, single.php, etc.):
if(function_exists('wp_seriesmeta_write')){echo wp_seriesmeta_write();}

I’m not sure why it stopped working, and I can’t see anything in the code that indicates an issue. I thought perhaps some filters that I have in my functions.php for the_content and the_content_more_link might be the cause, but removing those (temporarily) didn’t change anything.

I hope the above is helpful!

Yeah, that makes sense (regarding performance)–I would figure that would be the case as file reads can be expensive, but I appreciate hearing your response as there’s always exceptions that I’m not aware of.

Regarding the sorting: Thanks for that! I was aware of that, but I don’t think it would work for how I was meaning (which I wasn’t clear about). In my case I plan to have one IMDB item (eg, movie) per post, and I’ll be adding some non-IMDB tags to each movie (probably in the form of a custom taxonomy). So I think the array sort stuff would only be useful for me if I was getting all of my IMDB movies all in a single plugin call (which I could then sort the results of that array); but I’d then lose the ability to easily add my additional tags to each movie.

Am I perhaps missing something though?

Regardless, like I said earlier, I don’t see it being an issue for a long time as I’m thinking I will just do my sorting and filtering via JS anyway (and only worry about doing it differently when I have so many entries all on one page as to be problematic for performance. My current plan is to just display the movie title (and year) for each, and then load the additional movie details via ajax on clicking the movie title. I can have additional data attached to the movie title element (as either class names or data-attributes) that I should be able to then sort/filter on via JS.
??

Wow, that’s awesome–you jumped on that quickly! ??

I’m curious: since one can’t filter (or sort either, I assume) on the data when it is stored in the get_option() environment, what would be the pros and cons of storing the data in files vs in the database in that way? For example, would there be a performance difference between the two methods? Other differences?

Regardless, thanks for adding this feature! ?? Also, I’m appreciating the improvements to “runtime” as well!

You’re welcome man! ??

Regarding being able to switch between file caching and database caching: That would definitely be cool! Since it seems that you’re interested I’ll add some more thoughts/suggestions about that.

In my case the main advantages to having the data in the database would be then being able to filter and sort off the various values. The fields I’d personally be interested in filtering and/or sorting by are: Title, Year, Runtime and Genres.

I’d also suggest that when adding the db functionality you make any of the array based fields each into a custom taxonomy so that we can work with that data like we would tags/categories. In my case I’m only concerned about Genres, but things like Actors and Directors would be logical fields to make into their own taxonomies as well.

Having said all that, I’m actually pretty content with the current functionality. I can display all my items on one page and then filter and sort via Javascript. It’s really only down the road when the list gets long enough to warrant splitting it into multiple pages that then being able to filter/sort off of database data would be helpful.

Those are my thoughts for the moment. I’ll let you know if I think of anything else! ??

For others’ reference, this problem is solved via the following tickets:
#19772
#18768
[19697]

The fix should be incorporated into a future update to WP.
??

What about adding an option in the back end to turn this on or off? Then those that wish to use it can turn it on and make whatever adjustments they need to for their theme, and those that don’t wish to use it can just turn it off. As long as you give the html of the Edit link some kind of css class or id so that it can be styled this should be pretty workable, I would think.

Plus, it will only be visible for logged in users, correct (just like Edit links for Posts/Pages are only visible to logged in users)?

Yes! Both of these are exactly what I was wanting! Thank you both of you for your hard work. This makes this excellent plugin even better!

??

Thanks for considering it. I worked some more on the Edit link for the Admin Widgets page. It still is not working yet, but perhaps the below will save you some time:

| <a id="<?php echo $this->get_field_id("custom_post_id"); ?>_edit_link" href="<?php echo get_edit_post_link( $currentID ); ?>">Edit Content Block</a><script type="text/javascript">jQuery('#<?php echo $this->get_field_id("custom_post_id"); ?>').change(function(){ jQuery('#<?php echo $this->get_field_id("custom_post_id"); ?>_edit_link').attr('href')=jQuery('#<?php echo $this->get_field_id("custom_post_id"); ?>_edit_link').attr('href').replace(/post=([0-9]+)/, 'post=5'); }); jQuery('#<?php echo $this->get_field_id("custom_post_id"); ?>').change();</script>

The Replace currently just has “post=5” in it for testing purposes, but at the moment that was not working correctly anyway. I can confirm that the Change event is firing correctly, but there is something I’m overlooking somewhere. I was editing this code via the WordPress Admin area (to save time), which is not what I’m used to (I usually use Notepad++) and was a bit harder to work with. I also don’t work with RegEx super often, so I may be misunderstanding something there as well (in the Replace function).

I hope the above helps, and thanks again for this great plugin and for considering my request!
??