• Troubleshooting
    • Advanced

    @pratyaksh99 did you try it again?

    It’s normal for a solo sub-page URL without its parent to resolve to the correct page. However, there should be a 302 redirect to the proper URL, and the canonical link in meta data should be the same either way. As long as the canonical link is the same, search engines will not penalize you for having duplicate content through multiple URLs. As for why there are nav links one way but not the other, IDK. Since pages are each assigned a specific template (even if the default), the same template is used through either URL, so nav link appearance has something to do with how the template is coded. You could alter the template code so nav links are never used, but it’d be…

    I neet help on this topic Km saini

    I don’t have a specific suggestion, but maybe a user could be granted the capability of importing .ics feeds? I assume only registered users should be able to import, even if they are only a subscriber level user. A roles and capabilities plugin would let you grant any user or role a specific capability. The question would be what capability is the import plugin checking for? It may or may not be a capability you’d be willing to grant to any registered user. If it’s granting too much power, perhaps the import plugin could be modified to check for a custom capability that doesn’t give the user power over anything else.

    Hey Lisa, thanks for the help. I found the pluginfolder and I renamed the folder, but that didnt seem to solve the problem.

    It’s likely something your theme is doing. As a test, try switching to one of the twenty* default themes. If we’re now taken to the right section, it confirms its something about your theme. Try asking through the theme’s dedicated support channel. Perhaps the devs and expert users there could shed more light on the behavior.

    The simplest solution would be to break the content into 2 or more pages. Just insert page breaks at strategic places in the content. I imagine that’s not a very desirable solution. You could try linking to some lesser elements as separate pages. Such as the recipe card, FAQs, comments. You could choose to eliminate the sidebar on this one page. Each one reduces the element count a little, so you likely need to remove several to make a significant difference. Just one page break will likely make a bigger difference. Linking to lesser elements likely involves customizing templates. Breaking the page is just a simple content edit. Or you could choose to ignore the “error”. I’m not sure what the SEO impact would be…

    @bcworkz : But isn’t this why you get 404s? Of course, but what I fail to understand is why things always worked well in the monthly archive. Another thing I wanted to point out is that this has been a Saturday afternoon project: since the plugin was never really used by website users, I completely forgot it and did not update the code. I’ll treasure any suggestion you posted, thanks. 🙂

    when it IS archive, it is NOT category and it is NOT tag, I wanted to display docs But isn’t this why you get 404s? An author or date query IS an archive and not category nor tag. Maybe you should be checking is_author() and ‘is_date()` to get posts? That would be one approach. There might be a better approach. The default is to get posts, so you really needn’t do anything when that’s what you want. Simply return without changing anything. You will need to decide under which conditions you want docs or both. Those will be the exceptions you should target in conditional statements. All of the requests we’re discussing are archive queries, so checking is_archive() doesn’t really serve much purpose. Your’e better…

    @bcworkz : even if this plugin has never been very important and I completely forgot it, I found 5 minutes to make a little test. The origin of the issue is definitely here: if (!is_tag()) { $query->set('post_type', 'docs'); } else { $query->set('post_type', 'post'); } So, when it IS archive, it is NOT category and it is NOT tag, I wanted to display docs. When it IS archive, it is NOT category and it is TAG, I wanted to display posts. Now, where I get my beautiful 404s I have: is_archive, is_date, is_month, is_ssl and is_archive, is_author, is_ssl and the code always falls in the first part of the if, attempting to display docs: when there aren’t docs WP responds with 404. Strangely enough, even if…

    @bcworkz : well, while it’s very uncommon for me and others to click the author’s name at the end of a post, the users generally use the month archive quite a lot (I’m a user too and I never noticed anything strange, for years, not just few days or weeks). My goal with that code was maybe to exclude my custom posts from the results of the date archive, and only have them as search results and in its specific archive (my.domain/docs). There could have been other sub-goals, but I really don’t remember any detail and, even if I generally comment a lot, this time what I left was really poor and didn’t let me fully understand what was the issue I was trying to…

    Your pre_get_posts callback is managing what post types should be queried for various archive queries. Author and date requests are archive queries, but they are neither category nor tag queries, so the post type gets set to “docs”, thus no posts are queried and there were no docs matching the requested date or author. Since there are all sorts of archive queries, using not a tag logic isn’t the best approach as it basically sets a new default state. It’s better to address only the exceptions to default so everything else behaves normally. I don’t wish to be critical, but it may help in your understanding that this callback, on any WP version, would have never worked on any author or date request that’s intended…

    Site Health contains subjective recommendations — no more, no less. If you understand the ramifications, then ignore the ones with which you don’t agree. For example, I have all automatic updates disabled, and Site Health displayed all sorts of “they sky is falling!!!” errors. I also don’t have certain PHP extensions enabled (fileinfo and imagick) that Site Health says I should have have enabled. Well…fileinfo (technically libmagic) is buggy and consumes A LOT of memory, and imagick is a CPU pig under most circumstances. So I’m happy letting WP guess MIME types internally, and since my server has the available memory to make it work well, I’m happy letting GD manage images. Eventually I decided to write a plugin to completely disable Site Health, because…

    The session happens to be open when you check site health. If you’re sure it’s not open when any other API requests are made (they may happen more often than you realize), then there’s no need for concern and the warning can be ignored.