Closed eric-pierce closed 2 years ago
I had a quick glance, I thought that preg_match was running on the $html for some reason it's using the empty $content_type variable. I'll have to give it a deeper look and figure out if that was deliberate or a mistake.
I just ran into the same warning. To me it looks like it wanted to parse the $content_type
not the $html
, otherwise it would not make sense to even return the content-type from get_content()
because that function is only use in this single place, right? Also it was doing the opposite before 70de0d5.
Maybe it should be something like
if ($content_type) {
// Match charset from content_type header
preg_match('/charset=(\S+)/', $content_type, $matches);
if (isset($matches[1]) && !empty($matches[1])) {
$this->charset = str_replace('"', "", html_entity_decode($matches[1]));
Feediron_Logger::get()->log(Feediron_Logger::LOG_TEST, "Matched charset:", $this->charset);
}
}
if (!$this->charset) {
// no encoding from content-type -> attempt to detect encoding of html directly
...
@Boris-de Yes you are correct, it was supposed to try pull the charset from the $content_type
header first then fall back to using the mb_list_encodings
function. Thanks for pointing that out.
Thanks @dugite-code - upgraded my local install and confirming that I see no errors being thrown so far with several hackaday (source that was triggering issues) articles being published. Thanks for the input @Boris-de!
Seeing these errors in console in TTRSS: