Update to PHPMailer 6.6.0 with composer

[Art4]

Changes proposed in this pull request:

• Update PHPMailer from 6.5.1 to 6.6.0 to fix some issues with the charset in mails
• Add the LICENCE and README.md of PHPMailer for legal reason
• This is another proposal (like Use Composer #4319), how the dependencies could be managed by composer to simplify update of 3rd libraries
• Update was made by running

  cd lib
  composer update
  

  and then removing all files we don't need.
• The same could be possible with CssXPath and SimplePie

How to test the feature manually:

I did not test this feature because it is a draft. I want to hear what do you think about this PR and could potentially improve it even further.

Pull request checklist:

• clear commit messages
• code manually tested
• unit tests written (optional if too hard)
• documentation updated

Additional information can be found in the documentation.

[Alkarex]

Hello, and thanks for the PR.
The Composer part is trivial and therefore not so interesting, but the important parts are the following when updating a library: A contributor should confirm to have:

• read the changelog of the library (reporting anything interesting for our use)
• checked all the lines of the diff
• tested with the updated library that FreshRSS still works as intended

Except for my comments, it could be a fine approach.

[Art4]

Hello, and thanks for the PR. The Composer part is trivial and therefore not so interesting, but the important parts are the following when updating a library: A contributor should confirm to have:

• read the changelog of the library (reporting anything interesting for our use)

The Changelog for PHPMailer could be found here: https://github.com/PHPMailer/PHPMailer/blob/v6.6.0/changelog.md

The most important changes are:

• Add more contextual information to TLS connection failure error messages, and throw exceptions on TLS connection errors
• Fix bug in use of CharSet property

All chages could also be found here:

PHPMailer Change Log

Version 6.6 (February 28th, 2022)

• Introduce interface for OAuth providers, making it easier to use OAuth libraries other than the League one, thanks to @pdscopes.
• Add more contextual information to TLS connection failure error messages, and throw exceptions on TLS connection errors, thanks to @miken32

Version 6.5.4 (February 17th, 2022)

• If we can't use escaping functions, refuse to do unsafe things
• Avoid PHP 8.1 trim issue
• Add tests for XMailer
• Fix bug in use of CharSet property
• Fix bug in file upload example
• Update dev dependencies

Version 6.5.3 (November 25th, 2021)

• Wrong commit tagged for the 6.5.2 release!
• Version file updated

Version 6.5.2 (November 25th, 2021)

• Enable official support for PHP 8.1
• Enable experimental support for PHP 8.2
• Fix for PHP 5.6
• Fix for incorrect options for punyencoding IDNs

• checked all the lines of the diff

To be done.

• tested with the updated library that FreshRSS still works as intended

I'm not a user of FreshRSS and could not test it. But the changes are relative trivial.

[Art4]

@Alkarex If you say that this use of Composer is fine for FreshRSS, then I will be happy to improve and finalize this PR. After that I would try the same for SimplePie.

My goal is to make SimplePie easier to update, so that the fork of SimplePie is no longer necessary, or implemented via extending the original classes. This should make FreshRSS ready for the upcoming massive changes of SimplePie 1.6+ (see simplepie/simplepie#722).

[Alkarex]

@Art4 I think using Composer as an optional way to update the libraries would indeed be fine, as long as it does not cause burden on the execution code (e.g. more complex/slower autoloader). Regarding SimplePie, I believe we will want to keep the ability to ship customised versions anyway, especially when waiting for upstream PRs to be merged, or when upstream PRs are not accepted

[Art4]

I think using Composer as an optional way to update the libraries would indeed be fine, as long as it does not cause burden on the execution code (e.g. more complex/slower autoloader).

Of course, manual updating without Composer will still be possible. I don't know exactly how the update process for a library works so far. I guess that the code is downloaded manually as zip and then the corresponding files are replaced?

With that in mind, preserving the composer.lock doesn't make sense because if a manual update is done in the future, the composer.lock will be obsolete. Therefore I will delete the file.

Regarding SimplePie, I believe we will want to keep the ability to ship customised versions anyway, especially when waiting for upstream PRs to be merged, or when upstream PRs are not accepted

This is understandable. My suggestion would be to leave the libraries in the lib folder in their original state if possible. Instead make the changes in a wrapper class which should be in the app folder. SimplePie also allows you to inject your own classes using the SimplePie\Registry class.

But we could clarify the details later in a corresponding PR.

[Alkarex]

Of course, manual updating without Composer will still be possible. I don't know exactly how the update process for a library works so far. I guess that the code is downloaded manually as zip and then the corresponding files are replaced?

With that in mind, preserving the composer.lock doesn't make sense because if a manual update is done in the future, the composer.lock will be obsolete. Therefore I will delete the file.

Correct. Personally, I have a git clone of the libraries we use, and update them via a diff. In the case of SimplePie, which contains more changes, I cherry pick the latest commits.

[Art4]

I removed the lib/composer.lock file. I also fixed and improved the autoloader. Since I could not run all tests successfully, but still wanted to test if PHPMailer can be loaded correctly, I simply created a new test about the existence of the PHPMailer class.

Update: I also pinned the version of PHPMailer to 6.6.0 because the composer.lock file is no longer there. Therefore, for a possible update of PHPMailer using Composer, the version in lib/composer.json must be adjusted first.

[Art4]

@Alkarex Is there anything else to improve about this PR? I would like to start with the next one, but would like to build on this PR.

[Art4]

The build failed because of the markdown linting in lib/phpmailer. Should we remove the markdown linting for 3rd party libraries?

[Alkarex]

@Art4 Looks good, thanks 👍🏻
But did you do some more changes by hand? When I run composer update, I also get additional 58 files such as https://github.com/PHPMailer/PHPMailer/tree/master/language (not necessarily bad if we actually use them, but I have not checked)

$ composer update
$ git status
On branch update-phpmailer-with-composer
Your branch is up to date with 'Art4/update-phpmailer-with-composer'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        lib/phpmailer/phpmailer/COMMITMENT
        lib/phpmailer/phpmailer/SECURITY.md
        lib/phpmailer/phpmailer/composer.json
        lib/phpmailer/phpmailer/get_oauth_token.php
        lib/phpmailer/phpmailer/language/
        lib/phpmailer/phpmailer/src/OAuth.php
        lib/phpmailer/phpmailer/src/POP3.php

[Art4]

@Alkarex As I mentioned in the PR description I removed files we don't need to keep the changes clear.

• Update was made by running

  cd lib
  composer update
  

and then removing all files we don't need.

But it would be easier for update to keep all files.

[Alkarex]

@Art4 Thanks for the efforts. Please add a line for you in https://github.com/FreshRSS/FreshRSS/blob/edge/CREDITS.md