Answers.Body: <p>I got the error on <code>5.43.2</code>. A search for <code>HTMLPurifier_Config</code> in the code turns up nothing.</p>
  <p>When updating CiviCRM via composer make sure to update dependencies as well with:</p>
  <pre><code>composer update civicrm/civicrm-core --with-dependencies
  </code></pre>
  <p>The HTMLPurifier will then be installed this way.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-10T22:53:26.017Z
Answers.Text: That's strange because the above change was definitely 5.44.0 - the file is [in the tree](https://github.com/civicrm/civicrm-packages/blob/5.43.2/IDS/vendors/htmlpurifier/HTMLPurifier/Config.php) in 5.43.2, and then removed in 5.44.0. But yes if you only update civicrm/civicrm-core without specifying dependencies then there can be trouble. The downside to `update with dependencies` is it does different things depending on the environment, so you can end up with versions of libraries you don't want. Maybe that's what happened here and it decided to do 5.44.0? Composer does that sometimes.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-12T18:27:46.790Z
Answers.Text: I ran composer with --update-with-all-dependencies and still got the issue. I'll wait for 5.44.1 before trying again.
Answers.UserDisplayName: Stephen Palmstrom
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-10T18:11:48.420Z
Answers.LastActivityDate: 2021-12-10T18:11:48.420Z
Answers.UserDisplayName: herb
Answers.Body: <p>I experienced this problem today (Drupal 9.3, Civi 5.44).  For me, it was because I had an extension (advimport) that was causing issues.  Even using the latest version, which <a href="https://lab.civicrm.org/extensions/advimport/-/merge_requests/21" rel="nofollow noreferrer">is supposed to work with Civi 5.44</a> and even with it uninstalled, it caused problems.  I'm guessing there's some part of the Composer autoloader that doesn't like the presence of a <code>composer.json</code> that references HTMLPurifier.  In fact, the earlier version of advimport doesn't have this issue.</p>
  <p>To fix this, I rolled back to a pre-Civi 5.44 commit, ran <code>composer install</code>, then moved forward to the commit before advimport.  Even checking out the commit with the latest advimport, without <code>composer install</code>, replicated the bug for me.</p>
  <p><strong>UPDATE</strong>: The problem returned for me, even after removing <code>advimport</code>.  However, restarting Apache/PHP/Redis fixed it for me (I did all three at once, so not sure which one worked).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-27T23:35:39.217Z
Answers.Text: "doesn't like the presence of a composer.json that references..." - that seems odd. Does your checkout include the vendor/composer folder? Since then that might explain at least some weirdness, since the autoloader would then be in a possibly mismatched state.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-27T20:09:48.840Z
Answers.LastActivityDate: 2021-12-28T00:19:03.770Z
Answers.LastEditDate: 2021-12-28T00:19:03.770Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>After upgrading to CiviCRM 5.44.0 under Drupal 9.2.10 under Windows/IIS I got the following error when trying to view a report:</p>
  <pre><code>Error: Class 'HTMLPurifier_Config' not found in CRM_Utils_String::purifyHTML() (line 634 of E:\drupal_test\vendor\civicrm\civicrm-core\CRM\Utils\String.php)
  </code></pre>
  <p>in one CiviCRM instance. I have another instance on another machine where the error did not occur. The 'offending' instance is a test environment but I daren't upgrade the live environment until I have an answer to the problem.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-12-03T20:41:39.347Z
Comments.Text: There was a change made but composer should work it out. I haven't seen a problem myself but it's composer so who knows since it does a different thing in each environment. https://github.com/civicrm/civicrm-packages/pull/334
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-12-06T10:31:31.273Z
Comments.Text: The problem only occurred when upgrading from 5.43.2 to 5.44.0. Is that when the new HTML_Purifier was used?
Comments.UserDisplayName: Stephen Palmstrom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-12-06T10:49:19.100Z
Comments.Text: yes it was 5.44.0
Comments.UserDisplayName: Demerit
Tags: <upgrade><core><drupal-9><5.44.0>
Title: What would cause: Error: Class 'HTMLPurifier_Config' not found in CRM_Utils_String::purifyHTML()?
ThreadText: # What would cause: Error: Class 'HTMLPurifier_Config' not found in CRM_Utils_String::purifyHTML()?
  
  (Asked by: username_0 on 2021-12-03)
  
  After upgrading to CiviCRM 5.44.0 under Drupal 9.2.10 under Windows/IIS I got the following error when trying to view a report:
  
  ```
  Error: Class 'HTMLPurifier_Config' not found in CRM_Utils_String::purifyHTML() (line 634 of E:\drupal_test\vendor\civicrm\civicrm-core\CRM\Utils\String.php)
  
  ```
  
  in one CiviCRM instance. I have another instance on another machine where the error did not occur. The 'offending' instance is a test environment but I daren't upgrade the live environment until I have an answer to the problem.
  
  **Tags:** upgrade, core, drupal-9, 5.44.0
  
  > **Comments:**
  > **username_1**: There was a change made but composer should work it out. I haven't seen a problem myself but it's composer so who knows since it does a different thing in each environment. https://github.com/civicrm/civicrm-packages/pull/334  
  > **username_0**: The problem only occurred when upgrading from 5.43.2 to 5.44.0. Is that when the new HTML_Purifier was used?  
  > **username_1**: yes it was 5.44.0  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-12-10. Score: 0
  
  I got the error on `5.43.2`. A search for `HTMLPurifier_Config` in the code turns up nothing.
  
  When updating CiviCRM via composer make sure to update dependencies as well with:
  
  ```
  composer update civicrm/civicrm-core --with-dependencies
  
  ```
  
  The HTMLPurifier will then be installed this way.
  
  > **Comments:**
  > **username_1**: That's strange because the above change was definitely 5.44.0 - the file is [in the tree](https://github.com/civicrm/civicrm-packages/blob/5.43.2/IDS/vendors/htmlpurifier/HTMLPurifier/Config.php) in 5.43.2, and then removed in 5.44.0. But yes if you only update civicrm/civicrm-core without specifying dependencies then there can be trouble. The downside to `update with dependencies` is it does different things depending on the environment, so you can end up with versions of libraries you don't want. Maybe that's what happened here and it decided to do 5.44.0? Composer does that sometimes.  
  > **username_0**: I ran composer with --update-with-all-dependencies and still got the issue. I'll wait for 5.44.1 before trying again.  
  
  ---
  
  ### Answer by username_3 on 2021-12-27. Score: 0
  
  I experienced this problem today (Drupal 9.3, Civi 5.44). For me, it was because I had an extension (advimport) that was causing issues. Even using the latest version, which [is supposed to work with Civi 5.44](https://lab.civicrm.org/extensions/advimport/-/merge_requests/21) and even with it uninstalled, it caused problems. I'm guessing there's some part of the Composer autoloader that doesn't like the presence of a `composer.json` that references HTMLPurifier. In fact, the earlier version of advimport doesn't have this issue.
  
  To fix this, I rolled back to a pre-Civi 5.44 commit, ran `composer install`, then moved forward to the commit before advimport. Even checking out the commit with the latest advimport, without `composer install`, replicated the bug for me.
  
  **UPDATE**: The problem returned for me, even after removing `advimport`. However, restarting Apache/PHP/Redis fixed it for me (I did all three at once, so not sure which one worked).
  
  > **Comments:**
  > **username_1**: "doesn't like the presence of a composer.json that references..." - that seems odd. Does your checkout include the vendor/composer folder? Since then that might explain at least some weirdness, since the autoloader would then be in a possibly mismatched state.  
  
  ---
  
  