Title: grapepress's Replies | WordPress.org

---

# grapepress

  [  ](https://wordpress.org/support/users/grapepress/)

 *   [Profile](https://wordpress.org/support/users/grapepress/)
 *   [Topics Started](https://wordpress.org/support/users/grapepress/topics/)
 *   [Replies Created](https://wordpress.org/support/users/grapepress/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/grapepress/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/grapepress/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/grapepress/engagements/)
 *   [Favorites](https://wordpress.org/support/users/grapepress/favorites/)

 Search replies:

## Forum Replies Created

Viewing 15 replies - 1 through 15 (of 28 total)

1 [2](https://wordpress.org/support/users/grapepress/replies/page/2/?output_format=md)
[→](https://wordpress.org/support/users/grapepress/replies/page/2/?output_format=md)

 *   Forum: [Themes and Templates](https://wordpress.org/support/forum/themes-and-templates/)
   
   In reply to: [[Block Lite] JS That Detects/Sets Light vs Dark Header Colors Makes Wrong Choice Sometimes](https://wordpress.org/support/topic/js-that-detects-sets-light-vs-dark-header-colors-makes-wrong-choice-sometimes/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [5 years, 3 months ago](https://wordpress.org/support/topic/js-that-detects-sets-light-vs-dark-header-colors-makes-wrong-choice-sometimes/#post-13863083)
 * 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.
 *   Forum: [Themes and Templates](https://wordpress.org/support/forum/themes-and-templates/)
   
   In reply to: [[Block Lite] JS That Detects/Sets Light vs Dark Header Colors Makes Wrong Choice Sometimes](https://wordpress.org/support/topic/js-that-detects-sets-light-vs-dark-header-colors-makes-wrong-choice-sometimes/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [5 years, 3 months ago](https://wordpress.org/support/topic/js-that-detects-sets-light-vs-dark-header-colors-makes-wrong-choice-sometimes/#post-13859414)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] Grabbing thumbnail url with raw code](https://wordpress.org/support/topic/grabbing-thumbnail-url-with-raw-code/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/grabbing-thumbnail-url-with-raw-code/#post-6688135)
 * 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).
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Fast Secure Contact Form] Google's new recaptcha Iam not a robot](https://wordpress.org/support/topic/googles-new-recaptcha-iam-not-a-robot/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/googles-new-recaptcha-iam-not-a-robot/#post-5549072)
 * Yeah, I’ll be curious to hear if Mike has interest in integrating this.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Fast Secure Contact Form] Google's new recaptcha Iam not a robot](https://wordpress.org/support/topic/googles-new-recaptcha-iam-not-a-robot/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/googles-new-recaptcha-iam-not-a-robot/#post-5549057)
 * [@topkai](https://wordpress.org/support/users/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.
    [http://thehackernews.com/2014/12/Google-reCAPTCHA-code-in-PHP.html](http://thehackernews.com/2014/12/Google-reCAPTCHA-code-in-PHP.html)
   [https://developers.google.com/recaptcha/](https://developers.google.com/recaptcha/)
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[VideoPress] VideoPress on Hosted SSL Site](https://wordpress.org/support/topic/videopress-on-hosted-ssl-site/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/videopress-on-hosted-ssl-site/#post-5239033)
 * 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](https://github.com/Automattic/jetpack/issues/124)
 * Edit: Nevermind. Just saw that you posted there already ([https://github.com/Automattic/jetpack/issues/1072](https://github.com/Automattic/jetpack/issues/1072)).
   🙂
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Issues and Series for Newspapers, Magazines, Publishers, Writers] series meta display options](https://wordpress.org/support/topic/series-meta-display-options/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/series-meta-display-options/#post-4307508)
 * 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.
    🙂
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Issues and Series for Newspapers, Magazines, Publishers, Writers] series meta display options](https://wordpress.org/support/topic/series-meta-display-options/)
 *  [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/series-meta-display-options/#post-4307507)
 * 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!
 *   Forum: [Reviews](https://wordpress.org/support/forum/reviews/)
    In reply to:
   [[IMDb Connector] Excellent!](https://wordpress.org/support/topic/excellent-1721/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/excellent-1721/#post-7891883)
 * 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.
    🙂
 *   Forum: [Reviews](https://wordpress.org/support/forum/reviews/)
    In reply to:
   [[IMDb Connector] Excellent!](https://wordpress.org/support/topic/excellent-1721/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/excellent-1721/#post-7891880)
 * 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!
 *   Forum: [Reviews](https://wordpress.org/support/forum/reviews/)
    In reply to:
   [[IMDb Connector] Excellent!](https://wordpress.org/support/topic/excellent-1721/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/excellent-1721/#post-7891863)
 * 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! 🙂
 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [Nested install writes htaccess to root instead of install base](https://wordpress.org/support/topic/nested-install-writes-htaccess-to-root-instead-of-install-base/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [14 years, 3 months ago](https://wordpress.org/support/topic/nested-install-writes-htaccess-to-root-instead-of-install-base/#post-2480186)
 * For others’ reference, this problem is solved via the following tickets:
    [#19772](http://core.trac.wordpress.org/ticket/19772)
   [#18768](http://core.trac.wordpress.org/ticket/18768) [[19697]](http://core.trac.wordpress.org/changeset/19697)
 * The fix should be incorporated into a future update to WP.
    🙂
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Content Blocks (Custom Post Widget)] [Plugin: Custom Post Widget] Feature Suggestion: Easy Edit Links](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/#post-2204623)
 * 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)?
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Content Blocks (Custom Post Widget)] [Plugin: Custom Post Widget] Feature Suggestion: Easy Edit Links](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/#post-2204619)
 * 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!
 * 🙂
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Content Blocks (Custom Post Widget)] [Plugin: Custom Post Widget] Feature Suggestion: Easy Edit Links](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/)
 *  Thread Starter [grapepress](https://wordpress.org/support/users/grapepress/)
 * (@grapepress)
 * [14 years, 9 months ago](https://wordpress.org/support/topic/plugin-custom-post-widget-feature-suggestion-easy-edit-links/#post-2204439)
 * 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!
    🙂

Viewing 15 replies - 1 through 15 (of 28 total)

1 [2](https://wordpress.org/support/users/grapepress/replies/page/2/?output_format=md)
[→](https://wordpress.org/support/users/grapepress/replies/page/2/?output_format=md)