Forum Replies Created

Viewing 15 replies - 1 through 15 (of 18 total)
  • Interesting. I don’t actually use the main site, but of course it exists. I went there and found the plugin but it was not activated (this appears to be treated out of network).

    After activation, the network sites showed Anti-Spam was active, but “SERVER ERROR NO: 3 MSG: Access key unset”. All red “X” in the settings. Clicking “refresh” (sometimes more than once) fixed it, for each child site.

    I didn’t actually need to click “Allow users to use another key” (and didn’t want to use different keys).

    Thank you for the fast reply and helpful support!


    Thanks for the ultra-fast reply Ben!

    On #1, when I go to Settings -> Kadence Blocks -> Advanced Button (settings) the various color defaults offer a color selector but not any of my theme colors. Whereas, when I actually use the button on a page my theme colors are available for selection. Is this just me (my environment is not vanilla)?

    On #2 and #3, super!

    Thank you for your work and for sharing this.

    Hi @renzms,

    I have since uninstalled the plugin, but the warning messages should be apparent by (1) use PHP 7.2 and (2) enable debugging (in wp-config.php define WP_DEBUG as true).


    Thanks wpress2010. Patching is problematic unless you fork or have some other means of handling it.

    In this case, which is a hack and could stop working for a variety of reasons, loss of the patch would just stop randomizing the gallery until the patch is reapplied.

    For my own environment, I wrote something I call autopatch which reapplies any patches automatically when plugins are updated (and notifies me if there are any issues). I use this only when there is no other supported means of accomplishing the same thing. Even then, I try to limit my patches to additional hooks wherever possible (as in this case).

    Thanks for the reply!

    I would hate to see a performance penalty for choosing random. While my current example is a temporary hack, the approach is good per se and benefits from the cache.

    Consider changing from an HTML cache to a “gallery cache”, keeping all the info in some structured format (JSON is trivial to do in PHP). Generate the HTML from that when it is retrieved.

    This would be as fast as the current method, could easily support random order by the plugin, provide a useful filter point and improve site portability.

    On that last point, I have a setup where I move sites between development and production. I had to extend it to delete foogallery_cache metakeys from postmeta (which of course is then recreated) in order for it to work automatically. The “gallery cache” approach could fix this small issue too.

    The problem appears to be a design flaw. Fully formed gallery HTML is cached in postmeta (“foogallery_cache” meta_keys). There is no filter to intercept it. Full URLs are embedded which is an annoyance for site portability (just click update on the gallery to recreate).

    IMHO only thumbnail data with relative paths should be saved in an easily parsed format with a filter hook.

    For now, I am patching the plugin to add a filter hook in class-foogallery-cache.php changing:

    echo $gallery_cache;
    echo apply_filters( 'foogallery_meta_cache', $gallery_cache );

    Then using it (e.g. in functions.php):

    add_filter('foogallery_meta_cache', function($cache) {
    	$lines = preg_replace(
    		['@(\r|\n|\\\\r|\\\\n|\\\\t)@', '@(<a|</div)@', '@https?://[^/]*@'],
    		['', "\n$1", ''], $cache);
    	$thumbs = preg_grep('/<a/', preg_split("/\n/", $lines));
    	return preg_replace('/(<div[^>]*>).*/s', "\n\n$1", $cache) .
    		implode("\n", $thumbs) . "\n</div>\n";

    I have been looking for this too. There appears to be no way to randomly sort thumbnails upon each page load. I have searched Google, looked at filters, checked for extensions, etc. This seems basic so I must have missed it.

    Sorting randomly on the gallery edit page is a 1 time thing and not at all what I want. Randomly ordering on each page load keeps a gallery fresh for visitors.

    0.9.5 breaks my site too on Centos 7 with Webmin/Virtualmin. My error message:

    mod_fcgid: stderr: PHP Fatal error: require(): Failed opening required ‘/home/sitename/public_html/wp-content/plugins/w3-total-cache/lib/Google/Photo/Access.php’ (include_path=’.:/usr/share/pear:/usr/share/php’) in /home/sitename/public_html/wp-content/plugins/w3-total-cache/w3-total-cache-api.php on line 143

    Same here on all my sites using it.

    I am using the Pro version (bought yesterday).

    Thanks for the explanation.

    OK, thanks.

    I’ve found the list of hooks for 2.x at but am unsure which of the older hooks I can safely depend on. Some are marked legacy in the code so that makes me cautious to use them (and also am unsure if they are even used in the newer shortcodes). I couldn’t find a comprehensive, up-to-date list.

    I have found in the code (in addition to the 2.x, cmb2 and puc stuff):


    It would be most helpful if the 2.x list was expanded to include both new and prior shortcodes that will be maintained going forward.

    BTW – I have used other testimonial plugins in the past and tested about a dozen this time. I like yours because it is cleanly implemented, has all the features I need without fluff and produces attractive output. Well done! Also, FWIW, I avoid commercial plugins for a lot of reasons but your pricing for a quality plugin and developer friendly license makes this an easy purchase. It also makes me interested in your other stuff…


    3.0.2 works out-of-the-box for me. Thanks Nick.


    Thanks MortimerMcMire315, that worked for me.

    I had found a quick CSS hack that I was not happy with. FWIW, it was:

    .simcal-week-day-0 { display: none; }

    Which had the effect of killing the first label and shifting the remaining left one column (Sat went unlabeled). Your fix is much better. Now I just have to monitor for when the plugin is actually fixed and until then keep reapplying yours.


    Still broke for me in 3.0.1.

    The Google calendar is set with Sunday as the first day. My WP General Settings make Sunday the first day. My Simple Calendar settings leave the setting to default (Sunday).

    The grid displays correctly, but the column headings are wrong with the first column listed as Saturday.

    This is not a converted calendar (I deleted those after 3.0.1 brought them back), but rather is a NEW calendar created (under 3.0.0 but now on 3.0.1).

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