Add SHA-512 to list of available hashing algorithms

Can you resolve the coding standards messages at https://www.drupal.org/pift-ci-job/1439666

Your specification of the index in filehash_update_7001() isn't working, maybe it needs an "indexes" key?

There is still one coding standards message left to resolve.

The one downside of this patch is that the table size will be significantly larger.. changing to binary storage of hashes would be a nice future improvement.

Great! Thanks!

If you also have time to work on a Drupal 8 version of the patch, that would be amazing...

Rerolled

Fixes broken addIndex in the update function (it passed in the full schema array rather than just the "filehash" element).

Wrap long line in README file.

Very minor reroll due to README changes.

A while back, PHP added support for the "sha512/256" algorithm.

I wonder if that would meet the needs of this feature request?

Or is full sha512 a requirement for some users?

On the other hand, perhaps we should support dynamic schema specification when algorithms are enabled, and allow anyone to enable whatever hash algorithm they need.

Ok here's an improved patch that makes the rest of the SHA-2 and SHA3 algorithms available, modifying the table schema dynamically via the ConfigEvents::SAVE event.

Unfortunately ended up being a kinda big patch, as the new PHP hash algorithm identifiers are not "safe" alphanumeric strings. So I had to add logic to deal w/ that.

Update module help text and a couple other fixups.

Fix config change logic to handle NULL, e.g. config deleted in Drush.

Ok a bunch more changes needed :p

We need to add new column and index in two separate method calls, to work around SQLite issue (wanting the current state of full filehash schema).

Arbitrary config could theoretically be created, so I added some helper functions to validate the config before passing it in to table alter statements. Also separated the translated strings into their own function so these aren't loaded unless needed.

Views data cache was being invalidated incorrectly.

Use a nicer version of algorithm string for SQL column comment.

Ok turns out we cannot rely on the "original" config when handling config save events - particularly re: config import, which sets the original to NULL for some reason (#2605144: Original configuration is missing during configuration imports).

So revamping all the config state change logic to try to drop any columns that shouldn't be there, and create any columns that should be present but aren't...

Move any column dropping to a separate batch process - as it can be slow on larger databases and isn't really necessary.

(Adding a column should be fast in many cases thanks to "instant add column")

Report the name of the hash algorithm column currently being deleted to batch engine, and start adding some test coverage for new functionality.

Miscellaneous code cleanup. Guess next time I'll use a merge request, but I think this is getting close

Sadly we don't (yet) have a test for content-addressable storage w/ File (Field) Paths module, but I tested with [file:filehash-sha512_256-pair-1]/[file:filehash-sha512_256-pair-2] tokens and appears to work fine.

Cleaning up redundant logic in filehash.tokens.inc that calls hash_file() - I don't think this was ever needed, but certainly shouldn't be needed now.

Tweak strings from "unused" to "disabled". All we really know is they're disabled.

Back to 7.x-1.x for backport

In case of config imported via features, drush, etc. catch PDOException and add missing database column, if required.

Some fixes for duplicate check.

Remove any invalid configuration elements before using in table alter statements.

Fix index name.