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.
Bug as reported by Yorick: When two Assets have the same capture
date, a bug occurs in the interface where the user gets stuck in
a loop when moving to the next image.
This patch uses the primary key as a fallback when ordering the
images by capture date. This way, the asset ordering is complete
and it should resolve the bug.
Aaron van Geffen
Amber Sprenkels
Bart Schuurmans