This was considered good practice in the days before always-on https,
but is considered superfluous today. It even gets in the way of IPv6
privacy extensions, which is the main argument for removing them today.
Removes the intermediate confirmation page, instead using JavaScript for confirmation.
Fixes an XSS issue, in that the previous method was not passing or checking the session (!)
`var_dump` was the wrong function to call for objects, as it would just output all object
data to the output buffer... Let's generalise and use `var_export` instead :-)
Thumbnails are normally created on demand, e.g. when processing the format codes in a post's body text.
Normally, the temporary URL is only used once to generate thumbnails ad-hoc. However, when cache is
enabled, a reference to the asset may be used in a cached version of a formatted body text, skipping
the normal thumbnail generation routine.
When an asset is replaced, currently, all thumbnails are removed and references to them are removed
from the database. In case the asset is still referenced in a cached formatted body text, this could lead
to an error when requesting the thumbnail, as the thumbnail request is no longer present in the system.
As we do not know what posts use particular assets at this point in the code, it is best to work around this
issue by unsetting the thumbnail filenames rather than deleting the entries outright. This effectively
generates them again on the next request.
In the future, we should aim to keep track of what posts make use of assets, so cache may be invalidated
in a more targeted way.
