The probability of the routine to run is 5% so it should run approximately 5 times
per 100 writes. So the limit 1000 should be pretty safe to prevent the table from bloating.
[MAILPOET-5071]
This commit changes the way that we are passing data from Twig to JS
variables. Before we were using the raw value of the variable which
could be insecure depending on the source of the variable. Malicious
code could be injected in the variable that would result in JS code
being executed in the browser.
Now we are escaping the value of the variable and then parsing it with
JSON.parse(). This should ensure that whatever is the content of the
Twig variable, it is never possible to inject code that is executed by
the browser.
[MAILPOET-5238]
Before this commit, whenever we needed to output HTML from a function
call in a Twig template, we would use the raw filter that allows any
kind of HTML to be outputted.
This commit adds a new filter called wpKses that internally calls
wp_kses(). We can use this filter instead of raw, this way we can define
the list of allowed HTML and the output becomes more secure.
This commit also replaces all the instances where we were using raw.
[MAILPOET-5238]
In this particular template, using raw was not necessary as the HTML
markup encapsulated the full translatable string. So I removed the call
to raw, and added the HTML markup directly to the template.
[MAILPOET-5238]
I found this file as part of the ticket to investigate Twig templates in
the context of the security scan ([MAILPOET-5238]) as it use the `raw`
filter. It seems this file is not used anymore, so instead of fixing the
use of `raw`, I'm removing it.
As far as I can check, we stopped using this view back in 2016, when
this commit f8efb3934b replaced the homepage
with the newsletter page.
Currently there is only one person per week who is supposed to review
dependabot PRs, so it makes the most sense to me to simply skip this
workflow for any dependabot PRs.
I took this solution from here: https://github
.com/flowwer-dev/pull-request-stats/issues/47
#issuecomment-1221583794
MAILPOET-5260
We were running Tracy 2.9.1 and this version was generating warnings
when running PHP 8.2. Example:
```
ErrorException: Creation of dynamic property Tracy\DefaultBarPanel::$time is deprecated in phar:///var/www/html/wp-content/plugins/mailpoet/tools/vendor/tracy.phar/Tracy/Bar/panels/info.tab.phtml:2
```
[MAILPOET-5265]
This commit updates the remove date of the deprecated models
NewsletterOption and NewsletterOptionField. When they were initially
deprecated it was missed that two Newsletter model methods still used
them.
Those two methods are deprecated in this commit as apparently they are
not used anymore in MP's codebase.
[MAILPOET-5252]
In the previous commit, I removed all calls to the deprecated
utf8_encode() that seemed safe to remove. In this commit, I'm replacing
the calls to this function that I'm not sure if are same to remove or
not with mb_convert_encoding().
mb_convert_encoding() requires the extension mbstring to be enabled. It
should be enabled on most PHP install but not all. We are already using
mbstring functions in our code base and we provide a polyfill for PHP
installs where the extension is not enabled
(62bb75ed91/mailpoet/prefixer/composer.json (L25)).
So it should be safe to use it.
[MAILPOET-4865]
This was added in a37ff8d. Per the commit message, php_uname() in a
Windows server can sometimes return the string using encondings other
than ISO-8859-1 and thus utf8_encode() was added. The problem is that
utf8_encode() only converts from ISO-8859-1 to UTF-8 so it does not work
for the purpose that it was added and it was deprecated in PHP 8.2.
Removing it seems safe. If we start having problems with character
encoding in the string that we are sending to Helpscout, we can consider
other alternatives to make sure the string is always send using UTF-8.
[MAILPOET-4865]
