Brian Brown, Ph.D.

Forum Replies Created

Viewing 15 replies - 31 through 45 (of 117 total)

  • You wouldn’t be using Cloudflare, by any chance?
    Cloudflare caches robots.txt and it is, apparently, impossible to control it. I tried creating a robots.php file with a rewrite in .htaccess to robots.txt, and adding no-caching headers to it. I’ve also tried changing the caching with a filesmatch directive in .htaccess all to no avail. And I even have CF set to “respect existing headers” but it doesn’t.
    This is one of the reasons that I’ve about had it with CF.

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Okie Dokie!
    I was able to create a filter to fix the offending issue!
    Thanks, though!
    -Brian

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    I have done some extensive testing of this plugin and I have found that it has issues iterating through the array of domains on the account, leaving the variable $domain empty at times (even with >8M memory available to WP), so I am marking this as a broken plugin.
    Luis: I suggest that you re-work this plugin to use the individual zone (domain) API rather than the global API, then you won’t have the problems walking through an array.
    Regards,
    -Brian Brown

    Hi Z!
    Its a harmess error, just disable WP debug error reporting and/or php error reporting. Its caused by a php version bump up that doesn’t support ‘continue.’
    In the alternative, since this plugin is no longer being maintained/supported, use a file editor or the built-in WP editor and edit:
    seo-ultimate/modules/class.su-module.php line 1195
    from:
    case 'auto-draft': continue; continue;
    to:
    case 'auto-draft': break; break;
    Regards,
    -Brian

    I think this option has some issues.
    Additionally, the URL is stripped of punctuation and other characters, for instance:
    a.php?s=WPSHL
    becomes:
    a-phpswpshl
    after saving options.
    This may be your problem, too!
    Regards,
    Brian
    @brianbrown

    Forum: Plugins
    In reply to: [Farticles] undefined index
    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Thanks!
    -Brian

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Hi Keith!
    Thanks for the quick response!
    FYI This plugin had the exact same issue; perhaps the same solution:
    https://www.ads-software.com/support/topic/causing-404-on-category-tag-pages/
    Thanks again!
    -Brian

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Thanks for the very quick fix Matthias!
    I can also confirm that this plugin v1.2.7 works with WP 5.7-alpha-50001.
    Regards,
    -Brian Brown

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Thanks for the quick response, Mathias!
    Short Answer: It isn’t. Its causing the posts to completely disappear on the category and tags pages.
    It is not generating an error in the debug log.
    It is not a conflict with other plugin(s)/theme(s). It does this regardless of any other plugin activations. As soon as your plugin is deactivated the expected, correct default behavior occurs again.
    It only sends a 404 on the category/tag pages when the category/tag (as set in the permalinks) base is only one (1) letter i.e., ‘example.com/c/‘ instead of ‘example.com/category/‘. If the category/tag base is >1 letter i.e., ‘example.com/cc/‘ it seems to redirect to an actual post, if the Link Fixer plugin is active.
    The browser “remembers” the 301 redirection when the Link Fixer plugin is deactivated.
    The Link Fixer plugin also causes this issue, regardless of whether your plugin is active or not and also acts independently of other plugin activations. Similarly, when the Link Fixer plugin is deactivated the expected default behavior is again restored, regardless of other plugins that are active, including yours.
    So these plugins have some action/hook in common.
    Nothing in the .htaccess file seems to be affecting the issue.
    Thanks!

    -Brian

    WordPress: (5.7-alpha-50001)
    PHP: 7.4.13
    PHP Memory Limit: 9 GB/WP Script 32 GB Total

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    I am calling it like this:

    <div class="headline"><?php
		if (defined('PJNT_VERSION')) {
			$pjshortcode = '[pj-news-ticker show_label="false" label_bg_colour="transparent" ticker_bg_colour="transparent" speed="120"  gap="false" custom_separator="&hellip;&nbsp;" target="_self"';
if(isset($taxonomy->slug)){echo do_shortcode( $pjshortcode.'post_cat="'.$taxonomy->slug.'"]');}
			else {echo do_shortcode( $pjshortcode.'show_label="false" ]' );}}
		else {echo 'WELCOME';}
?></div>

    So, perhaps I will test for an empty taxonomy slug, but, by default, WordPress ALWAYS has at least one category, so this should not be necessary.
    It seems to be okay now, so maybe I was looking at a cached page (I don’t know how, since the cache gets cleared upon any update).
    I guess we can mark this as resolved for now.
    Thanks!
    -Brian

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Hi Paul!
    I’m still seeing this warning on ver. 1.9.2 on an existing install (with >78,000 posts).
    Thanks!
    -B

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Hi Pail!
    This occurs (I replicated it on a fresh install) when there are no posts in the chosen category.
    Its not a big issue, just a warning that I thought I would bring to your attention (and only shows when the debugger is on). Having said that, the ‘There are no matching posts to display’ is correctly output, however. So the logic is correctly identifying that there are no posts.
    Best for the New Year!
    -Brian

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Ah!
    I should have seen that! Thanks again, Paul.
    By the way, I noticed some other issues:
    There is a shortcode for the ‘target’ attribute, but no setting in the admin.
    There is a ‘Show Top Banner’ in the admin, but no shortcode.
    I don’t use those, but I noticed the discrepancy.
    Regards,
    -Brian
    (Mark as resolved.)

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Hi PJ!
    Thanks for the prompt response! I tried the above fix to no avail. I had also previously text-decoration:none !important on various other selectors, even directly on the element, in Firefox’s DOM inspector.
    I have been previously using a different font which has more whitespace at the bottom of the glyphs (see here and are hidden by the bottom horizontal line inbuilt into the theme.
    But this particular site has a different font (“Teletype_1945-1980”), and, as you can see, just shows an underline (and not below the separator, which has its own styling).
    The primary stylesheet is here.
    Thanks!
    -B

    Thread Starter Brian Brown, Ph.D.

    (@brianbrown)

    Thank you!
    I’m very impressed at your responsiveness!
    Thanks!
    Regards!
    @brianbrown
    (Mark as resolved.)

Viewing 15 replies - 31 through 45 (of 117 total)