It's better to encode the string to prevent possible (yet unknown) bugs in combination with PHP's type juggling.

Previously the boolean statements evaluated to either an empty string (false) or a not empty one (true, then it was 1). Not it always evaluates to false or true.

This also removes a stray - that was not intended there but shouldn't have produced any bugs. Just to increase readability.

Thanks @nickvergessen for spotting.

Addresses https://github.com/owncloud/core/pull/13235/files#r22852319

Allow dropping files on the table container

Make it possible to drop files below the table even if the table is
smaller than the window height.

Added a check to make sure upload is not triggered on invisible lists.

make versions of shared files downloadable

make Share/Download buttons localized again

l10n: delete permanently fix

version up

it seems we have forgotten to use named FileAction

keep spaces out of translation

32-bit typo fix

otherwise translators cannot notice it on Transifex

Don't double encode string

Simplify isValidPath and add unit tests

Verify whether value is already normalized

Use isset() instead of strlen()

Cache results of `normalizePath`

Add CSRF check to search

Apparently `normalizer_normalize` is not verifying itself whether the string needs to be converted or not. Or does it at least not very performantly.

This simple change leads to a 4% performance gain on the processing of normalizeUnicode. Since this method is called quite often (i.e. for every file path) this has actually a measurable impact. For examples searches are now 200ms faster on my machine. Still not perfect but way to go.

Part of https://github.com/owncloud/core/issues/13221

Isset is a native language construct and thus A LOT faster than using strlen()

On my local machine this leads to a 1s performance gain for about 1 million paths. Considering that this function will be called a lot for every file operation this makes a noticable difference.

`normalizePath` is a rather expensive operation and called multiple times for a single path for every file related operation.

In my development installation with about 9GB of data and 60k files this leads to a performance boost of 24% - in seconds that are 1.86s (!) - for simple searches. With more files the impact will be even more noticeable. Obviously this affects every operation that has in any regard something to do with using OC\Files\Filesystem.

Part of https://github.com/owncloud/core/issues/13221

Cache responses from the AppStore server

We already use `.text()` here which automatically properly encodes the string. Thus the string will be double-encoded and look ugly. (i.e. when you search for ">" you will see "No results found for >")

Fixes itself.

The check for invalid paths is actually over-complicated and performed twice resulting in a performance penalty. Additionally, I decided to add unit-tests to that function.

Part of https://github.com/owncloud/core/issues/13221

Doesn't hurt to have a check on this one as well.

Otherwise every time the AppStore was opened a lot of connections to the AppStore server were made which resulted in a terrible performance.

This changeset will cache the response for a sensible time so that only the first request will be somewhat slow.

Performance changes:
- Loading a category took previously more than 3 seconds on my machine. Now for every follow-up request it takes less than 200ms, resulting in a performance gain of 1950%
- Loading the category list took previously about 750ms - now it takes 154ms, a total performance gain of 395%

Encryption fix key lost if group share gets renamed

Fix reshare permission issue

HHVM Workaround: Do not use Exception from Stream.

Use memcache for findBinaryPath

Works around https://github.com/facebook/hhvm/issues/2436#issuecomment-69351373

Add check if user is logged-in