tizz

Hi Chris, thank again for your time.
When writing text I use the normal quotation marks that are always used, the ones that on the keyboard are above the “2” key, and they contain text, not a title tag.
I don’t fully understand what you said about the HTML problem (< a title >, etc.), or maybe in part but I don’t think it has anything to do with it as the quotation marks are in the text, not inside the HTML, where I know that something like " must be used inside an HTML tag to make the quotes, otherwise it will be stripped.

In my site I use a footnotes plugin that creates tooltips when hovering the link of the note number in the text. I have never had issues with HTML markup, and quotation marks in the text are displayed how they should be, see here for example (please hover the mouse over the note no 3).
In the example, however, we are dealing with articles, i.e. text written in the normal WP editor intended for writing posts as articles.

Below, two images of the page in which I am testing (locally) your plugin. As you can see in the first (without any code, the situation that display HTML tags) the quoted text is normally seen, while in the second, with the code that strips the HTML, you see the break before the quotation marks.

https://snipboard.io/h7E9rt.jpg

https://snipboard.io/zDkw5A.jpg

Your last function works fine, but it is not so correct replace quotation marks ” ” with ‘ ‘ and above all there should be no need because quotation marks, like other punctuation marks, should be rendered like they are.
The only thing I can think about is: is it possible that the problem is the WP editor, the one used for the tag descriptions, not really suitable for handling texts in the same way as the normal editor for posts (classic or Gutemberg) does?

Sorry, strip_tags does not keep the inner parts.
Gives the same result as above.

Hi Chris, the new code works perfectly for stripping HTML, thanks! Unfortunately, the issue now is that it removes also all the following words if quotation marks are present; e.g., I have this tag description:

Deep Ellum (distorsione di “deep Elm Street”), and bla bla…

that becomes:

