tizz

@stevejburge Thank you very much

@sdobreff Thank you so much!

Thanks for your attention

Thank you

The notice is repeated several times, but it is always the same:

PHP Deprecated: Creation of dynamic property swas_wp_footnotes::$styles is deprecated in /var/www/vhosts/bluesreviews.it/httpdocs/wp-content/plugins/footnotes-made-easy/footnotes-made-easy.php on line 40

Now that the 503 is gone, I can confirm that everything works fine, backend and frontend, without visible errors. Actually, I think that the issue has been there for some time but I saw it only yesterday because I turned on debug file while I had the 503 error.

I see. Even though I’m not too familiar with php I can still try to fix that line myself, maybe with some external help, assuming it’s the only problem. Unless you think the difference between php 8 and 7 is too big and doing this would just break the plugin further.

8.2.9

Oh yes, you’re right. Thanks.

The descriptions I edited yesterday still have all my HTML in place today. I forgot to ask if now I need to delete the function in functions.php.
Thanks.

Thank you Chris, so I just updated the plugin, and I don’t have to do anything else, right? (Other than redo what has been lost I mean…)
I don’t have to insert that define and put “false”, right?

OK, I see that it is the Yoast SEO plugin that modifies the default behavior, creating a visual view in the tag description editor and allowing the insertion of HTML. Switching from one view to the other nothing is lost, as it has never been lost in time or deactivating the plugin. It has never been a problem and still is, so much that I had forgotten that it was not the default behavior. I mean that it has always worked well and I would have continued to lose nothing – except for an unlikely plugin bug on that particular aspect, which is not happened. So, Yoast is definitely responsible for that “rich” editor, but I have no doubts that it is not the culprit about the sudden loss of those formatting.

I know that it can be difficult to focus a case like mine, and that you probably won’t have others like mine because there are very few users who use the tag description field as I do, but maybe something has happened when I installed and activated your plugin as the remove / keep option was “remove” by default, or I saved it like this because it was the recommended one. Then, starting to assign some tags for testing, I changed that setting several times during the attempts to adjust the behaviors described in the reported topics. Only at the end it remained on “keep” as per your indication due to the coexistence with the function you kindly provided.

Perhaps during one of the switches of that settings the HTML formatting was lost: on some descriptions by removing all the formatting altogether, on others only the “target_blank”, maybe depending on how the situation was when I assigned that particular tag.
If you say that the various functions not stripped the HTML in the descriptions I believe you, but sure something else related to the plugin or its settings has did it, because that formatting was lost after the plugin activation and use even if I can’t say when or how, perhaps while proceeding with the tests and with the assignment of the tags at different times. In other words, it is sure that from a certain point on and even now I always had “keep”, but before there was also “remove” and something happened.

I don’t have any other new plugin and no other new code, my plugin list has been the same for years until now and I have never lost the HTML formatting in those tag descriptions before.
As already mentioned, the HTML formatting seems to remain if I do redo and save now, the loss has occurred before, maybe now it is stable, and here I return to the previous question.
If, as you said in the other topic, you will change the code and I will remove that function and put “remove” in the settings as per your indication, do I might lose the formatting again? Because if I start putting them back in place as they were I wouldn’t want to lose my work again.
I know it’s a difficult question to answer and you can’t be sure of that, but my fear is right here.

Fantastic! It works like a charm. Thanks again Chris.

Thanks again.

Hi Chris, the option works fine.

As for the excerpt, if you have any ideas/suggestion and this don’t bother you too much I would be happy to know at any time.

Thank you.

OK thanks, I understand now what you mean, but anyway I don’t understand why elsewhere, i.e. in the tooltips of the footnotes, the normal quotes on the keyboard in that HTML are automatically converted into the other type of quotes, let’s say RTF, so to avoid conflict, while here, in the tooltips of the tag descriptions, it does not happen… unless you have a function like the one you kindly provided me (same thing I could say for the visible HTML: in the tooltips of the footnotes does not happen).
So I thought it was because of the non-advanced WordPress editor where the tag description is written.

I don’t want anything complicated, but rather the exact opposite: just that what I write is printed as it is, and I didn’t know that there in the function I had/could replace with “: it isn’t a character on visible keyboard keys.