Add an ASCII export option

Can you paste a sample report format you would be looking to have?

The module is a UI on top of https://github.com/mglaman/drupal-check, which has this exact output by default you are requesting. If you are interested primarily in a CLI interface and that output, then you probably don't need the module :)

That said if this is superior to the HTML output and we can assume that everyone using the module wants this ASCII limited output for single and full site exports, then we should change our HTML output to be this instead. We can at least do away with our duplicated CSS in the single and full output templates (and even the templates themselves really).

Changed title based on suggested change.

The main reason we went with HTML exports is that there are links in the generated text, and that makes them easy to click directly from the web interface. I don't have any problem with an HTML/ASCII selector, but I think making them only ASCII makes the output less usable, as you now need to select + copy + paste to get the same info.

If there's a need to add another export format, we can modify the current occurrence of the export to mention the format as well (something like "Export HTML" ?). We can also extend the operations for each project row with an extra link which will do the export in the desirable easy to copy format (something like "Export ASCII" ?) and place an extra button on the project report modal popup with the same title. Also modifications needed in constructing the current report, maybe adding a way to select the formatting mode. For example "formatted" and "plain", but we can think it through to make it a bit more extendable, in case somebody will need another format besides HTML or ASCII.
What do you think about the above? The button titles and changes on the report constructor are just suggestions.

If the links are all we care about for HTML then we can output in a HTML page in <pre> or <code> and still inline the links as HTML. Then you can copy paste it (loosing the links) or use it as HTML (click links). I am not fond of adding a lot more UI weight for various more output formats if we can get the best of both worlds.

I understand the copy-pasting for custom projects (to your own internal issue tracker), but for contrib modules, an issue could very well already exist, you may not be running the latest version, stuff may be fixed in dev, etc. So searching the queue first and figuring out how to engage with the maintainer is better. We do have plans to guide users of this module in that interaction. See #3053948: Guide users on how to best engage with a contrib project maintainer.

@gábor here is what I have so far on the ASCII export option. I feel there are two things left to make this a complete feature;

1. Export a .txt file instead of HTML file: I'm still using a twig template file to generate the export. I think we said a simple .txt file would be the right file format here.
2. Issue with links: They are there, but they are not particularly useful as it is difficult to copy paste URL that span multiple lines. See example screenshot.

The patch seems to have been done reversibly (wrong direction, thus no diff here). Attached patch fixes that, and adds dynamic export file extension.

Removed phpstan/phpstan version downgrade (mistake assumed), and html tags from the ascii export file twig template - seems to be cleaner this way.

I don't have enough composer fu (or time ATM) to figure out how to make a locally updated composer.json function when composer attempts to update the project either way. So I committed just the dependency update as a start to make it easier to test the rest.

@rpsu: you forgot to attach the twig file.

- Restored the twig ASCII template.
- Refactored the form integration a bit.
- Added security filtering to the single export format argument.
- Simplified the ASCII output format, more whitespace less lines.

Still definitely needs work in terms of the table structure and how the ASCII itself gets generated, because it has some duplicate code still.

Removed link generation from ASCII tables, I think its distracting.
Fixed test text looking for export button labels, so those should pass again.
Moved to per file tables instead of one table per project, this makes results a LOT more readable, like this:

--------------------------------------------------------------------------------
Upgrade Status 8.x-1.0-beta2+3-dev
Scanned on Thu, 08/08/2019 - 11:17.

2 errors found. 3 warnings found. Items categorized "Fix now" are uses of
deprecated APIs from community unsupported core versions.

See #3056118: Keep Upgrade Status itself Drupal 9 compatible other than testing
code

modules/contrib/upgrade_status/src/DeprecationAnalyser.php:
┌────────┬──────┬────────────────────────────────────────────────────────────┐
│ STATUS │ LINE │                          MESSAGE                           │
├────────┼──────┼────────────────────────────────────────────────────────────┤
│ Fix    │ 366  │ Call to deprecated function file_prepare_directory().      │
│ later  │      │ Deprecated in Drupal 8.7.0, will be removed before Drupal  │
│        │      │ 9.0.0. Use                                                 │
│        │      │ \Drupal\Core\File\FileSystemInterface::prepareDirectory(). │
│        │      │                                                            │
│ Fix    │ 374  │ Call to deprecated function file_prepare_directory().      │
│ later  │      │ Deprecated in Drupal 8.7.0, will be removed before Drupal  │
│        │      │ 9.0.0. Use                                                 │
│        │      │ \Drupal\Core\File\FileSystemInterface::prepareDirectory(). │
│        │      │                                                            │
└────────┴──────┴────────────────────────────────────────────────────────────┘

modules/contrib/upgrade_status/tests/modules/upgrade_status_test_contrib_error/s
rc/Controller/UpgradeStatusTestContribErrorController.php:
┌─────────┬──────┬────────────────────────────────────────────────────────────┐
│ STATUS  │ LINE │                          MESSAGE                           │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ Fix now │ 15   │ Call to deprecated function format_string(). Deprecated in │
│         │      │ Drupal 8.0.0, will be removed before Drupal 9.0.0. Use     │
│         │      │ \Drupal\Component\Render\FormattableMarkup.                │
│         │      │                                                            │
└─────────┴──────┴────────────────────────────────────────────────────────────┘

modules/contrib/upgrade_status/tests/modules/upgrade_status_test_error/fatal.php:
┌──────────┬──────┬─────────────────────────────────────────────┐
│  STATUS  │ LINE │                   MESSAGE                   │
├──────────┼──────┼─────────────────────────────────────────────┤
│ Check    │ 3    │ Syntax error, unexpected T_STRING on line 3 │
│ manually │      │                                             │
└──────────┴──────┴─────────────────────────────────────────────┘

modules/contrib/upgrade_status/tests/modules/upgrade_status_test_error/src/Contr
oller/UpgradeStatusTestErrorController.php:
┌─────────┬──────┬─────────────────────────────────────────────────────────────┐
│ STATUS  │ LINE │                           MESSAGE                           │
├─────────┼──────┼─────────────────────────────────────────────────────────────┤
│ Fix now │ 10   │ Call to deprecated function menu_cache_clear_all().         │
│         │      │ Deprecated in Drupal 8.6.0, will be removed before Drupal   │
│         │      │ 9.0.0. Use \Drupal::cache('menu')->invalidateAll() instead. │
│         │      │                                                             │
└─────────┴──────┴─────────────────────────────────────────────────────────────┘

I tried making tables fixed width but the library did not allow to do so. Although given how much we are doing ourselves now, not sure how much is left for the library to do really. Anyway, keeping that for now.

Fix the custom/contrib project labels.

Add its own test coverage.

All right, put this in, thanks both for your help :)