Deep Ellum (distorsione di

Thank you very much @camthor for your prompty reply, but those functions are more or less the same from which I started, taking it from the same thread you reported.
The first two does nothing at all, and does not strip HTML, does not do excerpt / does not remove final number in brackets from the tag description in tooltip.

The third is the same like “mine”, with the only difference of an empty “return”, so it does the same: remove tooltip altogether.

I’m not a programmer at all, but for what I asked it seemed logical to me find in the function / filter at least the words “HTML”, “excerpt”, “tag description”, and so on, otherwise I don’t see how it could work.

As for the shortcode suggestion (my current shortcode looks like this: [tag_groups_tag_list column_count=3]), adding custom_title=”” removes tooltip altogether.
Is there really nothing better to try before keeping it as a downside solution?

@boltonstudios, it works perfectly. Thank you very much!

.post-date {display: none;}

This will remove the date from the page.
Though, the date will remain visible in the page source in the “published updated” HTML tag element.

Solved.

.widget_categories > ul > li a::before, .widget_recent_comments > ul > li::before {content:none;}

Thanks @m00g.
I had already done this a few days ago, deleted both plugins (Gallery and Plus) and reinstalled.
I can’t say if the reported error has been solved, since I don’t see anything strange or new in backend or frontend.

The two big issues that I have with Nextgen are old-aged:
– when I deactivate the plugin some settings are lost
– my server crashes due to excessive consumption of resources e.g. when, after having deleted the image cache for some reasons, the galleries have to rebuild themselves.

Hi @priscillamc
It is incorrect to say the issue with the dashboard widget doesn’t happen on test site. As I said above, then I found that appears sporadically also in local site. Yesterday after all my proceedings the widget count was right, but today is wrong again, in local site.
The only difference now is that in local site sometimes I see it right, while in live site I haven’t seen it right yet since I realized the issue.
Unfortunately I am unable to tell how to replicate the issue more than what I have already written above, so I’m not going to open a thread on GitHub.

In all those tests I did, there is nothing definitive that make me understand why and when the widget is correct (on the local site), and how and why when it isn’t.

Thinking of an involvement with Nextgen, today in the live site I *deleted* the two Nextgen plugins, but nothing has changed about Yoast.

Anyway today I saw one error in the server log concerning Yoast, I don’t know if it has anything to do with it but I report it:

ModSecurity: collections_remove_stale: Failed deleting collection (name “SESSION”, key “18cdc6adf2e30cea0b882310d8829e54”): Internal error [hostname “”] [uri “/wp-content/plugins/wordpress-seo/js/dist/draft-js-1500.js”] [unique_id “X4LaSVnCYDeCs4iP6l6EgQAAAAk”], referer: /wp-admin/index.php?w3tc_note=flush_pgcache

and this:

ModSecurity: collections_remove_stale: Failed deleting collection (name “SESSION”, key “18cdc6adf2e30cea0b882310d8829e54”): Internal error [hostname “”] [uri “/wp-includes/js/clipboard.min.js”] [unique_id “X4LaSSAq6RYLUB4yyANC6wAAAAI”], referer: /wp-admin/index.php?w3tc_note=flush_pgcache

I think it is a conflict with Nextgen Gallery. Sorry in advance for the length, I will try to be as clear as possible but it’s difficult to explain and difficult to reproduce it too.
The issue is not evident simply by activating or deactivating Nextgen (I also have the Nextgen Plus plugin, add-on pro for Nextgen, but it seems irrelevant). To be honest, Yoast and Nextgen have never do very well together.
I did a lot of tests, but only on the local site I’m able to reproduce the issues (yes, there are more than one), without understanding exactly when and why they occur or resolve themselves.

Some anomalies of Nextgen (not that you have to solve them, neither the authors can, I mention them as they seem sporadically related to Yoast):

– When I deactivate the plugin some settings are lost (age-old issue). A strange fact is that yesterday after fixing those settings again, while they returned as they have to be, the dynamic pages obtained with the Nextgen tags (via tag-cloud) instead didn’t work (the images were not outputted and the template wasn’t the right one).
So, just to try, I have updated (saved) the page in SEO > Titles & Metas > Taxonomies (don’t know if it’s the right page name, the one with the image tag scheme [ngg_tag]) and suddenly the related Nextgen page appeared, photos and templates. This didn’t always happen during the other Nextgen deactivations-activations, sometimes the page was right only after updating the permalinks, and / or updating that same Yoast page along with the permalinks.

– I noticed that the Imagely (authors of Nextgen) welcome-widget does not appear in the Dashboard > Home in the production-site. I say this because it is a widget too and on the same page as the one of Yoast with the wrong count on the production-site.

Anomalies of Yoast:

– The overview widget was incorrect even locally today, then fixed after various steps that I will try to summarize below; not the same success on the production-site (maybe because I didn’t do so many tests there being a live site).
– I found out that Yoast’s settings tabs don’t appear as they should. After having saved any of those pages, the tab highlighting disappears so you can’t say which tab you’re in.
Screenshot before update (save), screenshot after having saved the page.
During one of the many tests I saw for a moment how it should be, with the tab highlighted in white on a grey background (not underlined in blue), which remains in the updated page. Still this anomaly is also present locally.

As said, for the overview widget, even in the local site there was the same issue today, even if I remembered having seen it right. In the local site the posts are 190, but today it looked like this (same total as in the production site, 117, addends are different because I didn’t manually optimize any post there), certainly due to the tests made yesterday.
I can’t report every move done to fix it, and some passages seems self-contradictory, but I’m trying to report the important ones.

Only Nextgen e Yoast activated (and Twenty-Ten, but the theme seems irrelevant): plugins screenshot, the issue is not present, widget s.s.: 66+124 = 190
Without touching Nextgen, with other plugins activated: plugins s.s., widget s.s., still OK.
Only Nextgen deactivated and still OK, but when Nextgen is activated again (so, all plugin are activated as before): s.s. widget, the issue is here again: 46+71 = 117.
Sorry for all these screenshots…

I don’t know which move brought back to normal the widget.
I can only say that, not necessarily in this order, I have saved Yoast settings page by page, I have saved those critical Nextgen settings, I have updated the permalinks several times, but only when I re-setted the Nextgen options again (the ones get lost with deactivation), the Yoast widget count has become right again.
I don’t if this makes sense.

Now it doesn’t even seem like a server-related issue to me, as the issue sporadically is present on the local site as well. So, probably a conflict between the two plugins (also Nextgen is used by me since a long time and, although always updated, it has an old “base” [eg, there are still the “legacy” files, for the old users]), maybe some old data / settings conflicting in DB.
At this point I don’t expect anyone to solve these annoying but little issues; this is meant to be just an user experience – however any suggestion is always welcome!

@mazedulislamkhan, thanks.

I have installed that plugin and done as you said, reset and then indexation process (I have tried twice), but unfortunately the issue persists.
Sorry to waste your time on this.

Thanks @priscillamc

Here is the screenshot

@jeroenrotty Thank you very much for your interest.

First I tried to exclude from the firewall those IDs related to the errors I saw yesterday, and a couple of today (one related to xmlrpc, one to wp-json and one I don’t know, the “uri” was only ” / “).
Those errors no longer showed up in the log (on the other hand some warnings appeared, I don’t know how much related), but the output of that widget is still incorrect, even after clearing the browser / site caches, and testing with other clean browsers. I also tried to disable all the plugins, just to exclude some oddity, but nothing.
I don’t know now if I need to re-enable those rules in the firewall for security reasons, it seems the provider gives me freedom in this.

I also tried, as you said, to completely disable the firewall on the server, just for a few minutes doing the usual tests (cleaning caches, different browsers), but nothing has changed. Maybe I need to keep it off for longer?
Does the plugin make a fresh check or call on those numbers in the widget every time the dashboard is opened, or just update the number like, say, every time a new post is published? (As for the change of color, I see that the update is immediate) I haven’t published anything for more than a year.

P.S .: Speaking of xml-rpc – sorry it has nothing to do with the support question – but today I read that it shouldn’t be kept enabled for security reasons, as there is the REST API now. So I disabled it with a filter in functions.php [add_filter (‘xmlrpc_enabled’, ‘__return_false’);], and actually is no longer active by checking with the WordPress XML-RPC Validation Service. I have noticed an immediate positive change in loading speed, in the front-end and especially in the back-end. Is it good to deactivate it?

Thanks. I’ve been using WordPress for many years and I know how to check for conflicts, but I don’t think it’s the case because in the local server site, an exact replica of the production-site, the issue is not present (moreover, for what it worth, the plugins and the theme are always the same).

Maybe I could uninstall Yoast (since I have installed it when it was not yet called so, i.e. very different) and reinstall it, but I must be sure I’m not going to lose anything, specially all data related to every single article and page, otherwise I keep it as it is since it’s not a big issue.

I am inclined to believe it’s a server side error. I asked my provider how to “refresh” it, but I can’t because I’m on a shared server.
I have 7.4 PHP version on the server, is it good for Yoast or being new is not that stable? I don’t remember how it was with the previous versions.
The provider advised me to look at the server logs, and if I find any plugin-related error excluding that rule from the firewall by ID could work. The problem is that I don’t spot anything that clearly has to do with Yoast, I don’t understand error logs so much. Maybe can you shed some light?
The error, at least today, is always one repeated:

Error [client …] ModSecurity: Warning. Operator EQ matched 0 at IP. [file “/etc/httpd/conf/modsecurity.d/rules/comodo_free/30_Apps_OtherApps.conf”] [line “5965”] [id “240335”] [rev “5”] [msg “COMODO WAF: XML-RPC Attack Identified (CVE-2013-0235)|Source 112.198.227.136 (+1 hits since last alert)|www.bluesreviews.it|F|2”] [severity “CRITICAL”] [tag “CWAF”] [tag “OtherApps”] [hostname “www.bluesreviews.it”] [uri “/xmlrpc.php”] [unique_id “…”]

Only one is different:

Error [client …] ModSecurity: Warning. String match “get” at REQUEST_METHOD. [file “/etc/httpd/conf/modsecurity.d/rules/comodo_free/27_Apps_WPPlugin.conf”] [line “4595”] [id “222212”] [rev “2”] [severity “CRITICAL”] [tag “CWAF”] [tag “WPPlugin”] [hostname “…”] [uri “/wp-admin/edit-comments.php”] [unique_id “…”], referer: …/wp-admin/index.php

I see that both are about mod_security but one is for comments.php, and I don’t know what they mean.

Yes, I always update regularly.

P.S.: I’ve turned to green other posts, now the score in the widget is 25 – 92… but the sum is always 117.